Re: Mixing OO and DB
Date: Sun, 17 Feb 2008 13:06:05 +0100
Message-ID: <2yeot0n753e1$.1tnllqoy7dkx3.dlg_at_40tude.net>
On Sat, 16 Feb 2008 22:05:54 +0100, mAsterdam wrote:
>>>>>> Anyway it would be not "I want data, else there is no >>>>>> common ground." It would be about the structure of the formal system which >>>>>> you wished deploy for what you call data. (Maybe, I could to do it as well, >>>>>> but for something having a different name.) >>>>> If that what it takes to get rid of the scarequotes, I have no >>>>> problem with you calling it something else if there are enough >>>>> common associations and isomorphisms - and no blocks. >>>>> Do you have a name in mind? Blurk sucks. >>>> Inputs? >>> No, that won't work. Inputs do not need to be meaningful (have >>> values/symbols associated with informal denotations) in order to be >>> acceptable to processes. Good enough for IPO, not for IDO. >> >> But why do you insist of meaningfulness? Even informally we deal with a lot >> of conditionals, uncertain and contradictory facts. Can't you live with >> "let the input X be meaningful"?
>
> It is to coarse.
>
> Many bugs are due to subtle (and sometimes not so subtle)
> differences in interpretation. The denotation should be explicit.
> IMO common understanding of ("township approved"?) external
> predicates leads to better software. If the system designers
> do not share understanding of the data - who is going to
> understand at all?
>
> Still, protection of the data is another matter.
> Rejection of inconsistencies: bug or feature?
>
> As a bug:
> Anything goes - but I would not call that data-centric (IDO).
>
> As a feature (i.e. data as an asset, as in most ventures):
> How about "let the input X be meaningful and consistent with current
> data"? The consistency part can be delegated to the DBMS
> as far as we can give it rules about what to consider consistent:
> constraints in the schema.
There exist DB based on intuitionistic fuzzy and other logics which can express and handle contradictions. But this is different from an input X being meaningless. No formal system can detect it in the sense that it will yield some output Y meaningful or not. If a system has to handle contradiction (as in intuitionistic logic), then these contradictions and uncertainties have measures and these are a *part* of the input. Same with physical values, you get an interval instead of a value or a mean plus sigma etc. There is no other way.
> A dedicated datacapture process needs to be
> aware of the schema, and eventually of the current data.
> Rendering also benefits from schema awareness.
Oh, that's simple. The process yields the value of given type. That's all it need to care. If an integer number range 1..35 is expected, then it is illegal to return 100 or string. Contract is only meaning.
>>>>>>>>>> Yes, we cannot reason about meaning while staying >>>>>>>>>> within the same formal system. Because you seem >>>>>>>>>> to bind data with a meaning (as I do), that immediately >>>>>>>>>> kicks the notion of data out of the formal system.
>
> (retry) Indeed. However, we can have a shared, formal proxy to
> meaning. Date's external predicates are a good starting point
> for that.
See above. IMO it the responsibility of a type system to make it possible to express constraints (when new types are obtained by constraining). This is not the only way though, you need also other operations in types algebra.
-- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.deReceived on Sun Feb 17 2008 - 13:06:05 CET