Re: [Uri-review] Allow identifying issues with ISSN NID

[David Booth <[e-mail]>]

On Wed, 2009-05-20 at 09:55 +0200, Kristof Zelechovski wrote:
> Well said, but the only authority to provide such a PURL is ISSN.org, isn't
> it?  (WorldCat.org does not allow to hyperlink to specific issues either.)
> Until ISSN.org provides such functionality, there is no way to encode such
> information in URL.  ISSN.org is big, it may take them three years to set
> things up, if they ever consider it worth doing.

No, it doesn't have to be ISSN.org, although they are a reasonable
candidate.  purl.org itself allows users to manage and allocate
subspaces of the http://purl.org/* URI space:
http://purl.oclc.org/docs/purl_faq.html#toc1.8
http://purl.oclc.org/docs/purl_faq.html#toc3.8
(By the way, purl.org uses the word "domain" to refer to a subspace of a
URI space -- not a domain name like ietf.org.)
So you or some other organization could mint your own PURLs.  

> OTOH, an URN has the following advantages:
> 1.  It is not that arbitrary.  While I am unable to tell what the ISSN.org
> prefix will be, I can imagine what form the URN should take.

The owner of a URI space can define whatever syntactic conventions are
desired for minting URIs in that URI space, and can publish these
conventions just as the conventions for URNs were published.

> 2.  Until that happens, using a http prefix leads to HTTP 404, which is
> uninformative and cannot be easily intercepted by a browser protocol
> handler.

Sure, but until foo-specific resolution mechanisms are widely
implemented for foo URNs, they will be just as useless to a browser as
http URIs that are 404.  But HTTP is already widely implemented.

David Booth

> What do you think?
> Chris
> 
> -----Original Message-----
> From: David Booth [mailto:[e-mail]] 
> Sent: Wednesday, May 20, 2009 12:00 AM
> To: Kristof Zelechovski
> Cc: 'Slawek Rozenfeld'; [e-mail]; [e-mail]
> Subject: Re: [Uri-review] Allow identifying issues with ISSN NID
> 
> I don't see any reason why a URN should not be used to name a set of
> resources.  That URN would have to be different from the URNs used to
> name the individual members of that set though.  What document is
> recommending otherwise?
> 
> However, I personally believe that http URIs are, in virtually all
> cases, superior to URNs.  In essence, http URIs can serve the exact same
> naming functions of URNs, but with the added benefit of *potentially*
> being dereferenceable via an extremely widely implemented protocol --
> HTTP.  This is further explained here:
> http://dbooth.org/2006/urn2http/
> 
> David Booth
> 
> 
> 
> On Tue, 2009-05-19 at 21:51 +0200, Kristof Zelechovski wrote:
> > Problem statement
> > The ISSN NID syntax, as defined in RFC 3044, does not allow to
> > identify specific issues of a serial publication.  It only identifies
> > a serial publication, as a set of past and future issues.  This is an
> > abstract entity and it is not in line with the prevailing URN practice
> > that URN should be used to name concrete resources and not sets
> > thereof.  While the present state of affairs is acceptable, the
> > ability to identify specific issues is missing.
> 
> 
> 
> 
> 
> 
> 
-- 
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.