On 17.7.2014 23:34, Stuart Yeates wrote:
> On 07/17/2014 09:39 AM, Denenberg, Ray wrote:
>> I think the advice is:
>> (1) don't use a URI to identify a bf:Identifier.  Treat it as a blank 
>> node.
>> (2) Only a non-URI identifier (e.g. isbn) should be treated a
>> bf:Identifier.  (I.e. a URI  should not be treated as a bf:Identifer.
>> Thus the property bf:uri should be eliminated.)
+ 1.

URLs are neither unique nor persistent and should not be treated as 
identifiers. IMO it would be better not to have them in bibliographic 
records at all. Instead they could be stored in the mapping tables of 
URN / Handle / DOI resolvers. Then we would have just one place in which 
to maintain the location information, instead doing that in hundreds of 
databases holding copies of the bibliographic record. And we could 
provide everyone the extra services URN resolution can provide, compared 
with plain vanilla HTTP GET.

>> I think there is consensus on this, someone correct me if I’m wrong.
> In real systems, won't ISBNs be represented as URNs in the namespace 
> URN:ISBN:... as defined by ?

Well, yes and no.

Since a URN namespace has been registered for ISBNs, it is possible to 
expand every ISBN into a URN. Making that URN actionable is for the time 
being possible only if the address of a resolver is hard-coded into the 
URN like this:

Global resolver discovery service should solve this problem eventually 
for all URN namespaces. Alas, ISBN namespace will be one of the tricky 
ones since many URN:ISBN resolvers are required.

> Are there really any identifiers that we care that aren't already 
> mapped to URNs? If yes, isn't the solution to map them to URNs?

If only it were that easy.

There are several identifier systems which do not have a URN namespace. 
Of course you can construct PIDs like urn:lccn:<lccn-number> but that is 
not "safe" since there is no quarantee that LCCN will get Namespace 
Identifier "LCCN". Moreover, there would be no resolution services 
available for your URN:LCCN:s out there. And since URNs are supposed to 
make existing identifier systems actionable, there is no real point with 
urn:xxx:yyy unless it is a hyperlink. Of course any URN may be 
searchable via Google etc., but that's not enough.

Registering URN namespaces is not difficult. IETF is liberal in what it 
approves, as manifested by urn:uuid. If and when a decision is made to 
register a namespace for LCCN, writing the registration request would 
take maybe a few hours. IMO registering URN namespaces to all key 
bibliographic identifiers would do no harm, and then people could safely 
mint e.g. URN:LCCNs. The next step - how to make them actionable - could 
be more complicated.

The most challenging bit in a satisfactory registration request is to 
specify how URNs in that namespace can be resolved. There are both 
technical and practical requirements which need to be taken into 
account. If the identifier is non-semantic ("dumb"), then there has to 
be a single resource out there where URNs in that namespace are 
resolved. ISSN and ISNI are examples of systems which meet both 
requirements. Then all that is needed is a political decision to 
register a namespace and creation of a URN resolver.

Things get difficult when the identifier provides no hint on how to find 
the correct resolver, and there are several resolvers out there. Of all 
the existing namespaces, ISBN is one of the most complicated ones to 
manage in the Global Resolver Discovery Service, if and when it is 
established.  Of course, there are no problems to find resolvers as long 
as they are "hard-coded" into URNs, but it is to be hoped that that will 
be just an intermediate step.

Best regards,


> cheers
> stuart


  Juha Hakala
  Senior advisor

  The National Library of Finland
  Library Network Services
  P.O.Box 26 (Teollisuuskatu 23)
  FIN-00014 Helsinki University
  Tel. +358 9 191 44293
  Mobile +358 50 3827678