Subject: Re: [urn] I-D Action: draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01.txt

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 16 Dec 2011 14:36:25 -0700

<hat type='individual'/>

On 11/17/11 3:18 AM, Juha Hakala wrote:
> Hello Alfred; all,
> 
> Below is my take on the open issues listed by Alfred, plus some
> additional comments.
> 
> Abstract
> 
> URN is a resource identifier; therefore the end of the last sentence of
> the first para could be changed into ... make available generic and
> persistent network-based resolution services for the identified
> resources (documents, artifacts and other objects, and metadata related
> to them).

See the message I just sent about 2141bis. I think this claim is not
exactly uncontroversial.

> Chapter 2
> 
> Statement "identifiers are never assigned to more than one resource"
> needs some tuning. Resources themselves may be static or dynamic (as
> pointed out in page 19). The identified resource may be a metadata
> record which describes a collection which contains a number of objects.
> The important thing is that the resolution process itself is clear;
> there must always be one and only one entity to resolve.
> 
> Suggested new formulation:
> 
> For the purposes of URNs, a "namespace" is a collection of uniquely
> assigned identifiers.  That is, the identifiers are never assigned to
> more than one resource. These resources may be stable (e.g. a doctoral
> dissertation) or dynamic (e.g. a continuously evolving web site of a
> periodical). When the identified resource is a metadata record, such
> record may describe several objects (such as two versions of a book) or
> a collection of objects. Once assigned, URNs are never re-assigned to a
> different resource.  A single resource, however, may have more than one
> URN assigned to it since the namespaces are not mutually exclusive.

Proposed text is always good, so thanks for sending it.

I don't know if we need to explicitly make a distinction here between
data records/resources and metadata records/resources. Isn't that a
matter for particular namespace definitions?

> Chapter 3.1 Experimental namespaces
> 
> After considering the issue, I am in favour of removing experimental
> namespaces. In 12 years, not a single experimental namespace has been
> registered. Nor do I foresee a need for them, as identifier systems
> which deserve a URN namespace should be relatively stable.
> 
> As an aside, we may need informal and experimental services. But these
> services (or mechanism for registering them) should not be described in
> rfc3406bis, but in rfc2483bis.

I think that makes sense.

> Chapter 3.3 Formal namespaces
> 
> It has been easy to register formal URN namespaces. In order to
> guarantee the reliability and persistence of the URN system, control
> should be tightened in the future, 

Why?

I would not describe the registration process as overly loose. Quite a
bit of attention is paid to registration requests on the urn-nid list.

> and rfc3406bis should provide tools
> for this.
> 
> Given the experiences from the last 12 years, the key factors here are
> scope (type of resources to be identified) and user community (who is
> entitled to assign identifiers in this namespace). Control is the key
> factor; the more clearly the scope and the user community are specified,
> the better. On the other hand, an identifier which covers everything and
> can be used by anybody should be treated with caution, due to overlap
> with all the other URN namespaces and total lack of control in the
> identifier assignment.

Do you have evidence that any existing namespaces are being used in such
an uncontrolled manner?

> To illustrate the problem, we may compare urn:isbn and urn:uuid. ISBNs
> are assigned by large publishers and ISBN agencies for books. The system
> has been in operation for almost 40 years, and is deeply embedded into
> the book trade (which does not mean that everyone uses it correctly, or
> according to the same principles).
> 
> UUIDs can be assigned to everything (including books) by anyone. There
> is no control over this namespace; nobody knows how it is used and by
> whom. Some users may have utilized in a highly useful manner and this is
> to be hoped; once a namespace has been approved it can never be
> discontinued, unless it can be proven that zero URNs have been assigned
> (or remain resolvable).

The UUID namespace is different from the rest. See the thread we had on
this list back in September, starting here:

http://www.ietf.org/mail-archive/web/urn/current/msg01612.html

You wouldn't use the UUID namespace if you had another namespace to use.
If publishers are using that namespace instead of the ISBN namespace,
then that is their fault.

> It is not sufficient to give "some consideration as to the longevity and
> maintainability of the namespace" (see page 6). Careful consideration is
> called for.

Are you proposing that we change "some" to "careful"? That seems fine to
me, since careful consideration is already given.

> As regards the three bullet points in page 7, I suggest the following
> changes:

Those changes are hard to track. Please in the future provide such
changes via the following convention:

OLD
   lorem ipsum foo bar baz qux

NEW
   some new text here

So:

OLD
> -  the organization maintaining the URN Namespace should demonstrate
>       stability and the ability to maintain the URN namespace for a long
>       time, and/or it should be clear how the namespace can continue to
>       be usable/useful if the organization ceases to be able to foster
>       it;

NEW
>    -  the organizations assigning URNs should demonstrate ability and
> competency in name assignment;
>       this should improve the likelihood of persistence (e.g., to
>       minimize the likelihood of conflicts);

That doesn't seem like an improvement to me. You've removed the notion
of organizational stability and added competency. How do you judge
competency? What if the organization hasn't issued URNs before? And are
we really worried about incompetent namespace administrators?

Furthermore, persistence considerations are already contained elsewhere
in the document.

I realize that your text is in fact closer to RFC 3406 (rather than
3406bis), so perhaps the WG might have consensus to keep what's in the
current RFC. But please note that those bullet points are included as
the types of things that people might consider.

OLD
> - the organizations assigning URNs MUST follow the rules and regulations
> outlined in namespace registration reguests. They SHOULD always use the
> identifier which is the best match for the resource at hand (e.g. ISSN
> for serials). However, identifiers which do not have a registered URN
> namespace MUST NOT be expressed as URNs.

NEW
>    -  the user organizations need to commit to not re-assign existing
> names. Old names MUST continue to be valid, even if the owners or assignees
>       of those names are no longer members or customers of these
>       organizations; this does not mean that there must be resolution of
>       such names, but that they must not resolve the name to false or
>       stale information, and that they must not be reassigned.

Why "user organizations"?

And again resolution is creeping in here. That isn't a necessary aspect
of URNs and shouldn't be a core consideration in the assignment of
namespaces.

> If the review process is made more strict, then more time than the
> current two weeks is needed. I suggest a review period of 8 weeks; this
> is still a very short time compared to the life time of namespaces
> (which should equal or exceed that of the URNs in that namespace).

2 weeks has proven to be sufficient, in my experience on the urn-nid list.

> 4.4. Registration documents
> 
> After having written a few namespace registrations, I prefer keeping the
> namespace and community considerations separate. But it is necessary to
> clarify the differences between the two. My take on this is that we
> could rephrase thse aspects into technical and organisational
> considerations.

I agree that registrants are often confused about what needs to go in
the community considerations section.

> Technical (namespace) considerations are primarily technical and should
> outline the scope (types of resources to be identified), identifier
> assignment process, services needed (some of which may be non-existent
> by the time of registration), and the resolution process.
> 
> Organizational (community) considerations should clarify the background
> of the identifier used (formal standard or something else), its relation
> ot other identifier systems with or without URN namespace, and different
> aspects of the user community (who is allowed to assign these
> identifiers; who can use them for resolution; who maintains the
> resolution services). 

That's a good list of considerations. I might add a few more once I have
time to think about my experience with namespace registrations.

> Something may also be said about the costs of
> maintaining the system.

Why?

> IANA review should pay particular attention to the scope and user
> community (from the assignment point of view) issues. Standard
> identifier namespace registrations should always involve the maintenance
> agency of the standard in question.
> 
> 4.4.4 IANA considerations
> 
> There are a lot of strings (in addition to "urn-" that must be reserved
> from IETF point of view, such as uri, urc, url, iana, ietf, iesg, and so
> on.
> 
> All known identifier acronyms should be reserved for those identifier
> systems.
> 
> Registration requests with intentionally misleading NIDs (e.g. NID
> UNESCO when the request has nothing to do with UNESCO) should be turned
> down.

Do you think those restrictions need to be formalized? IMHO coming up
with a complete list of reserved strings is fruitless -- better to leave
this up to the judgment of the reviwers / document sponsor (typically an
AD).

> Validation mechanism (page 20)
> 
> This section may still need some work.
> 
> First, it is possible to validate NSS if the identifier has a mechanism
> for it. 

I think validation applies to a URN, not the NSS.

> For instance, when ISSN or ISBN is used as URN, it is possible
> to check that the namespace specific string is a valid ISBN or ISSN. In
> order to do this, the validator must be aware of the identifier syntax.
> 
> Second (and this is point 1 in the current version of the document), it
> is necessary to check the NID. There are a number of opportunities here.
> For instance, URN parsing may have revealed that the NSS is ISTC.  Even
> if the ISTC string were OK the URN would not be correct, since ISTC does
> not have a URN namespace (which may not prevent some people from using
> NID ISTC). We may also have valid NID (such as ISSN), but NSS that does
> not belong to this namespace; it can be either some other identifier
> (such as ISBN) or something unrecognizable. Such NID - NSS mismatch are
> fatal because they will prevent successfull resolution.
> 
> Third (point 2 in the current document) step is to check if the (valid)
> URN can be used for resolution. Many syntactically URNs will fail at
> this point; for instance, most URN:ISBNs are not functional yet. But
> this has nothing to do with the validity of those URNs; the problem is
> in the infrastructure. Thus this step is not part of the URN validation,
> but it can still be included as validation of the resolution process.

That seems sensible.

> As regards elaboration of services: I am still working on RFC2483bis,
> but completing the first draft take at least a few weeks.

Have you had a chance to work on that yet?

Peter

> 
> Alfred Hoenes wrote:
>> [email-masked] wrote:
>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories. This draft is a work item of the Uniform Resource
>>> Names, Revised Working Group of the IETF.
>>>
>>>   Title     : Uniform Resource Name (URN) Namespace Definition
>>> Mechanisms
>>>   Author(s) : Alfred Hoenes
>>>   Filename  : draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01.txt
>>>   Pages     : 29
>>>   Date      : 2011-10-31
>>>
>>>   Uniform Resource Names (URNs) are intended to serve as persistent,
>>>   location-independent, resource identifiers.  To structure and
>>>   organize their usage, the URN syntax specifies a hierarchy that
>>>   divides the set of possible URNs into "URN Namespaces" that can be
>>>   individually defined and managed.  URN Namespaces in particular serve
>>>   to map existing identifier systems into the URN system and thereby
>>>   make available generic, network-based resolution services for the
>>>   identified documents, artifacts, and other objects (and their
>>>   metadata).
>>>
>>>   To actually leverage such synergetic advantage, URN Namespaces need
>>>   to be specified in a comparable manner, and their Namespace
>>>   Identifiers (NIDs) need to be registered with IANA, so that naming
>>>   conflicts are avoided and implementers of services can follow a
>>>   structured approach in support of various namespaces, guided by the
>>>   registry to the related documents and the particularities of specific
>>>   namespaces, as described in these namespace registration documents.
>>>
>>>   This document serves as a guideline for authors of URN Namespace
>>>   definition and registration documents.  It describes the essential
>>>   content of such documents and how they shall be structured to allow
>>>   readers familar with the scheme to quickly assess the properties of a
>>>   specific URN Namespace.  Further, this RFC describes the process to
>>>   be followed to get a URN Namespace registered with IANA.
>>>
>>>   This document is a companion document to the revised URN Syntax
>>>   specification, RFC 2141bis; it supersedes and replaces RFC 3406.
>>>
>>>
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01.txt
>>>
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> This Internet-Draft can be retrieved at:
>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-urnbis-rfc3406bis-urn-ns-reg-01.txt
>>>
>>
>>
>> [[ speaking as the draft author/editor ]]
>>
>> This is mainly an editorial update, based on received review
>> comments and a bit of on-list discussion.
>>
>> Please see the newly amended Appendix D in the draft for the
>> open issues that need on-list discussion, state your opinions,
>> and provide replacement text snippets where deemed appropriate.
>>
>> The delta information summary for this version inadvertently has
>> been dropped during XML debugging; it will be restituted in the
>> next draft version.
>>
>> Best regards,
>>   Alfred.
>>
>> _______________________________________________
>> urn mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/urn
>>

---

From: Juha Hakala <[email-masked]>
Date: Thu, 22 Dec 2011 15:06:48 +0200

Hello Peter,

Again a few comments below.

>> should be tightened in the future, 

The three most popular persistent identifier systems in existence at the 
moment are Handle, DOI and URN.

Technically speaking, DOIs are Handles. The key difference between the 
two is the level of control; while Handle usage policy is liberal and 
nobody knows have many Handles have been assigned, DOI is centrally 
co-ordinated system where the level of control is high. And there is a 
good chance that DOIs will live longer than normal Handles.

With URN, all namespaces are currently equal, and the reader has no 
simple means of estimating the relative trustworthiness of the URNs 
belonging to different namespaces. But there are ways in which we can 
introduce a simple mechanism with which to indicate that some namespaces 
may be more reliable.

For instance, 3406bis might say that if a namespace does not specify the 
e.g. organisational background and if there is no description of the 
resolution mechanism (or if these descriptions are vague), then the 
registration request may be approved, but the RFC will be only 
informational. On the other hand, if all the essential data is provided, 
the registration could be elevated to standards track (perhaps iff the 
namespace is based on a proper standard). The registration request 
should then contain a question of whether the registrants want a 
standard status to the registration or not.

URN system would still differ significantly from DOI/Handle, since 
instead of a sharp dichotomy, we would have all kinds of shades of grey. 
  Some namespaces such as issn (which will use a single resolution 
service maintained by the ISSN international centre) will be very 
reliable, whereas some other standard track namespaces will be slightly 
less so.

> bit of attention is paid to registration requests on the urn-nid list.

I may have been misled by paying too much attention to UUID. I suppose 
the archive of the urn-nid is accessible so that the URNBIS folks can 
see what has been going on.

> Do you have evidence that any existing namespaces are being used in such

No, and it would be difficult to obtain it. There can be at least three 
kinds of problems: dysfunctional URNs which are not capable of providing 
any services, lack of resolver infrastructure, and lack of URN 
assignment. It is not and it will not be easy to spot these, manually or 
otherwise.

Having said this, it is not hard to find URNs from UUID namespace using 
Google. But trying to resolve

urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

is impossible since I don't know the address of the resolution service.

> http://www.ietf.org/mail-archive/web/urn/current/msg01612.html

OK.

> then that is their fault.

For libraries, NBN is the fall back mechanism when other systems such as 
ISBN cannot be used. I can see the point of UUID namespace from this 
point of view (as the system level fall back namespace). I still have a 
problem grasping how such an abstract namespace would work in practice, 
but that may be a solely personal issue :-).
> me, since careful consideration is already given.

Yes.

>    lorem ipsum foo bar baz qux

OK.
> we really worried about incompetent namespace administrators?

I withdraw the suggestion, except that the competency in identifier/name 
assignment should be added to the old text.
> Why "user organizations"?

It has a different scope: although there will be just one organisation 
which assigns the URN, there will be many more in the foreseeable future 
using the URN to provide services, and they may be tempted to reassign 
URNs at some point.

> of URNs and shouldn't be a core consideration in the assignment of

OK.

> 2 weeks has proven to be sufficient, in my experience on the urn-nid list.

OK; if we allow some registrations to become standards track documents, 
that may (I guess) mean stricter control for those namespaces.
> time to think about my experience with namespace registrations.

OK.

>> Something may also be said about the costs of

Costs of the system and the funding mechanism may have an impact on the 
longevity of the service. I might trust more on a service which is 
relatively cheap and funded from the state budget, than on a system 
which is expensive and dependent on private donations.

> this up to the judgment of the reviwers / document sponsor (typically an

There is no way we could produce a complete list, but we should mention 
the principle of not approving misappropriate NIDs in the RFC so as to 
diminish the risk that somebody who has nothing to do with UN tries to 
register e.g. the namespace identifier "UNESCO".
> I think validation applies to a URN, not the NSS.

We can and should validate NSS (whenever possible) as a part of the URN 
validation process. Generally, such validation can be carried out when 
the identifier contains a check sum. Quite a few of them do, and they 
tend to be very useful.

> Have you had a chance to work on that yet?

Alas, not yet. But I'll restart the drafting tomorrow, 23rd of December, 
and will concentrate on it on 27th and 28th. That may not be sufficient 
to complete the text, and I will face some technical problems in getting 
the XML coding right.

Juha

-- 

  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 [email-masked], tel +358 50 382 7678

---

From: Julian Reschke <[email-masked]>
Date: Thu, 22 Dec 2011 14:21:31 +0100

On 2011-12-22 14:06, Juha Hakala wrote:
> ...

Here's a high level comment: I think that adding requirements on 
resolution services is a step into the wrong direction. In particular, 
it's totally OK that urn:uuids are not resolvable, because that's by design.

Do you want to force identifiers like these into different URI schemes? Why?

Also, once you start to focus too much on resolution then you'll 
inevitably get people asking why you don't start with a scheme that 
already is resolvable in the first place. In the end, stability of URIs 
depends mainly on those who mint them, not on the actual notation.

Best regards, Julian

---

From: Juha Hakala <[email-masked]>
Date: Fri, 23 Dec 2011 10:14:03 +0200

Hello,

> it's totally OK that urn:uuids are not resolvable, because that's by 

The current working draft of RFC2483bis makes it clear that there is no 
such thing as an obligatory resolution service. But it does require that 
at least one service is supported, since I could not see the point of 
URNs which are a priori unresolvable.

After reading RFC 4122 (urn:uuid namespace specification) I realize it 
is necessary to drop the resolvability requirement, so RFC2483bis will 
allow namespaces with zero services. This change can be done easily 
enough. Resolution related requirements can be weeded from other 
relevant I-Ds as well.

Is there a way to estimate how widely the UUID community is using 
urn:uuids, and for what purposes?

> Do you want to force identifiers like these into different URI schemes? 

To be honest, I would rather not see another URN namespace like uuid, 
since most users of persistent identifier systems have service 
expectations based on resolvability. And URN:UUIDs a priori will not 
fulfill any of these expectations. But based on what Peter said earlier, 
I suppose URN:UUID is and will be different from (all/most) other URN 
namespaces in this respect.

> depends mainly on those who mint them, not on the actual notation.

Yes, there is a broad agreement among the people who deal with long term 
preservation of digital content that preservation is primarily an 
organizational issue.

The reason why resolution is important is that URN and other persistent 
identifiers will only become popular if they can provide added value; 
services which cool URIs etc. cannot support at all, or could only 
support with difficulty. These services are often based on resolution. 
There are good reasons for keeping services and identification apart 
(for instance, services are technology driven and will change over 
time), which is why the URN community has tried to avoid conflicts here, 
both in the existing URN RFCs and in the documents currently under 
development.

All the best,

Juha

-- 

  Juha Hakala

---

From: Julian Reschke <[email-masked]>
Date: Fri, 23 Dec 2011 09:49:21 +0100

> urn:uuids, and for what purposes?

I think it's safe to say that it's used a lot if you need a globally 
unique URI that doesn't need to be resolvable.

And no, I don't think there's something like an "UUID community"...

> namespaces in this respect.

We should keep that the important point in UR*N* * *naming*.

URNs *can* be (made) resolvable, and URLs *can* be (stable) names.

If this WG believes that urn:uuid is something that is kind of wrong 
then I think we have a problem :-)

>> already is resolvable in the first place. In the end, stability of
>> URIs depends mainly on those who mint them, not on the actual notation.
>

I don't follow. Any kind of organization that can make name-based 
identifiers stable and resolvable *could* do that with HTTP URIs as 
well. It's not a technical problem but only one of organization.

> both in the existing URN RFCs and in the documents currently under

Is this the "HTTP" may go way argument? Even if it does, you will still 
be able to write resolvers, just like what you're trying to do right now 
with URNs.

Best regards, Julian

---

From: Juha Hakala <[email-masked]>
Date: Fri, 23 Dec 2011 13:01:31 +0200

Hello again,

> We should keep that the important point in UR*N* * *naming*.

In my community (libraries & publishing) naming has been taken for 
granted for decades, due to the identifier systems like ISBN and ISSN. 
URN is relevant for us because we need to make these traditional 
identifiers actionable (resolvable) in the Internet. So the important 
point in URN may vary, depending on the implementer community's 
requirements and background.

> URNs *can* be (made) resolvable, and URLs *can* be (stable) names.

True, and the shelf location codes the libraries use could be utilized 
as identifiers too. But approximately 4000 years of practical experience 
has proven that it is a very good idea to separate location information 
and identification, since things do move around, and often in ways that 
haven't been anticipated. Using URLs as names of Internet resources will 
eventually (after a few decades or centuries) get more complicated than 
URN-based solution (which becomes truly useful only when supported by 
some kind of resolution services).
> then I think we have a problem :-)

We do not have a problem, since RFC 4122 and approximately 300.000 
assigned urn:uuid's have settled this issue forever. It is definitely 
not wrong to use UUIDs as URNs. Whether it is a good idea to do that is 
an entirely different question, and one that will be answered by the 
users, not by us. Since many people are using just prefix uuid: instead 
of urn:uuid: there is a chance that at least some people are failing to 
see the point of using URN:UUIDs.

> be able to write resolvers, just like what you're trying to do right now 

No, I was just emphasizing the point that if we piggyback service 
parameters in <query> they will not be part of the URN itself. Whenever 
there are fundamental changes in technology, the URN itself remains the 
same, but the service parameters may be encoded differently.

Best regards,

Juha

-- 

  Juha Hakala

---

From: Julian Reschke <[email-masked]>
Date: Fri, 23 Dec 2011 13:34:21 +0100

On 2011-12-23 12:01, Juha Hakala wrote:
> ...
>> Is this the "HTTP" may go way argument? Even if it does, you will
>> still be able to write resolvers, just like what you're trying to do
>> right now with URNs.
>

(Because the NSS syntax doesn't allow "?").

True, but it *will* be part of the identifier if you view it from a URI 
point of view.

> same, but the service parameters may be encoded differently.

Not convinced; you described one way to add resolution information to 
the urn: URI, creating a different thing that is a different URI.

If you're ok with the URN not being resolvable without additional 
out-of-band information, there are many many other ways to achieve the 
same result.

Best regards, Julian

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 26 Dec 2011 16:26:33 +0900

Hello Juha,

> haven't been anticipated.

This experience applies very much to traditional libraries, where the 
artefacts being stored are physical in nature. The physical nature and 
constraints of e.g. printed books, namely having a number of identical 
copies (because it doesn't matter which one you read) which are 
nevertheless clearly distinct items makes such a two-level distinction 
quite obvious.

However, the "4000 years" is probably too long; before the printing 
press, it was extremely rare that a library had two copies of the same 
book, or if they did, they will have been sufficiently different from 
each other to be worth taking a closer look.

For electronic resources, the physical constraints are virtually gone. 
Copying electronic content is essentially instantaneous and cost-free 
(it may not be legally free, though). If I read a book electronically, 
the library still has it, as does my hard disk and maybe a few caches 
and content delivery networks between the library and me.

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.

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.

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.

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

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.

Regards,    Martin.