Vedvarende enhetlig ressurssøker - Persistent uniform resource locator

En vedvarende enhetlig ressurssøker ( PURL ) er en enhetlig ressurssøker (URL) (dvs. stedsbasert enhetlig ressursidentifikator eller URI) som brukes til å omdirigere til plasseringen til den forespurte nettressursen . PURLs omdirigerer HTTP- klienter ved hjelp av HTTP-statuskoder .

Opprinnelig var PURLer gjenkjennelige for å være vert på purl.org eller andre vertsnavn som inneholder purl. Tidlig brukte mange av de andre vertene etterkommere av den opprinnelige OCLC PURL-systemprogramvaren. Til slutt ble imidlertid PURL-konseptet generisk og ble brukt til å betegne enhver omdirigeringstjeneste (kalt PURL-resolver ) som:

  • har en "root URL" som resolverreferanse (f.eks. http://myPurlResolver.example);
  • gir midler til sitt brukerfellesskap for å inkludere nye navn i rot-URL-en (f.eks. http://myPurlResolver.example/name22);
  • gir midler for å knytte hvert navn til sin URL (skal omdirigeres), og for å oppdatere denne omdirigerings-URL;
  • sikre utholdenhet (f.eks. etter kontrakt) av rot-URL og PURL-resolvertjenester .

PURL-er brukes til å kurere URL-oppløsningsprosessen, og løser dermed problemet med overgående URI-er i stedsbaserte URI-ordninger som HTTP. Teknisk sett er strengoppløsningen på PURL som SEF URL- oppløsning . Resten av denne artikkelen handler om OCLCs PURL-system, foreslått og implementert av OCLC (Online Computer Library Center).

Historie

PURL-konseptet ble utviklet på OCLC i 1995, og PURL-systemet ble implementert ved hjelp av en forked pre-1.0-utgivelse av Apache HTTP Server . Programvaren ble modernisert og utvidet i 2007 av Zepheira under kontrakt til OCLC og det offisielle nettstedet flyttet til http://purlz.org ('Z' kom fra Zepheira-navnet og ble brukt til å skille PURLs programvare med åpen kildekode fra PURL-resolveren som drives av OCLC).

PURL-versjonsnumre kan betraktes som forvirrende. OCLC ga ut versjoner 1 og 2 av det Apache-baserte kildetreet, opprinnelig i 1999 under OCLC Research Public License 1.0 License og senere under OCLC Research Public License 2.0 License ( http://opensource.org/licenses/oclc2 ). Zepheira ga ut PURLz 1.0 i 2007 under Apache License, versjon 2.0 . PURLz 2.0 ble utgitt i Beta-testing i 2010, men utgivelsen ble aldri avsluttet. Den Callimachus Prosjektet gjennomføres purls som av sin 1,0 utgivelse i 2012.

Den eldste PURL HTTP- oppløseren ble drevet av OCLC fra 1995 til september 2016 og ble nådd som purl.oclc.org, så vel som purl.org , purl.net og purl.com .

Andre bemerkelsesverdige PURL-oppløsere inkluderer US Government Printing Office ( http://purl.fdlp.gov ), som drives av Federal Depository Library Program og har vært i drift siden 1997.

PURL-konseptet brukes i w3id.org , som kan erstatte de gamle PURL-tjenestene og PURL-teknologiene.

27. september 2016 kunngjorde OCLC et samarbeid med Internet Archive, noe som resulterte i overføring av resolver-tjenesten og administrasjonsgrensesnittet til Internet Archive. Tjenesten støttes av nyopprettet programvare, atskilt fra alle tidligere implementeringer. Overføringen aktiverte muligheten til å administrere PURL-definisjoner som var deaktivert i OCLC-vert-tjenesten i flere måneder. Tjenesten vert på Internet Archive-servere støtter tilgang via purl.org , purl.net , purl.info og purl.com . OCLC omdirigerer nå DNS-forespørsler for purl.oclc.org til purl.org .

Prinsipper for drift

PURL-konseptet tillater generell URL-kurering av HTTP URIer på nettet . PURL-er tillater tredjeparts kontroll over både URL-oppløsning og ressursmetadata.

En URL er ganske enkelt en adresse til en ressurs på nettet. En vedvarende URL er en adresse på internett som forårsaker en omdirigering til en annen nettressurs. Hvis en nettressurs endrer plassering (og dermed URL), kan en PURL som peker på den oppdateres. En bruker av en PURL bruker alltid den samme nettadressen, selv om den aktuelle ressursen kan ha flyttet. PURL kan brukes av utgivere til å administrere sitt eget informasjonsrom eller av nettbrukere til å administrere deres; en PURL-tjeneste er uavhengig av utgiveren av informasjon. PURL-tjenester tillater dermed styring av hyperkoblingsintegritet. Hyperkoblingsintegritet er et designutveksling av World Wide Web, men kan delvis gjenopprettes ved å tillate ressursbrukere eller tredjeparter å påvirke hvor og hvordan en URL løser seg.

En enkel PURL fungerer ved å svare på en HTTP GET-forespørsel ved å returnere et svar av type 302 (tilsvarende HTTP-statuskoden 302, som betyr "Fant"). Svaret inneholder en HTTP "Location" -overskrift, hvis verdi er en URL som klienten senere skal hente via en ny HTTP GET-forespørsel.

PURLs implementerer en form for vedvarende identifikator for virtuelle ressurser. Andre vedvarende identifikasjonsordninger inkluderer Digital Object Identifiers (DOIs), Life Sciences Identifiers (LSIDs) og INFO URIer . Alle vedvarende identifikasjonsskjemaer gir unike identifikatorer for (muligens endrede) virtuelle ressurser, men ikke alle ordninger gir kurasjonsmuligheter. Curation av virtuelle ressurser er definert som "aktiv involvering av fagpersoner i administrasjonen, inkludert bevaring, av digitale data for fremtidig bruk."

PURLs har blitt kritisert for deres behov for å løse en URL, og dermed knytte en PURL til et nettverkssted. Nettverkssteder har flere sårbarheter, for eksempel registreringer av domenenavnsystemer og vertavhengigheter. En feil i å løse en PURL kan føre til en tvetydig tilstand: Det ville ikke være klart om PURL ikke klarte å løse fordi en nettverksfeil forhindret den eller fordi den ikke eksisterte.

PURL er i seg selv gyldige URL-er, så komponentene må tilordnes til URL-spesifikasjonen. Skjema-delen forteller et dataprogram, for eksempel en nettleser, hvilken protokoll som skal brukes når du løser adressen. Ordningen som brukes for PURL er generelt HTTP. Vertdelen forteller hvilken PURL-server du skal koble til. Den neste delen, PURL-domenet, er analog med en ressurssti i en URL. Domenet er et hierarkisk informasjonsrom som skiller PURLer og gjør det mulig for PURLer å ha forskjellige vedlikeholdere. En eller flere utpekte vedlikeholdere kan administrere hvert PURL-domene. Til slutt er PURL-navnet selve PURL. Domenet og navnet utgjør tilsammen PURLs "id".

Sammenligning med permalink

Både permalink og PURL brukes som permanent / vedvarende URL og omdirigerer til plasseringen til den forespurte nettressursen . Grovt sett er de de samme. Forskjellene deres handler om domenenavn og tidsskala :

  • En permalink endrer vanligvis ikke nettadressens domene, og er designet for å fortsette over år .
  • Et PURL- domenenavn kan endres uavhengig av hverandre, og er designet for å vare i flere tiår .

Typer

De vanligste typene PURL-er er oppkalt sammenfallende med HTTP-responskoden de returnerer. Ikke alle HTTP-responskoder har tilsvarende PURL-typer, og ikke alle PURL-servere implementerer alle PURL-typer. Noen HTTP-responskoder (f.eks. 401, Uautorisert) har tydelige betydninger i sammenheng med en HTTP-samtale, men gjelder ikke prosessen med HTTP-omdirigering. Tre ekstra typer PURLer ("chain", "partial" og "clone") får mnemoniske navn relatert til deres funksjoner.

PURL-typer
Type PURL betydning HTTP-betydning
200 Innhold opprettet eller samlet OK
301 Flyttet permanent til en mål-URL Flyttet permanent
302 Enkel omdirigering til en mål-URL Funnet
Kjede Viderekoble til en annen PURL på samme server Funnet
Delvis Viderekoble til en mål-URL med etterfølgende stiinformasjon lagt til Funnet
303 Se annen URL Se Annet
307 Midlertidig viderekobling til en mål-URL Midlertidig omdirigering
404 Midlertidig borte Ikke funnet
410 Permanent borte Borte
Klon Kopier attributtene til en eksisterende PURL Ikke relevant

De fleste PURL er såkalte "simple PURLs", som gir en omdirigering til ønsket ressurs. HTTP-statuskoden, og dermed av PURL-typen, av en enkel PURL er 302. Hensikten med en 302 PURL er å informere webklienten og sluttbrukeren om at PURL alltid skal brukes til å adressere den forespurte ressursen, ikke den endelige URI løst. Dette for å tillate fortsatt oppløsning av ressursen hvis PURL endres. Noen operatører foretrekker å bruke PURL-er av type 301 (noe som indikerer at den endelige URI-en skal adresseres i fremtidige forespørsler).

En PURL av typen "chain" tillater en PURL å omdirigere til en annen PURL på en måte som er identisk med en 301 eller 302 omdirigering, med den forskjellen at en PURL-server vil håndtere omdirigering internt for større effektivitet. Denne effektiviteten er nyttig når mange omdirigeringer er mulige; siden noen nettlesere slutter å følge omdirigeringer når en angitt grense er oppstått (i et forsøk på å unngå sløyfer).

En PURL av typen "200" er en "Active PURL", der PURL deltar aktivt i opprettelsen eller aggregeringen av de returnerte metadataene. En aktiv PURL inkluderer noen vilkårlig beregning for å produsere utdataene. Aktive PURLer er implementert i PURLz 2.0 og The Callimachus Project . De kan brukes til å samle kjøretidsstatusrapporter, utføre distribuerte spørsmål eller hvilken som helst annen type datainnsamling der en vedvarende identifikator er ønsket. Aktive PURL-er virker som en lagret prosedyre i relasjonsdatabaser.

En PURL av typen "303" brukes til å lede en webklient til en ressurs som gir tilleggsinformasjon om ressursen de ba om, uten å returnere selve ressursen. Denne subtiliteten er nyttig når HTTP URI-forespørselen brukes som en identifikator for et fysisk eller konseptuelt objekt som ikke kan representeres som en informasjonsressurs. PURLer av type 303 brukes oftest til å omdirigere til metadata i et serialiseringsformat av Resource Description Framework (RDF) og har relevans for Semantic Web og koblet datainnhold . Denne bruken av 303 HTTP-statuskoden er i samsvar med http-range-14- funnet fra Technical Architecture Group i World Wide Web Consortium .

En PURL av typen "307" informerer en bruker om at ressursen midlertidig befinner seg på en annen URL enn normen. PURLs av typene 404 og 410 bemerker at den forespurte ressursen ikke ble funnet, og foreslår litt informasjon for hvorfor det var slik. Støtte for HTTP 307 (midlertidig omdirigering), 404 (ikke funnet) og 410 (borte) responskoder er gitt for fullstendighet.

PURLs av typene "404" og "410" er gitt for å hjelpe administratorer med å merke PURLs som krever reparasjon. PURLs av disse typene tillater mer effektive indikasjoner på feil på ressursidentifikasjon når målressursene har flyttet seg og en passende erstatning ikke er identifisert.

PURLer av typen "klon" brukes utelukkende under PURL-administrasjon som en praktisk metode for å kopiere en eksisterende PURL-post til en ny PURL.

Omadressering av URL-fragmenter

PURL-tjenesten inkluderer et konsept kjent som delvis omdirigering. Hvis en forespørsel ikke stemmer overens med en PURL nøyaktig, blir den forespurte URL-en sjekket for å avgjøre om noen sammenhengende frontdel av PURL-strengen samsvarer med en registrert PURL. I så fall skjer det en omdirigering med resten av den forespurte URL-en lagt til mål-URL-en. Tenk for eksempel på en PURL med en URL på http // purl.org / some / path / med en mål-URL på http://example.com/another/path/. Et forsøk på å utføre en HTTP GET-operasjon på nettadressen http // purl.org / some / path / og / some / more / data vil resultere i en delvis omdirigering til http://example.com/another/path/and/ noe / mer / data. Konseptet med delvis omdirigering gjør det mulig å adressere hierarkier av nettbaserte ressurser via PURL uten at hver ressurs krever sin egen PURL. Én PURL er tilstrekkelig til å fungere som en toppnode for et hierarki på en enkelt målserver. Den nye PURL-tjenesten bruker typen "delvis" for å betegne en PURL som utfører delvis omdirigering.

Delvise omdirigeringer på nivå med en URL-bane bryter ikke vanlige tolkninger av HTTP 1.1-spesifikasjonen. Håndteringen av URL-fragmenter på tvers av omdirigeringer har imidlertid ikke blitt standardisert, og det har ennå ikke kommet enighet. Fragmentidentifikatorer indikerer en peker til mer spesifikk informasjon i en ressurs og er betegnet som følgende # separator i URI-er.

Delvis omdirigering i nærvær av en fragmentidentifikator er problematisk fordi to motstridende tolkninger er mulige. Hvis et fragment er knyttet til en PURL av typen "delvis", bør en PURL-tjeneste anta at fragmentet har betydning på mål-URL-en, eller bør den forkaste det i formodningen om at en ressurs med endret beliggenhet også kan ha endret innhold, og dermed ugyldiggjøre fragmenter som er definert tidligere? Bos foreslo at fragmenter skulle beholdes og sendes videre til mål-URL-er under HTTP-omdirigeringer, noe som resulterte i 300 (flervalg), 301 (flyttet permanent), 302 (funnet) eller 303 (se annet) svar med mindre en angitt mål-URL allerede inneholder et fragment identifikator. Hvis en fragmentidentifikator allerede er tilstede i en mål-URL, bør ethvert fragment i den opprinnelige URL-en forlates. Dessverre mislyktes Bos 'forslag om å navigere i IETF-standardsporet og gikk ut uten videre arbeid. Dubost et al. gjenopplivet Bos 'forslag i en W3C-note (ikke en standard, men veiledning i fravær av en standard). Produsenter av nettklienter som nettlesere har "generelt" ikke fulgt Bos 'veiledning.

Fra og med PURLz 1.0-serien implementerer PURL-tjenesten delvis omdirigeringer inkludert fragmentidentifikatorer ved å skrive fragmenter på mål-URL-er i et forsøk på å overholde og unngå problematisk og inkonsekvent oppførsel fra nettleserleverandører.

Se også

Referanser

Eksterne linker