[sc34wg3] Question on TNC / Montreal minutes

[Lars Marius Garshol]

* Mary Nishikawa
| 
| If there is no unique identifier as a string we don't need the
| basename, so its occurrence may be 0. For example, we are using
| subject indicator ref for subject identity.

Well, first of all: if you have a string that uniquely identifies a
subject there are several ways you might use it:

 - as a base name in a specific scope, subject to merging, (provided
   it fits the semantics of base names),

 - as an occurrence, subject to merging according to application-
   specific rules, (provided it fits the semantics of occurrences),
   and

 - to create a subject identifier where that string forms a part.

All of these methods works, but they have slightly different semantics
associated with them, as well as different implications for the
applications that you build. (It is sort of like the "should I
represent this using an attribute or an element?"-question in XML.)
 
| However for phyical data that has only one unique string
| identifier... the base name would have one and only one occurrence
| in the topic.

Well, it is only in a closed world that you can know that each subject
only has a single identifier, and part of the point about topic maps
is that it opens your world up, so that you can connect it to other
worlds, where others may well have assigned different identifiers to
the same subjects.

So while you may often find that your subjects only have a single
identifier I don't see why you would want to restrict yourself to only
ever allow a single identifier.
 
| So what I mean is, when you are talking about acquisition of
| geophysical data at a given location, you may not be interested in
| multiple identities. So in this case, multiple identifiers would be
| a problem.

Why would they be a problem? You may just have a single identifier,
but how does the ability of the standard to support more than one
become a problem?
 
| Agreed. I also hope that we come up with some textbook on TM
| patterns.

I think that would be a great project. Personally, I don't have the
bandwidth, but I would love to see someone do this. Even just
publishing individual patterns would be very useful.
 
| Typing is really important. Domain (scope) and type are really very
| different.

They are, but the lack of types for names forces us to conflate the
two. I think that's unfortunate, but at the same time changing it
means we're making substantial changes to XTM 1.0.
 
* Mary Nishikawa
|
| <topic id="t1">
|     <baseName><scope>
|          <topicRef xlink:href="core-id-types.xtm#us-ss-no"/>
| </scope>
|        <baseNameString>123-23-3456</baseNameString>
|    </baseName>
| </topic>
| <topic id="t6">
|    <label>
|        <instanceOf><topicRef xlink:href="#possible-name"/></instanceOf>
|        <labelString>Mama Cass</labelString>
|   </label>
| </topic>

I was unhappy about this for several reasons:

 (1) it forces the identifier/label split high up in the element
     hierarchy, making this a rather intrusive change to the DTD,

 (2) it exacerbates the naming mistake XTM 1.0 made with regard to
     the <baseName> element type. The structure should really be as
     follows:

        <topic id="t1">
          <topicName>
            <scope>
              <topicRef xlink:href="core-id-types.xtm#us-ss-no"/>
            </scope>
            <identifier>123-23-3456</identifier> <!-- merged name -->
          </topicName>
        </topic>

        <topic id="t6">
          <topicName>
             <scope>
               <topicRef xlink:href="#possible-name"/>
             </scope>
             <label>Mama Cass</label>
          </topicName>
        </topic>

     The rationale for this is that conceptually, topics have a number
     of topic names. Each of those consist of a base name, which can
     have either a label or an identifier as well as a set of variant
     names. 

     By adding a new <label> element at the level of <baseName> we
     obscure this in several different ways. We make it seem as if
     topics either have a base name or a label (the distinction is
     really identifier/label), and we make it seem as though the
     distinction also affects the variants, which it does not.

(Well, reason (2) really contains a number of reasons, so the list
ends here.)

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
ISO SC34/WG3, OASIS GeoLang TC        <URL: http://www.garshol.priv.no >