[sc34wg3] Comments on N554 (ISO 13250-5)

Lars Marius Garshol sc34wg3@isotopicmaps.org
Thu, 18 Nov 2004 21:13:48 +0100


Here are my comments on the current RM draft.

Generally, the document does not follow correct ISO style. To be more
precise:

  - section 2 should be named "Terms and definitions", not "Glossary"
    (ISO/IEC Directives, Part 2, 2001, 6.3.1)

  - the numbering of notes is not correct; it should be per subclause,
    and when there is only one in the clause/subclause it should have
    no number (6.5.1)


The terms "OP" and "SIP" seem a bit misleading, since it really
appears that it is the classes that are either O or SI. Given this, it
would seem better to use the terms "OPC" and "SIPC".

Their definitions are not entirely in sync. OP has only one definition
(the class), while SIP has two (the class, or the instance).

Generally, I don't think it's a good idea to define a single term with
two meanings. At the DC meeting it was said that this happens in the
real world, and I'll grant you that it does (as any dictionary will
show), but when we define terminology for technical use we can avoid
this and define the terms without built-in ambiguity.

In RM, only the following terms have multiple meanings:

  - SIP, and here meaning #2 seems incorrect to me, especially if the
    name of the term is changed

  - "topic map", where meaning #2 again seems incorrect, in the sense
    that this would be a "topic map document" (a very strange term in
    this context, but then it matches the very strange definition)

In short, I think none of these should retain their second definition.
If necessary, separate terms can be defined to cover those, but this
does not seem to me to be needed.

Defining a term for TMRM seems unnecessary to me.


The use of the glossary also does not seem very helpful for the
reader. Admittedly this is the ISO way, but one could do like TMDM and
have a reader-friendly exposition of the terms that duplicates the
"glossary" section.


I do *not* like the use of the term "topic map" in this document. It
is wholly at odds with how the term has traditionally been used. (The
same goes for TMA and TMV, of course.)


The second sentence of the definition of the term "subject" seems very
strange. Why add "A potential or actual subject of conversation." at
the end of the definition? If it can be "anything whatsoever", surely
it can be this, too?


The rule that there must be exactly one SIP (that is, SIPC instance)
for each subject proxy seems wholly bogus. Why is it there?


A lot of what's said about this document seems to deal with one TMA
"importing" or otherwise making use of another, yet the document
itself is silent about this. That seems a little strange.


The definition of TMA is very vague. Is the TMA the disclosure, or the
rules? And how is the disclosure done? Have I disclosed the rules if I
present them orally? If I record the description on tape? Can a
closed-source software application be considered the disclosure of its
own rules? Can the source of an open source one be? Etc etc.


The definition of "property class" calls it a "named type". So, is it
a class or a type? Is there any significance to the difference in
terms?


merging: "The process whereby two subject proxies that are surrogates
..."  Surely this is really "the process triggered by equal SIPC
values?" If the subject proxies in question have the same subject
surely that is a different thing, which may or may not be true, but in
any case this is not what triggers the merge.


The term "reification" will be defined differently here from in TMDM,
and I'm not sure we should be using it at all, if TMDM is to use it.
Thoughts?


"built-in": I don't think this term is very appropriate. This is
usually used for things that are hard-wired in the definition of the
structure of something and cannot be changed. These properties seem to
me to be more "given" or "assigned" or something.


There's a lot to take exception to in clause 5, but since Robert is
already busy doing so I'll wait for later.


"Grammar" rule 7 seems wholly bogus. It's not a BNF rule in any useful
sense at all. Also (8) seems to mean "topic map", rather than "topic
map view", though the difference between the two is unclear, to say
the least.


I hope this helps!

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >