Hello,

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 http://www.ietf.org/rfc/rfc3187.txt ?

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:

http://urn.fi/URN:ISBN:978-951-51-0007-8

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,

Juha

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