[topicmapmail] PSIs?

[Murray Altheim]

Lars Marius Garshol wrote:
> * Murray Altheim
[...]
> | Yes, absent a library to do validation we can't actually use the set
> | for that purpose, but I'm still interested in knowing whether or not
> | the PSI set itself is "correct" or useful for the purpose intended,
> | if it needs more documentation, etc.
> 
> I had a quick look through it and found some issues:
> 
>   a) there is both a "sID" and a "PSI" for each subject. The subject
>      identifier always resolves to the subject indicator, so it's
>      difficult to see how the "PSI" in this document can claim to be a
>      PSI. Or do you define two equivalent subject identifiers for each
>      subject? 

Both are considered subject identifiers. The basis of each comes from
the original XSD Recommendation, each then reified as a topic in an
XTM document. I thought it would be strange to additionally have each
of the topics also include a reference to themselves as subject
identifiers. That kind of semantic recursion is weird. The <topic>
elements *are* the central place where all topic characteristics come
together. I don't think one wants a reference to itself to be included
in those characteristics, and the XTM document creates the set of IDs
that are the PSIs.

>   b) it recommends using scope on individual occurrences to indicate
>      data type and unit of measure. Repeating it on every single
>      occurrence seems to me awkward and error-prone. Why not define
>      PSIs for connecting this information to the occurrence type so
>      that it can be specified there once and for all?

Could you propose a definition for this and perhaps an example? I'm
unclear on why this would be really necessary:

   PSI Title:
   PSI Definition:
   Example:

[If I like the idea I'll certainly acknowledge you in the document.]

>   c) the "language" PSI is already defined by the OASIS GeoLang TC, so
>      you don't need that. Also, I think Example 3 is dubious: the name
>      may be in the scope "French", but I don't think it's in the scope
>      "language".

I do need that since it's in XSD and I'm mirroring the entirety of it.
If indeed the definitions are identical (and I don't know that they
are), then subject equivalence can be included in the XTM document
establishing the PSIs.

> | The PSI set is necessary (IMO) prior to any implementation so that
> | multiple implementations can use the same PSI set and hopefully the
> | same API too. 
> 
> Definitely!
> 
> | It may be Kal or you or I that works up that API, but I'd hope the
> | PSIs would remain stable, IF they are okay. I'll probably be needing
> | a few of them in Ceryle (and would develop validation features for
> | those few), so I'd be happy to cooperate on an API. I don't expect
> | it will be easy.
> 
> I guess this would fall under the TMAPI umbrella, but exactly how to
> structure it I'm not sure of. We'd have to give this one some thought,
> I think.

I think it should be considered an extension of TMAPI, as I'd think
we should keep that API as simple and generic as possible. There are
a *lot* of potential PSI sets as important as datatypes that might
deserve their own API (programmatically).

Murray

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

    Hunt the Boeing! And test your perceptions!
    http://www.asile.org/citoyens/numero13/pentagone/erreurs_en.htm