mailto: payer@hbi-stuttgart.de
Zitierweise / cite as:
Payer, Margarete <1942 - >: Wir katalogisieren das Internet : URL's, URN's und Co. ; Vortrag auf der 1. InetBib-Tagung, Dortmund, am 12.3.1996. -- Fassung vom 21. April 1996. -- URL: http://www.payer.de/einzel/urlco.htm . -- [Stichwort].
©opyright: Dieser Text steht der Allgemeinheit zur Verfügung. Eine Verwertung in Publikationen, die über übliche Zitate hinausgeht, bedarf der ausdrücklichen Genehmigung der Verfasserin.
Im Internet werden zur Zeit eine Reihe von Vorschlägen diskutiert, die zu Standards der Beschreibung von Internetressourcen werden sollen. Man erwartet, daß diese Standards, sobald sie offiziell vorgeschlagen sind, sich genau so durchsetzen wie der Uniform Resource Locator (URL). Verantwortlich für diese Entwicklung ist die IETF (Internet Engineering Taskforce), die Diskussionsgruppen eingesetzt hat. Demokratisch, wie das Internet ist, kann jeder, der von der Sache etwas versteht, sich anmelden und in erster Linie über Mailing-Listen mitmachen.
IETF: http://www.ietf.cnri.reston.va.us/home.html
Zu diesen Entwürfen gehören:
auf der einen Seite der Uniform Resource Identifier (URI) mit den Teilen :
- Uniform Resource Name (URN)
- Uniform Resource Locator (URL)
- Uniform Resource Characteristics (URC)
- Uniform Resource Agent (URA),
auf der anderen Seite das Dublin Metadata Core Element Set.
Ich werde im folgenden diese Standardvorhaben behandeln mit Ausnahme der URA, einem Vorschlag, der erst angedacht ist. Zusätzlich wird als proprietäre Lösung der Persistent Uniform Resource Locator (PURL) von OCLC in die Diskussion mit eingeschlossen.
Wie oben gesagt, besteht die URI zur Zeit im wesentlichen aus den Teilen URN (eindeutige Identifizierung der Quelle), URL (Standort der Quelle) und URC (Beschreibung der Quelle).
Webpage für URI: http://www.acl.lanl.gov/URI/
An diese Standards werden u.a. folgende Anforderungen gestellt:
- der Zeichensatz muß allgemein gültig sein (US-ASCII)
- der Transport muß über die gängigen Internet-Protokolle möglich sein (also TCP, FTP, Telnet usw.)
- die maschinelle Verarbeitbarkeit muß gewährleistet sein, d.h. ein Programm muß die Angaben interpretieren und verarbeiten können
- die Daten müssen vom Menschen gelesen und eingetippt werden können
- ein Ausdruck muß möglich sein
- die Standards müssen erweiterbar sein.
Ausführlich zu URL: Margarete Payer: Computervermittelte Kommunikation. - Kapitel 13,2. - URL: http://www.well.com/user/payer/cmcs1302.html
Während sich die anderen Teile der URI noch im Entwurfsstadium befinden, ist die URL ein anerkannter Standard, der sich weltweit durchgesetzt hat. Es handelt sich um eine Art Signatur bzw. die Angabe des Standorts und die Zugangsmöglichkeit zu einer Internetressource.
Eine URL kann aus folgenden Bestandteilen bestehen:
Zugangsprotokoll://Hostadresse:Port/Pfad
Als Zugangsprotokoll findet man zur Zeit:
- http: Hypertext Transfer Protocol, das für World Wide Web zuständige Protokoll
- ftp: File Transfer Protocol, vor allem für die sichere und schnelle Übertragung von Dateien benutzt
- telnet: ist zu benutzen, wenn man im entfernten Rechner arbeiten will - vor allem noch für OPAC-Suchen nötig
- wais: Wide Area Information Service: für inhaltliche Suche in Volltexten benutzt
- gopher: menuegeführtes Angebot
- news: USENET news
- mailto: für e-mails
- file: klientspezifische Dateinamen (also lokale Dateinamen)
Als Hostadresse kann die IP-Adresse oder der Domain Name angegeben werden:
- die IP-Adresse (Internetprotokoll-Adresse) ist die einem Host offiziell zugeteilte Nummer, die aus vier Blöcken besteht z.B. 26.104.0.19. Es handelt sich um die Klassenkennung, die Netzadresse und die Rechneradresse, weshalb sich diese Nummer häufig ändern kann.
- wesentlich häufiger findet man die Angabe des Domain Name, der der jeweiligen IP-Adresse zugeordnet ist. Es wäre zu wünschen, daß Netzwerkverwalter diesen Namen möglichst nie ändern: es schadet doch nichts, wenn eine Institution trotz Namensänderung ihren alten Namen im Internet beibehält! Es gäbe viel weniger Probleme z.B. bei der Verwaltung der URL´s.
Es gibt zwei Arten von Domain-Namen: die Organisations-Domains, die man vor allem in den USA findet, und die Landes-Domains (z.B. hbi-stuttgart.de) für die übrige Welt. Da es oft sehr hilfreich ist, schon an der Adresse die Art der sendenden Institution abzulesen, folgt hier ein Überblick über die im Bibliotheksbereich wichtigsten Organisations-Domain-Namen:
- gov = nichtmilitärische Regierungsstellen z.B. loc.gov (Library of Congress)
- edu = Universitäten und andere Bildungseinrichtungen z.B. ucla.edu (University of California at Los Angeles)
- com = kommerzielle Unternehmen z.B. microsoft.com
- org = Non-profit-Organisationen z.B. oclc.org
DerPort wird nur angegeben, wenn es sich nicht um einen Standardport handelt (jedes Zugangsprotokoll benutzt einen standardisierten Eingang im Server, der Verwalter kann aber auch einen anderen Eingang zuweisen), z.B. ...edu:1234.
Als Pfad wird der volle Pfadnamen einschließlich eventueller Dateinamen angegeben.
Für die Schreibweise der URL werden neben der festgelegten Reihenfolge und den festgelegten Zeichen noch folgende Vorschriften gemacht:
- Klein- und Großbuchstaben sollten gleiche Bedeutung haben
- Ziffern und bestimmte Sonderzeichen sind erlaubt
- Spatien sind unzulässig
- nur der US-ASCII-Zeichensatz ist zulässig, also keine Umlaute in deutschen Namen!
Die Probleme der URL:
- es können für einen Text mehrere URL´s angegeben werden, weil der Text auf mehreren Servern liegt, oder unterschiedliche Zugangsprotokolle benutzt werden können. Lösung: es müssen alle URL´s zum jeweiligen Text angegeben werden.
- die Hostadresse ändert sich, weil sich der Name der Institution geändert hat und diese Änderung im Domain-Namen nachvollzogen wurde, oder weil der Text auf einen anderen Host verlegt wird (z.B. auf einen billigeren). Hier will OCLC mit der PURL eine Lösung anbieten, auch die URN soll zu einer Lösung des Problems beitragen.
- die Zugangsmethode ändert sich.
mailing list zu PURL: mailto:listserv@oclc.org ; Text: subscribe purl-l [Vorname] [Nachname]
PURL-FAQ: http://purl.oclc.org/
Die PURL wurde von OCLC entwickelt, um aus dem Problem der sich ändernden URL´s herauszukommen. Von der Funktion her ist die PURL eine URL, nur daß die PURL nicht direkt auf die Internetstelle verweist sondern auf einen dazwischengeschalteten Dienst. Dieser Dienst (zur Zeit auf einem Server bei OCLC) verbindet die PURL mit der jeweils aktuellen URL. Der Server sendet bei einer Anfrage mit der PURL dem Client die gerade aktuelle URL zurück, der Client benutzt dann die aktuelle URL. Ist die PURL bekannt - d.h. wird sie in der Titelaufnahme angegeben - , können sich die URL´s beliebig verändern, und man findet den Text doch.
Gebildet werden diese PURL´s in der üblichen Weise mit dem verwaltenden Server als Hostadresse und dem entsprechenden Pfad: bei OCLC wird die Identifikationsnummer der dazugehörigen Titelaufnahme genommen. Als Transportprotokoll wird grundsätzlich http genommen. Da OCLC inzwischen die Software frei zur Verfügung stellt, könnten auch andere Institutionen z.B. Verbundzentralen einen solchen Weg gehen.
Source code für PURL: http://purl.oclc.org/
Beispiel: http://purl.oclc.org/oclc/oluc/32127398/1
oder ohne OCLC: http://purl.somewhere. edu/library/catalog
Für jede Titelaufnahme wird eine PURL oder mehrere PURL´s entsprechend der Anzahl der vorhandenen URL`s geschaffen und im MARC-Format in Kategorie 856 (subfield $u) abgelegt. Die eigentliche URL wird in 856 subfield $z (Public Note) erfaßt, damit die darin enthaltene Information erhalten bleibt. Selbstverständlich muß gleichzeitig die URL in die OCLC-PURL-Resolver-Datenbank geschrieben werden.
Man stellt sich von OCLC aus vor, daß diese Datenbank weltweit genutzt wird. Um die Datenbank im Griff zu halten, dürfen nur registrierte Nutzer PURL´s erstellen und URL´s zuordnen, bzw. Umleitungen durchführen. Der Berechtigte kann dies aber nur für die eigene Domain machen. Daß zwei identische PURL´s entstehen, wird durch Programm verhindert. OCLC erwartet, daß Änderungen in URL´s von den Leuten, die URL´s erstellen, an die Datenbank gemeldet werden. Und genau das ist die Schwachstelle des Vorschlags.
PURL´s sollen im übrigen nur für Texte vergeben werden, von denen man annnimmt, daß sie von bleibender Bedeutung sind, also z.B. für individuelle Artikel, aber nicht für einzelne Kapitel, Graphiken usw, Texte, die ohne Kontext unverständlich sind, vergängliche Meldungen.
Was sind die Vorteile der PURL?
- Gesetzt der Fall, man recherchiert im OLUC (der Online-Datenbank von OCLC) und findet eine Titelaufnahme zu einem elektronisch publizierten Text, kann man mit der angezeigten PURL über den Zwischenweg OCLC-Server die im Zeitpunkt des Suchens aktuelle URL finden.
- Links in Hypertexten müssen nicht geändert werden, wenn sich die URL ändert.
- Systemverwalter, die den Hostnamen ändern, müssen nur dieses melden: für die Weiterleitung wird dann jeweils nur dieser Teil ersetzt.
Archiv der URN mailing list: http://www.gatech.edu/iiir/urn/
Um den Schwierigkeiten der sich ändernden URL´s aus dem Weg zu gehen und bei mehreren URL´s für ein Objekt das Objekt sicher identifizieren zu können, entwickelt man zur Zeit im Auftrag der Internet Engineering Task Force (IETF) die URN´s. Ein Uniform Resource Name ist fest mit einem einzigen Objekt verbunden - unabhängig davon, auf welchem Server das Objekt liegt. Eine URN dient nicht dazu, etwas über den Inhalt auszusagen. Wie die frühere Auflösung der Abkürzung URN als Uniform Resource Number schon andeutete, besteht die URN im wesentlichen aus Ziffern und entspricht etwa einer ISBN. Hat das Werk schon eine ISBN, wird diese innerhalb der URN angegeben.
Bei der Entwicklung der URN´s versucht man Automatismen zu entwickeln, die aus einer URN zu den URL`s führen können. Wie man aus einer ISBN den Verlag bzw. die verantwortliche Körperschaft ablesen kann, soll ein Programm entsprechende Hinweise aus der URN entnehmen.
Die URN besteht aus vier Komponenten, die jeweils durch Doppelpunkt getrennt sind:
- die Angabe URN
- die Angabe des Standards bzw. der Normbezeichnung (naming authority scheme identifier) z.B. ISBN, ISSN, IANA [Internet Assigned Numbers Authority]
- die Angabe der verantwortlichen Stelle d.h. der Stelle, die das Recht hat, eine URN zu erstellen z.B. IANA:merit.edu
- die Angabe einer Ziffern- oder Buchstabenfolge, die von der verantwortlichen Stelle speziell für das einzelne Objekt vergeben wird
z.B. :
URN:IANA:merit.edu:1929642
Bevor die URN zum Standard erklärt wird, muß u.a. noch geklärt werden, was man als identischen Text ansieht: Soll einem ASCII-Text und einem Postskript-Text für ein identisches Werk eine oder zwei URN´s zugeteilt werden? Wie weit gilt das auch für Übersetzungen? Die Tendenz scheint zur Zeit zu sein, daß man sich eher für nur eine URN entscheiden will, damit der Benutzer nicht viele URN´s aufsuchen muß, nur um dann festzustellen, daß es sich um einen identischen Text handelt.
mailing list zu URC: mailto:listproc@list.gatech.edu ; Text: subscribe urc-l [Vorname] [Nachname]
HyperMail Archive zur URC mailing list: http://www.gatech.edu/iiir/urc/
Bei der URC handelt es sich um eine Beschreibung einer Internet-Ressource, die beliebig tief gehen kann. Man stellt sich vor, daß man mit einer minimalen Beschreibung beginnt und jemand anderes, z.B. Katalogisierer, dann nach Bedarf noch weitere Elemente hinzufügt. Die URC kann sich zu einer sehr ausführlichen Titelaufnahme entwickeln. Die Elemente der URC sollen so definiert werden, daß sie in unterschiedlichste Systeme übernommen werden können.
Die URC muß mindestens die Angaben der URN und die URL (den physischen Standort) enthalten, oder nach neueren Vorschlägen die URN und das Format (content type):
Beispiel für eine minimale URC:
<urc>
<urn>IANA:lanl.gov:LA-UR-94-00023
<location>http://www.acl.lanl.gov/...
Eine ausführliche URC kann folgende zehn Elemente enthalten:
- die URN
- Verfasser
- Titel
- Schlagwort
- Abstract
- physischen Standort (URL)
- Version
- Zugangsbestimmungen z.B. "access restriction"
- Beglaubigung: digitale Unterschrift (signature) mit der Angabe, welches Verschlüsselungsschema benutzt wurde
- Hinweis auf Rezensionen (review)
Jedes dieser Elemente kann verschiedene Ausführlichkeitsgrade haben:
z.B. Element Verfasser:
- kurze Lösung:
Daniel, Ronald E. Jr
- lange Lösung:
Daniel, Ronald E. Jr
Email: rdaniel@lanl.gov
Phone: 1 505 665 0139
Was verspricht man sich im wesentlichen von der URC?
- Hilfe beim Finden der URL´s, da man die URN angeben muß
- nähere Informationen über einen Text, damit der Benutzer im World Wide Web einem Link schon ansieht, ob es sich lohnt, den Text, der ja auch etwas kosten kann, zu holen
- daß der Benutzer sicher sein kann, den richtigen Text zu erhalten (deshalb soll die Signatur angegeben werden).
Die Vorschläge zur URC werden zur Zeit heftig diskutiert, besonders:
- die Anwendung der SGML (Standard Generalized Markup Language)
- das Verhältnis zu MARC, AACR2 und ähnlichem
Metadata Workshop Report: http://www.oclc.org:5047/oclc/research/publications/weibel/metadata/dublin_core_report.html
Entwurf vom 1.5.95: http://www.acl.lanl.gov/URI/dublin2.txt
Während die URC ursprünglich nur gedacht war, über eine Besonderheit eines Textes zu informieren, und keineswegs eine Art Titelaufnahme darstellen sollte, wurde parallel ein Vorschlag (das Dublin Metadata Core Element Set) zur standardisierten Beschreibung von Daten in elektronischen Netzen entwickelt. Die Auswahl der Metadaten sollen zwischen den Angaben in den Suchmaschinen auf der einen Seite und den Angaben in vollem MARC-Format auf der anderen Seite liegen. Man wählte ausdrücklich nicht ein verkürztes MARC-Format, da man sich bewußt war, daß eine traditionnelle Beschreibung auf viele Objekte im Netz nicht anwendbar ist. Außerdem will man erreichen, daß der jeweilige Verfasser selbst diese Daten in standardisierter Form seinen Texten beigibt, so daß man durch eine automatische Suche einen Katalog erstellen kann.
An der Entwicklung sind Organisationen wie OCLC, LoC, MARBI (das Gremium für MARC), SGML-Entwickler usw. beteiligt. Wesentliche Ergebnisse wurden auf einem ersten Workshop im März 95 beschlossen. Der nächste Workshop im April 96 soll den Vorschlag auf alle Disziplinen und Sprachen ausdehnen, und außerdem Mechanismen schaffen, die eine ausführlichere Beschreibung und Verknüpfungen zu anderen Beschreibungen schaffen soll. Im April werden auch europäische Vertreter dabei sein.
Wenn nun jeder Verfasser eine Beschreibung liefern soll, muß der Standard sehr einfach sein, und es muß möglich sein, mit Minimalangaben auszukommen. Die Elemente für die Minimalangaben wurden so ausgewählt, daß mit ihnen ein Wiederfinden der Quelle möglich ist. Außerdem grenzte man den Vorschlag auf dokumentenähnliche Objekte (document-like objects) ein, wobei man bewußt keine genaue Definition gab: im weitesten Sinne handelt es sich um Text. Als Beispiele werden genannt: elektronische Version eines Zeitschriftenartikels, ein Wörterbuch, aber nicht eine elektronische Version einer Karte.
Man einigte sich auf 13 Metadata Elemente:
- Subject = das Wissensgebiet, zu dem das Werk gehört
- Title = Name des Objekts
- Author = der oder die Personen, die in erster Linie für den intellektuellen Inhalt des Werkes zuständig sind
- Other agent = sonstige beteiligte Personen, wenn ihre Mitarbeit wesentlich ist
- Publisher = derjenige oder die Körperschaft,die verantwortlich ist, daß das Objekt erhältlich ist (Agent or Agency)
- Date = Veröffentlichungsdatum
- Object type = Gattung z.B. Roman, Gedicht, Wörterbuch
- Form = die physikalische Form z.B. Postskript file
- Identifier = Buchstabenfolge oder Nummer, die diesem Objekt zugeordnet ist
- Relation = Beziehung zu ähnlichen Objekten
- Source = Objekte (gedruckt oder elektronisch), aus denen das vorliegende Werk entstanden ist
- Language = Sprache des Inhalts
- Coverage = Raum und Zeitdauer
Bei der Anwendung dieser Elemente ist folgendes zu beachten:
- es geht darum, den intellektuellen Inhalt des Werkes zu beschreiben, nicht so sehr die physische Form
- kein Element muß verbindlich benutzt werden (z.B. keine Verfasserangabe bei einem Satellitenbild)
- alle Elemente sind wiederholbar (z.B. mehrere Verfasser)
- Bibliotheken können den Elementen Indikatoren zuordnen
- die Elemente sollen so beschrieben sein, daß sie in anerkannten Standards wie MARC verwendet werden können
- die Beschreibung (durch die Autoren) sollte zumindest soweit nutzbar sein, daß sie als Grundlage für qualifizierte Katalogisierung benutzt werden kann.
Es werden zur Zeit noch folgende Probleme diskutiert:
- Versionen: Wie lange ist ein Text derselbe? Solange er bitweise identisch ist oder so lange der Verfasser den Text als identisch ansieht? Man hilft sich zur Zeit mit folgender Lösung: wenn der Verfasser den Text inhaltlich als identisch ansieht, benutzt er das "Source"-Element, um die frühere Version zu beschreiben, sonst soll das "Relation" Feld benutzt werden.
- Ausführlichkeit: wenn jeder unterschiedliche Dinge hinzufügen darf, bleibt die Frage, ob die Aufnahmen dann nicht eine unendliche Varietät von Datentypen und Standards aufweisen. Man will bewußt nicht SGML (Standard Generalized Markup Language) vorschreiben, da das dem Ziel, daß jeder die Regeln anwenden können soll, widerspricht.
- Zeichensatz: Kann man bei US-ASCII bleiben? Was geschieht mit nichtlateinischen Schriften?
Ein Beispiel:
- Subject: same as above
- Author: same as above
- Title: same as above
- Date: 1993
Man muß sich darüber im klaren sein, daß mit Ausnahme der URL und damit zusammenhängend der PURL alle Standards erst im Entwurfsstadium sind und sich noch sehr ändern können. Man erwartet, daß URC und URN noch 1996 zu anerkannten Standards werden. Leider sind bei der Diskussion, die zwischen Bibliothekaren, Netzwerkverwaltern und weiteren interessierten Personen geführt werden, nur Personen aus englischsprachigen Staaten aktiv (USA, Australien, Großbritannien). Man ist sich in den Mailing-Listen durchaus bewußt, daß man Probleme aus anderen Sprachbereichen wohl zu wenig beachtet, und hofft auf Teilnehmer aus anderen Ländern. Es wäre gut, jemand aus den InetBib-Reihen würde nicht nur die Sache beobachten, was nach meiner Erfahrung auch schon eine Menge Zeit kostet, sondern würde sich aktiv beteiligen.
ENDE