OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [xtm-wg] Re: Registration Autorities and PSIs


Some months ago - on April 4 to be precise for those who would like to
retrieve it ... and BTW when will we have a topic map for those archives? -
I started a thread called "a challenge on PSI". There were some open
questions pending, and I'm glad we're somehow back to them, even if by some
narrow path I won't comment on ... But I will make two comments on Lars
Marius and Jim last posts.

Lars Marius wrote:
<< Actually, I disagree that the PSIs need to be online. The PSIs are
URIs, not resources, so what they resolve to is immaterial. The
document that defines them needs to be online and permanent, but the
URIs that are the PSIs have no such needs. The URIs, as defined by the
document, are stable, no matter what they do or do not resolve to.>>

One could be really puzzled by such a statement when reading in the
specification:

* published subject indicator :
A subject indicator that is published and maintained at an advertised
address for the purpose of facilitating topic map interchange and
mergeability.

* subject indicator
A resource that is intended by the topic map author to provide a positive,
unambiguous indication of the identity of a subject.

In fact I think we have a big deal of ambiguity in the above last sentence,
and people do interpret variously "provide", because there is no clue for
"to whom" or "to what" this "provide" is aiming to.
If we think only about interchange between systems and mergeability - and my
hunch is that is what Lars Marius has in mind - it's clear that identity can
be provided by a simple URI. Identity in the sense : Topic A and Topic B
have the same PSI URI, hence they have the same <subjectIdentity> and
can/should be merged. The system does not need to "know more" about what
"is" or "represents" or "means" this identity, no more than I have to know
what a, b, c "are" to infer (a=c) from (a=b) and (b=c)
But thinking about it, why do you need an URI there if it's just to compare
strings? It could be any other kind of identifying string - for example a
weird name or id number. In the Mondeca data base, every other topic you add
gets a random number id. For example in the semantopic data base, a topic
named "OASIS" has the id number 10067. Through XML, and then HTML
publication, this topic generates automatically for end-users the URL:
http://mondeca-publishing.com/s/anonymous/title10067.html

If this address is considered stable and authoritative, with all below Jim's
caveats, it could be used by anyone as a PSI. But if you don't need to
resolve it and simply need the system to compare strings for merging, it
could be as well any arbitrary character string like "semantopic10067".

But IMO, and I think also in the mind of those who wrote and approved the
above definitions, there is more to it. When the server is not down, the
above URL yields to human end-user an index page giving all sorts of
characterisics of the topic, which together hopefully "provide a positive,
unambiguous indication of the identity of the subject" to this human reader,
and to any topic map author willing to include that topic in her topic map,
and use that PSI being sure what the subject"is". And that of course is not
possible with a mere "semantopic 10067", or if the resource is not available
because the server is down. But it's clear that we are speaking there of
another conception of identity.

So there is a bottom problem: are PSI (and for that matter the whole TM
thing) for system use only, or also for human users at each end of the
communication chain, both authors and readers? I am among those who tend to
care much more for human users than for what is going on inside the systems.
I know a bunch of other people who, like me, are mainly interested by Topic
Maps as tools for knowledge organization, representation and exchange
between humans through the systems. But maybe we're wrong. Maybe most people
want TM to be created, exchanged, used and read only by systems ...

Jim wrote:
<< I am not taking a formal position on (1) whether PSI thingies must be
accessible online or (2) if the answer to 1 is affirmative, who should be
responsible.
<snip/>
My long-term concern is that if we do decide that there are certain PSIs
that not only are needed for Topic Maps to work but also need to be
accessible, then those things need to be in some reliable place. The Net is
entirely too squishily unstable for me to place much confidence in finding
anything other than a 404 error at the end of a lot of links. I don't want
that to happen with PSIs. >>

Completely true and relevant. And if what you add afterwards about
bureaucraty I'm compelled to approve too, even if I don't fancy it more than
you, I tend to think now that reliable PSIs should not rely on one single
registry, but that some kind of redundant network could allow them to be
accessible even if one of the registries is temporarily or definitely dead.
To be sure to keep something available a long time, there are two ways: keep
it single in a safely guarded place, or make it alive and spread it all over
the planet. My hunch is that in the long run, the latter (DNA strategy) is
more sustainable than the former (bunker strategy).
How to make that technically possible I don't know. But I have confidence,
as always, in all the smart engineers we got out there ...

Cheers all

Bernard

-------------------------------------------------
bernard.vatant@mondeca.com
Mondeca - "Making Sense of Content"
www.mondeca.com
-------------------------------------------------


To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC