A persistent uniform resource searcher ( PURL ) is a uniform resource locator (URL) (i.e., location-based uniform resource identifier or URI) used to redirect to location of the requested web resource. PURL redirects HTTP clients using HTTP status codes.
The PURL concept is generic and can be used to designate a redirection service (named PURL resolver ) that:
- has a "root URL" as a reference to resolver (eg
http://myPurlResolver.example); - provides a means, for the user community, to enter a new name in the root URL (eg
http://myPurlResolver.example/name22); - provides a means to associate each name with its URL (for redirection), and to update these redirections;
- ensure persistence (eg by contract) from the root URL and PURL resolver services.
PURL is used to curate the URL resolution process, thus solving transitory URI problems in location based URI schemes such as HTTP. Technically, the string resolution in PURL is like SEF URL resolution . The rest of this article is about the PURL OCLC system, proposed and implemented by OCLC (Center for Online Computer Library).
Video Persistent uniform resource locator
Histori
The PURL concept was developed at OCLC in 1995 and the PURL system is implemented using a pre-1.0 release of Apache HTTP Server. The software was modernized and extended in 2007 by Zepheira by contract to OCLC and the official website moved to http://purlz.org ('Z' derived from the Zepheira name and used to distinguish open source PURL software from PURL resolver operated by OCLC).
The PURL version number can be considered confusing. OCLC released versions 1 and 2 of the Apache-based source tree, originally in 1999 under the License 1.0 Public License of OCLC Research and later under the OCLC Research Public License 2.0 License (http://opensource.org/licenses/oclc2). 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 its release was never completed. The Callimachus project implements PURL on a 1.0 release in 2012.
The oldest HTTP PURL compliant is operated by OCLC from 1995 to September 2016 and is reached as purl.oclc.org and purl.org , purl.net and purl.com .
Other reputable PURL successors include the US Government Printing Office (http://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 w3id.org, which can replace old PURL services and PURL-technologies.
On September 27, 2016, OCLC announced a partnership with the Internet Archive that generated the transfer of resolver services and its administrative interface to the Internet Archive. This service is supported on newly created software, separate from all previous implementations. This transfer re-enables the ability to manage PURL definitions that have been disabled in the OCLC host service for several months. This service is hosted on the Internet Archive Server supporting access via purl.org , purl.net , purl.info , and purl.com . OCLC now redirects DNS requests to purl.oclc.org to purl.org .
Maps Persistent uniform resource locator
Principles of operation
The PURL concept allows general URL classification of HTTP URIs on the World Wide Web. PURL allows third-party control over URL resolutions and the provision of resource metadata.
URL is a resource address on the World Wide Web. Persistent URL is an address on the World Wide Web that causes redirects to other Web sources. If Web resources change location (and hence URL), PURL pointing there can be updated. PURL users always use the same Web address, even though the resources may have moved. PURL can be used by publishers to manage their own information space or by Web users to manage them; PURL services are not dependent on the publisher of information. The PURL service allows hyperlink integrity management. Hyperlink integrity is a World Wide Web design trade-off, but can be partially restored by allowing users of resources or third parties to influence where and how to resolve URLs.
Simple PURL works by responding to a GET HTTP request by returning a type 302 response (equivalent to HTTP status code 302, which means "Found"). The response contains the HTTP "Location" header, whose value is the URL the client must retrieve through a new GET HTTP request.
PURL implements a permanent identifier form for virtual resources. Other fixed identification schemes include Digital Object Identifiers (DOIs), Life Sciences Identifiers (LSIDs) and INFO URIs. All identification schemes still provide unique identifiers for virtual resources (may change), but not all schemes provide curation opportunities. The curation of virtual resources has been defined as, "the active involvement of information professionals in management, including preservation, digital data for future use."
PURL has been criticized for their need to resolve the URL, thus binding PURL to a network location. The network location has several vulnerabilities, such as the Domain Name System registration and host dependencies. Failure to complete PURL may lead to ambiguous circumstances: It is unclear whether PURL failed to complete because network failure prevented it or because it did not exist.
PURL itself is a valid URL, so the component must be mapped to the URL specification. The schema section tells a computer program, such as a Web browser, which protocol is used when resolving an address. The scheme used for PURL is generally HTTP. The host part tells which PURL server to connect to. The next section, the PURL domain, is analogous to the resource path in the URL. Domain is a hierarchical information space that separates PURL and allows PURL to have different managers. One or more designated managers can manage each PURL domain. Finally, the name PURL is the name PURL itself. Domains and names together form "id" PURL.
Compare with permanent links
Both, permalink and PURL , are used as permanent/persistent URLs, and redirects to the requested web resource location. Roughly speaking, therefore, the concept is the same. The main differences in concepts are about domain names and time scales:
- A permalink usually does not change the URL domain, and is designed to last for years .
- The PURL domain name is independently customizable, and is designed to last decades .
Type
The most common PURL types are named to coincide with the HTTP response code they returned. Not all HTTP response codes have an equivalent PURL type and not all PURL servers apply all types of PURL. Some HTTP response codes (eg 401, Unbidden) have a clear meaning in the context of HTTP conversations but do not apply to HTTP redirects. Three additional types of PURL ("chains", "partial" and "clones") are given mnemonic names that relate to their function.
Most PURLs are called "simple PURL", which provides redirects to the desired resources. The HTTP status code, and therefore of the PURL type, of the simple PURL is 302. The purpose of 302 PURL is to inform the Web client and the end user that PURL should always be used to address the requested resource, not the end of the unresolved URI. This is to allow advanced resolution of resources if PURL changes. Some operators prefer to use PURL type 301 (indicating that the final URI should be handled in future requests).
A PURL type "chain" allows PURL to redirect to another PURL in a way similar to 301 or 302 redirects, with the difference that the PURL server will handle the redirections internally for greater efficiency. This efficiency is useful when multiple redirects are possible; because some Web browsers will stop following redirects once the specified limit is found (in an attempt to avoid loops).
A PURL of type "200" is "PURL On", where PURL actively participates in the creation or aggregation of metadata returned. An Active PURL includes some arbitrary calculations to generate its output. Active PURL has been implemented in PURLz 2.0 and The Callimachus Project. They can be used to collect runtime status reports, perform distributed queries or other types of data collection where identifiers are still required. PURL actively acts similar to the stored procedure in the relational database.
A PURL of type "303" is used to direct Web clients to resources that provide additional information about the resources they request, without restoring the resources themselves. This subtlety is useful when HTTP URIs are requested to be used as identifiers for physical or conceptual objects that can not be represented as sources of information. PURL type 303 is most commonly used to redirect to metadata in the serialization format of the Resource Description Framework (RDF) and has relevance for Semantic Web and linked data content. The use of this HTTP 303 status code matches the http-14 findings of the Technical Architecture Group of the World Wide Web Consortium.
A PURL type "307" informs the user that the resource is temporarily at a different URL than the norm. PURL types 404 and 410 noted that the requested resource could not be found and suggested some information as to why it happened. Support for HTTP 307 Response code (Temporary Redirection), 404 (Not Found) and 410 (Go) are provided for completeness.
PURL types "404" and "410" are provided to assist administrators in marking PURL that requires fixes. This type of PURL allows a more efficient indication of resource identification failures when the target resource has moved and the corresponding substitute has not been identified.
PURL type "clones" are used only during PURL administration as an easy method to copy existing PURL recordings to the new PURL.
Redirection of URL fragments
The PURL service includes a concept known as partial redirects. If the request does not match PURL, the requested URL is checked to determine whether some of the adjacent fronts of the PURL string match the registered PURL. In that case, the redirect occurs with the rest of the requested URL added to the target URL. For example, consider PURL with URL http//purl.org/some/path/with the target URL http://example.com/another/path/. Attempts to perform GET HTTP operations on URL http//purl.org/some/path/and/some/more/data will result in a partial redirection to http://example.com/another/path/and/some/more/data. The concept of partial redirection allows a Web-based resource hierarchy to be handled via PURL without any resources requiring PURL itself. One PURL is enough to function as a top-level node for a hierarchy on a single target server. The new PURL service uses a "partial" type to show PURL that does a partial redirection.
Partial redirects at the URL path level do not violate the general interpretation of the HTTP 1.1 specification. However, the handling of URL fragments in redirections has not been standardized and consensus has not yet appeared. The fragment identifiers indicate the pointer to the more specific information in the resource and are set as the following # separator in the URI.
Partial redirection in the presence of a problem-solving identifier because two conflicting interpretations are possible. If a fragment is attached to a PURL of "partial" type, should the PURL service assume that the fragment has a meaning on the target URL or should throw it into the assumption that the resource with the changed location might also change the content, thus undoing the previously defined fragment? The boss suggests that fragments should be retained and forwarded to the target URL during an HTTP redirect that generates 300 (Multiple Choice), 301 (Moving Permanently), 302 (Found) or 303 (See More) responses except the designated target URL includes a fragment identifier. If the fragment identifier already exists in the target URL, any fragments in the original URL must be left. Unfortunately, the Boss's suggestion failed to navigate the IETF standard path and ended without further work. Dubost et al. resurrect the Boss's suggestion in W3C Notes (not standard, but guide if there is no standard). Web client generators like the "general" browser fail to follow the boss's guidance.
Beginning with the PURLz 1.0 series, the PURL service implements partial redirects including fragment identifiers by writing fragments to the target URL in an attempt to comply and avoid troubled and inconsistent behavior by browser vendors.
See also
- Sample implementation:
- Archive Resource Key (ARK)
- Digital Object Identifier (DOI)
- Handles System identifiers
- Rot link
- OPAC
- Permalink
- URL redirects
- URL shortening
- Uniform Source Name (URN)
- The Wayback Machine
References
External links
- Official website for PURLz
- The official website for The Callimachus Project
- Internet Archive PURL Modifiers
- US Government Printing PURL Resolver
- persistent-identifier.de
- DPE/PURL Information and Deployment Sites
Source of the article : Wikipedia
0 Comments