[topicmapmail] PSIs?

[Murray Altheim]

Lars Marius Garshol wrote:
> (This was written very quickly, and that probably shows. Sorry.)
> 
> * Murray Altheim
> | 
> | I don't follow. If I publish a spec that includes an XTM document,
> | and use its IDs as the PSIs (i.e., make it clear that they are the
> | PSI URLs), but also have subject identity with the URLs found in the
> | XSD spec, what's wrong with that? 
> 
> See <URL: http://www.ontopia.net/tmp/pubsubj-gentle-intro.htm >,
> requirement 2. Basically, that XTM is not human-interpretable.
> (Actually, we should fix that wording. "interpretable" is too broad,
> it should be "human-oriented".)
> 
> | It's not leaving any ambiguity if the spec says use the ones I have
> | created. 
> 
> I agree, though why you would then want the other URIs I don't know.

For the reasons I've stated.

> | I'm very uncomfortable defining PSIs that happen to have a base URL
> | in the W3C namespace/domain, and there might even be legal barriers
> | to me doing so. 
> 
> I agree. The question is whether you are reusing those already there
> or creating new ones.

I would be publishing a specification that overlaps a domain owned by
somebody else. The W3C may wish to publish a PSI set. PSIs are very
likely to be considered IP, and I think that even though we're new to this
territory, my guess is that it's a *very bad* idea for me to publish PSIs
using their URLs.

> | I can, however, publish something within my own namespace/domain and
> | claim subject identity with W3C/XSD, which is what I've done.
> 
> So you don't define PSIs within the W3C domain, just SIs. I'm not sure
> there's a big difference.

As a matter of principle and a matter of law, to me there is a big
difference. Surely you're not insensitive to IP issues?

> * Lars Marius Garshol
> |
> | Unless it also has the PSI URLs in there you'll have to load the file
> | over HTTP to get the equivalence declarations between the PSI and
> | "sID" URLs. That won't work in all cases, of course.
>  
> * Murray Altheim
> |
> | They wouldn't in order to use the PSI set, it's just that if they
> | did, they'd have subject identity with any other PSI that used the
> | XSD definitions, which is whole point of my having them (and to me,
> | the whole point of doing this in topic maps).
> 
> What I'm trying to say is that if I download datatypes.xtm and load it
> from a local file and merge it with one of my own topic maps that use
> the PSIs defined by you they won't merge because the PSIs defined by
> you won't actually be in datatypes.xtm.

Yes it will. Downloaded or on the web, the datatypes.xtm document
has a base URL that is identical, so XML processors that correctly
map the URLs will get the same URLs no matter where the document is.
I even went so far as to get a PURL for this, so even if the hosted
domain it's on currently goes away or I move the document, it still
wouldn't change. From datatypes.xtm:

   <topicMap xmlns="http://www.topicmaps.org/xtm/1.0/"
     xmlns:xlink="http://www.w3.org/1999/xlink"
     xml:base="http://www.purl.org/psi/datatypes.xtm">
   ...

> | Because, as I mentioned above, I want merging behaviour with anyone
> | else's topics that match the XSD subjects.
> 
> Right. My instinct in that case would be to use the XSD ones and claim
> that they already existed and that you are only annotating them.

That's not the kind of claim that would hold up in any court if
the owner of the IP came after me. I don't think this would be
the case with identifiers designed for sharing (such as ISBNs).

> | There is only one single PSI identifier for each subject. I don't
> | see any harm in including the XSD URL as a binding point as well, so
> | long as my documentation (both in the spec and in the comments of
> | the XTM document) make it clear which to use as the PSI.
> 
> I agree there's no harm. I don't feel it's very clean, but you won't
> actively hurt anything.

I think the use case of PSIs sets defined by a topic map but
using non-topic map URLs as originators will be very common,
especially given that the topic map may be used to make various
associations between or characterizations of the PSIs. For
example, the ITIS zoological taxonomy *does* have a canonical
URL for each taxon available, but I'd *still* want to use my
own URL since I want to make associations (that are themselves
PSIs) between various PSIs, in effect mirror the ITIS taxonomic
structure within the topic map. This would be a confusing mess
if some of the PSIs were ITIS-based and some XTM-based. I merely
add subject identity with the ITIS URLs but the entire PSI set
as published has consistent URLs defined by the topic map.

As for being "clean", I guess we disagree. I see this as a very
straightforward topic map:

     a. I use an existing set of stable URLs to establish
        subject identities, in this case they happen to also
        neatly point into a web document.
     b. I make a topic map that establishes a set of PSIs
        based on those web URLs, which also additionally
        provides associations and characterizations about
        the PSIs (such as which ones are classes*, which are
        subclasses, which are typing topics, etc.)

If I have this much difficulty I hate to think what a newbie is
going to suffer in trying to publish PSIs.

Murray

* BTW, you recommended recently that someone not use core.xtm#class.
   There is an existing, installed base of applications that do, and
   no published standard that deprecates that topic map. I, for
   example, have been using #class for several years now, and plan to
   continue (esp. since I disagree with the proposed alternative).
......................................................................
Murray Altheim                  <http://kmi.open.ac.uk/people/murray/>
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK

    Boundless wind and moon - the eye within eyes,
    Inexhaustible heaven and earth - the light beyond light,
    The willow dark, the flower bright - ten thousand houses,
    Knock at any door - there's one who will respond.
                                     -- The Blue Cliff Record