A persistent uniform resource locator (PURL) is a uniform resource locator (URL, i.e. a uniform resource identifier, or URI, that is location-based) that is used to redirect to the location of the requested web resource. PURLs redirect HTTP clients using HTTP status codes. Originally, PURLs were recognizable for being hosted at purl.org or other hostnames containing purl. Early on many of those other hosts used descendants of the original OCLC PURL system software. Eventually, however, the PURL concept came to be generic and was used to designate any redirection service (named PURL resolver) that:
has a "root URL" as the resolver reference (e.g. http://myPurlResolver.example); provides means, to its user-community, to include new names in the root URL (e.g. http://myPurlResolver.example/name22); provides means to associate each name with its URL (to be redirected), and to update this redirection-URL; ensure the persistence (e.g. by contract) of the root URL and the PURL resolver services. PURLs are used to curate the URL resolution process, thus solving the problem of transitory URIs in location-based URI schemes like HTTP. Technically the string resolution on PURL is like SEF URL resolution. The remainder of this article is about the OCLC's PURL system, proposed and implemented by OCLC (the Online Computer Library Center).
History The PURL concept was developed by Stuart Weibel and Erik Jul at OCLC in 1995. The PURL system was implemented using a forked pre-1.0 release of Apache HTTP Server. The software was modernized and extended in 2007 by Zepheira under contract to OCLC and the official website moved to purlz.org (the 'Z' came from the Zepheira name and was used to differentiate the PURL open-source software site from the PURL resolver operated by OCLC). PURL version numbers may be considered confusing. OCLC released versions 1 and 2 of the Apache-based source tree, initially in 1999 under the OCLC Research Public License 1.0 License and later under the OCLC Research Public License 2.0 License. Zepheira released PURLz 1.0 in 2007 under the Apache License, Version 2.0. PURLz 2.0 was released in Beta testing in 2010 but the release was never finalized. The Callimachus Project implemented PURLs as of its 1.0 release in 2012. The oldest PURL HTTP resolver was operated by OCLC from 1995 to September 2016 and was reached as purl.oclc.org as well as purl.org, purl.net, and purl.com. Other notable PURL resolvers include the US Government Printing Office (purl.fdlp.gov), which is operated for the Federal Depository Library Program and has been in operation since 1997. The PURL concept is used in the w3id.org, that may replace the old PURL-services and PURL-technologies. On 27 September 2016 OCLC announced a cooperation with Internet Archive resulting in the transfer of the resolver service and its administration interface to Internet Archive. The service is supported on newly created software, separate from all previous implementations. The transfer re-enabled the ability to manage PURL definitions that had been disabled in the OCLC-hosted service for several months. The service hosted on Internet Archive servers supports access via purl.org, purl.net, purl.info, and purl.com. OCLC now redirects DNS requests for purl.oclc.org to purl.org.
Principles of operation The PURL concept allows for generalized URL curation of HTTP URIs on the World Wide Web. PURLs allow third party control over both URL resolution and resource metadata provision. A URL is simply an address of a resource on the World Wide Web. A Persistent URL is an address on the World Wide Web that causes a redirection to another Web resource. If a Web resource changes location (and hence URL), a PURL pointing to it can be updated. A user of a PURL always uses the same Web address, even though the resource in question may have moved. PURLs may be used by publishers to manage their own information space or by Web users to manage theirs; a PURL service is independent of the publisher of information. PURL services thus allow the management of hyperlink integrity. Hyperlink integrity is a design trade-off of the World Wide Web, but may be partially restored by allowing resource users or third parties to influence where and how a URL resolves. A simple PURL works by responding to an HTTP GET request by returning a response of type 302 (equivalent to the HTTP status code 302, meaning Found). The response contains an HTTP Location header, the value of which is a URL that the client should subsequently retrieve via a new HTTP GET request. PURLs implement one form of persistent identifier for virtual resources. Other persistent identifier schemes include Digital Object Identifiers (DOIs), Life Sciences Identifiers (LSIDs) and INFO URIs. All persistent identification schemes provide unique identifiers for (possibly changing) virtual resources, but not all schemes provide curation opportunities. Curation of virtual resources has been defined as, "the active involvement of information professionals in the management, including the preservation, of digital data for future use." PURLs have been criticized for their need to resolve a URL, thus tying a PURL to a network location. Network locations have several vulnerabilities, such as Domain Name System registrations and host dependencies. A failure to resolve a PURL could lead to an ambiguous state: It would not be clear whether the PURL failed to resolve because a network failure prevented it or because it did not exist. PURLs are themselves valid URLs, so their components must map to the URL specification. The scheme part tells a computer program, such as a Web browser, which protocol to use when resolving the address. The scheme used for PURLs is generally HTTP. The host part tells which PURL server to connect to. The next part, the PURL domain, is analogous to a resource path in a URL. The domain is a hierarchical information space that separates PURLs and allows for PURLs to have different maintainers. One or more designated maintainers may administer each PURL domain. Finally, the PURL name is the name of the PURL itself. The domain and name together constitute the PURL's ID.
Comparing with permalink Both permalink and PURL are used as permanent/persistent URL and redirect to the location of the requested web resource. Roughly speaking, they are the same. Their differences are about domain name and time scale:
… excerpt ends here. Continue reading the full article.
