Re: [tm-pubsubj] Comments from Dave Beckett

[Peter Flynn <peter@silmaril.ie>]

Mary Nishikawa wrote:

> We should *always* modify  *resources* with  *network retrievable* or
> as you mentioned for the other types.

So long as it doesn't make it unreadable (like if the word occurs
several times in a sentence).

[Eric]
>> Lars Marius has long ago supported that topic maps "subject" and
>> RDF "resource" are equivalent. And if I remember well, in a RDF-TM
>> meeting in Seattle a year ago, this was written down on a board and
>> accepted as a consensus by both TM and RDF folks in the room. So,
>> if we want to be consistent, we should write "information resource"
>> all along instead of "resource".

That would be much clearer for the rest of the world.

[someone]
>>> In addition, we need to look again at using the acronym PSI for
>>> both indicator and identifier.
[Eric]
>> OK. This keeps coming to the surface again and again. I had always
>>  mixed feelings about it. My opinion now is that we should come
>> back to the historical extension of the acronym as Published
>> Subject Indicator. See below.
[Mary]
> Agreed. Using one acronym for two words will always cause serious 
> confusion. I have never changed my position on this one. In my
> Montreal paper, I only used PSI for Published Subject Indicator and
> did not even mention "identifier" in it. I bet nobody missed it. The
> concept of the "identifer is there but I avoid the term to avoid the
> two word/one acronym phenomenom.

As the owner of a large acronym server I have to agree! There certainly
are other fields which have several meanings for one acronym, and I know
they regret it.

I suppose it's too late to start using PSIndic and PSIdent?

> What I mean is, we do not have to state explicitly the term
> *published subject identifier* or *subject identifier*. We reserve
> using *published subject* and *subject* for modifying *indicator*
> only, to avoid confusion and PSI is reserved for this one.
> 
> The identifier is the URI of the published subject indicator.
> 
>>> dajobe: 2.4.2 " The address of a subject indicator is called a
>>> subject identifier." but there is also something else called a
>>> 'subject
>> address' !

We just need a short section giving absolute definitions (with links
to other standards/proposals which use the term the same way, or
differently, so the readers from other fields can see what *we* mean.

[Eric?]
>> The subject identifier (the URI) is a *required component* of the 
>> subject indicator. We have not thought enough about the fact that
>> there are various (unbounded in fact) ways to retrieve the subject
>> indicator (URL redirection, data base queries, whatever). Among 
>> those, only one is the "good" URI, declared as identifier by the 
>> publisher. So this identifier declaration has to be found *inside*
>> the subject indicator. It's not a should, it's a must. Otherwise if
>> the subject indicator is retrieved by a "wrong" URI (e.g. a 
>> redirected URL) there is no way to know that this URI is not the 
>> "good" one, and should not be used as identifier. We have to be
>> crystal clear on the fact that the subject identifier is not any
>> damned URI that can retrieve the subject indicator by any mean, but
>>  *the* URI which is defined and explicitly written down *inside*
>> the subject indicator by the publisher.

The problem is common. http://www.ucc.ie/xml/ is the PSIdent for the
XML FAQ (which I assume could be taken to be the PSIndic for the subject
"Freqently-Asked Questions about XML"). [I hope I have that right :-]

It resolves (at the moment) to http://www.ucc.ie:8080/cocoon/xmlfaq and
of course people have started quoting that URL despite my urging that
it's http://www.ucc.ie/xml/

When we reorganise the server and junk some of the JavaServer dead wood,
Cocoon will be the default servlet, and portions of the long URL will
disappear (including the goddessdamned port 8080 I hope), so it's an
unstable URL whereas the short one is stable.

If I turn the FAQ into a Topic Map, and make it a Published Subject,
I certainly will want to assert the canonicalisation of the short URL.

So how do we get this concepr across?

///Peter