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

David Booth <david@dbooth.org> Tue, 19 May 2009 21:58 UTC

Return-Path: <david@dbooth.org>
X-Original-To: uri-review@core3.amsl.com
Delivered-To: uri-review@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D21C828C383 for <uri-review@core3.amsl.com>; Tue, 19 May 2009 14:58:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.394
X-Spam-Level: *
X-Spam-Status: No, score=1.394 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ka5aRcvA7c8a for <uri-review@core3.amsl.com>; Tue, 19 May 2009 14:58:27 -0700 (PDT)
Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by core3.amsl.com (Postfix) with SMTP id 7AF633A7093 for <uri-review@ietf.org>; Tue, 19 May 2009 14:58:10 -0700 (PDT)
Received: (qmail 27840 invoked from network); 19 May 2009 21:59:45 -0000
Received: from 192.35.79.70 (HELO ?10.78.165.80?) (192.35.79.70) by relay01.pair.com with SMTP; 19 May 2009 21:59:45 -0000
X-pair-Authenticated: 192.35.79.70
From: David Booth <david@dbooth.org>
To: Kristof Zelechovski <giecrilj@stegny.2a.pl>
In-Reply-To: <35A23FE7952844FBA667A306B8CDC982@POCZTOWIEC>
References: <35A23FE7952844FBA667A306B8CDC982@POCZTOWIEC>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 19 May 2009 17:59:45 -0400
Message-Id: <1242770385.12336.386.camel@dbooth-laptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.26.1
Content-Transfer-Encoding: 8bit
Cc: 'Slawek Rozenfeld' <rozenfeld@issn.org>, issnic@issn.org, uri-review@ietf.org
Subject: Re: [Uri-review] Allow identifying issues with ISSN NID
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/uri-review>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 May 2009 21:58:28 -0000

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
> 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.
> 
> 
> _______________________________________________
> Uri-review mailing list
> Uri-review@ietf.org
> 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.