On 7/18/14, 3:34 PM, Robert Sanderson wrote:
> Or an HTTP space such as Jeff's suggested <>.
This may be a question for Jeff ... must PURLs re-direct to a non-PURL 
URL? - If so, then in any case one will need a conformant non-PURL URL 
for the identifiers.

Taking Ray's example “info:bibframe\publisherNumber\ 256A090” - that 
could be expressed as "". I 
rather doubt that it makes sense to create a PURL for every identifier 
value, although I like the idea that one could re-direct to a more 
authoritative URL when the relevant agency actually instantiates a URL 
form of the identifier scheme.

There's another issue, which is that the "identifiers" in the records 
today aren't normalized. As Thomas Berger points out, already the LCNA 
identifier has a different form when encoded in a URL:

MARC: $a n 96055058

I suspect that Ray's publisher number example has been normalized. Some 
of the schemes are quite awkward in form, using varying punctuation:

*074* 	*##**$a*277-A-2 (MF)

  and sometimes being multi-part, such as:

*017* 	*##**$a*EU781596*$b*U.S. Copyright Office
*017* 	*##**$a*DL 80-0-1524*$b*Bibliothèque nationale du Québec
*017* 	*##**$a*PA1116341*$b*U.S. Copyright Office*$d*20020703

Some of us have the experience of developing search algorithms for these 
identifiers, but search is considerably different from minting a URI - 
to begin with, the usage of these in library systems does not require 
them to be unique; occasionally two normalize to the same string.

What I think we are forgetting here is how we use these various codes 
and numbers. Essentially they are searched and displayed. In the future 
we may be using them for linking. This means that if they are 
"converted" to URLs, they will still need human-readable labels, and 
some thought must be given to how (if?) they can be made searchable.


Karen Coyle
[log in to unmask]
m: 1-510-435-8234
skype: kcoylenet