[sc34wg3] New SAM PSIs

[Murray Altheim]

Lars Marius Garshol wrote:
> * Murray Altheim
> | 
> | First, I don't understand what a "subtype loop" is logically,
> | and I can't quite think what it could be, in FOL terms. Steve?
> 
> A subtype loop looks as follows in LTM syntax:
> 
>   super-sub(a : superclass, b : subclass)
>   super-sub(b : superclass, a : subclass)
> 
> (Assuming, of course, that 'super-sub', 'superclass', and 'subclass'
> have been assigned the correct PSIs.)

Okay, so this is something that is syntactically possible but
logically impossible. I'm not sure why it's proposed, unless
there's some domain when something's superclass can also be a
subclass of it. I can't think of any examples.

> | Secondly, pardon my ignorance of the specifics of this document,
> | as I've not read it in great detail, nor have I been privy to
> | the discussions leading to it, but I did notice that the SAM
> | defines a new set of PSIs equivalent to those in XTM 1.0.
> | 
> | I wonder what utility these perform, since they're identical.
> 
> This was the issue psi-topicmaps.org, which we closed in Baltimore.
> See <URL: http://www.ontopia.net/omnigator/models/topic_complete.jsp?tm=tm-standards.xtm&id=psi-topicmaps.org >
> 
> I admit it is something of a pain to have a double set, but we felt
> uneasy about the old PSIs, which do not follow the OASIS PubSubj
> guidelines, and which were also not very clearly defined. 

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. 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?

> 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.

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)

> | This only seems to add confusion and potential ambiguity, in that
> | absent a topic map establishing these identities, implementors must
> | now check a PSI against two sets now, not one (this would be
> | hard-wired into any topic map engine).
> 
> Either that, or they may require the new one, forcing users to either
> change their topic maps or merge in the mapping topic map.

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.

> | We already have two URLs for each (the PSI from the core.xtm topic
> | map and the ID link inside XTM spec), so this makes three.
> 
> 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.

Yes, I agree. Point is, the number of identifiers for a subject should
be only one.

> | Also, I realize that the W3C has gone to great trouble to confuse
> | the world about the syntax of URLs, but absent an HTTP server to
> | link the ID (eg., "type" of
> | "http://psi.topicmaps.org/sam/1.0/#type") with a default document
> | name such as "index.html" (or "index.xtm"), why was the document
> | name left off? 
> 
> 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.

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.

> | It would seem it leaves implementors with little ability to even
> | guess what is at the other end of that URL. (Yes, I do realize PSIs
> | can be considered as opaque strings).
> 
> I think they *should* be considered opaque strings, and that
> implementors should never try to guess what is on the other side.  In
> fact, I think maybe the PubSubj TC should even say this explicitly.

Maybe I need to read the PubSubj TC's texts again, but I thought that
PSIs can resolve to a topic map. If that's been elided, it seems strange
to me. There's certainly supposed to be a human-readable component to
the topic map model, but it also needs to be complete in computer-side
processing. *sigh*

> | Without wishing to open a heated debate, could someone clarify at
> | least the reason for the new PSIs?
> 
> I've tried, but I'm not sure if I've succeeded. You are basically
> right in what you say, so it's difficult to get very geared up about
> your saying it. :)
> 
> Anyway, I was aware of what you said, and so slightly uneasy about
> this change, but went along with it even so.

Decisions are made in committee all the time, some right, some
wrong. I look back on some of those we made in XTM that I agree
with, some I disagreed with, and in retrospect realize that *at
the time* there was simply no way to predict the future. We're
not all wise men and women capable of knowing the impact of each
of these decisions, some technical, some political, some based
on what we think our audience wants and needs. Today I received
a private email from someone saying they were still digging
themselves out of the hole created when RDF hit the streets...
a lot of time has been spent on a flawed early specification,
which rather than fixing its problems, the W3C has patched them
over with new problems introduced by the early ones. I don't
want us to do that.

Murray

......................................................................
Murray Altheim                  <http://kmi.open.ac.uk/people/murray/>
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK

     "In Las Vegas Mr Gates also demonstrated a prototype
      fridge magnet which can be programmed to receive traffic
      reports, sports results and advertisements from local
      restaurants using the same FM signal as the wristwatch."
                                  -- The Guardian, 10 Jan 2003.