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

LCCNs have a specified normal form - see URLs, like handles,  can generate responses based on prefix
matches,  so 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

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
> 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
> URL:
> 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]
> m: 1-510-435-8234
> skype: kcoylenet