[topicmapmail] PSIs?

[Lars Marius Garshol]

* Lars Marius Garshol
|
|   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?

* Murray Altheim
| 
| Both are considered subject identifiers. 

In that case we have a problem. Which one am I supposed to use in my
topic maps/schemas? And which one is validation software going to look
for? What happens if I use one and you use the other? Indeed, why have
two at all?

Note also what the PubSubj TC document says:

  "A Published Subject Indicator must explicitly state the unique URI
  that is to be used as its Published Subject Identifier."
            <URL: http://www.ontopia.net/tmp/pubsubj-gentle-intro.htm >

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

Why not make the <subjectIndicatorRef/> in the XTM document point to
the URI derived from the XSD Recommendation? Then you have no loop,
and everything should be fine. You can have a single URI and simplify
your document quite a bit.

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

Well, if those are the PSIs I think you should take away the XSD
URIs. Note also that for those to be the PSIs would not be in line
with what OASIS is recommending.
 
* Lars Marius Garshol
|
|   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?
 
* Murray Altheim
|
| Could you propose a definition for this and perhaps an example? 

It need not be very complicated. Something like this might do the
trick:

  type-constraint(weight : occurrence, integer : type)
  unit-constraint(weight : occurrence, kilos : type)

This basically says that all occurrences of type weight must be
integers and that they must be specified in kilos. 

The point of doing it this way is that now you can actually do
validation with this. If we didn't do it this way I could have done

  {lmg, weight, [[2003-04-04]]} / date gregorian

and the validator would have said that this was fine, even though it
is of course nonsensical. Using the PSIs I propose above it would look
like this:

  {lmg, weight, [[2003-04-04]]}

and the validator would complain when it found a 'weight' occurrence
that is not an integer.

* Lars Marius Garshol
|
|   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".
 
* Murray Altheim
|
| 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.

Hmmmm. What definitions are given for this in XSD? I didn't know they
even had this stuff in there.
 
* Lars Marius Garshol
|
| 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.
 
* Murray Altheim
|
| 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).

I agree, but I think it's possible to create a validator API for TMAPI
that is independent of how the schemas for the topic maps are specified.
So we might be able to create something that works with AsTMa!, OSL,
your PSI set, and also the final TMCL when that is ready.

The OKS already has an API of this kind in it.

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