[sc34wg3] Question on TNC / Montreal minutes

Jan Algermissen sc34wg3@isotopicmaps.org
Thu, 05 Sep 2002 12:36:58 +0200

Lars Marius Garshol wrote:
> * Jan Algermissen
> |
> | Oh yes, sure. I have been thinking of making a statement about the
> | particluar assertion ("this assertion does not cause a TNC based
> | merge') but you are of course right that introducing another
> | assertion type is the way to go. There would then be something like
> | ..#ap-topic-basename and ...#ap-topic-name .
> I think this was what SRN & MB were thinking, but I might be wrong.
> Personally I certainly agree with you.
> | But shouldn't the merge attribute then be on <baseName> rather than
> | <baseNameString>, to reflect the idea that it is a property of the
> | assertion rather than of the basename.
> Well, there are two assertions in the Reference Model, are there not?

I think the way I started this discussion is likely to cause confusion because
I wasn't very precise in the use of the term 'reference model'.

What we have been talking about is actually not a reference model issue but
a processing model issue. The reference model 'just' defines what a topic
map graph is and imposes some constraints (such as the rule that each
subject must be represented by exactly one node). In addition it provides
the semantics that make it possible to distinguish between subject indicating
resources and subject constituting resources. It does so by providing an assertion
pattern 'ap-topic-subjectIndicator' and the appropriate roles.

Actually, this is all the RM does (in my understanding of course,...Steve and Michel, please
correct me if I am seriously wrong here).

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

So, there is only one assertion pattern in the RM.

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

> attribute does not affect the topic name as such, only the base name
> string and whether that is a label or an identifier.

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>

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. It is essentially
not a question of the reference model and I saw the danger that we are causing this

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 ;-)

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