Re: The naive test for equality
Date: 11 Aug 2005 12:01:24 -0700
> VC wrote:
> > Presumably the team has meetings at which they discuss the
> > stuff they interested in and come to some agreement as to what
> > terminology they want to use and what the terms are
> > supposed to mean.
> Let me get this straight. In your methodology the terminology
> is ready (agreed upon) before the modelling starts?
That's not what I said. I wrote 'they discuss the stuff they are
intersted in and come to an agreement as to what terminology they want
to use'. It can be rephrased as:
Step one: discover the items/entities of interest;
Step two: give the entities names (or use the existing names if it
Step one: discover the items/entities of interest; Step two: give the entities names (or use the existing names if it makes sense)
> > It's, like, introduction to modelling 101.
> What is 101?
> > Besides, you describe a hypothetical terminology
> > selection/definition process yourself, so it's not clear what the problem
> > might be unless the "team" neglects to identify, say, data objects and
> > relationships [self-infilcts potential pain because of not doing required
> > work].
> How do you propose to identify data objects and
> relationships from a requirement "It should be
> possible to find out where a piece
> of information came from."?
Presumably 'a piece of information' can come from a newspaper article, gossip, bank statement, or any other entity capable of producing such piece of information. What's the problem with identifying the information source ? If the requirement is literally as general as you wrote, then it needs to be made more specific in order to be realistically implemented.
> >>Another, less cryptic example:
> >>Say a team tries to meet the requirement that it should
> >>be possible to find out where a piece of information came from.
> >>One thinks 'origin', another one thinks 'source'. (1)
> >>Let's say they talk about it and decide on 'source'.
> >>One thinks 'the source code of a program' because
> >>yesterday he spent some time finding a source-file,
> >>another one thinks 'the external agent providing the
> >>piece of information' because he just finished
> >>a business process analysis session. (2)
> > You are kidding, right ?
> > If the modellers chose the name/label "source" and
> > did not define what entity the name refers to,
> > then the name is just meaningless, like say "fshsalkfd".
> > Apparently, your hypothetical modellers
> > are not modellers but some kind of impostors.
> Please take the drivers' seat. Show us the real thing.
> Pretend you are modelling the data to meet the requirement.
> Feel free to ask relevant questions/check assumptions about it.
I do not want to 'take the driver's seat' whatever it means. *You* claimed that there is a 'homonym/synonym problem' with respect to naming entities and attributes, therefore, the burden of proof shwing that such problem does in fact exist is squarely on *your* shoulders. So far, you failed to provide the proof: your example either can be handled by conventional entity-relationship methods, or is under-specified to the extent of making almost no sense.
> >>Both the synonym-problem (1) and the homonym-problem (2) may
> >>very well be recognized and resolved, of course.
> >>Or not. Or to late.
> > As I wrote before, data modelling is not a work of
> > [literary] fiction where one needs to bother with stuff like
> > synonyms, homonyms, metaphors, metonymy and what not.
> If you don't bother with that "stuff" your work will be
> exactly that: a work of fiction.
> > Just identify the entities, invent (or use commonly
> > accepted ) names for them and you'll be a happy
> > camper without any need to hide behind high-faluting
> > nonsense like "synonym problem", "conceptual
> > object type" or some such.
> - I am not hiding at all.
> - Please refrain from attributing terms to me I did not use.
Cheers. Received on Thu Aug 11 2005 - 21:01:24 CEST