Re: Principle of Orthogonal Design

On 22 jan, 10:46, mAsterdam <mAster..._at_vrijdag.org> wrote:
> 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

>

Yes. An inclusions dependency implies meaning overlap. It is a sufficient condition, but not a necessary one.

> ?

>

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

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

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.

• Jan Hidders