OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [xtm-wg] "subject-descriptor-ness" scoping topic


Steven,

I like the concept, it is great
and takes care of many potential problems.

My question is more about the chosen syntax.
I will try to be more clear.

Is it true that in the proposed syntax model
the only way to say that one topic occurs
in another topic is by means of "association"?
And "topicRef" always means subject descriptor of a topic?
irrespectively of "instanceOf" and "scope" ?

In other words,
is the following valid:

<topic>
<baseName>smart-guy</baseName>
<occurrences>
   <instanceOf>publications</instanceOf>
   <resource>
   <scope>
     <topicRef xlink:href="#xml"/>
   </scope>
   <topicRef xlink:href="urn:bla:bla:isbn:1-23234-456"
referent="isSubject"/>
   <topicRef xlink:href="urn:bla:bla:isbn:8-98764-987"
referent="isSubject"/>
  </resource>
</occurrences>
</topic>
<topic>
<baseName>smart-guy's-coauthor</baseName>
<occurrences>
   <instanceOf>publications</instanceOf>
   <resource>
   <scope>
     <topicRef xlink:href="#xml"/>
   </scope>
   <topicRef xlink:href="urn:bla:bla:isbn:1-23234-456"
referent="isSubject"/>
  </resource>
</occurrences>
</topic>

Thanks,

Nikita.

[Steve]
> [Nikita Ogievetsky:]
> > [Steve]  [1]
> > >  Anyway, in the graph, the presence of a special
> > > XTM-defined public subject -- conveying, among other things, the
> > > notion of "subject-descriptor-ness" -- in the scope of an occurrence
> > > indicates that the occurrence is a subject descriptor.
>
> > [Steve]  [2]
> > > Therefore, the distinction of being a subject descriptor is not
> > > conferred by adding a <topicRef> to a scope; the notion of scope does
> > > not apply here.  The distinction is conferred by using a <topicRef>,
> > > rather than a <resourceRef>, in the <resource> that specifies the
> > > information as an occurrence.
> > ...
> > > * To specify the subject descriptor of a topic, make the subject
> > >   descriptor an occurrence of that topic.  However, instead of using
> > >   <resourceRef> to point at the subject descriptor, use <topicRef>
> > >   instead.
> >
> > It seems contradictory to your [1] statement.
> >
> > I still like "subject-descriptor-ness" scoping topic (theme).
> > Otherwise you can not state that a topic occurs in another topic
> > (you will have to use topicRef for this)
> > without implying identity.
>
> I don't *think* it's contradictory...  I'm trying to explain that
> *both* of the following things happen in the graph when you use a
> <topicRef> to refer to a resource in order to make it an occurrence
> characteristic:
>
>  (1) one of two special XTM-defined topics (one is "referent is
>      subject descriptor that describes the subject", the other is
>      "referent is subject descriptor that is the subject") is added to
>      the scope of the occurrence, and
>
>  (2) the occurrence is regarded as a subject descriptor, which may
>      have significant impact on the graph construction process, by
>      causing the various <topic>s that regard it as a subject
>      descriptor (in the same sense -- see below) to merge into a
>      single topic node.
>
> We're proposing that both of these things happen, at graph
> construction time, simply because you used a <topicRef> rather than a
> <resourceRef> to point at the occurrence.
>
> At a conceptual level, the notion of "subject-descriptor-ness" is
> quite distinct from the notion of "occurrence-ness".  What we're
> proposing here is that, as a practical matter, it makes sense to
> regard any subject descriptor as an occurrence, as well as a subject
> descriptor.
>
> We're also saying that it makes sense to use, as a subject
> descriptor, something that actually provides information about what
> the subject of the topic is.  (A subject descriptor could give no
> information at all, and still perform its merge-controlling function:
> if two <topic>s regard the same information object as their common
> subject descriptor (in the same sense -- "describesSubject" or
> "isSubject"), then the two <topic>s will be merged into a single topic
> node at graph construction time.)
>
> The alternative is to divorce the idea of "subject binding point" from
> the idea of "subject description".  From an information interchange
> perspective, the idea of using, as a subject binding point, something
> that does not somehow describe the subject, makes no sense to me.  It
> would lead us to a place where an address is extremely significant, but
> nothing has to exist at the address, and the address doesn't even have
> to make any sense.  I personally would see such an outcome as
> detrimental to the accomplishment of the mission of topic maps, not to
> mention disastrously confusing for anyone who has common sense.



-------------------------- eGroups Sponsor -------------------------~-~>
Create your business web site your way now at Bigstep.com.
It's the fast, easy way to get online, to promote your business,
and to sell your products and services. Try Bigstep.com now.
http://click.egroups.com/1/9183/1/_/337252/_/973715826/
---------------------------------------------------------------------_->

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC