[sc34wg3] Question on TNC / Montreal minutes

[Mary Nishikawa]

Lars Marius,

These are related so I have placed them together.


>| 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?

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.

However for phyical data that has only one unique string identifier... the 
base name would have one and only one occurrence in the topic.  For example,

I just attended a presentation on DLIS (Digital log interchange standard). 
It is a common data format for interchanging oilfield logging data. It is 
standard RP66 published by POSC. I am talking about data structures for 
physical properties, so in this case there is one an only one unique 
identifier. People are more complex and have more identifiers as you well 
pointed out.

I think that it would be worthwhile for the mathematicians and physicists 
to take a look at the logical structure of this data format. Each file is 
conprised of an EFLR (explicitly formatted logical record) and Implicitly 
formatted logical record (channel data).

Each object has one unique identifier and the object is typed.

The objects have attributes which are of the following characteristics:
label (long name ascii 8 bit)
count
data type
units
value
indices of dimension
limit
etc.

Each record is a set of objects which is typed. All objects of the same 
type are in the same data set. The types are "published" in an "official" 
dictionary. You can also define your own set types.

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.

>
>| 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.
>
>| 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...

Sometimes my head is in the clouds and I am only thinking about more 
elemental subjects, not complex subjects like people ;-))

>
>| 2.  Label  (occurrence of 1 or more, or 0 or more?)
>|
>| 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.

Agreed. I also hope that we come up with some textbook on TM patterns. The 
physical data model would be one kind of pattern.

>
>| 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.

OK. I think that I agree with this.

>
>| 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.

I think that this would help map to other data structures like the one I 
mentioned. Typing is really important. Domain (scope) and type are really 
very different.


>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.)
>
>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
>|
>| <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>
>
>Seems reasonable, if not in line with what we agreed in Montreal.
>(Just trying to avoid confusion here.)

This is not what we agreed to in Montreal, but there were some objections 
or problems with this approach?

>
>| (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.

Glad to hear that. I really think that we may need to address the security 
issue in the future. Schlumberger is heavily involved in identity and 
encription in the smart card business as you may well know.

Cheers,
Mary