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] [Fwd: NISO-Sponsored INFO URI Scheme Published]


Bernard Vatant wrote:
> Patrick
> Thanks for the pointer. I was aware of the info URI scheme initiative but
> had not followed the recent developments.
> What strikes me at first reading is that info URIs are by design not
> dereferenceable:
> http://www2.elsevier.co.uk/~tony/info/info.html#usp
> "The unique aspect of info URIs is that info URIs are not dereferenceable.
> The sole purpose of info is the disclosure of the identity of an
> information asset from a public namespace."
> One could say at first sight that this makes info URIs non-conformant with
> PSI Requirement 2
> "A Published Subject Identifier must resolve to an human-interpretable
> Published Subject Indicator."
> But maybe we should consider carefully before striking them out for this
> simple reason. The choice of "non-dereferenceability" (what a word!) 

Yes, one of the sadder impacts of technology. ;-)

> is
> quite argumented at
> http://www2.elsevier.co.uk/~tony/info/info.html#non_deref and I think we
> should read that carefully.
> Although info URIs are not resolvable through the network, their very
> scheme provides completely non-ambiguous definition not only of the
> subject, but of publishing authority through a registration mechanism. So
> by design they are indeed subject identifiers, and intended to be.
> BTW http://www2.elsevier.co.uk/~tony/info/info.html#topic_map
> indicates topic map subject identity as a use case, although it describes
> the URI used as a "public subject indicator", which is not completely
> accurate terminology, should be "published subject identifier", but using
> it that way seems to me completely conformant to the spirit of
> non-ambiguous subject identification, is not to the letter of Deliverable
> 1.
> I think it interprets somehow the requirement of "resolvability" into
> something like:
> "A Published Subject Identifier must provide a non-ambiguous mechanism
> giving access to a unique human-interpretable Published Subject Indicator.
> This mechanism is usually network resolution, but it could be any other
> non-ambiguous process defined by the Publishing Authority."
> Note that "Subject Indicator" is defined in Deliverable 1 like an
> information resource, but not explicitly a network-retrievable one. So
> under those relaxed requirements, info URIs would be conformant PSIs.
> What do folks think ?

I would amend your interpretation to read:

"The Publisher of a Published Subject Identifier must provide a 
non-ambiguous mechanism giving access to a unique human-interpretable 
Published Subject Indicator."

The publishers cited, such as NASA Astrophysics Data System, Library of 
Congress, etc., already have legacy systems in place that provide the 
"unique human-interpretable Published Subject Indicator."

A few other quick points:

First, there is a cost associated with requiring dereferenceable 
identifiers, as noted in the document you cite above:

> Further, if HTTP URIs were used to provide resource representations,
> it must be recognized that managing the namespace and infrastructure
> is a costly enterprise that may not be appropriate or cost effective
> in a given business context.

Second, note that all the extant legacy identifiers become immediately 
usable with this system. No requirement to construct dereferenceable 
URIs, machine/human readable metadata, etc.

Third, and a even more practical concern for PubSubj, can we walk away 
from identifiers that comprise 2.6% of Google space?

Having argued against dereferenceable identifiers early in this process 
I can hardly be considered neutral but I do think this proposal has much 
to recommend itself.

I would suggest that we all spend some time with the full proposal as I 
think it may influence what we determine to be our next deliverables.

Note that I am not arguing that network accessible human/machine 
readable metadata is a bad thing. It would be very useful to users and 
machines alike but useful does not equal required. As noted in the 
proposal we are discussing, publishers are free to do that, just not as 
part of that particular identifier.

Hope you are having a great day!


Patrick Durusau
Director of Research and Development
Society of Biblical Literature
Chair, V1 - Text Processing: Office and Publishing Systems Interface
Co-Editor, ISO 13250, Topic Maps -- Reference Model

Topic Maps: Human, not artificial, intelligence at work!

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