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

 


Help: OASIS Mailing Lists Help | MarkMail Help

tm-pubsubj message

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


Subject: Re: [tm-pubsubj] Re: [tm-pubsubj-comment] Comments from Dave Beckett


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

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

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

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

> 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 :))

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

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.

Bernard



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