Re: Mixing OO and DB

Dmitry A. Kazakov wrote:
> mAsterdam wrote:

>> Dmitry A. Kazakov 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.

Yes, inconsistencies as a feature.
Rejection of inconsistencies as a feature is the more common situation when "Mixing OO and DB".

> 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.

RIRO: Rubbish in, rubbish out - or is there more to it?

> 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.

More about inconsistencies as a feature - do you have a special reason to go into that? If not please keep it simple and let's regard rejection of inconsistencies as a feature - which is the more common situation.

>> A dedicated datacapture process needs to be
>> aware of the schema, and eventually of the current data.
>> Rendering also benefits from schema awareness.

> Contract is only meaning.
Lost in translation. Please rephrase.

>>>>>>>>>>> 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.

I have to guess what you mean, here.
Is *Type* what you propose as shared, formal proxy to meaning?

> This is not the only way though, you need also
> other operations in types algebra.

Way to do what? Received on Sun Feb 17 2008 - 21:24:54 CET