Subject: Re: [apps-discuss] [urn] URNs are not URIs (another look at RFC3986)

From: "Svensson, Lars" <[email-masked]>
Date: Fri, 25 Apr 2014 15:28:03 +0000

All,

I'll enter the discussion here, commenting on Phillip's mail and add some thoughts of mine that relate to what others have said earlier.

Phillip said in answer to Maurizio: 

> > I am wondering if it is useful and maybe necessary to define what a
>> 'persistent identifier' is .... as many of you said technology is mot persistent
>> per se but policy underpinning the system can make persistent the
>> identifiers and the service linked to them .... in the APARSEN project
>> www.aparsen.eu in WP 22 we reached agreement with many experts about
>> a list of criteria that a 'trusted persistent identifier system' must have and we
>> could start from this work to define a broader consensus .... doing so in my
>> view we  could clearly distinguish between a URN or URI and a PI ... does it
>> sound reasonable?
> >
> 
> People have been compiling wish lists for properties of names for 20+
> years. The issue is not what people would want, it is what they can
> get.
> 
> I can't take the 'urn' approach seriously until someone provides an
> explanation of
> 
> 1) How the persistence properties are to be achieved

It is clear that persistence is not a quality of the identifier syntax but there need to be other things in place, too. What I have understood from the discussion is that people in different communities seem to have a different understanding of what 'persistent' in 'persistent identifier' is supposed to mean and IMO we need to agree on that before we can move forward. My definition is that a persistent identifier is a string that uniquely identifies an object in such a way that there are procedures in place that guarantee that once a specific string has been attached to a specific resource (in the widest sense), that string can never be used to identify any other resource. Period. It does not mean that there persistently (=always) will be a resolution service in place that can resolve a persistent identifier to a resource. Technically, I can have a persistent identifier for a resource even if there is no resolution service available, but of course it is better if there is some documentation on which identifier is tied to which resource. A database with PIs and locators/metadata and a resolver on top of it is *one* way to document that, but I could just as well print 500 copies of a catalogue with identifier/metadata pairs and put those in 500 libraries worldwide and let people look it up there (Kudos to Esa-Pekka Keskitalo for this nice example). As an aside, this is why I keep arguing that urn syntax and urn resolution belong together but still have to be considered separately.

I think that this is similar to what Barry said although I might be biased:

[[
I think both of these confuse the issue.  Given a name, we can often
turn it into a locator.  That's clear, and that's one thing that makes
names useful.  But I think we still need to keep in mind that the
names *aren't* locators.  If I can always take "urn:doi:xyz-abc",
transform it to "http://dx.doi.org/find/xyz-abc", and get a valid
locator for the thing named, that's great.  But it's still the case
that the former is a name and *not* a locator.  And if dx.doi.org goes
away at some point, the thing is still named by "urn:doi:xyz-abc",
even though I can no longer use that locator.
]]

RFC 2141bis states that urn assignment is a managed process. That is how the persistent the connection between identifier and resource is achieved.

> 2) Why a taxonomic distinction between URLs and URNs helps achieve the
> persistence properties.

When someone loses a DNS lease (for whatever reason), there is no guarantee that previously named resources under that DNS name will be available any more. With urn:s (the RFC 2141 kind), the administration of a NID is delegated to an organisation through a managed process including public review.  This means that the responsibility and administration of e. g. urn:nbn:fi cannot suddenly move from the National Library of Finland to e. g. the Swedish Financial Supervisory Authority (Finansinspektionen (FI), http://www.fi.se), who happens to use the abbreviation "fi" as well.
> 
> A name is by definition a signifier that bears only a conventional
> relationship to the thing signified. In the case of DNS that
> relationship is mediated by the DNS infrastructure.

And the DNS infrastructure can and does transfer the responsibility for the domain names between organisations.

> There are only two ways to make an identifier persistent. The first
> being to use an index rather than a name. SHA256(c) is a persistent
> identifier for the content c. Which is what we use in the ni: scheme.
> 
> The second is to have a first come, first served registry that never
> revokes previous assignments.

Yes, and that is what urn NIDs are about. You register a NID and the IETF process ensures that no-one else can be assigned that NID. The resolution might be dependent on the DNS, but the naming need not be.

> Now one could imagine a whole new
> infrastructure for establishing such a scheme. But really, wouldn't
> anyone setting up such a scheme apply for a TLD?
> 
> So now imagine we have .pid which is a first come, first served
> registry that never revokes an assignment or alternatively requires
> the date to be inserted into the HTTP URIs.
> 
> I can give you a HTTP method identifier which is persistent using such
> an infrastructure.
> 
> Now we can argue over whether the proposal I make is actually
> practical. But I think it is at least as practical as all the
> 'persistent identifier' schemes based on a new registry.
> 
> 
> The bottom line is that persistence is a qualified property of a
> naming infrastructure, not a syntactic distinction.

Yes, those are the so called PI Systems Maurizio talks about.
 
> If people want to argue further, I want them to put up and show HOW
> their persistence scheme actually works. No more wish lists or
> requirements for identifiers. I want to see how the scheme works at a
> technical and political level to achieve the persistence requirements.

Quoting Maurizio:
[[
First, in the digital preservation arena we consider that policy are more important than technology actually, all the digital preservation applications have a strong and well defined policy in support of their goals, technology will be migrated in the years. As you said, any technology can become a PI if supported by an appropriate policy and application.
Second, in our recent work we agreed on that a PI is not only a number or string, a PI is a service where to that code an information service is granted by a trusted agency with a defined mandate in time and for a specific user community, this is then case for all the most relevant PI systems like DOI, Handle, ARK, NBN, and for the emerging PI systems for people also. In our work a PI system is composed by a reliable technology, a trusted body offering the service, a policy and mandate by the user community.
]]

I can only agree with that. Persistence of persistent identifiers (the way I understand them) has nothing to do with technology but is a matter of policy and of institutions fulfilling their responsibilities. The identifier as such is only part of a larger ecosystem (the PI System). The German DIN 31646 defines a PI System as a combination of Policies, PI registration, Resolvers and Data Sources, and this is very similar to Maurizio's definition above.

A last comment on the URN vs. URI question: I see nothing so far that prevents URNs (the RFC 2141 kind) to be URIs. One of the issues coming up every now and then is the question if we should allow queries or not. I think we can, but have to differentiate between queries in urn:s and queries targeting resolution services (which is another argument why we need to keep those two separate). Queries targeted at resolution services can be used to specify if I want the identified resource, metadata about the resource or metadata about the identifier (who registered it, etc.). Queries in the urn are specific to the identified resource. As an example: if I have urn:example:google-query and that resolves to https://www.google.com/search?, then urn:example:google-query?q=rfc%202141 would resolve to https://www.google.com/search?q=rfc%202141. So there is a difference in functionality.

Best,

Lars