Print

Print


Hello Ray,

On 18.7.2014 23:17, Denenberg, Ray wrote:
[log in to unmask]" type="cite">

I've started this thread, a sub-thread of the identifier discussion, to focus on the suggestion that BIBFRAME identifiers  (non-http  identifiers)  be expressed as  URIs (non-http URIs)  

 

(To be clear:

> From:  Stuart Yeates

> There are very few identifiers for which there is only one URI form. For

> example Wikipedia has ISBN URLs such as

> https://en.wikipedia.org/wiki/Special:BookSources/0140206523, Amazon has

> theirs, etc, etc.


ISBN is an identifier, but in my opinion the URL above is not. Anyone can incorporate ISBN into a URL which acts as a link to something, but we will open a door to chaos if creation of such URLs has anything to do with identification. But having single ISBN and multiple persistent identifiers (URN & DOI, for instance) and URLs based on it is not a problem if all this metadata is encoded properly. 

 
[log in to unmask]" type="cite">

Yes, non-http URIs can often be turned into http URIs. I am excluding http in this discussion.)

 

Actually one person offered the stronger suggestion that the identifiers all be expressed as URNs.


It is more realistic to suggest that traditional identifiers should be expressed as persistent identifiers including URNs, Handles, DOIs, etc. Please note that unlike traditional identifiers PIDs are not mutually exclusive.

Main reason for preferring PIDs is that they are managed; some more stringently than others, but there is always at least some expectation of e.g. persistence.


[log in to unmask]" type="cite">

 

So,three issues:

1.       How to represent an identifier that does not have a URN form, but can be expressed by another (non-http) scheme, e.g. ‘info:’


URN namespace registration can be made to any existing standard identifier system. For non-standard identifiers such as NBN the registration should specify steps with which the global uniqueness of the identifier is guaranteed (national bibliography number uses e.g. country code for this purpose). 

Using info URIs is not viable, since the info URI registry was frozen in 2010 and there has been no registrations since then (see http://info-uri.info/).

If URN namespace registration is regarded as cumbersome (see below), other PIDs can be used instead.

[log in to unmask]" type="cite">

2.       How to represent an identifier that might have more than one (non-http) URI form. E.g. ‘urn:’ and ‘info:’


It is often the case that persistent identifiers provide different services. Therefore, if ISBN is expressed as URN by the national library, as Handle by a university and as DOI by the publisher, all these PIDs should be represented in bibliographic record with appropriate schemas.


[log in to unmask]" type="cite">

3.       How to represent an identifier that has no URI form at all.



[log in to unmask]" type="cite">

 

 

No URN form  but can be expressed by another scheme.

An example is LCCN. It cannot be represented as a URN, but can be represented as an ‘info:’ URI.   I am assuming that the answer here is to represent it as an ‘info:’ URI, I just want to confirm that everyone agrees.  This would apply as well to ark, pmid  and others.


I am not in favour of using info URIs since the system is no longer being developed. As regards LCCN, LC - or someone acting on behalf of LC - could register a URN namespace for LCCN. LCCNs could also be used as Handles or DOIs, depending on who is providing services based on these identifiers. 
 

[log in to unmask]" type="cite">

 

more than one (non http) URI form.

While there are no subspaces common to:

‘info:’ http://info-uri.info/registry/OAIHandler?verb=ListRecords&metadataPrefix=oai_dc) and

‘urn:’ (http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xml)  

There is quite a body of literature that claims that this or that identifier, in the ‘info’ table, but not in the ‘urn’ table,  is expressible as a URN.  These include sici, doi, and hdl, and perhaps others.  I am assuming that the rule here would be to express these as ‘info:’ URIs, and never as URNs.


Why, especially since info URI home page says that:

prudent adopters should consider migrating their resource identity requirements towards mainstream Web practices over the long term

Bibframe should rely on persistent identifiers which are still being actively developed and used.

[log in to unmask]" type="cite">

 

No URI form

I am hoping that there is unanimous consensus that an identifier whose scheme is not listed in the URN registry should never be expressed as a URN.   But there are quite a number of these, including Ismn, isrc, istc, iswc, legalDeposit, musicPublisherNumber, publisherNumber, stockNumber, strn, systemNumber, and several more.  Getting these registered as URN subspaces is not a practical idea. (And those of you who have registered URN spaces know what a painful process it is.)    I have a radical suggestion: re-open the info: registry  (Jeff?) and register the single space ‘bibframe:’ and structure it’s definition as we want it. For example:  “info:bibframe\publisherNumber\ 256A090”.


Info URI registry has been closed since 2010 and adding bibframe into is not a good solution. Why flog a dead horse? And would registering just "bibframe" be a sufficient solution?

I have written two URN namespace registration requests (NBN and ISBN) and strongly disagree with the statement that the process is painful. IETF does not scrutinize these requests; on the contrary, IMO they could be more conservative (I could have lived without the URN:UUID namespace).

I can help LC experts to write a namespace registration request for LCCN. Such registration would do no harm, and it would not require much time to write the document, especially if details concerning the resolution of URN:LCCNs are left out.

Juha
[log in to unmask]" type="cite">

 

Other suggestions?

 

--Ray

 

 

 



-- 

 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