# Re: Principle of Orthogonal Design

From: Jan Hidders <hidders_at_gmail.com>
Date: Tue, 22 Jan 2008 05:18:47 -0800 (PST)

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