[topicmapmail] Dates and Published Subject Indicators

[Lars Marius Garshol]

* Robert McKinnon
|
| > Is there a definition for what should be at the end of a PSI URL?
| 
| The answer in the 20 August 2002 draft of Deliverable 1[2] is:
| 
| "Recommendation 1:
| * A Published Subject Indicator should provide human-readable metadata.
| 
| Recommendation 2:
| * A Published Subject Indicator should provide machine-processable
| metadata.

Be careful not to misinterpret this. This is not the definition of
what goes at the end of a PSI URL. That's defined in the topic map
standard. This is recommendations for what *ought* to be there.

If you put nothing but HTML there you will still be compliant, or even
if you put a GIF there.

| I agree this is very important, especially to allow machine
| generated natural language presentations of information contained in
| a topic map.  The availability of machine-processable multi-language
| metadata at an indicator is an attractive prospect, as it would aid
| the generation of multi-cultural topic map presentations.

No, I don't think that is the way to do it. It is better to store a
machine-interpretable form of the information in the topic map (say a
date as something the topic map processor *knows* is a date) and then
to do locale-specific rendering for each individual user as part of
the rendering process.

Storing multiple renditions generated remotely in the topic map is
architecturally complex as well as being redundant, and so heir to a
host of problems.
 
| The current 27 June 2002 draft of Deliverable 2[3] does not have any
| more details on the nature of machine-processable metadata.
| Currently I favour having XTM metadata available. IMO this will make
| implementing an XTM processing application easier by providing
| metadata syntax the application is already designed to process.

I agree completely. It is a goal for the TC, however, to support both
XTM and RDF, since it would be much better for the two communities if
they could use the same concept of published subjects and the same
URIs.

For a recent example of a published subject set that uses HTML and
RDF, see <URL: http://psi.ontopia.net/rdf/ >.
 
| > Is there a behaviour defined for what a topic map processor should
| > do when a subjectIndicatorRef is parsed?
| 
| I imagine this question will be answered by a recommendation in a
| future Deliverable from the technical committee.
 
No, that is out of scope for OASIS. It's ISO which will define how XTM
is to be processed. You may want to read

  <URL: http://www.y12.doe.gov/sgml/sc34/document/0323.htm >

which explains the standardization process and the various efforts
currently underway.

| I see that Issue 25[4] in Deliverable 2 makes reference to the idea of
| dynamically generated indicators:
| 
| "ISSUE 25: Infinite Subject Sets
| 
| In the case of infinite subject sets (e.g time and space), is it
| possible to allow both subject indicators and identifiers to be
| dynamically created on application's request, and not be static
| documents?"

Yep. This issue is also mirrored in a SAM issue:
  <URL: http://www.ontopia.net/omnigator/models/topic_complete.jsp?tm=tm-standards.xtm&id=infinite-subject-spaces >

This is not one of the currently burning issues, so it may take a
while before this one makes it to the top of the heap.

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
ISO SC34/WG3, OASIS GeoLang TC        <URL: http://www.garshol.priv.no >