[sc34wg3] New SAM PSIs

[Lars Marius Garshol]

* Murray Altheim
| 
| To my understanding, it wasn't necessary to create new PSIs, but
| merely fix the places the old ones pointed to. Unless I'm
| misunderstanding the issue. So an update to core.xtm would be due,
| not a new set with the existence of the old [broken?] set still
| there and necessarily so as to not break existing XTM software. 

That's something we could have done, but to conform to the PubSubj TC
recommendations we would then have had to switch core.xtm from being
XTM to being HTML...

Another reason for the change was that the old URIs used the term
'class', whereas we've decided to use 'type'.

  <URL: http://www.ontopia.net/omnigator/models/topic_complete.jsp?tm=tm-standards.xtm&id=type-vs-class >

| IOW, I'd have just fixed the topic map, not left it broken and then
| created new PSIs. Also, if the old and the new PSI set are
| identical, but the old set is in some way "incorrect", then merging
| the old with the new just merges a broken set with a non-broken one,
| leaving a broken set again. Follow?

Certainly, but that's only a transitional step in any case.
 
* Lars Marius Garshol
|
| There will be an XTM document you can merge into your topic maps
| that will perform the necessary mapping for you, so I think in
| practice the impact will be slight.
 
* Murray Altheim
|
| Unless the software processes the old as well, and in whatever way
| it is "broken" this has impact. (I can't imagine it honestly would,
| but this seems theoretically true)

I don't think this is an issue, and if it is I don't see what can be
done about it.
 
* Lars Marius Garshol
|
| Either that, or they may require the new one, forcing users to
| either change their topic maps or merge in the mapping topic map.
 
* Murray Altheim
|
| I don't think that's a good policy in practice, esp. since the way
| in which the old ones are "broken" is pragmatically hard to
| demonstrate.

It's a policy we won't be able to follow many times, I agree. You can
do it once or twice, but that's about it.
 
* Lars Marius Garshol
|
| The ID link inside the XTM spec are not official URIs, and I don't
| think anyone supports them. Section 2.3.2 of XTM 1.0 implies that
| it's the core.xtm URIs that are to be used.
 
* Murray Altheim
|
| Yes, I agree. Point is, the number of identifiers for a subject
| should be only one.

Depends on what angle you're seeing it from. When you publish a
subject you should only create one subject identifier for it, I
agree. For a topic to have multiple subject identifiers, on the other
hand, is perfectly OK, and definitely unavoidable.
 
* Lars Marius Garshol
|
| These URIs will be typed in quite often by humans, and it's good to
| keep them short. Leaving off the document name also makes us more
| flexible with regard to how the page is produced. We can start using
| server-side includes (.shtml) or some scripting system without
| having to change the URI. So I think this is a feature rather than a
| bug.

* Murray Altheim
| 
| It's a bug if one wanted to use the server-based document locally,
| without a server. There'd be no way to resolve the ID to a document
| absent a server, and therefore no way to use the topics *except* as
| opaque strings. That's a bug in my book.

Not sure I follow you here. Nobody is going to use these documents
locally on amati.petesbox.net, and even if someone intended to do so
they could just resolve references via http like everyone else and get
the same results as everyone else. So while this might in theory be a
problem I don't see how it could be in practice.
 
| Maybe I need to read the PubSubj TC's texts again, but I thought
| that PSIs can resolve to a topic map. 

According to the SAM they can resolve to anything at all, and it's not
even an error if they do not resolve. The PubSubj TC only requires
them to resolve to something human-interpretable.

-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >