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


Help: OASIS Mailing Lists Help | MarkMail Help

tm-pubsubj-comment message

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

Subject: [tm-pubsubj-comment] More grumbling

This is a critique of the current strawman proposal, in order to get
what I consider to be the issues with it onto the table where they can
be discussed.

  "In order to facilitate the automated discovery of PSI sets,
  publishers are recommended as far as possible to use URLs that
  contain the token 'psi', for example as a component of the hostname
  or path [...]"

Here it is unclear what "automated discovery" is supposed to mean.
Discovery of what, by what means, and in what context?

In any case, it is very clear that the appearance of the string "psi"
in a URI is by no means sufficient to establish that the URI refers to
a published subject. When doing a simple Google search for "PSI" out
of the first 10 URIs returned, 9 contain that token...

I think if we can specify clearly what it is we want to achieve, we
can do so by different means, but that requires us to be clear about
what it is we want to do.

  "In order to make PS identifiers easier to remember and use,
  publishers are advised to consider using human interpretable strings
  rather than numeric or other values that are not immediately
  interpretable by humans, provided that this does not otherwise
  compromise the stability, longevity, acceptability, or usability of
  the PSI."

My problem with this recommendation is that it is self-contradictory.
Steve's and Bernard's response to that was that in some cases you will
know up front that this is not going to be a problem. There are two
responses to that. 

The first is that if that were true it is still a problem that this
paragraph provides too little guidance on how to tell those cases
apart. To be really effective we should provide more guidance.

The second is that I would not trust myself to be able to distinguish
between such cases. Do you think the people who chose "ROM" as the
identifier for Romania knew that the word meant gypsy, that it would
appear on people's passwords in big yellow letters, and that the
Romanians would object to this?

In computer science it is held to be common knowledge that one should
not create identifiers that have significance to humans, precisely for
this reason.

I would very much prefer that we just leave this out.

  "URNs that conform to registered and approved URN schemes may be
  used as PS identifiers in conformance with this Technical
  Report. However, publishers are recommended to consider the
  implications for usability if there is no well-defined resolution
  mechanism for the URN scheme."

This is bound up with a SAM issue, actually. See

  <URL: http://www.ontopia.net/omnigator/models/topic_complete.jsp?tm=tm-standards.xtm&id=locator-reference >

Basically, what this issue is about is that the [subject address] and
[subject indicator] may, as things now stand, contain locators that
refer to something that is not an information resource. If that
happens the heuristics meant to be provided by these properties no
longer work as intended.

So we need to consider what to do about this. 

At the moment I don't really see why we would want to allow URNs.
Aren't PSIs supposed to have a subject indicator resource somewhere?
If so, why do we want to allow URIs that don't resolve?

  <meta lang="en, fr, jp"/>

This is incorrect HTML. In fact, there's no good way to specify this
in HTML, but then I am not sure we have any need to. I would let it
be. (Yes, there is a lang attribute, but it only supports a single

  <link rel="topicmap" href="http://psi.fruits.org/fruits.xtm";

This raises several different issues. The first is what "rel" values
we should use. Do we need different values for RDF and topic maps? How
do we distinguish different topic map syntaxes? 

The MIME type given here is not valid, since it is not registered. The
question is, should we try to register one for XTM? I am not sure
whether it will be accepted (and it won't help for HyTM and LTM), but
it seems that it could be done without too much work. I volunteer to
do it, if we decide that we want to.

See also the relevant section of HTML 4.01:

  <URL: http://www.w3.org/TR/html401/types.html#type-links >

(Note the stuff about profiles.)

Well, that should be enough grumbling for one email.

Lars Marius Garshol, Ontopian         <URL: http://www.ontopia.net >
ISO SC34/WG3, OASIS GeoLang TC        <URL: http://www.garshol.priv.no >

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

Powered by eList eXpress LLC