RE: [tm-pubsubj-comment] Should we recommend use of XTM?

["Bandholtz, Thomas" <thomas.bandholtz@koeln.sema.slb.com>]

Title: RE: [tm-pubsubj-comment] Should we recommend use of XTM?

-----Original Message-----
From: Steve Pepper [mailto:pepper@ontopia.net]
Sent: Thursday, February 21, 2002 4:33 PM
To: tm-pubsubj-comment@lists.oasis-open.org
Subject: [tm-pubsubj-comment] Comments on my strawman

> ....
> The first point to note is that I have chosen to express my subject
> indicators as topics in a topic map. I believe there will be substantial
> benefits to using a machine processable syntax and, in particular, topic
> maps, for published subjects. Although we have agreed not to REQUIRE any
> particular syntax, I think we should RECOMMEND using XTM and provide
> examples of how to do so.
>
> * Issue: What are the arguments for using a machine processable syntax?
> * Issue: Should we recommend use of XTM?
> .....

We should *recommend* - but not regulate - a machine processable syntax.
We may use XTM in examples, but not explicitely recommend it.

Why?

Jim Mason, Chairman, ISO/IEC JTC1/SC34, posted in http://lists.oasis-open.org/archives/topicmaps-comment/200112/msg00012.html

"We need to keep clear that the transfer serializations are not the definition of Topic Maps: The standard is the definition. SC34 intends that the supplementary standards will clarify the meaning of Topic Maps without changing their essential nature. (We also recognize that other transfer serializations are possible, outside the standard.)"

Or: Michel Biezunski, Martin Bryan, Steven R. Newcomb in http://www.y12.doe.gov/sgml/sc34/document/0277.htm:
"It is important to recognize that information that has the character of Topic Map Information is ordinarily expressed in many different notations. It is highly desirable to be able to federate all kinds of "finding information", not just the finding information that happens to be expressed in one of only two syntaxes."

This should also be valid for PSI. If we bind PSI to XTM (even by recommendation) we are in conflict with statements like these, or we implicitely declare PSI to be an XTM specific feature not valid for TM generally.

 
What is really necessary?

The most important value of PSI is to provide a unique and stable URI to be used as a subject indicator reference.
This can be handled in many ways and formats. If someone ("whosoever") wants to publish subjects about "whatsoever", this should be made as easy as possible. Even a plain HTML file with individual anchors for each subject will provide a set of unique URLs. PS need not to be topics to be used as PSIs.

Even http://www.mu.niedersachsen.de/cds/etc-cds_neu/library/data/gemet_ENG.html?language=ENG&thesaurus=1#desc2501
(GEMET "economics" - remember the discussion?) would do as a subject indicator reference.
And GEMET is *published* set of subjects, but not as a topic map.

I could even use "isbn:3-423-08570-3" as a PSI, as this is a published URI that references a certain book (Goleman's "Emotional Intelligence", in german translation, in this case), although this is not an accessable web link.

I think what W3 states about Namespace Names is applicable to PS documentation sets:
"The attribute's value, a URI reference, is the namespace name identifying the namespace. The namespace name, to serve its intended purpose, should have the characteristics of uniqueness and persistence. It is not a goal that it be directly usable for retrieval of a schema (if any exists). An example of a syntax that is designed with these goals in mind is that for Uniform Resource Names [RFC2141]. However, it should be noted that ordinary URLs can be managed in such a way as to achieve these same goals." http://www.w3.org/TR/REC-xml-names/#ns-decl

Only if whosoever wants to *process* any PS-"characteristics" assigned to the PS, there must be a defined information structure ("machine processable syntax") that *might* be XTM, but any other format is possible. There are ways to negotiate the local structure as part of the communication:

One example is the Web Service Description Language (http://www.w3.org/2002/ws/). Each WSD contains a <types> section where the structure of the data used by the service is described in XML Schema language.

Another example is the Open GIS Consortium Catalog Service (moving to WSDL anyway). It knows a DESCRIBE request that returns a mapping schema. Then you can use this Schema to understand what GETRECORD will return.

Another reason for format tolerance is the usage of Dublin Core. The DC community is completely tolerant about format, though there seems to be a preference for RDF notation. The DCMI Recommendation "Using DC" (http://dublincore.org/documents/2001/04/12/usageguide/)

contains examples in HTML, XML (RDF), and 'in a generic form (Element="value")'.
There is no normative decision:
"When considering an appropriate syntax, it is important to note that Dublin Core concepts are equally applicable to virtually any file format, as long as the metadata is in a form suitable for interpretation both by search engines and by human beings." DC in XML is given in the following example:

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:dc="http://purl.org/dc/elements/1.1/">
          
  <rdf:Description rdf:about="http://media.example.com/audio/guide.ra">
      <dc:creator>Rose Bush</dc:creator>
      <dc:title>A Guide to Growing Roses</dc:title>
      <dc:description>Describes process for planting and nurturing different kinds of rose bushes.</dc:description>
      <dc:date>2001-01-20</dc:date>
  </rdf:Description>
</rdf:RDF>

I think that DC folks will find it hard to understand the XTM encoding, and even that they have to use it when they want to publish subjects.

Thomas Bandholtz
XML Competence Center
SchlumbergerSema
Sema GmbH
Kaltenbornweg 3
D50679 Köln/Cologne
++49 (0)221 8299 264