Re: Principle of Orthogonal Design

From: mAsterdam <>
Date: Tue, 22 Jan 2008 10:46:48 +0100
Message-ID: <4795bade$0$85795$>

Jan Hidders wrote:

> JOG wrote:
>> David Cressey wrote:
>>> Brian Selzer wrote:

>>>> I think that there are times when it makes sense to
>>>> 'collectivize' under a single predicate, and there
>>>> are times when it does not. In particular, if the
>>>> individuals represented are just different kinds
>>>> of the same sort of thing, such as is the case
>>>> with the different kinds of phone numbers, then
>>>> it makes sense to 'collectivize' those attributes
>>>> that are common to all of those individuals under
>>>> a single predicate. If, on the other hand, the
>>>> individuals represented are different sorts of things
>>>> that just happen to have the same attributes, then
>>>> it doesn't. A disjunctive predicate--something like,
>>>> for example, each tuple exemplifies an individual
>>>> that is an X or a Y, just doesn't make any sense to me.
>>>> A conjunctive predicate on the other hand--for a
>>>> relation that has multiple keys, for example--is not
>>>> a problem since each tuple would exemplify an individual
>>>> that is /both/ an X /and/ a Y. So if the predicate
>>>> can be stated so that it is not disjunctive, then
>>>> 'collectivizing' is to be preferred.
>>> It seems to me that you are describing the 
>>> generalization-specialization pattern.
>>> Am I reading you right?
>>>>> Either way, I certainly find that appealing to notions
>>>>> of "meaning" within formal design recommendations 
>>>>> seems to head towards very slippery ground.
>>> Why?  If you called it "the semantics of the data"  instead, 
>>> would that make it less slippery ground?
>> Absolutely not - worse in fact, because then it would be greased
>> with buzzwords too ;) Years of working with the semantic web,
>> ontologies, expert systems, etc have emphasised to me that
>> "meaning" is only something that can be obtained via situated 
>> embodiement within the environment concerned, and that context is
>> far too  complex a beast to be tamed by computerized encoding. 
>> As such I'd rather rules appealed to functional dependencies and 
>> logical consequents than to appeal to the slippery notion of
>> "meaning".
> Hear hear. But I think the part of POOD that actually does make sense
> and really removes redundancy and update anomalies can be defined that
> way. For example, if there is an inclusion dependency between a
> relation R and S then it makes sense to say that there is overlap in
> meaning. 


inclusion dependency --> meaning overlap


Slowly, please - where has the 'might' (from the redundancy in your other post) gone? And the 'qualified' in the inclusion dependency?

> You can generalize this by defining the notion of overlap
> such that there is overlap if there is an inclusion dependency between
> (1) the result of a selection of R and (2) S, or vice versa. ...
Received on Tue Jan 22 2008 - 10:46:48 CET

Original text of this message