[topicmapmail] PSIs - alternatives

[Steve Pepper]

* Simon Grant
|
| I think what would be useful to look at is the information
| necessary within the PRI/PRD system as a whole. There is 1. as
| Steve above (providing humans with information) 2. whatever else
| may be necessary towards a self-sustaining infrastructure and
| motivation to use it.
|
| It seems to be Steve's position that all of 2. can be provided
| outside the PRD, with the PRD used exclusively for 1.

No, that's not really my position (although I can see how some of the things
I write might give that impression).

My main point is that we should be extremely careful about keeping agreement
concerning the *identity* of a subject separate from agreement concerning
*opinions* about a subject. We should therefore avoid overloading the PRD
with assertions, especially machine-processable assertions.

However, assertions about the *PRD* (as opposed to assertions about the
subject it describes) are another matter. I have no problem with either
human-readable or machine-processable metadata about the PRD, such as its
publisher, type, date, version, etc. Such metadata can play an important
role in your 2. ("whatever else may be necessary towards a self-sustaining
infrastructure and motivation to use it").

Whether references to other PRIs deemed to be equivalent belong here is
something that needs to be discussed more fully.

How would they be used? Certainly not when actually merging topic maps,
because the whole point of the PRI/PRD mechanism is that computers do not
need to dereference the PRI in order to ascertain if two things are the
same: they simply compare strings.

I guess there could be a use for harvesters that go round collecting such
equivalences in order to build mapping tables, but could the resulting
tables really be trusted? The minter of PRI "X" might claim that it is
equivalent to somebody else's PRI "Y", but who's to say whether the minter
of PRI "Y" agrees with that assertion?

At the very least there are issues here that need to be thought through more
carefully before designing a complete solution. My initial goal with the PRI
initiative is to go for a less complete but more immediately adoptable
solution and then see how things develop.

| This is
| plausible to the extent that proposals for providing the rest of
| 2. are plausible. What I read here is that one class of
| approaches, involving central repositories or directories, is not
| thought to be plausible by many.

I think repositories or directories are likely to be very useful, but I
wouldn't want them to be centralized. Some kind of distributed mechanism
would be far more appropriate. I understand that DCMI (Dublin Core Metadata
Initiative) has something along those lines. Does anyone know more about it?

| A key consideration in discussion here is, what if (as seems
| likely) people persist in minting "their own" identifiers for
| subjects where there are already identifiers? There are many
| reasons why this is likely to happen, including ignorance,
| laziness, and failure of discovery mechanisms, but also
| dissatisfaction with the accuracy or reliability of another
| authority. And when it has happened, as it inevitably will,
| following Steve's "easy for computers" requirement it will be
| essential for everyone to converge on the same one. Will this
| happen, and how long will it take? What will happen in the
| meantime?

My intention is for something like Adam Smith's "hidden hand" of enlightened
self-interest to be brought into play, based on the hope that the desire for
semantic interoperability will prove stronger than the negative factors that
you enumerate. Whether this turns out to be true will depend partly on how
easy we make the mechanism. The bar has to be very low in order to get
traction.

| My suggestion addresses both the situations where people won't do
| the merging, and the situation where alternatives exist prior to
| merging. Having a list of accepted equivalent PRIs included means
| that the machine comparison is still relatively easy - it would
| involve fetching the two PRDs and then string comparison of two
| lists against each other. That's all.

I certainly think there is a place for services along these lines. I've
already created one myself: the mapping between ISO 3166 and CIA country
codes. All I'm questioning is whether it makes sense to include the ability
to specify mappings in the PRD itself. I want PRDs to be as simple as
possible, and I want to encourage reuse rather than a free-for-all. That's
why I suggested a standard way to deprecate one's own PRI in favour of
someone else's: We would get the mapping you want while at the same time
making it clear which is the preferred PRI.


--
Steve Pepper, Ontopian