[sc34wg3] Question on TNC / Montreal minutes
Mary Nishikawa
sc34wg3@isotopicmaps.org
Thu, 05 Sep 2002 14:53:59 +0900
Oh, I forgot to add something. For backwards compatibility, we may need to
have the same structures and constraints for label/lblstring as we have for
basename/bnstring now. So for those who want to use their basenames as only
labels, this would be an easy conversion.
-- Mary
>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