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

From: Kristof Zelechovski <[email-masked]>
Date: Tue, 19 May 2009 21:51:48 +0200

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.

Use case

The authorities of Republic of Poland publish the acts of law in a serial
publication called The Journal of Statutes with the corresponding URN
urn:ISSN:0867-3411.  It is common for Web content related to Polish law to
refer to individual acts of law contained within this publication; this URN
is not sufficient for the purpose.

Benefits

Allowing ISSN NID to refer to fragments of particular publications would
allow: 

*	content management systems - to supply the correct human-readable
reference to the fragment,
*	Web browser protocol handlers - to provide textual information about
the availability of the particular issue both in printed and downloadable
form.

Proposed Solution

Allow extended ISSN of the form urn:ISSN:0867-3411:2001:72#747, meaning year
2001, issue 72, position 747, where:

*         The format of the year part is four digits.  

*         The format of the issue number part is generally a number but it
depends on the publication; several publications have several versions of
the same issue with varying components; the versions are distinguished by an
alphabetic suffix appended to the issue number.  Formally, the issue number
can contain any characters allowed in an URI, except the reserved characters
as defined by RFC 3986 and the colon character ":", and can contain
percent-encoded characters in the UTF-8 character set.  The colon character
is not allowed because it is reserved for future development.  

*         The meaning of the fragment identifier depends on the particular
publication and it is not defined by the present specification.  The
fragment identifier is supposed to be the position number for scientific and
legal journals that maintain running position numbers, which constitute the
majority of use cases of references to serial publications.  It should also
be possible to address a range of pages within an issue using the syntax
urn:ISSN:0867-3411:2001:72#pages=247-259 ; this way of identifying a
fragment is deprecated when position numbers are provided by the editor.

Known problems

ISSN URN can resolve to electronic publications available in various media
types as well as printed publications.  The meaning of the fragment
identifier part as defined above is valid for printed publications only.  As
the interpretation of fragment identifiers is different for different media
types, the fragment identifier, if carried over from the ISSN URN without
reinterpretation, need not denote a valid fragment identifier in the sense
of the media type of the resource retrieved.  However, if the human reader
can see the identifier of the fragment that is being referred to, he can
find it in the retrieved resource by reading it as if it were a printed
publication.

---

From: David Booth <[email-masked]>
Date: Tue, 19 May 2009 17:59:45 -0400

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.

> 
> 
> Use case
> The authorities of Republic of Poland publish the acts of law in a
> serial publication called The Journal of Statutes with the
> corresponding URN urn:ISSN:0867-3411.  It is common for Web content
> related to Polish law to refer to individual acts of law contained
> within this publication; this URN is not sufficient for the purpose.
> 
> 
> Benefits
> Allowing ISSN NID to refer to fragments of particular publications
> would allow: 
> 
>       * content management systems — to supply the correct
>         human-readable reference to the fragment,
>       * Web browser protocol handlers — to provide textual information
>         about the availability of the particular issue both in printed
>         and downloadable form.
> Proposed Solution
> Allow extended ISSN of the form urn:ISSN:0867-3411:2001:72#747,
> meaning year 2001, issue 72, position 747, where:
> 
> ·        The format of the year part is four digits.  
> 
> ·        The format of the issue number part is generally a number but
> it depends on the publication; several publications have several
> versions of the same issue with varying components; the versions are
> distinguished by an alphabetic suffix appended to the issue number.
>  Formally, the issue number can contain any characters allowed in an
> URI, except the reserved characters as defined by RFC 3986 and the
> colon character “:”, and can contain percent-encoded characters in the
> UTF–8 character set.  The colon character is not allowed because it is
> reserved for future development.  
> 
> ·        The meaning of the fragment identifier depends on the
> particular publication and it is not defined by the present
> specification.  The fragment identifier is supposed to be the position
> number for scientific and legal journals that maintain running
> position numbers, which constitute the majority of use cases of
> references to serial publications.  It should also be possible to
> address a range of pages within an issue using the syntax
> urn:ISSN:0867-3411:2001:72#pages=247-259; this way of identifying a
> ISSN URN can resolve to electronic publications available in various
> media types as well as printed publications.  The meaning of the
> fragment identifier part as defined above is valid for printed
> publications only.  As the interpretation of fragment identifiers is
> different for different media types, the fragment identifier, if
> carried over from the ISSN URN without reinterpretation, need not
> denote a valid fragment identifier in the sense of the media type of
> the resource retrieved.  However, if the human reader can see the
> identifier of the fragment that is being referred to, he can find it
> in the retrieved resource by reading it as if it were a printed
> publication.
> 
> 
> _______________________________________________
> Uri-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uri-review
-- 
David Booth, Ph.D.
Cleveland Clinic (contractor)

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

---

From: Kristof Zelechovski <[email-masked]>
Date: Wed, 20 May 2009 09:55:10 +0200

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.
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.
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.
What do you think?
Chris

-----Original Message-----
From: David Booth [mailto:[email-masked]] 
Sent: Wednesday, May 20, 2009 12:00 AM
To: Kristof Zelechovski
Cc: 'Slawek Rozenfeld'; [email-masked]; [email-masked]
Subject: Re: [Uri-review] Allow identifying issues with ISSN NID

David Booth

---

From: David Booth <[email-masked]>
Date: Wed, 20 May 2009 19:12:43 +0000

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

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

> uninformative and cannot be easily intercepted by a browser protocol

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

---

From: Leslie Daigle <[email-masked]>
Date: Wed, 20 May 2009 19:51:06 -0400

You should know:  URN syntax (as in, the syntax for URNs, not the ISSN 
NID) does not support fragments.

Best,
Leslie.

Kristof Zelechovski wrote:
>     */Problem statement/*
> 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.
> 
> 
>     */Use case/*
> 
> serial publication called /The Journal of Statutes/ with the 
> corresponding URN |urn:||ISSN:0867-3411|.  It is common for Web content 
>     */Benefits/*
>     * content management systems — to supply the correct human-readable
>       about the availability of the particular issue both in printed and
>       downloadable form.
> 
> 
>     */Proposed Solution/*
> 
> Allow extended ISSN of the form |urn:||ISSN:0867-3411:2001:72#747|, 
> URI, except the reserved characters as defined by RFC 3986 and the colon 
> character “:”, and can contain percent-encoded characters in the UTF–8 
> character set.  The colon character is not allowed because it is 
> number for scientific and legal journals that maintain running position 
> numbers, which constitute the majority of use cases of references to 
> serial publications.  It should also be possible to address a range of 
> pages within an issue using the syntax 
> |urn:||ISSN:0867-3411:2001:72#pages=247-259| ; this way of identifying a 
>     */Known problems/*
> different for different media types, the fragment identifier, if carried 
> over from the ISSN URN without reinterpretation, need not denote a valid 
> fragment identifier in the sense of the media type of the resource 
> retrieved.  However, if the human reader can see the identifier of the 
> fragment that is being referred to, he can find it in the retrieved 
> resource by reading it as if it were a printed publication.
> 
> 
> ------------------------------------------------------------------------
> 

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: "Daniel R. Tobias" <[email-masked]>
Date: Wed, 20 May 2009 20:30:00 -0400

> conventions just as the conventions for URNs were published.

How does any of this become normative, authoritive, and binding on 
anybody including the issuer him/herself?  I own the domain dan.info, 
and I can issue whatever proclamations I want about URIs within it, 
like "http://dan.info/dogs/fido" refers to a dog named Fido, but why 
should anybody regard this as having any standards-level authority, 
and if the following day I said I was only kidding about that dog 
stuff, which statement would have more authority?

-- 
== Dan ==
Dan's Mail Format Site: http://mailformat.dan.info/
Dan's Web Tips: http://webtips.dan.info/
Dan's Domain Site: http://domains.dan.info/

---

From: David Booth <[email-masked]>
Date: Thu, 21 May 2009 08:21:49 -0400

On Wed, 2009-05-20 at 20:30 -0400, Daniel R. Tobias wrote:
> anybody including the issuer him/herself?  

The same way it does for standards organizations.  For the most part,
standards organizations only have as much authority as people choose to
give them: most standards are voluntary.  When W3C issues a standard --
what it calls a "Recommendation" -- it has garnered enough community
support, and the W3C has enough respect as a standards body, that many
implementers *choose* to follow it.  When W3C -- and I'm only taking W3C
as an example -- publishes a specification it creates a social
expectation that if others choose to use it, they will do so in
accordance with the specification.  The big difference between you (as
an individual) issuing a specification and the W3C issuing a
specification is one of degree, not kind: the W3C specification is more
authoritative only because people know W3C's reputation.  This, in turn,
creates the social expectation that people *will* faithfully follow the
specification when they claim to be following it.

See the Architecture of the World Wide Web on URI ownership:
http://www.w3.org/TR/webarch/#uri-ownership

> I own the domain dan.info, 

By doing so dan.info would be establishing itself as unreliable, so
people would be unlikely to use that URI to refer to Fido.

The point is that URNs are not the only *mechanism* that can be used to
establish the URI convention that you want.  http URIs are (in my view)
a superior mechanism to URNs.  But the mechanism is only one part of
establishing the convention.  The important part is to gather sufficient
community support and institutional commitment to back it up, so that it
will have credibility and people will choose to follow it.  And this is
independent of mechanism.