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


Help: OASIS Mailing Lists Help | MarkMail Help

tm-pubsubj message

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

Subject: [tm-pubsubj] Published Subject = Subject Indicator + Subject Descriptor

Trying to answer again Mary's interrogations concerning ISO 13250 
vs XTM 1.0 terminology, and pushing the reflection a little further.

The subject line of this message sums it all IMO. We work clearly 
in the perspective of a Web-based use of Topic Maps and 
Published Subjects, where descriptors non available on the Web 
are to be ruled out.

1. Subject Indicator is the address (URL) of the ressource,
to be used through XTM syntax as an identifier for a <topic> 
element, through an xlink attribute in <subjectIndicatorRef> 

One of our TC requirements is to recommend a standard structure 
for those URLs, and Mary's propositions are to be considered and 
discussed. I don't know if the use of www.purl.org namespace is 
the best solution, although I thought about it too. In any case, 
permanent availability of the URL is a requirement that we should 
stick too.

2. Subject Descriptor contains information that *both humans and 
systems* should be able to retrieve when resolving the Subject 
Indicator. We should recommend standard structure(s) (DTD and/or 
XML schema) for the Subject Descriptor that will allow both 
intelligent agents to use their content, not only their address, and 
human authors to understand it.

My opinion a few months ago was, in the spirit of "paradigm 
consistency", that the best structure for a Subject Descriptor 
should be a Topic Map, written in XTM syntax. 
Now I think that would be maybe a mistake. As widely discussed 
on various Topic Maps forums, Topic Maps are in potential danger 
of falling in a recursivity trap, if identity of a <topic> is always 
defined by reference to other <topic> element(s) in the same or 
other Topic Maps. Subject Descriptors should be the points where 
this recursivity ends, where the Topic Maps gain their primitive 
semantics from some meta-level.

That's why in my present view, the Subject Descriptor should be:
-- a standalone ressource, not a Topic Map, to show clearly that it 
lives at the TM meta-level, as an end-of-recursivity-point.
-- certainly using RDF description + Dublin Core elements to be 
consistent and interoperable with other semantic standards.
-- permanently available from the Subject Indicator URL, but also 
portable for off-line applications (e.g. CD-ROM catalogs ...)


Bernard Vatant - Consultant
Mondeca - "Making Sense of Content"

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

Powered by eList eXpress LLC