Some purls might not resolve to URLS any more; however they can still denote. http://purl.org/docs/help.html#purladvcreate LCCNs have a specified normal form - see http://www.loc.gov/marc/lccn-namespace.html 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 Simon 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" > <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* *##**$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. > > kc > > -- > Karen [log in to unmask] http://kcoyle.net > m: 1-510-435-8234 > skype: kcoylenet > >