I like Simon's point that URIs "denote" something. In contrast, it seems like people stuck in the MARC paradigm believe that a record "denotes" something in a disturbingly similar sense. The term "surrogate record" sticks in my craw.



On Jul 19, 2014, at 1:01 PM, Simon Spero <[log in to unmask]> wrote:

Some purls might not resolve to URLS any more; however they can still denote.

LCCNs have a specified normal form - see

purl.org URLs, like handles,  can generate responses based on prefix matches,  so http://purl.org/bibframe/... might only require a singe entry.

It is an open question as to how far generic URLs name,  but can usually be ignored by fixing the meaning to be the referent at a specified time in the actual world.

There are also URI schemes that are approximately rigid- the unofficial magnet URI scheme, and the proposed standard in  http://tools.ietf.org/html/rfc6920


On Jul 19, 2014 12:08 PM, "Karen Coyle" <[log in to unmask]> wrote:

On 7/18/14, 3:34 PM, Robert Sanderson wrote:

Or an HTTP space such as Jeff's suggested purl.org
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 "http://bibframe.org/publisherNumber/256A090". 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
URL: http://id.loc.gov/authorities/names/n96055058

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

074 ##$a277-A-2 (MF)

 and sometimes being multi-part, such as:

017 ##$aEU781596$bU.S. Copyright Office
017 ##$aDL 80-0-1524$bBibliothèque nationale du Québec
017 ##$aPA1116341$bU.S. Copyright Office$d20020703

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] http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet