[sc34wg3] Question on TNC / Montreal minutes
Jan Algermissen
sc34wg3@isotopicmaps.org
Thu, 05 Sep 2002 15:54:28 +0200
Lars Marius Garshol wrote:
>
> * 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.
Sure, but how does all this affect the reference model ? All you need to do
is to provide the right PSIs (together with the explanation of their semantics)
at the SAM level and then define how an XTM instance is to be represented
as a topic map graph using the PSIs and the reference model.
[..]
> As for a processing model, I don't know what that is. There's nothing
> like that in the roadmap[1], 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.
Hmm, if you agree on this, why is the TNC issue an exception ?
>
> | 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.
I think, that the _SAM_ will just provide the assertion patterns that
are needed to express the semantics reuquired by the SAM.
>
> | > 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>
> | element.
>
> 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
Yes, but is it inherent to the concept of 'name' that it acts as an identifier
or as a name ? To me these semantics are in the _relationship_ between a name
and a topic. Is there any theoretical background that supports either Lars' or my
point of view, can anyone help ???
> and cause different processing. They are *not* the same kind
> of name at all.
So, if we are talking about how to process them, why are we not talking
about processing models ;-) ?
>
> | 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[2] and a SAM -> RM mapping (as yet unpublished and
> presumably unwritten).
Ok, I understand what you mean, it is certainly more precise, because
XTM -> RM implies that the application MUST implement the RM, sorry if
I appeared to be proposing that.
>
> 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
> upon[3].
>
> | 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?
I don't see the RM being an issue in our discussion and I felt that
the way I said some things might cause that impression.
>
> | 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>
> | <label type="simplename">
> | <labelString>Paris</labelString>
> | </label>
> | </topic>
> |
> | (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:
>
> <topic id="t1">
> <baseName>
> <baseNameString>Paris, capital of France</labelString>
> </baseName>
> <baseName>
> <label>Paris</label>
> </baseName>
> </topic>
>
> Of course, neither of these were chosen by WG3.
see above, the question whether the semantics of label vs. baseName are
'on' the name or on the relationship.
Jan
>
> [1] <URL: http://www.y12.doe.gov/sgml/sc34/document/0323.htm >
>
> [2] <URL: http://www.y12.doe.gov/sgml/sc34/document/0328.htm >
>
> [3] <URL: http://www.y12.doe.gov/sgml/sc34/document/0286res.htm >,
> resolution 7.
>
> --
> Lars Marius Garshol, Ontopian <URL: http://www.ontopia.net >
> ISO SC34/WG3, OASIS GeoLang TC <URL: http://www.garshol.priv.no >
>
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
--
Jan Algermissen
Consultant & Programmer
Tel: ++49 (0)40 89 700 511
++49 (0)177 283 1440
Fax: ++49 (0)40 89 700 841
Email: algermissen@acm.org
Web: http://www.topicmapping.com