Persistenter einheitlicher Ressourcen-Locator - Persistent uniform resource locator

Ein persistenter Uniform Resource Locator ( PURL ) ist ein Uniform Resource Locator (URL) (dh ein ortsbasierter Uniform Resource Identifier oder URI), der verwendet wird, um zum Standort der angeforderten Webressource umzuleiten . PURLs leiten HTTP- Clients mithilfe von HTTP-Statuscodes um .

Ursprünglich waren PURLs daran erkennbar, dass sie auf purl.org oder anderen Hostnamen gehostet wurden, die purl. Früher verwendeten viele dieser anderen Hosts Nachkommen der ursprünglichen OCLC PURL-Systemsoftware. Schließlich wurde das PURL-Konzept jedoch generisch und wurde verwendet, um jeden Umleitungsdienst (genannt PURL-Resolver ) zu bezeichnen, der:

  • hat eine "Root-URL" als Resolver- Referenz (zB http://myPurlResolver.example);
  • stellt seiner Benutzergemeinschaft Mittel zur Verfügung, um neue Namen in die Root-URL aufzunehmen (zB http://myPurlResolver.example/name22);
  • stellt Mittel bereit, um jeden Namen mit seiner URL zu verknüpfen (umgeleitet zu werden) und um diese Umleitungs-URL zu aktualisieren;
  • die Persistenz (zB vertraglich) der Root-URL und der PURL-Resolver- Dienste sicherstellen .

PURLs werden verwendet, um den URL-Auflösungsprozess zu kuratieren, wodurch das Problem vorübergehender URIs in standortbasierten URI-Schemata wie HTTP gelöst wird . Technisch gesehen ist die String-Auflösung auf PURL der SEF-URL- Auflösung gleich . Der Rest dieses Artikels befasst sich mit dem PURL-System von OCLC, das von OCLC (dem Online Computer Library Center) vorgeschlagen und implementiert wurde .

Geschichte

Das PURL-Konzept wurde 1995 bei OCLC entwickelt und das PURL-System wurde unter Verwendung einer gegabelten Version von Apache HTTP Server vor 1.0 implementiert . Die Software wurde 2007 von Zepheira im Auftrag von OCLC modernisiert und erweitert und die offizielle Website wurde nach http://purlz.org verschoben (das 'Z' stammt vom Namen Zepheira und wurde verwendet, um die Open-Source-Software- Site PURL von der von OCLC betriebene PURL-Resolver).

PURL-Versionsnummern können als verwirrend angesehen werden. OCLC veröffentlichte die Versionen 1 und 2 des Apache-basierten Quellbaums, zunächst 1999 unter der OCLC Research Public License 1.0 License und später unter der OCLC Research Public License 2.0 License ( http://opensource.org/licenses/oclc2 ). Zepheira veröffentlichte PURLz 1.0 im Jahr 2007 unter der Apache-Lizenz, Version 2.0 . PURLz 2.0 wurde veröffentlicht Beta - Tests im Jahr 2010 , aber die Veröffentlichung wurde nie fertig gestellt. Das Callimachus-Projekt implementierte PURLs ab seiner Version 1.0 im Jahr 2012.

Der älteste PURL- HTTP- Resolver wurde von 1995 bis September 2016 von OCLC betrieben und war als purl.oclc.org sowie purl.org , purl.net und purl.com erreichbar .

Andere bemerkenswerte PURL-Resolver sind das US Government Printing Office ( http://purl.fdlp.gov ), das für das Federal Depository Library Program betrieben wird und seit 1997 in Betrieb ist.

Das PURL-Konzept wird in w3id.org verwendet , das die alten PURL-Dienste und PURL-Technologien ersetzen kann.

Am 27. September 2016 OCLC kündigte eine Zusammenarbeit mit Internet - Archiv in der Übertragung des Resolver - Dienstes und seine Administrationsoberfläche zu Internet Archiven führt. Der Dienst wird auf neu erstellter Software unterstützt, getrennt von allen vorherigen Implementierungen. Durch die Übertragung wurde die Verwaltung von PURL-Definitionen wieder aktiviert, die im von OCLC gehosteten Dienst mehrere Monate lang deaktiviert waren. Der auf Internetarchivservern gehostete Dienst unterstützt den Zugriff über purl.org , purl.net , purl.info und purl.com . OCLC leitet nun DNS-Anfragen für purl.oclc.org an purl.org weiter .

Funktionsprinzipien

Das PURL-Konzept ermöglicht eine generalisierte URL-Kuration von HTTP-URIs im World Wide Web . PURLs ermöglichen Dritten die Kontrolle über die URL-Auflösung und die Bereitstellung von Ressourcenmetadaten.

Eine URL ist einfach eine Adresse einer Ressource im World Wide Web. Eine persistente URL ist eine Adresse im World Wide Web, die eine Umleitung zu einer anderen Webressource bewirkt. Wenn eine Webressource den Standort (und damit die URL) ändert, kann eine darauf verweisende PURL aktualisiert werden. Ein Benutzer einer PURL verwendet immer dieselbe Webadresse, auch wenn die betreffende Ressource möglicherweise umgezogen ist. PURLs können von Herausgebern verwendet werden, um ihren eigenen Informationsraum zu verwalten, oder von Webbenutzern, um ihren eigenen zu verwalten; ein PURL-Dienst ist unabhängig vom Herausgeber der Informationen. PURL-Dienste ermöglichen somit die Verwaltung der Hyperlink-Integrität. Die Hyperlink-Integrität ist ein Design-Kompromiss des World Wide Web, kann jedoch teilweise wiederhergestellt werden, indem es Ressourcenbenutzern oder Dritten ermöglicht wird, Einfluss darauf zu nehmen, wo und wie eine URL aufgelöst wird.

Eine einfache PURL funktioniert, indem sie auf eine HTTP-GET-Anfrage antwortet, indem eine Antwort vom Typ 302 zurückgegeben wird (entspricht dem HTTP-Statuscode 302, was "Gefunden" bedeutet). Die Antwort enthält einen HTTP-Header "Location", dessen Wert eine URL ist, die der Client anschließend über einen neuen HTTP-GET-Request abrufen soll.

PURLs implementieren eine Form eines persistenten Bezeichners für virtuelle Ressourcen. Andere persistente Identifier-Schemata umfassen Digital Object Identifiers (DOIs), Life Sciences Identifiers (LSIDs) und INFO URIs . Alle persistenten Identifizierungsschemata stellen eindeutige Identifizierungszeichen für (möglicherweise ändernde) virtuelle Ressourcen bereit, aber nicht alle Schemata bieten Kuratierungsmöglichkeiten. Die Kuratierung virtueller Ressourcen wurde definiert als „die aktive Beteiligung von Informationsfachleuten an der Verwaltung, einschließlich der Bewahrung digitaler Daten für die zukünftige Verwendung“.

PURLs wurden dafür kritisiert, dass sie eine URL auflösen müssen, wodurch eine PURL an einen Netzwerkstandort gebunden wird. Netzwerkstandorte weisen mehrere Schwachstellen auf, wie z. B. Domain Name System-Registrierungen und Hostabhängigkeiten. Ein Fehler beim Auflösen einer PURL könnte zu einem mehrdeutigen Zustand führen: Es wäre nicht klar, ob die PURL nicht aufgelöst werden konnte, weil sie durch einen Netzwerkfehler verhindert wurde oder weil sie nicht existierte.

PURLs sind selbst gültige URLs, daher müssen ihre Komponenten der URL-Spezifikation entsprechen. Der Schemateil teilt einem Computerprogramm, beispielsweise einem Webbrowser, mit, welches Protokoll beim Auflösen der Adresse verwendet werden soll. Das für PURLs verwendete Schema ist im Allgemeinen HTTP. Der Host-Teil teilt mit, mit welchem ​​PURL-Server eine Verbindung hergestellt werden soll. Der nächste Teil, die PURL-Domäne, entspricht einem Ressourcenpfad in einer URL. Die Domäne ist ein hierarchischer Informationsraum, der PURLs trennt und es ermöglicht, dass PURLs unterschiedliche Betreuer haben. Ein oder mehrere designierte Betreuer können jede PURL-Domäne verwalten. Schließlich ist der PURL-Name der Name der PURL selbst. Domain und Name bilden zusammen die "ID" der PURL.

Vergleich mit Permalink

Sowohl Permalink als auch PURL werden als permanente/persistente URL verwendet und leiten an den Speicherort der angeforderten Webressource weiter . Grob gesagt sind sie gleich. Ihre Unterschiede beziehen sich auf den Domainnamen und die Zeitskala :

  • Ein Permalink ändert normalerweise nicht die Domain der URL und soll über Jahre bestehen bleiben .
  • Ein PURL- Domainname ist unabhängig änderbar und soll über Jahrzehnte bestehen bleiben .

Typen

Die gebräuchlichsten PURL-Typen werden so benannt, dass sie mit dem von ihnen zurückgegebenen HTTP-Antwortcode übereinstimmen. Nicht alle HTTP-Antwortcodes haben äquivalente PURL-Typen und nicht alle PURL-Server implementieren alle PURL-Typen. Einige HTTP-Antwortcodes (z. B. 401, Unauthorized) haben im Kontext einer HTTP-Konversation eine klare Bedeutung, gelten jedoch nicht für den Prozess der HTTP-Umleitung. Drei zusätzliche Arten von PURLs ("chain", "partial" und "clone") erhalten mnemonische Namen, die sich auf ihre Funktionen beziehen.

PURL-Typen
Art PURL-Bedeutung HTTP-Bedeutung
200 Inhalte erstellt oder aggregiert OK
301 Dauerhaft zu einer Ziel-URL verschoben Dauerhaft umgezogen
302 Einfache Weiterleitung zu einer Ziel-URL Gefunden
Kette Weiterleitung zu einer anderen PURL innerhalb desselben Servers Gefunden
Teilweise Weiterleitung zu einer Ziel-URL mit angehängten Pfadinformationen Gefunden
303 Siehe andere URL Siehe Andere
307 Temporäre Weiterleitung zu einer Ziel-URL Temporäre Weiterleitung
404 Vorübergehend weg Nicht gefunden
410 Für immer weg Weg
Klon Kopieren Sie die Attribute einer vorhandenen PURL N / A

Bei den meisten PURLs handelt es sich um sogenannte "einfache PURLs", die eine Weiterleitung auf die gewünschte Ressource ermöglichen. Der HTTP-Statuscode und somit der PURL-Typ einer einfachen PURL ist 302. Die Absicht einer 302-PURL besteht darin, den Web-Client und den Endbenutzer darüber zu informieren, dass die PURL immer verwendet werden sollte, um die angeforderte Ressource zu adressieren, nicht die endgültige URI gelöst. Dies soll eine fortgesetzte Auflösung der Ressource ermöglichen, wenn sich die PURL ändert. Einige Betreiber bevorzugen die Verwendung von PURLs des Typs 301 (was darauf hinweist, dass der endgültige URI in zukünftigen Anfragen berücksichtigt werden sollte).

Eine PURL vom Typ "Kette" ermöglicht es einer PURL, zu einer anderen PURL auf eine Weise umzuleiten, die mit einer 301- oder 302-Umleitung identisch ist, mit dem Unterschied, dass ein PURL-Server die Umleitung intern für eine höhere Effizienz handhabt. Diese Effizienz ist nützlich, wenn viele Umleitungen möglich sind; da einige Webbrowser aufhören, Umleitungen zu folgen, sobald ein festgelegtes Limit erreicht ist (um Schleifen zu vermeiden).

Eine PURL vom Typ "200" ist eine "Active PURL", bei der die PURL aktiv an der Erstellung oder Aggregation der zurückgegebenen Metadaten beteiligt ist. Eine aktive PURL enthält einige willkürliche Berechnungen, um ihre Ausgabe zu erzeugen. Aktive PURLs wurden in PURLz 2.0 und The Callimachus Project implementiert . Sie können verwendet werden, um Laufzeitstatusberichte zu sammeln, verteilte Abfragen durchzuführen oder jede andere Art von Datensammlung, bei der eine dauerhafte Kennung gewünscht wird. Aktive PURLs verhalten sich ähnlich wie eine gespeicherte Prozedur in relationalen Datenbanken.

Eine PURL vom Typ "303" wird verwendet, um einen Web-Client zu einer Ressource zu leiten, die zusätzliche Informationen bezüglich der angeforderten Ressource bereitstellt, ohne die Ressource selbst zurückzugeben. Diese Feinheit ist nützlich, wenn der angeforderte HTTP-URI als Bezeichner für ein physisches oder konzeptionelles Objekt verwendet wird, das nicht als Informationsressource dargestellt werden kann. PURLs vom Typ 303 werden am häufigsten verwendet, um auf Metadaten in einem Serialisierungsformat des Resource Description Framework (RDF) umzuleiten und haben Relevanz für Semantic Web und verlinkte Dateninhalte. Diese Verwendung des HTTP-Statuscodes 303 entspricht dem Ergebnis http-range-14 der Technical Architecture Group des World Wide Web Consortium .

Eine PURL vom Typ "307" informiert einen Benutzer, dass sich die Ressource vorübergehend unter einer anderen URL als der Norm befindet. PURLs der Typen 404 und 410 weisen darauf hin, dass die angeforderte Ressource nicht gefunden werden konnte und schlagen einige Informationen vor, warum dies so war. Der Vollständigkeit halber werden die Antwortcodes HTTP 307 (Temporary Redirect), 404 (Not Found) und 410 (Gone) unterstützt.

PURLs der Typen "404" und "410" werden bereitgestellt, um Administratoren beim Markieren von PURLs zu unterstützen, die repariert werden müssen. PURLs dieser Typen ermöglichen effizientere Hinweise auf einen Ressourcenidentifikationsfehler, wenn Zielressourcen verschoben wurden und kein geeigneter Ersatz identifiziert wurde.

PURLs vom Typ "Clone" werden ausschließlich während der PURL-Administration verwendet, um einen bestehenden PURL-Record bequem in eine neue PURL zu kopieren.

Umleitung von URL-Fragmenten

Der PURL-Dienst umfasst ein Konzept, das als partielle Umleitung bekannt ist. Wenn eine Anforderung nicht genau mit einer PURL übereinstimmt, wird die angeforderte URL überprüft, um zu bestimmen, ob ein zusammenhängender vorderer Teil der PURL-Zeichenfolge mit einer registrierten PURL übereinstimmt. Wenn dies der Fall ist, erfolgt eine Umleitung, wobei der Rest der angeforderten URL an die Ziel-URL angehängt wird. Betrachten Sie beispielsweise eine PURL mit einer URL von http//purl.org/some/path/ mit einer Ziel-URL von http://example.com/another/path/. Ein Versuch, einen HTTP-GET-Vorgang für die URL http//purl.org/some/path/and/some/more/data auszuführen, würde zu einer teilweisen Umleitung zu http://example.com/another/path/and/ führen. einige/mehr/Daten. Das Konzept der partiellen Umleitung ermöglicht es, Hierarchien webbasierter Ressourcen über PURLs zu adressieren, ohne dass jede Ressource eine eigene PURL benötigt. Eine PURL reicht aus, um als Knoten der obersten Ebene für eine Hierarchie auf einem einzelnen Zielserver zu dienen. Der neue PURL-Dienst verwendet den Typ "partial", um eine PURL zu bezeichnen, die eine teilweise Umleitung durchführt.

Teilweise Umleitungen auf der Ebene eines URL-Pfads verstoßen nicht gegen gängige Interpretationen der HTTP 1.1-Spezifikation. Der Umgang mit URL-Fragmenten über Weiterleitungen hinweg ist jedoch nicht standardisiert und es gibt noch keinen Konsens. Fragmentbezeichner geben einen Zeiger auf spezifischere Informationen innerhalb einer Ressource an und werden als nach einem #-Trennzeichen in URIs bezeichnet.

Eine teilweise Umleitung bei Vorhandensein einer Fragmentkennung ist problematisch, da zwei widersprüchliche Interpretationen möglich sind. Wenn ein Fragment an eine PURL vom Typ "partiell" angehängt wird, sollte ein PURL-Dienst davon ausgehen, dass das Fragment eine Bedeutung auf der Ziel-URL hat oder sollte er es verwerfen in der Annahme, dass eine Ressource mit einem geänderten Standort möglicherweise auch den Inhalt geändert hat, also Fragmente, die zuvor definiert wurden, ungültig machen? Bos schlug vor, dass Fragmente beibehalten und während HTTP-Umleitungen an Ziel-URLs weitergeleitet werden sollten, was zu 300 (Multiple Choice), 301 (Moved Permanently), 302 (Found) oder 303 (See Other) Antworten führt, es sei denn, eine festgelegte Ziel-URL enthält bereits ein Fragment Kennung. Wenn in einer Ziel-URL bereits eine Fragment-ID vorhanden ist, sollten alle Fragmente in der ursprünglichen URL aufgegeben werden. Leider konnte der Vorschlag von Bos nicht auf dem Weg der IETF-Standards navigieren und lief ohne weitere Arbeit ab. Dubostet al. die Vorschläge von Bos in einer W3C-Notiz wiederbelebt (kein Standard, aber Anleitung in Ermangelung eines Standards). Hersteller von Web-Clients wie Browsern haben es "im Allgemeinen" versäumt, den Anweisungen von Bos zu folgen.

Beginnend mit der PURLz 1.0-Serie implementiert der PURL-Dienst teilweise Umleitungen, einschließlich Fragment-IDs, indem er Fragmente auf Ziel-URLs schreibt, um problematisches und inkonsistentes Verhalten von Browseranbietern einzuhalten und zu vermeiden.

Siehe auch

Verweise

Externe Links