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:[1]
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.[2] 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 http://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 (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 the release was never finalized. The Callimachus Project implemented PURLs as of its 1.0 release in 2012.
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.[3] 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."[4]
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.[5]
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:
A permalink usually does not change the URL's domain, and is designed to persist over years.
A PURL domain name is independently changeable, and is designed to persist over decades.
Types
The most common types of PURLs are named to coincide with the HTTP response code that they return. Not all HTTP response codes have equivalent PURL types and not all PURL servers implement all PURL types. Some HTTP response codes (e.g. 401, Unauthorized) have clear meanings in the context of an HTTP conversation but do not apply to the process of HTTP redirection. Three additional types of PURLs ("chain", "partial' and "clone") are given mnemonic names related to their functions.
PURL types
Type
PURL meaning
HTTP meaning
200
Content created or aggregated
OK
301
Moved permanently to a target URL
Moved permanently
302
Simple redirection to a target URL
Found
Chain
Redirect to another PURL within the same server
Found
Partial
Redirect to a target URL with trailing path information appended
Found
303
See other URL
See Other
307
Temporary redirect to a target URL
Temporary Redirect
404
Temporarily gone
Not Found
410
Permanently gone
Gone
Clone
Copy the attributes of an existing PURL
N/A
Most PURLs are so-called "simple PURLs", which provide a redirection to the desired resource. The HTTP status code, and hence of the PURL type, of a simple PURL is 302. The intent of a 302 PURL is to inform the Web client and end user that the PURL should always be used to address the requested resource, not the final URI resolved. This is to allow continued resolution of the resource if the PURL changes. Some operators prefer to use PURLs of type 301 (indicating that the final URI should be addressed in future requests).
A PURL of type "chain" allows a PURL to redirect to another PURL in a manner identical to a 301 or 302 redirection, with the difference that a PURL server will handle the redirection internally for greater efficiency. This efficiency is useful when many redirections are possible; since some Web browsers will stop following redirections once a set limit is encountered (in an attempt to avoid loops).
A PURL of type "200" is an "Active PURL", in which the PURL actively participates in the creation or aggregation of the metadata returned. An Active PURL includes some arbitrary computation to produce its output. Active PURLs have been implemented in PURLz 2.0 and The Callimachus Project. They may be used to gather runtime status reports, perform distributed queries or any other type of data collection where a persistent identifier is desired. Active PURLs act similar to a stored procedure in relational databases.[6]
A PURL of type "303" is used to direct a Web client to a resource that provides additional information regarding the resource they requested, without returning the resource itself. This subtlety is useful when the HTTP URI requested is used as an identifier for a physical or conceptual object that cannot be represented as an information resource. PURLs of type 303 are used most often to redirect to metadata in a serialization format of the Resource Description Framework (RDF) and have relevance for Semantic Web and linked data content. This use of the 303 HTTP status code is conformant with the http-range-14 finding of the Technical Architecture Group of the World Wide Web Consortium.
A PURL of type "307" informs a user that the resource temporarily resides at a different URL from the norm. PURLs of types 404 and 410 note that the requested resource could not be found and suggests some information for why that was so. Support for the HTTP 307 (Temporary Redirect), 404 (Not Found) and 410 (Gone) response codes are provided for completeness.
PURLs of types "404" and "410" are provided to assist administrators in marking PURLs that require repair. PURLs of these types allow for more efficient indications of resource identification failure when target resources have moved and a suitable replacement has not been identified.
PURLs of type "clone" are used solely during PURL administration as a convenient method of copying an existing PURL record into a new PURL.
Redirection of URL fragments
The PURL service includes a concept known as partial redirection. If a request does not match a PURL exactly, the requested URL is checked to determine if some contiguous front portion of the PURL string matches a registered PURL. If so, a redirection occurs with the remainder of the requested URL appended to the target URL. For example, consider a PURL with a URL of http//purl.org/some/path/ with a target URL of http://example.com/another/path/. An attempt to perform an HTTP GET operation on the URL http//purl.org/some/path/and/some/more/data would result in a partial redirection to http://example.com/another/path/and/some/more/data. The concept of partial redirection allows hierarchies of Web-based resources to be addressed via PURLs without each resource requiring its own PURL. One PURL is sufficient to serve as a top-level node for a hierarchy on a single target server. The new PURL service uses the type "partial" to denote a PURL that performs partial redirection.
Partial redirections at the level of a URL path do not violate common interpretations of the HTTP 1.1 specification. However, the handling of URL fragments across redirections has not been standardized and a consensus has not yet emerged. Fragment identifiers indicate a pointer to more specific information within a resource and are designated as following a # separator in URIs.[7]
Partial redirection in the presence of a fragment identifier is problematic because two conflicting interpretations are possible.[8] If a fragment is attached to a PURL of type "partial", should a PURL service assume that the fragment has meaning on the target URL or should it discard it in the presumption that a resource with a changed location may have also changed content, thus invalidating fragments defined earlier? Bos suggested that fragments should be retained and passed through to target URLs during HTTP redirections resulting in 300 (Multiple Choice), 301 (Moved Permanently), 302 (Found) or 303 (See Other) responses unless a designated target URL already includes a fragment identifier. If a fragment identifier is already present in a target URL, any fragment in the original URL should be abandoned. Unfortunately, Bos’ suggestion failed to navigate the IETF standards track and expired without further work. Dubost et al. resurrected Bos’ suggestions in a W3C Note (not a standard, but guidance in the absence of a standard).[9] Makers of Web clients such as browsers have "generally"[9] failed to follow Bos’ guidance.
Starting with PURLz 1.0 series, the PURL service implements partial redirections inclusive of fragment identifiers by writing fragments onto target URLs in an attempt to comply with[9] and avoid problematic and inconsistent behavior by browser vendors.
The Session Initiation Protocol (SIP) is a signaling protocol used for initiating, maintaining, and terminating communication sessions that include voice, video and messaging applications. SIP is used in Internet telephony, in private IP telephone systems, as well as mobile phone calling over LTE (VoLTE).
A Uniform Resource Identifier (URI) is a unique sequence of characters that identifies a logical or physical resource used by web technologies. URIs may be used to identify anything, including real-world objects, such as people and places, concepts, or information resources such as web pages and books. Some URIs provide a means of locating and retrieving information resources on a network ; these are Uniform Resource Locators (URLs). A URL provides the location of the resource. A URI identifies the resource by name at the specified location or URL. Other URIs provide only a unique name, without a means of locating or retrieving the resource or information about it; these are Uniform Resource Names (URNs). The web technologies that use URIs are not limited to web browsers. URIs are used to identify anything described using the Resource Description Framework (RDF), for example, concepts that are part of an ontology defined using the Web Ontology Language (OWL), and people who are described using the Friend of a Friend vocabulary would each have an individual URI.
A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that uses the urn scheme. URNs are globally unique persistent identifiers assigned within defined namespaces so they will be available for a long period of time, even after the resource which they identify ceases to exist or becomes unavailable. URNs cannot be used to directly locate an item and need not be resolvable, as they are simply templates that another parser may use to find an item.
A digital object identifier (DOI) is a persistent identifier or handle used to uniquely identify various objects, standardized by the International Organization for Standardization (ISO). DOIs are an implementation of the Handle System; they also fit within the URI system. They are widely used to identify academic, professional, and government information, such as journal articles, research reports, data sets, and official publications. DOIs have also been used to identify other types of information resources, like commercial videos.
URL redirection, also called URL forwarding, is a World Wide Web technique for making a web page available under more than one URL address. When a web browser attempts to open a URL that has been redirected, a page with a different URL is opened. Similarly, domain redirection or domain forwarding is when all pages in a URL domain are redirected to a different domain, as when wikipedia.com and wikipedia.net are automatically redirected to wikipedia.org.
A permalink or permanent link is a URL that is intended to remain unchanged for many years into the future, yielding a hyperlink that is less susceptible to link rot. Permalinks are often rendered simply, that is, as clean URLs, to be easier to type and remember. Most modern blogging and content-syndication software systems support such links. Sometimes URL shortening is used to create them.
In computer hypertext, a URI fragment is a string of characters that refers to a resource that is subordinate to another, primary resource. The primary resource is identified by a Uniform Resource Identifier (URI), and the fragment identifier points to the subordinate resource.
A web resource is any identifiable resource present on or connected to the World Wide Web. Resources are identified using Uniform Resource Identifiers (URIs). In the Semantic Web, web resources and their semantic properties are described using the Resource Description Framework (RDF).
Yadis is a communications protocol for discovery of services such as OpenID, OAuth, and XDI connected to a Yadis ID. While intended to discover digital identity services, Yadis is not restricted to those. Other services can easily be included.
URL shortening is a technique on the World Wide Web in which a Uniform Resource Locator (URL) may be made substantially shorter and still direct to the required page. This is achieved by using a redirect which links to the web page that has a long URL. For example, the URL "https://example.com/assets/category_B/subcategory_C/Foo/" can be shortened to "https://example.com/Foo", and the URL "https://en.wikipedia.org/wiki/URL_shortening" can be shortened to "https://w.wiki/U". Often the redirect domain name is shorter than the original one. A friendly URL may be desired for messaging technologies that limit the number of characters in a message, for reducing the amount of typing required if the reader is copying a URL from a print source, for making it easier for a person to remember, or for the intention of a permalink. In November 2009, the shortened links of the URL shortening service Bitly were accessed 2.1 billion times.
Clean URLs are web addresses or Uniform Resource Locator (URLs) intended to improve the usability and accessibility of a website, web application, or web service by being immediately and intuitively meaningful to non-expert users. Such URL schemes tend to reflect the conceptual structure of a collection of information and decouple the user interface from a server's internal representation of information. Other reasons for using clean URLs include search engine optimization (SEO), conforming to the representational state transfer (REST) style of software architecture, and ensuring that individual web resources remain consistently at the same URL. This makes the World Wide Web a more stable and useful system, and allows more durable and reliable bookmarking of web resources.
Security Assertion Markup Language 2.0 (SAML 2.0) is a version of the SAML standard for exchanging authentication and authorization identities between security domains. SAML 2.0 is an XML-based protocol that uses security tokens containing assertions to pass information about a principal between a SAML authority, named an Identity Provider, and a SAML consumer, named a Service Provider. SAML 2.0 enables web-based, cross-domain single sign-on (SSO), which helps reduce the administrative overhead of distributing multiple authentication tokens to the user. SAML 2.0 was ratified as an OASIS Standard in March 2005, replacing SAML 1.1. The critical aspects of SAML 2.0 are covered in detail in the official documents SAMLCore, SAMLBind, SAMLProf, and SAMLMeta.
The Handle System is the Corporation for National Research Initiatives's proprietary registry assigning persistent identifiers, or handles, to information resources, and for resolving "those handles into the information necessary to locate, access, and otherwise make use of the resources".
The HTTP Location header field is returned in responses from an HTTP server under two circumstances:
To ask a web browser to load a different web page. In this circumstance, the Location header should be sent with an HTTP status code of 3xx. It is passed as part of the response by a web server when the requested URI has:
To provide information about the location of a newly created resource. In this circumstance, the Location header should be sent with an HTTP status code of 201 or 202.
An Archival Resource Key (ARK) is a multi-purpose URL suited to being a persistent identifier for information objects of any type. It is widely used by libraries, data centers, archives, museums, publishers, and government agencies to provide reliable references to scholarly, scientific, and cultural objects. In 2019 it was registered as a Uniform Resource Identifier (URI).
An Extensible Resource Identifier (XRI) is a scheme and resolution protocol for abstract identifiers compatible with Uniform Resource Identifiers (URI) and Internationalized Resource Identifiers (IRI), developed by the XRI Technical Committee at OASIS. The goal of XRI was a standard syntax and discovery format for abstract, structured identifiers that are domain-, location-, application-, and transport-independent, so they can be shared across any number of domains, directories, and interaction protocols.
A persistent identifier is a long-lasting reference to a document, file, web page, or other object.
A Uniform Resource Locator (URL), colloquially known as an address on the Web, is a reference to a resource that specifies its location on a computer network and a mechanism for retrieving it. A URL is a specific type of Uniform Resource Identifier (URI), although many people use the two terms interchangeably. URLs occur most commonly to reference web pages (HTTP/HTTPS) but are also used for file transfer (FTP), email (mailto), database access (JDBC), and many other applications.
References
↑ Services as URN LEX, ELI and DOI, Permalink and others, they use directly or indirectly the PURL concept.
↑ "OCLC and Internet Archive work together to ensure future sustainability of Persistent URLs" (Press release). Dublin, Ohio: OCLC. 27 September 2016. Archived from the original on 2 February 2023. Retrieved 10 April 2023. OCLC and Internet Archive today announced the results of a year-long cooperative effort to ensure the future sustainability of purl.org. The organizations have worked together to build a new sustainable service hosted by Internet Archive that will manage persistent URLs and sub-domain redirections for purl.org, purl.com, purl.info and purl.net
This page is based on this Wikipedia article Text is available under the CC BY-SA 4.0 license; additional terms may apply. Images, videos and audio are available under their respective licenses.
