[sc34wg3] Question on TNC / Montreal minutes

Nikita Ogievetsky sc34wg3@isotopicmaps.org
Thu, 5 Sep 2002 07:09:11 -0700


Hi Merry,

I will try to recollect the summary of proposals here:

Lets consider a name of type "definition"
Given that typed names are accepted we have 3 choices:

1)Using merge attribute:
Merge attribute is a surrogate of a very high level type.
Using it allows to have two types of "#definition" names: one with
merge="on", the other with merge="off"
<topic id="t1">
     <baseName>
       <instanceOf><topicRef xlink:href="#definition"/></instanceOf>
       <baseNameString merge="on">a creature that has four
legs</baseNameString>
     </baseName>
</topic>
<topic id="t6">
     <baseName>
       <instanceOf><topicRef xlink:href="#definition"/></instanceOf>
       <baseNameString merge="off">a creature that has four
legs</baseNameString>
     </baseName>
</topic>

2)Merging is implied by the class of name (via sub-classing some base
"merge" and "no-merge" classes, that should form base PSIs).
Using sub-classes of definition: "strong-definition" implies merging,
"some-definition" - does not.
<topic id="t1">
     <baseName>
       <instanceOf><topicRef xlink:href="#strong-definition"/></instanceOf>
       <baseNameString>a creature that has four legs</baseNameString>
     </baseName>
</topic>
<topic id="t6">
     <baseName>
       <instanceOf><topicRef xlink:href="#some-definition"/></instanceOf>
       <baseNameString>a creature that has four legs</baseNameString>
     </baseName>
</topic>

3)Using labels:
<topic id="t1">
     <baseName>
       <instanceOf><topicRef xlink:href="#definition"/></instanceOf>
       <baseNameString>a creature that has four legs</baseNameString>
     </baseName>
</topic>
<topic id="t6">
     <label>
       <instanceOf><topicRef xlink:href="#definition"/></instanceOf>
       <baseNameString>a creature that has four legs</baseNameString>
     </label>
</topic>

Now there are also lots of different opinions on whether it is <label> or
<baseName> or <topicName>
and whether it is <baseNameString> or <labelString> or <string> or
<resourceData>

All assertions are scopable, and there are should not be any constraint on
the number of occurrences
otherwise merging is jeopardized.

--Nikita.


----- Original Message -----
From: "Mary Nishikawa" <nisikawa@fuchinobe.oilfield.slb.com>
To: <sc34wg3@isotopicmaps.org>
Sent: Wednesday, September 04, 2002 10:46 PM
Subject: Re: [sc34wg3] Question on TNC / Montreal minutes


> At 07:11 PM 9/4/2002 -0700, Nikita Ogievetsky wrote:
> >Actually the choice was between
> >1) on/off "merge" attribute
> >and
> >2)introduction of  typed  <label> elements (typed like occurrences with
> ><instanceOf>).
> >
> >The former was chosen, although I long hoped for the latter.
>
> Nikita,
>
> 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 ;-)
>
> I was wondering, can we think of
>
> 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. Some others may want to use
> "subjectIndicatorRef for subject identity, but not use baseName. 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 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.
>
> If there are no sting identifiers, there are no basenames. Names such as
> "dog" should be used in "label"
>
> There may be many that disagree with me here.
>
> 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.
>
> 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 may be missing something here. Please show me an example where more than
> one identifier is needed.
>
> 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?
>
> 3. The variants are variants of the label, not of the base name. Would
this
> work?
>
> Do we use scope or type on label? I an not sure.
>
> 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>
>
> (I don't think Mama Cass would like here SS# used like this, but it is
only
> an example. we would need to have encryption for stuff like this I guess.)
>
> Cheers,
> Mary
>
>
>
> >Now, if 2) choice were selected you would have:
> >
> ><topic id="t1">
> >    <baseName>
> >       <baseNameString>Mama Cass</baseNameString>
> >   </baseName>
> ></topic>
> ><topic id="t6">
> >   <label>
> >       <instanceOf><topicRef xlink:href="#possible-name"/></instanceOf>
> >       <labelString>Mama Cass</labelString>
> >  </label>
> ></topic>
> >
> >This case is pretty clear, right?
> >(<labelString> I had invented just now and for the purpose of this
example
> >only)
> >
> >So is the case that Mark had questioned about.
> >Just imagine <label> elements in place of <baseName> with merge="off".
> >A little confusing, but ...
> >
> >--Nikita.
> >
> >
> >----- Original Message -----
> >From: "Jan Algermissen" <algermissen@acm.org>
> >To: <sc34wg3@isotopicmaps.org>
> >Sent: Wednesday, September 04, 2002 2:29 PM
> >Subject: Re: [sc34wg3] Question on TNC / Montreal minutes
> >
> >
> > > Marc de Graauw wrote:
> > >
> > > > Also: is this Topic Map (going to be) valid?
> > > >
> > > > <topicMap>
> > > >
> > > >   <topic id="t1">
> > > >     <baseName>
> > > >       <baseNameString merge="on">Mama Cass</baseNameString>
> > > >     </baseName>
> > > >   </topic>
> > > >
> > > >   <topic id="t6">
> > > >     <baseName>
> > > >       <baseNameString merge="off">Mama Cass</baseNameString>
> > > >     </baseName>
> > > >   </topic>
> > > >
> > > > </topicMap>
> > >
> > > How interesting...this raises the question if the
> > > 'causeTNCbasedMerge'-flag is a property of a) the basename or b) the
> > > particular association between the topic and its base name.
> > >
> > > If it is a) then the above topic map would not be valid I think,
because
> > > a basename would either be triggering a merge or not. This also seems
to
> > > demand that the value of the merge attribute has to be the same for
> > > all basenames that are equal. But then, isn't it the topic map
processor
> > > that eventually decides how it interpretes 'equal' ? This would then
> > > lead to a situation where a map might be valid in the context of the
> > > author (suppose the author thinks of 'char-by-char' equality) but
might
> > > be invalid for some topic map engines (that propably apply a case
> >insensitive
> > > interpretation of 'equal')....???
> > >
> > >
> > > If it is b) then the merge attribute should be on the <baseName>
element
> > > and would mean: "whatever other pieces of the map say, don't merge
this
> > > topic with other topics that happen to have the same name (in the same
> >scope).
> > >
> > >
> > >  Jan
> > >
> > >
> > > > Thanks for clarifying,
> > >
> > >
> > > >
> > > > Marc
> > > >
> > > > _______________________________________________
> > > > 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
> > > _______________________________________________
> > > sc34wg3 mailing list
> > > sc34wg3@isotopicmaps.org
> > > http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
> > >
> > >
> > >
> >   Nikita Ogievetsky,             Cogitech Inc.
> >   Topic Maps Tutorials and Consultancy
> >   nogievet@cogx.com   --   (917) 406-8734
> >   http://www.cogx.com     Cogito Ergo XML
> >
> >
> >
> >_______________________________________________
> >sc34wg3 mailing list
> >sc34wg3@isotopicmaps.org
> >http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
>
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3@isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
>
>
>