Das World Wide Web Projekt hat neben den beiden Features HTTP und der Hypertext-Funktionalität noch eine dritte Säule hervorgebracht, die die revolutionäre Verbreitung der World Wide Web Technologie (und letztendlich auch des Internet) erst ermöglichte: Einheitliche Lokalisierung und Adressierung von Ressourcen mit dem URL. Doch der URL ist nur ein Teil einer noch umfassenderen Idee: Der Uniform Resource Identifiers - Identifikation einer Ressource, nicht nur durch ihren Standort.
Das Problem und die Idee
Bei der Entwicklung des World Wide Webs Anfang der neunziger Jahre des 20. Jahrhunderts machte man sich ebenfalls darüber Gedanken, wie Ressourcen im Informationsraum des World Wide Web und im Internet einheitlich angesprochen werden könnten. Das Ergebnis waren mehrere Konzepte und Dokumente, die unter dem Begriff Uniform Resource Identifiers (URI) zusammengefasst wurden.
Vereinfacht gesagt, wird dabei folgender gegangen: Das Internet wird als weitgehend unsortierter, dezentral organisierter Informationsraum angesehen, der eine unbestimmte Anzahl von unterschiedlichen, multimedialen Ressourcen beinhaltet. Das können einfache Texte sein, Musikdateien, Grafiken, Filme etc. sein. Die Idee der Uniform Resource Identifiers ist nun, alle Ressourcen in diesem unsortierten, dezentral organisierten Informationsraum eindeutig und unverwechselbar adressierbar zu machen.
Ein Beispiel für die Notwendigkeit von einheitlichen Konventionen zur Bestimmung von Inhalten finden Sie im Datumssystem: Niemand wird Zweifel daran haben, welcher Tag beispielsweise der 12. April 1975 ist; es ist zweifellos ein Tag, der Mitte April im Jahre 1975 liegt. Auch die kurze Schreibweise "12.04.1975" bringt uns nicht weiter in Verlegenheit, weil es in unserem Sprachraum üblich ist, dass in der numerischen Datumsnotation zuerst der Tag und dann der Monat angegeben wird. Das wird jedoch nicht mehr so einfach, wenn wir in den angelsächsischen Raum schauen, denn dort wird üblicherweise zunächst der Monat und dann der Tag angegeben, also in unserem Beispiel "04/12/1975". Wird dieses Datum in einem englischsprachigen Text verwendet, wird der geübte Leser dieses Datum in der Regel richtig interpretieren, der ungeübte könnte jedoch in die Falle treten und das Datum fälschlicherweise als 4. Dezember 1975 interpretieren. Richtig kompliziert wird es, wenn beispielsweise ein englischer Text in deutsche Sprache übersetzt wird und der Übersetzer das Datum nicht in hier übliche Datumsnotationen übersetzt ...
Gefragt wäre also eine einheitliche Notation, diese wäre jedoch aus Traditionsgründen nur in einem sehr langfristigen Zeitraum weltweit in allen Sprachräumen durchsetzbar. So lange muss man sich mit Teilkonventionen behelfen, beispielsweise, in unserem kleinen Datumsbeispiel, mit der Notation Jahr-Monat-Tag, also 1975-04-12.
Zusammenfassend kann man also sagen, dass mit Unified Resource Identifiers und allen darunter fallenden Konzepten keine Ressourcen selbst beeinflussen (den Tag, auf den ein Datum fällt, kann ja auch keiner beeinflussen), sondern sie nur einheitlich adressieren kann.
Das Konzept Uniform Resource Identifiers
Der Überbegriff Uniform Resource Identifiers dient genau genommen als Gesamtmenge für mehrere Einzelkonzepte, die die Idee verfolgen, einheitliche und unverwechselbare Adressierungsschemata zu implementieren. Das Konzept der URI wurde im August 1998 als RFC 2396 standardisiert
Der Aufbau eines URI (und damit auch aller darunter liegender Konzepte) ist dabei denkbar einfach:
Schema:Schemaspezifischer_Teil
Schema ist hierbei eine eindeutige Schemadefinition, gibt also an, um was für eine Ressource es sich handelt. Schemaspezifischer_Teil ist der eigentliche Ressourcenzeiger, beinhaltet also alle Angaben, die den Standort der Ressource oder die Ressource selbst genau definieren.
Zu den Einzelkonzepten der Unified Resource Identifiers gehören:
- Uniform Resource Locator (URL)
- Uniform Resource Names (URN)
- Persistent Uniform Resource Locator (PURL)
- Uniform Resource Characteristics (URC)
Diese werden nachfolgend näher beschrieben:
Uniform Resource Locator (URL)
Das URL-Schema ist der berühmteste und auch der am weitesten entwickelte Vertreter aus der URI-Konzeptfamilie. Es wurde im Dezember 1994 als Standard im RFC 1738 veröffentlicht, unter anderem von Tim Berners-Lee, dem "Vater" des World Wide Webs. Das URL-Schema gehört neben HTTP und HTML zu den drei Grundsäulen des World Wide Webs, heutzutage arbeiten jedoch alle gängigen Programme, die auf Internet-Ressourcen zurückgreifen, mit dem URL-Schema.
Der URL (es heißt genau genommen tatsächlich "der URL", da der englische Begriff "Locator" am ehesten mit "Zeiger" übersetzt werden kann) besitzt einen etwas komplexeren Aufbau:
Ressourcentyp://User:Passwort@Host.Domain.TLD:Port/Pfad/Datei Parameter
- Ressourcentyp steht für das anzuwendende Internet-Protokoll, mit dem die weiter hinten angegebene Ressource angesprochen werden soll. Dies kann beispielsweise "http" sein, wenn die Ressource per HTTP abgerufen werden soll.
- Gefolgt wird diese Protokollkennzeichnung von
einem Doppelpunkt, der Ressourcentyp und
Ressourcenzeiger voneinander trennt und, falls der URL
eine nicht-lokale Aktion auslösen soll, mit zwei
Schrägstrichen. "Nicht-lokal" bedeutet, dass der
Ressourcenzeiger eine Ressource außerhalb des eigenen
Rechners anspricht (beispielsweise
http://www.netplanet.org/). "Lokal" bedeutet, dass
die Ressource eine Aktion auf dem eigenen Rechner
startet, die wiederum dann eine Aktion bewirkt
(beispielsweise ein Verweis auf eine Mailadresse mit
mailto:user@foo.bar, der bei Eingabe in einen
Webbrowser ein Mailfenster öffnen lässt).
Eine (augenscheinliche) Ausnahme gibt es jedoch mit dem Ressourcentyp file:, wie in diesem Beispiel ersichtlich, wenn auf einem Windows-System auf den Ordner testordner auf dem C:-Laufwerk zugegriffen wird:
file:///C:/testordner/
Der Ressourcentyp file: wird verwendet, wenn beispielsweise über einen Webbrowser auf eine lokale Ressource auf dem Rechner des Benutzers zugegriffen wird. Der Webbrowser behandeln diese Ressource dann so, als ob der lokale Rechner ein eigenständiger Server wäre und fügt nach file: korrekterweise die zwei Schrägstriche an. Der dritte Schrägstrich ist keineswegs ein Fehler, sondern kennzeichnet die oberste Verzeichnishierarchie auf dem Rechner. Die Kennzeichnung dieser obersten Hierarchie mit einem Schrägstrich ist auf UNIX- und UNIX-ähnlichen System seit Anfang an bekannt. Unter Windows ist diese oberste Hierarchie, logisch gesehen, nicht etwa das C:-Laufwerk oder irgendein anderes, sondern die Ebene darüber, der Arbeitsplatz.
- User:Passwort enthalten, wie unschwer zu
erraten ist, Benutzername und Passwort. Beide Werte sind
optional, können also bei Ressourcen, die keine
Authentifizierung benötigen, weggelassen werden (dann
wird auch der nachfolgende Klammeraffe weggelassen).
Wird eine Authentifizierung benötigt und keine
angegeben, wird dies mit einer Fehlermeldung quittiert.
Moderne Webbrowser kaschieren dies übrigens elegant:
Wird eine zugangsgeschützte Ressource ohne
Authentifizierung angesprochen, liefert der Webbrowser
nicht sofort eine Fehlermeldung, sondern fordert den
Benutzer mit einem Eingabefenster zur Eingabe von
Benutzername und Passwort auf. Die Ressource wird dann
nochmals aufgerufen, nun mit diesen Benutzerdaten.
Es kann im URL-Schema übrigens auch nur ein Benutzername angegeben werden (im obigen Schemabeispiel also nur User). Diese Syntax führt nämlich dann zur Schreibweise von E-Mail-Adressen, denn, hier ist der vordere Teil (also vor dem Klammeraffen) der benutzerspezifische Teil. Will man also beispielsweise das obige Beispielschema auf E-Mail-Adressen anwenden, würde dies wie folgt aussehen:
mailto:User@Host.Domain.TLD
(Der Fairness halber muss jedoch an dieser Stelle gesagt werden, dass der Aufbau der E-Mail-Adresse, also die Nutzung des Klammeraffen zur Trennung zwischen Benutzer und Domain, schon lange vor der Entwicklung des URL-Schemas eingeführt wurde. Die Entwickler des URL-Schemas betteten demnach die Idee mit dem Klammeraffen in ihr Konzept ein und nicht umgekehrt.)
- Host.Domain.TLD enthält die Adresse des Rechners, der angesprochen werden soll und die gewünschte Ressource enthält. Dies kann beispielsweise www.netplanet.org sein, aber beispielsweise auch eine IP-Adresse.
- Port steht für die Adresse des TCP- oder UDP-Ports, mit dem eine Verbindung zur davor angegebenen Adresse des Rechners aufgebaut werden soll. Ist kein solcher Port angegeben, wird für gewöhnlich vom Programm, das diese Abfrage sendet, der Standard-Port verwendet, der für den Ressourcentyp reserviert ist. Wird beispielsweise in einem Webbrowser eine HTTP-Anfrage gesendet, wird diese, falls kein gesonderter Port angegeben wird, auf dem für HTTP reservierten TCP-Port 80 gesendet.
- /Pfad/Datei wird schließlich für die Ressourcenangabe lokal auf dem Zielrechner genutzt, enthält also Verzeichnis- und Dateiangaben.
- Parameter enthält Daten, die zur
Beeinflussung der gewünschten Ressource dienen. Dies
können Inhalte von Variablen sein, die beispielsweise
mit dem URL
"http://www.netplanet.org/index.shtml?variable=variableninhalt"
übergeben werden (variable ist hierbei die
Bezeichnung für die Variable und variableninhalt
deren Inhalt).
Bei Parametern gilt jedoch, dass die Verarbeitung abhängig vom Ressourcentyp, also dem zu verarbeitenden Internet-Protokoll, ist. Während beispielsweise HTTP eine Vielzahl von Parametern kennt (beispielsweise das obige Schema oder das Gatter "#" zur Angabe eines HTML-Ankers), gibt es bei FTP keine solchen Parameter, die zu übergeben wären.
Uniform Resource Names (URN)
Ein weiteres URI-Schema sind die Uniform Resource Names (URN), das federführend von der IETF entwickelt wird (siehe hierzu auch Standardisierung im Internet). Im Gegensatz zu den Uniform Resource Locators (to locate bedeutet übersetzt "zeigen"), bezeichnen die Uniform Resource Names direkt Objekte in einem bestimmten Informationsraum. Ein URN gibt also keine Auskunft über den genauen Standort oder den Inhalt einer Ressource, sondern bezeichnet sie lediglich eindeutig und unverwechselbar.
Beispiele für solche Informationsräume gibt es in unserer Umgebung zuhauf, einen der bekanntesten finden Sie auf fast jedem Produkt, das Sie kaufen: Den EAN-Code (EAN steht für European Article Number). Dieser besteht aus einer 13-stelligen Nummer und kennzeichnet das Produkt auf diese Weise weltweit eindeutig, da kein anderes Produkt (und übrigens auch keine andere Produktgröße, falls es verschiedene Ausführungen gibt) denselben EAN-Code trägt. Weitere Informationsräume sind beispielsweise der ISBN-Code (International Standard Book Number) für Bücher und der ISSN-Code (International Standard Serial Number) für periodisch erscheinende Publikationen wie Zeitungen und Zeitschriften.
Der Aufbau eines URN ist folgender:
urn:Namespace_Bezeichnung:Ressourcenbezeichner
- urn und der folgende Doppelpunkt dienen als Kennzeichnung, dass die nachfolgende Zeichenkette eine URN ist.
- Namespace_Bezeichnung und der darauf folgende Doppelpunkt ist eine Kennzeichnung für den Informationsraum, den Standard oder die Normbezeichnung, dem die zu bezeichnende Ressource angehört. Dieses Feld besteht aus einem unverwechselbaren und international verbindlichen Kürzel, in der Regel eine Abkürzung.
- Ressourcenbezeichner enthält schließlich die genaue Bezeichnung der Ressource beziehungsweise des Objekts. Dies kann eine Nummer, aber auch eine alphanumerische Kennung sein, ist aber auf jeden Fall bei jeder Ressource und Objekt im Informationsraum einzigartig.
Nehmen wir als Beispiel die offizielle ISSN-Nummer der Zeitschrift P.M.-Magazin, um diese als URN darzustellen:
urn:ISSN:0176-4152
Die Überlegung, die hinter dem URN-Schema steckt, ist ebenfalls die, den jeweiligen Informationsraum einheitlich ansprechen zu können. Da der jeweilige Informationsraum von einer offiziellen Stelle verwaltet wird, könnten sich auf diese Weise alle nötigen Informationen über die Ressource abrufen lassen, beispielsweise die Identifikationsdaten der jeweiligen Publikation oder einem Verweis auf die Redaktion, die ja in der Regel bereits schon in dem bestehenden ISSN-System vorhanden sind. Das URN-Schema kann mit seinem Ansatz nun eine eindeutige Zugriffsmöglichkeit auf diese Daten ermöglichen, ohne dass der Benutzer genau wissen muss, wo in unserem Beispiel das P.M.-Magazin seine eigene Homepage hat.
Persistent Uniform Resource Locator (PURL)
Persistent Uniform Resource Locator ("Beständiger, einheitlicher Ressourcenzeiger") ist eine Anwendung, die auf das URN-Schema basiert und per URL aufrufbar ist. Verwaltet wird das PURL-System vom Online Computer Library Center (OCLC) im Rahmen einer IETF-Arbeitsgruppe.
Die Idee, die hinter PURL steckt, ist folgende:
Eine Ressource (beziehungsweise in diesem Fall ein Ressourcenzeiger in Form einer URL) wird in eine eigene, neue URN-Baumstruktur eingebunden und ist fortan auch unter diesem URN-Baum erreichbar. Dies hat den (theoretischen) Vorteil, dass der Benutzer nicht den genauen Standort kennen muss, sondern lediglich den URN. Im Beispiel habe ich für netplanet einen PURL eingerichtet, der folgendermaßen lautet:
http://purl.oclc.org/net/netplanet
Geben Sie nun diesen URL in Ihrem Webbrowser ein, wird diese Anfrage an den PURL-Server geschickt. Der dortige Server wertet den hinteren Teil (also /net/netplanet) aus. Da ich unter der Hierarchie "net" im URN-Baum des PURL-Systems einen Eintrag für netplanet angelegt habe, wird dieser Eintrag gefunden, der nichts anderes enthält, als den "normalen" URL http://www.netplanet.org/. Auf diese Adresse leitet dann das PURL-System Ihren Webbrowser um. Sie müssen sich also bei diesem System nicht darum scheren, wo netplanet liegt, sondern müssen lediglich den Begriff "netplanet" eingeben, um automatisch dorthin geleitet zu werden.
Zugegeben, der Ansatz von PURL ist sehr abstrakt und theoretisch; passt "irgendwie" gar nicht in das etablierte URL-System mit Domainnamen, wie wir es aus dem Internet heute kennen. Diesem ersten Eindruck stimme ich persönlich zu, der daran liegt, dass mit dem PURL-System ein neuer Informationsraum geschaffen wird, der auf den ersten (und genau genommen auch auf den zweiten) Blick eigentlich unnötig ist; niemand wird im PURL-System nach netplanet suchen, wenn er noch nicht mal PURL selbst kennt.
PURL ist deshalb nur ein Beispiel für eine URN-Anwendung, die in das URL-System eingebettet ist. Andere URN-Anwendungen, wie beispielsweise der oben bereits angesprochene Ansatz mit ISSN-Nummern, sind sicherlich in zukünftigen Anwendungen deutlich interessanter, da hier der Informationsraum mit den ISSN-Nummern schon etabliert ist.
Uniform Resource Characteristics (URC)
Uniform Resource Characteristics ("Einheitliche Ressourcencharaktere") sind ein weiteres Mitglied in der URI-Familie und sind für Beschreibung beliebiger Eigenschaften und zusätzlichen Informationen zu einer Ressource vorgesehen, den so genannten Metadaten. Die Idee lehnt sich hierbei an die bekannten Kurztitel aus Büchern an, um auf diese Weise die Ressource mit bestimmten Informationen einheitlich zu beschreiben. Dazu gehören beispielsweise der Titel der Ressource, der genaue Standort in Form einer URL, der Verfasser, Schlagwörter, Versionsinformationen, Angaben über die verwendete Sprache, Zugangsbestimmungen et cetera.
Die meisten konkreten Ansätze bei URC beschränken sich auf Entwicklungen und Tests, da die Katalogisierung von Internet-Ressourcen ein sehr komplexes Unterfangen ist. Bei den ersten Überlegungen des URC-Schemas war die Informationswelt im Internet noch deutlich starrer und strukturierter und das World Wide Web ein Dienst von vielen. Ein System, dass die Charakteristika von Internet-Ressourcen auch nur annähernd katalogisieren will, muss hochflexibel auf die unterschiedlichsten Darstellungsarten von Informationen reagieren und darüber hinaus seine Datenbasis ständig in kürzester Zeit selbst aufbauen und pflegen können. Ein Blick auf viele Suchmaschinen und deren teilweise veralteten Verweise auf indexierte Ressourcen zeigt ansatzweise auf, wo das Problem gelagert ist, wenn man einen sich ständig verändernden Informationsraum katalogisieren möchte.
Einen mutigen Weg in Sachen Metadaten für Internet-Ressourcen geht seit vielen Jahren die Dublin Core Metadata Initiative (DCMI), die 1995 in Dublin, Ohio (USA) erstmalig zusammengekommen ist und einheitliche Beschreibungen für Internet-Ressourcen entwickelt. Durch diese Initiative, die ursprünglich auf der zweiten World Wide Web Konferenz in Chicago von Experten im Bereich Bibliothekswesen und dem Internet angeregt wurde, werden seit dem verschiedene Standards zur Beschreibung von Internet-Ressourcen veröffentlicht und weiterentwickelt.
Weiterführende Links
http://www.purl.org/
Persistent URL Home Page
http://www.dublincore.org/
Homepage der Dublin Core Initiative
