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] ANNOUNCE: Update of XTM Repository (new XTM prototype DTD)


[Steve Newcomb:]
> > So here's what happened to 13250's -identity- attribute, according to
> > me.
> >
> > * 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.
> >

[Kal Ahmed:]
> Firstly, as Nikita has pointed out topicRef is missing from the content
> model of either resource or occurrences.

I believe that's simply an editorial problem.  The four syntax editors
discussed it in one of our exhausting marathon teleconference, but
Murray, who has dropped very few stitches indeed, forgot what it was
for, and deleted it, thinking it was an error.  No big deal.  We just
have to fix it.  (Just so you don't think I'm singling out Murray for
opprobrium, I want you to know that I totally screwed up another
content model, but my error was caught and fixed by Murray before the
thing was posted.)

> Is it correct that despite the name, topicRef can reference anything
> which can be used as a subject descriptor (i.e. anything at all) and
> not just a topic [element].

Yes.  <topicRef> makes the thing that it references, if it isn't
already a <topic>, into a topic node that has the thing that was
referenced by the <topicRef> as its subject descriptor.  I believe
this is the key thing we needed to do in order to support RDF in a
reasonable fashion, and, not coincidentally, to round out the
capabilities of topic maps by making them useful for the kinds of
things that RDF is oriented towards doing, including adding metadata
to information resources.

> Furthermore, given that the xlink:href is a URI, is it possible to
> use a URN syntax for the reference.

Yes.

> In other words, can I do this:
> 
> <topic>
> 	<baseName>Kal Ahmed</baseName>
> 	<occurrences>
> 		<topicRef xlink:href="http://www.ontopia.net/people/kal_ahmed/"/>
> 		<topicRef xlink:href="urn:ontopia.net:20001108:people:kal_ahmed"/>
> 		<topicRef
> xlink:href="http://www.ontopia.net/people/topicmap.xtm#kal_ahmed"/>
> 	</occurrences>
> </topic>
> 
> Where the first two are simply URI syntax PSIs in the ISO13250 sense but the
> third is a <topic> which describes the subject should be merged with this
> <topic>. And can I also do this:

Yes.

> <topic>
> 	<baseName>techquila.com</baseName>
> 	<occurrences>
> 		<topicRef xlink:href="http://www.techquila.com/" referent="isSubject"/>
> 	</occurrences>
> </topic>
> 
> Where the subject *is* the internet resource located at
> http://www.techquila.com

Yes.

> Now, assuming that I have got this straight I have just one concern,
> which stems from this question. Is a conformant XTM processing
> application *required* to familiarise itself with all of the subject
> descriptors in a given topic map and to perform the appropriate
> merging ? While I can see that this processing model would be
> desirable, I would hope not that it would not be required for
> conformance, especially if
> http://www.ontopia.net/people/topicmap.xtm is several MB is size...

Yes.  XTM 1.0 won't solve the scaling problem, even though it's not
hard to foresee the existence of multi-gigabyte topic maps.  XTM 1.0
will only solve the interchange problem.  Ultimately, we have to
figure out a way to provide internet-mediated remote access to
pre-built topic map graphs.  Personally, I think this is where TMQL
comes in.  If we can *really* harness all the geniuses involved in
this work, we'll figure out a way to get the *effect* of merging
multiple pre-built topic map graphs without *actually* having to merge
them in a single graph.  But I think that can wait until after we can
do query topic map graphs from remote locations.  One step at a time.

-Steve

--
Steven R. Newcomb, Consultant
srn@coolheads.com

voice: +1 972 359 8160
fax:   +1 972 359 0270

405 Flagler Court
Allen, Texas 75013-2821 USA

-------------------------- eGroups Sponsor -------------------------~-~>
eGroups eLerts
It's Easy. It's Fun. Best of All, it's Free!
http://click.egroups.com/1/9698/1/_/337252/_/973701965/
---------------------------------------------------------------------_->

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