[sc34wg3] Question on TNC / Montreal minutes
Lars Marius Garshol
05 Sep 2002 13:12:50 +0200
* Jan Algermissen
| What we have been talking about is actually not a reference model
| issue but a processing model issue.
To be really precise: what we are talking about is the TNC. What you
are talking about is what impact that has on the Reference Model. The
representation of the SAM in the Reference Model needs to distinguish
between base names that are labels and base names that are identifiers.
So this is something that impacts the Reference Model above and beyond
mere processing and merging, since the two kinds of names have
As for a processing model, I don't know what that is. There's nothing
like that in the roadmap, and nobody has been suggesting this as a
work item for WG3.
| All additional issues are to be addressed by application models and
| the corresponding processing models (that define how a particular
| markup type is to be interpreted and processed to result in a valid
| topic map graph).
Here I think we agree, and (I think) this is what I said above, but I
might be wrong.
| So, there is only one assertion pattern in the RM.
I don't see how that could work, given that the label/identifier
distinction must be maintained.
| > One topic-to-topic-name,
| this would be SAM#ap-topic-basename (using SAM for whatever base URI
| the SAM might use)
| > and one topic-name-to-base-name-string. The
| This is done via the RM#ap-topic-subjectIndicator pattern (RM for
| base URI of reference model) meaning that the the particular
| <baseNameString> elements are interpreted as subject indicating
| resources for the concept of the name. This is what makes it
| possible for two elements like
| <baseNameString>XML-parser</baseNameString> and
| <baseNameString>XML-Parser</baseNameString> to *indicate* a single
| subject (the concept of the name "XML-parser".
That doesn't sound very good to me. It seems that the RM needs to be
somewhat richer in order to be able to model the TNC correctly. It's
difficult to provide a reasonable criticism of this without having
seen a complete presentation of the SAM-RM mapping, however, so if
someone could publish this stuff that would be very much appreciated.
| As it is not the name itself that causes a TNC based merge but the
| SAM#ap-topic-basename assertions between a name and two topics I'd
| argue that the 'triggerTNCmerge-flag' is a property of the
| assertion, not of the name. And thus it should be on the <baseName>
I think you are being lead astray by the surface syntax here. What the
proposed syntax is *really* doing is to distinguish between two
different kinds of names: labels and identifiers. These have different
semantics and cause different processing. They are *not* the same kind
of name at all.
| But (and this is the point I wanted to make) this is a question of
| the XTM syntax, the SAM and what the standardized processing model
| of XTM -> RM should be.
There are no official plans for an XTM -> RM processing model. What
the roadmap calls for is an XTM -> SAM deserialization
specification and a SAM -> RM mapping (as yet unpublished and
ISO 13250 needs to specify both XTM -> RM, XTM -> SAM, and SAM -> RM,
and it is clear that one of these connections is redundant. Given that
the SAM is more formal (in the sense that it relates more explicitly
to the things actually being processed, strings and locators) and that
it is closer to the surface syntax, going via the SAM is the obvious
choice, and it is the one that the WG3 meeting in Orlando agreed
| It is essentially not a question of the reference model and I saw
| the danger that we are causing this impression.
What danger? What do you mean?
| Having said that, I very much like the idea that
| <baseName merge="on"> and <label> are semantically the same (in my
| view expressed above) and that we might even have a generic <label>
| element and control the actual type of topic-label relationship via
| an attribute:
| <topic id="t1">
| <label type="basename">
| <labelString>Paris, capitol of France</labelString>
| <label type="simplename">
| (not a proposal for changing XTM of course ;-)
I'm not too happy with this. The <baseName> element type is misnamed
in XTM 1.0, and should really have been called <topicName>, and that
would have turned <baseNameString> into <baseName>, which would have
been far clearer.
I would much prefer this:
<baseNameString>Paris, capital of France</labelString>
Of course, neither of these were chosen by WG3.
 <URL: http://www.y12.doe.gov/sgml/sc34/document/0323.htm >
 <URL: http://www.y12.doe.gov/sgml/sc34/document/0328.htm >
 <URL: http://www.y12.doe.gov/sgml/sc34/document/0286res.htm >,
Lars Marius Garshol, Ontopian <URL: http://www.ontopia.net >
ISO SC34/WG3, OASIS GeoLang TC <URL: http://www.garshol.priv.no >