ISBNs have been made actionable by mEDRA (Italy) - turned into DOIs. But
the uptake for that in the US, at least in trade, has been nonexistent.
On 7/18/14, 6:16 AM, "Juha Hakala" <[log in to unmask]> wrote:
>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
|