[sc34wg3] Question on TNC / Montreal minutes

[Lars Marius Garshol]

* Mary Nishikawa
|=20
| I don't think that this was settled yet at all even though the
| minutes read that way. It may have just meant that we wanted to come
| to some initial agreement and then consider the decision. So for
| those who were not at the meeting, the book on this one is not
| closed yet, or maybe I just want to cause some trouble ;-)

This was a first attempt at solving the problem, but if the community
is not happy with the solution we will have to try and come up with
something better.
=20
| I was wondering, can we think of
|=20
| 1. baseNameSting as only the "container" for a string identifier
| within a "scope" (meaning within a particular domain). think that
| some are using it this way now (similar to what I presented in
| Montreal).
|
| This is the unique identifier as a string, so to speak, for those
| who want to use a string as an identifier.=20

It is, and this is how base names are in XTM 1.0.

| Some others may want to use "subjectIndicatorRef for subject
| identity, but not use baseName.=20

Count me in. :)

| So I think that the baseName should have an occurrence of 0 or
| 1. There should never be more than one sting identifier (different
| from the URI). AN ISBN comes to mind but there are others.

I'm not sure what you mean by this, Mary. Could you explain?
=20
| I am really against using any plain old name for the basename like
| "dog" to merge all topics that have "dog" within such and such a
| scope. Users will do as they like, but I think we should say
| explicitly that this is not the use for basename.
|=20
| If there are no sting identifiers, there are no basenames. Names such
| as "dog" should be used in "label"
|=20
| There may be many that disagree with me here.

I don't.
=20
| Question: Do we really want to apply constraints with the DTD at
| this point? Well, we are thinking about requiring attributes. This
| seems a little better to me.

You mean declaring the attribute as

  <!ELEMENT baseNameString merge (on | off) #REQUIRED>

? That is the best solution if you look at this in isolation, but I
fear that because of backwards compatibility we will have to make "on"
the default.

If you were to argue that this implies that using two different
element types <baseNameString> and <label> is better I would have to
agree.
=20
| I do not know, but it does not make sense to me to have something
| that is suppose contain something that uniquely identifies the
| subject but there can be more than one of them; even if they are all
| in different scopes.

I don't agree with that. It is perfectly possible for the same thing
to have more than one unique identifier, assigned by different
authorities, or even by the same authority.
=20
| I may be missing something here. Please show me an example where more
| than one identifier is needed.

If you look at the concept of "person" you'll see that there are
already at least 5 different subject identifiers in use for it, and
that only within my Omnigator's topic map registry...
=20
| 2.  Label  (occurrence of 1 or more, or 0 or more?)
|=20
| I do not think that we need attributes at all, but we need to define
| what this label is and how it differs from display name. Do we need
| to require at least one label name?

We don't require any names now, and I don't think we will do so in the
future. We do, however, need to clearly define the semantics of all of
these constructs. The next SAM draft will make an attempt to do so.
=20
| 3. The variants are variants of the label, not of the base name. Would
|    this work?

The variants are variants of the base name, and a base name can be
either a label or an identifier. In other words, the variants relate
to the base name in the same way regardless of whether the TNC is in
operation or not.
=20
| Do we use scope or type on label? I an not sure.

In the end I would like to see both, for both labels and identifiers.
That would make modelling cleaner, reduce the overloading of scope,
provide greater expressivity, simplify mappings to RDF, and generally
regularise the structure.

However, this is not a backwards-compatible change. If we open this
door we are looking at XTM 1.1 or 2.0, rather than a simple
reformulation of the existing XTM 1.0. (That is, an XTM 1.0 second
edition.)
=20
I've tried to keep this door firmly shut, but it seems that it is now
being forced open by the pressures of all that we've learned since XTM
1.0 was published.

| So adding to Nikita's example
|=20
| <topic id=3D"t1">
|     <baseName><scope>
|          <topicRef xlink:href=3D"core-id-types.xtm#us-ss-no"/>
| </scope>
|        <baseNameString>123-23-3456</baseNameString>
|    </baseName>
| </topic>
| <topic id=3D"t6">
|    <label>
|        <instanceOf><topicRef xlink:href=3D"#possible-name"/></instanceOf>
|        <labelString>Mama Cass</labelString>
|   </label>
| </topic>

Seems reasonable, if not in line with what we agreed in Montr=E9al.
(Just trying to avoid confusion here.)
=20
| (I don't think Mama Cass would like her SS# used like this, but it
| is only an example. we would need to have encryption for stuff like
| this I guess.)

This is where politics enter the picture. In Norway you need a
government license to use people's unique identifiers (Norwegian SSN
equivalent) in a topic map.

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