[topicmapmail] Dates and Published Subject Indicators

07 Oct 2002 23:07:49 +0200

* Robert McKinnon

| Is there a definition for what should be at the end of a PSI URL?

Yes. The current SAM draft answers this:
  <URL: http://www.isotopicmaps.org/sam/sam-model/#published-subject-indicator >

Of course, to understand the above you need to read this:
  <URL: http://www.isotopicmaps.org/sam/sam-model/#subject-indicator >

That's all that's said in normative text about this. What it means in
practice is that you should have something that's human-readable,
preferrably HTML. You don't need anything more, but you could have
something else.

| Is there a behaviour defined for what a topic map processor should
| do when a subjectIndicatorRef is parsed?

There is, though I couldn't exactly call it a pleasure to read. The
behaviour depends on the context in which the element occurs. If it is
with a <subjectIdentity> element, the following applies:
  <URL: http://www.isotopicmaps.org/sam/sam-xtm/#N1218 >

If elsewhere, the following applies:
  <URL: http://www.isotopicmaps.org/sam/sam-xtm/#sect-proc-subjectIndicatorRef >

| It would be nice if the URI would be invoked, and if the result is a
| topic then that topic be merged into the parsed representation of
| the topic map. Is this the case?

It is not the case, since the <subjectIndicatorRef> element type is
not required to point to a <topic> element, but to a subject
indicator.

If you are pointing to a <topic> element and want the processor to go
out and retrieve that <topic> just use <topicRef>. That's what it's
for. :)

| My problem is to find a good way to represent dates in a genealogy topic
| map. To me there seem to be three choices:
|
| 1) Use <occurrence> and <resourceData>
| [...]
|
| This results in a more concise format than the other two approaches
| I consider below. However Mary's date of death is not really an
| occurrence of the topic Mary, is it?

By the definition of occurrence in the current SAM draft it is. There
was a long discussion on this recently, which you may want to read:

  <URL: http://www.infoloom.com/pipermail/topicmapmail/2002q3/thread.html >

Look for "occurrence abuse".

| Also I don't get the advantage of having the date as a topic. 

Requires less machinery to represent, generally easier to deal with,
less verbose.

| I might what to query for all associations that involve a specific
| date for example, is this possible if <resourceData> is used?

Certainly it is. The next version of tolog will do it, and I believe
the empolis TMQL may be able to do it already. I can't answer for
AsTMa? or the GWTK query language. The final TMQL will definitely be
able to do this.

Taste differs. I have to say that I consider this approach so klunky
that I can't see any reason to use it.

| Also the base name strings on the association type topic and the
| date topic can be used for natural language generation in a
| presentation of the data.

They could in any case.

| However having a new topic for each date within the topic map seems
| incredibly verbose.

Exactly. :)

| 
| 3) Use an <association> and a <subjectIndicatorRef>
| [...]
| 
| This is the approach I like the most. However I would like the date
| PSI URL to resolve to a topic instance and for the topic map
| processor to use allow access to the base name strings for natural
| language generation in a presentation of the data.

This approach is actually the same as the approach above, except that
you are offloading the work of generating all the verbosity onto
someone else. That could be a web service using XTM Fragments or
something similar (if you'd used <topicRef>, that is), and it would
work, but it would also be very slow and just as complicated as
proposal (2).

I hope this helps. 

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