Re: cdt glossary 0.1.1 (repost)

On Apr 18, 3:23 am, dawn <dawnwolth..._at_gmail.com> wrote:
> On Apr 17, 6:17 am, Mike Preece <mich..._at_preece.net> wrote:
>
>
>
>
>
> > On Apr 14, 11:37 am, mAsterdam <mAster..._at_vrijdag.org> wrote:
> <snip>
> > > [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".
>
> I agree that as definitions these are far from perfect, Mike. I
> likely contributed to this in the first round, so the defs would have
> been related to a perceived need to clarify something. If I recall,
> the reason for putting it in the glossary was that the terms
> "MultiValue" (sometimes written "MV") and multi-value (or multivalue,
> sometimes written "MV") were not distinct enough (both abbreviated as
> "MV") so that someone outside of the space might get confused or use
> the terms in a confusing way. The existing defs merely clarify that
> there is a class of database and development products that goes under
> the trademarked name of MultiValue (MV), and we can also talk about an
> attribute being multi-valued (designated as M or MV in a dictionary)
> or a "multi-valued attribute".
>
> You are giving a third meaning of the term -- a multivalue as an
> actual value. So, 1) there is the umbrella term for the class of
> database, 2) the differentiation between attributes described as multi-
> valued and those described as single-valued (it should not say
> "defined" although I likely wrote or nodded to that way back when) and
> it should say "multi-valued attribute" for this second use, and then
> 2) an actual value which might be a multivalue.
>
> So the reason for these few words is related to addressing a specific
> misunderstanding of the term(s).
>
> By the way, if you get a chance, I was asked to take a shot at fixing
> up some wikipedia information, including starting a MultiValue
> document. I'm incredibly busy right now and took a few minutes to
> attempt to learn how to edit and create wikipedia documents (when I
> would rather read the info about my new Moto Q if I can get a
> chance ;-), so I did start one, but if you can spare any seconds,
> please feel free to jump in and work on editing that and related
> documents if you can, Mike. If we can write things up there, we
> could point people to that information as well.
>
> mAsterdam, do you have adequate information to alter the glossary
> regarding MultiValue?
> hugs to all --dawn- Hide quoted text -
>
> - Show quoted text -

The term "MultiValue", when applied to the class of products, is a relatively recent innovation. I, personally, don't like it, and prefer to use "Pick", although I often use "Pick/MV" to be clear and keep everyone happy. Iirc, MV began to be used in this context at a time when there was some antagonism between the Pr1me/UniVerse/UniData side of the family and the Pick/Reality/Mentor side. Those on the Pr1me side were, understandably, loathe to use the term "Pick" and the term "MultiValue" took purchase in this context.

Mike. Received on Wed Apr 18 2007 - 11:40:46 CEST