Print

Print

Thanks for splitting this out, Ray!

On Fri, Jul 18, 2014 at 1:17 PM, Denenberg, Ray <[log in to unmask]> wrote:

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)


So to try and rephrase, to make sure I follow... the proposal is that:

1. The subset of identifiers which are NOT already URIs and do not already have a translation mechanism to a URI form, should be expressed as URIs.
2. Those URIs should be non-http URIs.
 

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

For example DOI is trivially turned into an HTTP URI, which is fine, right?

 

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

I have to disagree with this one. If there's an HTTP URI, that's a perfectly reasonable identifier.  It's also entirely anti-thetical to the Linked Data principles.
 

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.


+1.  Any URI is better than a literal :)
 

 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.

If the community that mints those identifiers recommends an HTTP URI, then we should use that, as per the recommendation to use the http://dx.doi.org/ form for DOIs.  We don't want to proliferate even more identifiers if we don't need to.


 

 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.   


+1.  Even things that look vaguely like a URN are often interpreted as being a URN when they're not.  Just the notation of "DOI: 10.1001/1001" looks sufficiently like a URN to have prompted CrossRef to explicitly state that it isn't, and to please not do that.
I don't want to imagine the headaches if a DOI URN scheme was registered by some other organization!
 

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


Or an HTTP space such as Jeff's suggested purl.org. 

For local identifiers, it seems very appropriate for the institution to mint their own namespace. That's what local means, after all :)

HTH

Rob


--
Rob Sanderson
Technology Collaboration Facilitator
Digital Library Systems and Services
Stanford, CA 94305