Re: The naive test for equality
Date: Thu, 11 Aug 2005 21:52:24 +0200
Message-ID: <42fbac55$0$11073$e4fe514c_at_news.xs4all.nl>
vc wrote:
> mAsterdam wrote:
>>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
> makes sense)
And they wouldn't make sense if they where syn/homonyms?
>>>It's, like, introduction to modelling 101. >> >>What is 101?
>
> '101' is a synonym of 'introductory'.
Thx.
>
>>>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.
Of course - so what are the questions to ask to
get the specifics of the requirement?
Extrapolating from your assumption (newspaper article, etc)
you'ld ask about /which/ pieces of information you want
to know where it came from.
Another one would be: what is it you want to know about
where it came from?
Relevant, no doubt - but not adressing syn/homonym problem.
But that makes sense, since you also stated that it
shouldn't occur (I take it that 'self-induced'
implies 'mistake' here - please correct me if I
misinterpreted).
>>>>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 ? >> >>No. >> >>>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.
"proof" (whatever that word means in this context) is to much to ask.
In modelling sessions I recognize that
people spend a lot of time to get the meaning of terms
right for use in their model (IMO this is time well spent,
especially for large systems). Some of the effort revolves
around homonyms and synonyms. From what I read you explain
this effort as (just) correcting mistakes. I think there
is more about this that can be delt with in a systemic way - but
only (this is just a hunch) if we appreciate that this is
inherent to team modelling.
>>>>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.
>
> If you say so.
>
>>>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.
>
> "You" can be used, in English, as an impersonal pronoun referring to
> anyone out there engaged in data modelling. It was used in this sense
> - nothing personal.
Not only in English. I don't like to be put on one floor with high-faluting nonsense. Received on Thu Aug 11 2005 - 21:52:24 CEST