[topicmapmail] PSIs?

[Lars Marius Garshol]

* Murray Altheim
| 
| Okay, it's now done. 

Great!

| I also added another one of my sets -- if you think it's not
| appropriate I'll remove it (it's as much a test case for non-XTM set
| publication and use as anything...).

It's not my page. :-)
 
| Well, I make that statement based on the fact that the draft was
| announced to the topic map community at large via several of its
| mailing lists, but nobody has commented.

That's often the fate of good proposals, I've found.
 
| 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? 

  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?

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

| 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.
 
-- 
Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
GSM: +47 98 21 55 50                  <URL: http://www.garshol.priv.no >