Re: [tm-pubsubj] Comments from Dave Beckett

[Mary Nishikawa <nisikawa@fuchinobe.oilfield.slb.com>]

Bernard,

I think that we can really get somewhere discussing this.  See my 
additional comments below. We need to have terms that are understood by 
everyone, not only the people in the TM community, so this is important. I 
hope you understand where I am coming from.


At 10:51 03/03/20 +0100, Bernard Vatant wrote:
>*Eric Miller
> > >To the extent this group can minimize the necessary "context swap" that
> > >is required from various communities (RDF, librarians, taxonomists,
> > >etc.) that have been targeted to review this work, the better.
>
>*Mary Nishikawa
> > I recall that we agreed to use the DC definition of "resource." We need to
> > add this back perhaps?
>
>Reference : Dublin Core Metadata Element Set, Version 1.1 [DC]
>
>"Each Dublin Core definition refers to the resource being described. A 
>resource is defined
>in [RFC2396]  as "anything that has identity". For the purposes of Dublin 
>Core metadata, a
>resource will typically be an information or service resource, but may be 
>applied more
>broadly."

We should *always* modify  *resources* with  *network retrievable* or as 
you mentioned for the other types. This is what Lars Marius said, and I 
agree with it.

If we do this, then there is no conflict with the RFC def of *resource* 
since we do not use term by itself.

I think we agree on this.


>Does this cover exactly what we mean by "resource" in our document? Not 
>quite sure. It is
>not consistent with 2.4 "most subjects are not resources".

This is not an exact statement, looking at it again. It is also very 
confusing. I think we have been so used to talking like this that it is 
hard to see where others might not understand.

A subject, as such, may not be a *network retreivable resource*

we should avoid using the word *resource* standalone so to speak since it 
will cause confusion. that's all.


>There are some authoritative
>people in this TC who do not like that much the RFC2396 definition of 
>"resource" (even
>indirectly referenced by Dublin Core).

OK, I see your point on this. We do not have to be explicit on this one 
and say that our resource is the resource of the DC, but we will not use 
this word standalong as I mentioned before to avoid confusion.

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

agreed.


> > In addition, we need to look again at using the acronym PSI for both
> > indicator and identifier.
>
>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.

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.


> > dajobe: P3 PSI introduced without definition - is that Indicator or 
> Identifier?
>
>This is the last sentence in the introduction: "This document provides 
>an introduction to
>Published Subjects and defines requirements and recommendations for 
>publishers of PSI
>sets."
>
>Good remark. Using PSIs is useless here anyway, and the notion of PSI 
>sets at that point
>is confusing. The sentence should be cut after "publishers".
>
> > The term "subject identifier" is not in ISO 13250, so maybe we should
> > consider dropping it, since it does cause confusion.
>
><sigh/> Mary, we've had hard time pushing this notion, back in Orlando 
>meeting, and the
>distinction between "identifier for computers" and "indicator for humans" 
>is central to
>the recommendation. If we drop that distinction, it is "tabula rasa" and 
>we are back to
>the starting point of autumn 2001. Is it what you want?

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' !
>
>Some subjects are information resources, and are directly addressable ... 
>If that (2.3)
>was not understood by Dave, who will understand it? This section was 
>added by Steve, but
>I'm not sure it brings anything more than confusion. Maybe we should 
>strike any reference
>to "addressable subjects" since they do not need subject indicators, 
>although they need
>identifiers, but that is the global URI issue, which is not in our TC 
>scope, fortunately
>... we have already worms enough in our can, don't need that one too :))

Now I am confused too :)

We need to be simple and pragmatic. I know what you mean and what this 
passage meant since we have been having this discussion for months now, 
but from your statement above, I don't think that Dave would understand 
what you are talking about.


> > We can think of describing this in prose. I find when I write about
> > published subjects, all I need to define are the indicators and I do not
> > mention the identifiers. It is really not necessary.
>
><deeper sigh/> Mary, I'm sort of desperate to read that ... The 
>identifier is what the TM
>applications will use to merge topics! So how can you sweep it under the 
>carpet? I don't
>understand, really.

  What I meant is, I find that I do not need the term published subject 
identifier(as I, mentioned, I did not used it inmy paper and nobody missed 
it or complained about it not being there). Of course I need the *thing* itself.


>Now, there is something that Dave's remarks made suddenly obvious to me, 
>and that conforts
>my previous message proposing to make Recommendation 6 a Requirement (BTW 
>I had only
>Pete's feedback so far about it).
>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.


This is important, but I think this explanation needs to be clearer. What 
I am saying is we should avoid using *subject* or *published subject* 
modifying *identifier*

I realize that I keep repeating myself, but I want to be sure that this is 
understood.

Cheers,
Mary