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