Re: cdt glossary 0.1.1 [MV]

From: dawn <dawnwolthuis_at_gmail.com>
Date: 19 Apr 2007 07:09:07 -0700
Message-ID: <1176991747.394590.67030_at_b58g2000hsg.googlegroups.com>


On Apr 19, 7:18 am, Mike Preece <mich..._at_preece.net> wrote:
> On Apr 19, 12:12 am, mAsterdam <mAster..._at_vrijdag.org> wrote:
>
>
>
> > Mike Preece wrote:
>
> > Hi Mike,
>
> > Did you really have to quote the whole of the glossary to make us all
> > of scrolling like crazy?
>
> > (Answer: no you didn't. Oh well.)
>
> > >> [MultiValue, MV]
> > >> 1. One name for the industry surrounding the Nelson-Pick data model.
> > >> In this context:
> > >> FILE: a real-world collective noun.
> > >> RECORD: a real-world object.
> > >> FIELD: is a real-world adjective.n.
>
> > >> 2. A data field (or attribute) defined to permit a variable number of
> > >> values as a list (array).
>
> > > I think the context given for 1. above is less than helpful. In
> > > keeping with the quote from Date above: "The entire information
> > > content of a relational database is represented in one and only one
> > > way: namely, as attribute values within tuples within relations",
> > > perhaps:- "The entire data content of a MV/Pick database is
> > > represented as (delimited) strings: namely as zero or more subvalues
> > > within multivalues within attributes (or "fields") within items (or
> > > "records") within files". Also, 2. above is imprecise, if not
> > > incorrect. Better: "A multivalue is one of the multiple values of an
> > > attribute and can itself contain 0 or more subvalues".
>
> > You may very well be right. However, the purpose of the glossary is
> > /not/ to push home one view on c.d.t. (one admit I subscribe to: RM is
> > the best we have for DM thus far) - it is just to shortcut
> > misunderstandings because of identifiable different interpretations.
>
> > Dawn is our recognized MV expert, so if she agrees ... :-)- Hide quoted text -
>
> > - Show quoted text -
>
> We're allowed multiple experts.

Definitely. And, not too surprisingly, there is a variety of expertise within the Pick/MV world, as there is within SQL-DBMS-and-RM world. There are many areas within MV where Mike is an expert where I am not. Similarly, MV experts have as much agreement among themselves as RM experts have ;-) but seem more civil about their disagreements (which is odd, given the different cultures historically).

mAsterdam knows I have aligned with the purpose of his glossary (to help avoid unnecessary misunderstandings in this forum because of differences in terminology, for example) and pitched in my two cents in the past, so I'll accept the nod as "our recognized MV expert" as a comment on the past and appreciate the "our." But I am stopping by here only infrequently now, and responding even less frequently, so I'm happy to pass the baton along.

So, Mike, can you suggest specific wording to mAsterdam for the MultValue/multi-value/multi-valued (all using the abbrev of MV) entry so he can make the change? It need not be comprehensive, just enough to help a reader of cdt not be confused if they see such terms. I hope you will jump in on more of the discussions here (hard to stop myself when I see many-to-many relationships discussed). I'm going to go put my money where my mouth is and see where it takes me. Maybe I'll come back with tail between legs begging for strong typing. Maybe not.

Cheers! --dawn Received on Thu Apr 19 2007 - 16:09:07 CEST

Original text of this message