[topicmapmail] occurrence abuse ?

[Sam Hunting]

> Bernard Vatant:
> 
> | You think people are lazy, and that's why they will use
> | occurrence for a code, a phone number, an address, a short
> | description or a long name (fuzzy boarder here, trying to fix it
> | will lead to nowhere except religious wars), an application note
> | ... whatever bit of information that they do not consider
> | important enough to be made the subject of a distinct topic,
> | although they know that in theory it could (should) be.
> |
> | I must confess I've done it many times, and will do again. Even
> | though, as Murray and you, I long have considered to consider it
> | as an abuse, a drift from the original thinking of topic maps
> | "fathers". But now I'm not sure ...
> |
> | An abuse maybe, but a very pragmatic and efficient one. Maybe
> | lazy people are right after all.
> 
> Jan Algermissen:
> 
> >to begin with: I am a lazy person too...and part of my intention
> >was that I hoped someone would provide me with a reasonable
> >justification for remaining lazy ;-)
> >
> >I think I basically agree with what you say above.
> >
> >[definitions from 13250 and XTM omitted]
> >
> >According to these (very flexible) definitions I agree, I just
> >*think* that the intention was something else (that's why I am
> >curious what the intention actually was).
> 
> My position is that there is absolutely nothing wrong with using
> occurrences for codes, phone numbers, addresses, and the like.
> In fact, it is eminently sensible and perfectly in line with the
> "intention" of the "fathers". It is not a question of "laziness"
> but of pragmatism and the requirements of the application.

Is it your position that this should be the preferred practice for topic
map applications that use the SAM?

> Jan, I believe your feeling that this is an abuse is probably due
> to your judgement being clouded by the "everything-is-a-topic"
> view promoted by TMPM4 (now thankfully substantially moderated in
> the Reference Model drafts). 

Leaving beliefs and feelings aside, I'd be curious to see how, in your
view, RM "moderates" TMPM4 in this regard.

> Everything is *not* a topic; only those
> things are topics that the topic map author wants to make assertions
> about. In most applications, the only useful thing you might want
> to assert about a phone number is its owner. Does that justify
> making it a topic? Not really: that information can equally well be
> expressed by making the phone number an occurrence of the owner
> and be done with it.

> So why make things more complicated than they need to be?
> 
> In the case of a date, I often ask the question, how many events am I
> in general likely to want to associate with dates of this type in this
> application? If the answer is "usually, at most one", then I would
> express the date as a typed occurrence of whatever event it pertains
> to, rather than creating a new topic and using an association.
> 
> Put another way: A topic is a nexus for information about a given
> subject. If you know that you are only going to have one piece of
> information for topics of a certain type (say, phone numbers), then
> it's worth considering whether you can get by without creating
> topics for those things at all.

What you you mean, "create a topic"?


> Steve
> 
> --
> Steve Pepper, Chief Executive Officer <pepper@ontopia.net>
> Convenor, ISO/IEC JTC1/SC34/WG3  Editor, XTM (XML Topic Maps)
> Ontopia AS, Waldemar Thranes gt. 98, N-0175 Oslo, Norway.
> http://www.ontopia.net/ phone: +47-23233080 GSM: +47-90827246
> 
> _______________________________________________
> topicmapmail mailing list
> topicmapmail@infoloom.com
> http://www.infoloom.com/mailman/listinfo/topicmapmail
> 

Sam Hunting
eTopicality, Inc.

---------------------------------------------------------------------------
"Turn your searching experience into a finding experience."(tm)

Topic map consulting and training: www.etopicality.com
Free open source topic map tools:  www.goose-works.org

XML Topic Maps: Creating and Using Topic Maps for the Web.
Addison-Wesley, ISBN 0-201-74960-2.
---------------------------------------------------------------------------