URL labels on ref. items: summ. & cl

[Jul,Erik]

Steve Morris writes:

>  I'd like to learn a bit more about PURL resolution performance first.

In form and function, PURLs are URLs.  Instead of pointing directly to a 
network resource or service, PURLs point to a PURL server, which "resolves" 
the PURL--that is, determines the actual URL associated with the PURL--and 
returns the URL to the requesting client.  The client (i.e., your Web 
browser) then executes the URL protocol as appropriate.  In terms of the 
HTTP protocol, this is known as an HTTP redirect.

This process adds a series of transactions: PURL to PURL server, PURL 
resolution,
HTTP redirect.  This process, however, is nearly instantaneous.

> And unless the original URL is built into the PURL (and easily 
identifiable
> as such) there would be the loss of the subtle information that the 
original
> URL imparts.

True.  The PURL character string and the URL character string can be 
completely dissimilar.  This can be an advantage or a disadvantage, 
depending on your perspective.

URLs that attempt to convey meaning (embed semantics in the character 
string) run the risk of becoming overly long and complex.  This is mitigated 
to the extent that the semantics of the character string are considered 
valuable.  In studies of FTP sites in which the directory structure was 
intended to provide semantic structure, the method proved unreliable and 
insufficient to communicate information about the resource.  This would 
indicate that similar attempts to communicate meaning in URL character 
strings may similarly prove unsatisfying.

Alternatively, PURLs can comprise arbitrary characters that may or may not 
convey meaning to the average user.  Analogous systems include coding 
schemes such as ISSN or ISBN, which contain meaning in certain contexts but 
also serve arbitrarily as inventory control or access numbers.

Whether the PURL is semantically expressive or essentially arbitrary, it 
would be nice to be able to find out more about it.  This need is addressed 
in the PURL server.  Users can search the PURL database to obtain this 
information.

For example, take the PURL http://purl.org/oclc/oluc/36152881/1.  While this 
PURL does contain some semantic information, to most users it is an 
arbitrary character string.  If you search the PURL database 
(http://purl.org) using any or all of the PURL string as the search term, 
the PURL server displays the associated PURL maintenance record, which 
contains the actual (current) URL.  In this example we learn that the URL is 
http://www.nalusda.gov/bic/bio21.

In this example, because the PURL happens to be associated with a cataloged 
resource, you can link to the associated bibliographic record.  (Try it!)
Of course, this provides much more information that could ever be 
communicated in a
PURL or URL character string, no matter how long and complex.

Users can accomplish the same results as follows:

http://purl.org/service/display/http://purl.org/oclc/oluc/36152881/1
|-----request command----------|------------PURL of interest---------------|

This will take the user directly to the PURL display page.  (Try it!)

Thus, PURLs and the PURL server provide a range or services from simple 
resolution to the creation and maintenance of PURLs to providing information 
*about* the PURL and, in some instances, about the resource itself if a 
cataloging record or some other metadata record exists.  If viewed on a 
continuum, we see:

PURL-------->URL--------->Metadata record--------->Resource

as a possible sequence of information discovery.

> One problem: not being familiar with the resolver, I'm not
> sure if PURL updating could be automated by a script in batch sessions.

PURLs can be updated in a batch process.

Hope this helps.  Comments, questions, or discussion welcome.

 --Erik

Erik Jul
jul at oclc.org