Re: Principle of Orthogonal Design
Date: Tue, 22 Jan 2008 19:57:59 +0100
Message-ID: <47963c0a$0$85784$e4fe514c_at_news.xs4all.nl>
Jan Hidders wrote:
> mAsterdam wrote:
>> Jan Hidders wrote: >>> JOG wrote: >>>>>>> ... I certainly find that appealing to notions >>>>>>> of "meaning" within formal design recommendations >>>>>>> seems to head towards very slippery ground. >>>> ... 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
>
> Yes. An inclusions dependency implies meaning overlap.
> It is a sufficient condition, but not a necessary one.
>
>> ?
The easiest case of meaning overlap, then, should be
with the the most simple form of inclusion dependency:
RI, the foreign key.
How does the meaning overlap with simple RI?
>> Slowly, please - where has the 'might' (from the redundancy in >> your other post) gone?
>
> That applied to my improved version of EE's definition of meaning
> overlap. Under the definition I'm using here this "might" has become a
> "must".
Another change of the definition of meaning overlap? To what?
>> And the 'qualified' in the inclusion dependency?
>
> Saying that there is a qualified inclusion dependency between R and S
> is equivalent with saying that there is an inclusion dependency
> between (1) the result of a conjunctive query that selects tuples from
> R and (2) S, which I talked about in the subsequent generalization
> steps in the preceding posting. I though that a step by step
> introduction might make the concept and the reasoning behind it a bit
> easier to grasp.
I don't think the difficulties are in the genericity of the definition of the inclusion dependency. ISTM the problems are in the definition of 'meaning overlap'. You changed it twice since I mentioned my objection to Erki's definition.
> Apologies if this is all a bit confusing, but I'm developing these
> ideas as I post, and I'm not sure yet what the best way is to explain
> them.
Making the changes in your used definitions stand out more would definitely help. It is very hard to keep track of what you consider invariant and variant to your line of reasoning if definitions change without mention. Received on Tue Jan 22 2008 - 19:57:59 CET