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