Re: Principle of Orthogonal Design
Date: Tue, 22 Jan 2008 10:46:48 +0100
Message-ID: <4795bade$0$85795$e4fe514c_at_news.xs4all.nl>
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
?
> 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