Re: cdt glossary 0.1.1 (repost)

On Apr 18, 4:40 am, Mike Preece <mich..._at_preece.net> wrote:
> 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.

Over a decade ago, but yes, considering that next new years eve will be 40 years after Day 0 in Pick (all flavors), it is relatively new.

> I, personally, don't like it,

I surrendered to it after looking for alternatives.

> and prefer
> to use "Pick", although I often use "Pick/MV" to be clear and keep
> everyone happy.

That wouldn't be everyone on cdt, would it? smiles.

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

Yes, especially after many folks ended up in court with him, some paying, some not. Not everyone was fond of Pick's inclination to put his money up his nose either.

Additionally, PICK was trademarked by Pick Systems, with the trademark now owned by Raining Data.

> and the term
> "MultiValue" took purchase in this context.

Yes, Gus could give a more precise context for why they chose the term and why he trademarked it and gave it to the industry to use.. When we write it the Spectrum way as MultiValue, it is an umbrella term that pretty much every company with a Pick flavor would agree aligns with their product, whether they opt to use the term or not. jBASE marketed itself as "jBASE is not Pick." When I asked RD if I could use the term Pick as the umbrella term (since they have the TM) they thanked me for asking and said no.

So, it is fine informally to call it Pick, but it doesn't work to call it that in formal writing nor with each vendor of Pick, er MultiValue, software. Cheers! --dawn Received on Wed Apr 18 2007 - 21:04:58 CEST