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:’
> and
> ‘urn:’ (
> 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
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

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



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