Editing Persistent uniform resource locator (section)

==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 identifier|Digital Object Identifiers]] (DOIs), [[LSID|Life Sciences Identifiers]] (LSIDs) and [[Info:|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."<ref>{{Cite journal |first=E.|last=Yakel|title=Digital Curation |journal=OCLC Systems & Services |year=2007|volume=23|issue=4 |pages=335–340 |doi=10.1108/10650750710831466|s2cid=33219560 }}</ref>

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.<ref>{{Cite web |first=Sean|last=Martin|url=http://esw.w3.org/topic/HCLSIG_BioRDF_Subgroup/LSID_URN_URI |title=LSID URN/URI Notes |date=2006-06-30 |access-date=2011-01-05 |publisher=[[World Wide Web Consortium]] ESW Wiki}}</ref>

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#List_of_units|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''.