Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01.txt
Juha Hakala <juha.hakala@helsinki.fi> Tue, 10 January 2012 06:23 UTC
Return-Path: <juha.hakala@helsinki.fi>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9476D21F881A for <urn@ietfa.amsl.com>; Mon, 9 Jan 2012 22:23:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.136
X-Spam-Level:
X-Spam-Status: No, score=-4.136 tagged_above=-999 required=5 tests=[AWL=-0.437, BAYES_50=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkS+q1jMYSz3 for <urn@ietfa.amsl.com>; Mon, 9 Jan 2012 22:23:18 -0800 (PST)
Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7A23521F8812 for <urn@ietf.org>; Mon, 9 Jan 2012 22:22:43 -0800 (PST)
Received: from [128.214.91.90] (kkkl25.lib.helsinki.fi [128.214.91.90]) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id q0A6MbOT024786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 10 Jan 2012 08:22:39 +0200
Message-ID: <4F0BD92D.8070108@helsinki.fi>
Date: Tue, 10 Jan 2012 08:22:37 +0200
From: Juha Hakala <juha.hakala@helsinki.fi>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: "\"Martin J. Dürst\"" <duerst@it.aoyama.ac.jp>
References: <201110312251.XAA11909@TR-Sys.de> <4EC4DF6D.7070209@helsinki.fi> <4EEBB9D9.3060505@stpeter.im> <4EF32B68.2070408@helsinki.fi> <4EF32EDB.6040807@gmx.de> <4EF4384B.6090208@helsinki.fi> <4EF44091.3070608@gmx.de> <4EF45F8B.7040509@helsinki.fi> <4EF821A9.3050404@it.aoyama.ac.jp>
In-Reply-To: <4EF821A9.3050404@it.aoyama.ac.jp>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: Julian Reschke <julian.reschke@gmx.de>, urn@ietf.org
Subject: Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01.txt
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jan 2012 06:23:19 -0000
Hello Martin, I agree with you in many respects, but there are some differences of opinion as well. See below... Martin J. Dürst wrote: > Hello Juha, > This means that there is a strong question as to how, and to what > degree, the classical library-based name-location distinction is still > relevant and useful. With that I don't want to say that it's useless, I > just want to say that however many years of "practical experience" you > can claim, that experience may or may not transfer to a world with > essentially different "physical" rules. From a library point of view, for instance the following features of networked resources seem to be in favour of separating identification from location: 1. There may be multiple copies of a single resource in different locations. However a resource should have one and only one identifier. 2. Over time, there may be different resources available from a single location. 3. A single resource may be moved from one location to the next. 4. A digital resource may disappear (leaving only e.g. a printed surrogate). 5. A single file can incorporate multiple resources that should be identified separately; a single resource can span over multiple files. There has also been discussions about persistence (or the lack of it) of domain names, and the need of identifying abstract entities such as works (which may or may not have manifestations in the Web). > Also, at least as far as content is digital text, search engines add > another dimension to this picture. If things move, search engines just > catch up. Especially for specialized content, we are definitely not yet > there yet, but for more general content, the fact that something gets a > different URI isn't the end of the world these days. Search engines do catch up if the resource is not in a non-accessible silo. There seems to be an alarming trend that instead of making resources available in the (semantic) Web, some importand players are preferring to hide their data from the open Web. For resources in silos, it remains to be seen if persistent identifiers will be able to provide access. Moreover, any library has a significant amount of non-textual resources which for the time being are not well catered for by search engines. There are interesting (pilot) services for searching music or still images, but this is not yet mature technology. > So up to the middle ages, we mostly had the situation that one would > hear by chance that a certain library had a certain work, and would > travel to that library and read the work inside that library (though > indeed not on the shelf) if one had that much leisure time. It is a little bit ironic that for the Web content, most national libraries that harvest the Web must rely on similar practice. According to the existing legal deposit & copyright acts the harvested documents cannot be made freely available; the users must come to the national library or other legal deposit libraries in the country, and use the material on dedicated workstations, which are a modern equivalent of the chain that attached the mediaeval books to the shelf so as to protect them against thieves. > > In the "library age", one would go to the nearest public library, ask > e.g. "I want to read Tom Sawyer", got back a question whether one meant > Tom Sawyer by Mark Twain, and then got a "name" (or number) to write on > the order slip, or got directed to the relevant bookshelf (location). > And one would take the book home, and the library would record the > location of the copy in question as "with lender Foo". As an aside, while there is a well functioning business model for scientific periodicals (which, once purchased can be freely used) there is as of yet not a fixed model for e-books. There could be a limited number of electronic items (allowing for instance two users to read an electronic item at the same time), or each lending operation may have a fixed cost, so that one really popular book might take the entire acquisitions budget in a short time. > > In the digital age, we can type something into a search box, get the > content in no time, and never have to "give it back". At the same time, > several copies will have been created. Lots of > names/locations/identifiers (from metadata down to track numbers on a > hard disk) may be involved, but the overall thing may not easily fit an > old-style library name/location dichotomy anymore. The process you describe above applies freely available materials and e.g. commercial scientific periodicals. But for other kind of resources such as e-books things may become more complex, legally and otherwise. As regards the content, an e-book in EPUB 3 format becomes a ZIP container that can and will hold many things (each one of which must be identified separately) in addition to the text of the book, and even the text should adapt itself to different viewers. For the libraries' traditional cataloguing principles these resources will pose interesting challenges. > > > Regards, Martin. > -- Juha Hakala Senior advisor, standardisation and IT The National Library of Finland P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University Email juha.hakala@helsinki.fi, tel +358 50 382 7678
- [urn] I-D Action: draft-ietf-urnbis-rfc3406bis-ur… internet-drafts
- Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bi… Alfred Hönes
- Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bi… Juha Hakala
- Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bi… Peter Saint-Andre
- Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bi… Juha Hakala
- Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bi… Julian Reschke
- Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bi… Juha Hakala
- Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bi… Julian Reschke
- Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bi… Juha Hakala
- Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bi… Julian Reschke
- Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bi… Martin J. Dürst
- Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bi… Juha Hakala
- Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bi… Julian Reschke
- Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bi… Jonathan A Rees
- [urn] OT: urn:iana (was:Re: I-D Action: draft-iet… Peter Saint-Andre
- Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bi… Peter Saint-Andre
- Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bi… Svensson, Lars