Computervermittelte Kommunikation

cmclogo.gif

Kapitel 13, 2,2,1: OSI-7 -- Application Layer, Teil 2, 2

Die Anwendungsschicht im Internet: WWW -- World Wide Web

1. HTTP und URI

von Margarete Payer

mailto: payer@hbi-stuttgart.de

Zitierweise / cite as:

Payer, Margarete <1942 - >: Computervermittelte Kommunikation. -- Kapitel 13, 2,2,1: OSI-7 -- Application Layer. -- Teil 2, 2: Die Anwendungsschicht im Internet: WWW -- World Wide Web. -- 1. HTTP und URI. -- Fassung vom 8. Juli 1999. -- URL: http://www.payer.de/cmc/cmcs13221.htm. -- [Stichwort].

Erstmals publiziert: 1995

Überarbeitungen: 19. Juni 1997; 8. 7. 1999 [grundlegende Überarbeitung und Erweiterung]

Anlass: Lehrveranstaltungen an der HBI Stuttgart

©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.

Zur Inhaltsübersicht von Margarete Payer: Computervermittelte Kommunikation.

13.0. Übersicht über Teil 2, 2,1

13.5.2.10. WWW -- W3 -- World Wide Web

Das World Wide Web, das sich rapide durchgesetzt hat, basiert auf HyperText (besser Hypermedia). WWW verknüpft Informationen aus der ganzen Welt miteinander: es verbindet die Übersichtlichkeit eines Menusystems mit den Möglichkeiten der direkten Querverbindungen zu Texten, Bildern, Ton überall auf der Welt. WWW unterstützt alle oben genannten Zugänge zum Internet.

WWW ist ein verteiltes System, d.h. viele WWW-Server sind beteiligt. Das System wurde von Tim Berners-Lee an CERN in der Schweiz entwickelt und 1991 freigegeben. Biographisches zu Tim Berners-Lee: http://ruku.com/timberners.html. -- Zugriff am 28.6.1999.

Der Client benötigt dazu einen W3-Browser -- z.B. Netscape, MS Internet Explorer, Opera, Amaya -- mit dem man Hypermedia abrufen kann (z.B. Ton, sofern man eine Soundkarte hat, oder Video) -- oder den Browser Lynx, welcher nur Texte darstellt.

Die Hauptteile des Folgenden kann man sich leicht so einprägen:

Weiterführende Ressourcen zu WWW-Browsern:

Yahoo Categories:

Virtual Libraries:

Weiterführende Ressourcen zum WWW allgemein:

Yahoo Categories:

Virtual Libraries:

Argus Clearinghouse Categories:

WWW:

Ressourcen in Printform:

Aus der Unmenge von Literatur sei nur genannt:

Powell, Thomas A.: HTML : the complete reference. -- 2. ed. -- Berkeley [u.a.] : McGraw-Hill, ©1999. -- 1130 S. : Ill. -- ISBN 0072119772. -- [Sehr gute Gesamtdarstellung]. -- {Wenn Sie HIER klicken, können Sie dieses Buch bei amazon.de bestellen}

Wilde, Erik: Wilde's WWW : technical fundations of the World Wide Web. -- Berlin {u.a.] : Springer, ©1999. -- 594 S. : Ill. -- ISBN 3540642854. -- [Klar geschrieben, geht gut auf die neuesten Entwicklungen ein]. -- {Wenn Sie HIER klicken, können Sie dieses Buch bei amazon.de bestellen}

13.5.2.10.1. HTTP -- HyperText Transfer Protocol

HTTP ist ein relativ einfaches Anforderung-Antwort-Protokoll. HTTP stellt eine Verbindung nach TCP nur für die Dauer einer einzigen Dokumentanforderung her. Für jede einzelne Dokumentanforderung wird eine neue Verbindung hergestellt. Außerdem erzeugt jede Inline Graphic in einem Dokument eine eigene, neue Verbindung zum Server, auf dem sich diese Graphik befindet. So kann die Anforderung eines einzigen HTML-Dokuments mehrfache TCP-Verbindungen zum selben oder verschiedenen Servern herstellen.

HTTP bestimmt zwei grundlegende Vorgänge:

Request von Client an Server:

Beispiel ist die Anforderung der Ressource mit der URL: http://www.payer.de/cmc/cmcs01.htm 

Syntax des HTTP-Head:

[HTTP-Method] [Identifier] [HTTP-Version]
[Zusätzliche Request-Header (optional)]

Beispiel:

GET /cmc/cmcs01.htm HTTP/1.0
If-Modified-Since: Tuesday, 29-Jun-99 00:00:00 GMT
Referrer: http://www.payer.de/cmclink.htm
Connection: Keep-Alive
User-Agent: Mozilla/3.0 (Windows 95; Internet Explorer)
Accept: image/gif, image/x-bitmap, image/jpeg, image/pjpeg, */*
Accept-Language: de, en
Accept-Charset: iso-8859-1,*,utf-8

Erklärung:

HTTP-Method:

Folgende Request-Methods sind in HTTP 1.1 vorgesehen

GET fordert das durch den Identifier bezeichnete Objekt an
HEAD fordert nur den HEAD des durch den Identifier bezeichneten Objekts an
OPTIONS fordert Informationen über den Server oder über Methoden, die auf das bezeichnete Objekt angewandt werden können, an
POST Sendet Informationen an die Adresse, die durch den Identifier bezeichnet ist. Wird verwendet um auf Formularen (<FORM>) mit METHOD="POST" eingegebene Daten an ein CGI-Programm auf dem Server zu übergeben
PUT Ladet File auf Server
DELETE Löscht (normalerweise ausgeschaltet)
TRACE für diagnostische Zwecke

Als optionale zusätzliche Request-Header sind u.a. zulässig:

optionaler request-header Beispiel
Accept: [MIME-type]/[MIME-subtype] Accept: image/gif, image/x-bitmap, image/jpeg, image/pjpeg, */*
Accept-Charset: [Zeichensatz] Accept-Charset: iso-8859-1,*,utf-8
Accept-Encoding: [Kompressionstyp] Accept-Encoding: x-compress
Accept-Language: [Sprache] Accept-Language: de, en
Authorization: [Authorisations-Schema Authorisations-Daten] Authorization: user joeblow:testpass
Content-length: [Bytes] (bei PUT und POST) Content-length: 1805
Date: [Datum und Zeit] Date: Tuesday, 29-Jun-99 00:00:00 GMT
If-Modified-Since: [Datum und Zeit] If-Modified-Since: Tuesday, 29-Jun-99 00:00:00 GMT
Proxy-Authorization: [Authorisations-Information] Proxy-Authorization: joeblow: testpass; Realm: All
Referer: [URL] Referer: http://www.payer.de/cmclink.htm
User-Agent: [Code des Browsertyps] User-Agent: Mozilla/3.0 (Windows 95; Internet Explorer)
Cookie:[Cookie] GET /index.html HTTP/1.0
Cookie: Kunde=Alois+Payer; Kundennummer:12345; (s.unten)

Response of Server an Client:

Syntax des Response:

[Status line]
[Response Headers (meist optional)]

Beispiel:

HTTP/1.0 200 OK
Content-length: 1500
Content-type: text/html
Date: Tuesday, 29-Jun-99 00:00:00 GMT
Server: Netscape-Commerce/1.12

Syntax der Status line:

[HTTP-version] [Status-code] [Reason-String]

Beispiel:

HTTP/1.0 200 OK [bei erfolgreichem Request]

HTTP/1.0 404 Not Found [wenn File nicht gefunden]

Wichtige Status-codes sind:

Einige wichtige Response Header:

Syntax Beispiele Erklärungen
Content-type: [>MIME-type]/[MIME-subtype]

Content-type: text/html
Content-type: video/quicktime
Content-type: application/x-pdf

 Aufgrund des Content-type-Header "weiß" der Browser ob er Helper-Programme, Plugins oder dergleichen aufrufen muß.
Location: [URL] HTTP/1.0 301 Redirect
Location: http://www.payer.de/cmclink.htm		 Ermöglicht bei Status code 301 (Moved permanently) bzw. 302 (Moved temporarily) Umleitung auf neuen Standort
Retry-After: [Sekunden bzw. Zeitpunkt] Retry-After: 600 Bei Status code 503 (Service unavailable): gibt an, wann Service voraussichtlich wieder zugänglich ist
WWW-Authenticate: [Authentifizierungsschema] realm="[Bereich, für den Authentifizierung nötig ist]" WWW-Authenticate: Basic realm="Nutzerdatenbank" Bei Status code 401 (Unauthorized): fordert Authentifizierung an
Set-Cookie: [Angaben zu Cookie] Set-Cookie: Kunde=Alois+Payer; path=/; domain=www.amazon.de
expires=Fri 2-Jul-1999 00:00:00 GMT		 Setzt Cookie (s. unten)
Refresh: in HTML-HEAD:

<META HTTP-EQUIV="Refresh" CONTENT="300">
<META HTTP-EQUIV="Refresh" CONTENT="0"; URL="http://www.payer.de"> {leitet sofort auf neuen Standort um}

 Für Nachladen bzw. Umleiten von Seiten

Weiterführende Ressourcen zu HTTP:

Yahoo Categories:

Virtual Libraries:

13.5.2.10.1.1. Cookies

HTTP ist ein stateless (statusloses) Protokoll, d.h. es wird keine die einzelne Übertragung von Ressourcen und Objekten übergreifende Verbindung (wie z.B. eine Session) zwischen Client und Server hergestellt: jeder Request-Response-Austausch zwischen Client und Server ist unabhängig von vorangehendem Request-Response-Austausch und ohne Einfluss auf darauffolgenden Request-Response-Austausch. Dies ist ein großer Nachteil für zusammengehörige Vorgänge wie z.B. Einkauf in einen virtuellen "Einkaufswagen", den man erst am Schluss einer Sitzung abrechnet u.ä.

Zur Lösung dieses Problems entwickelte Netscape sogenannte Cookies. RFC 2109 übernimmt im Wesentlichen diese Lösung und ist mit den Netscape-Cookies kompatibel.

Der Grundgedanke von Cookies ist es, dass zwischen Server und Client Informationen ausgetauscht werden, die eine logische Sitzung konstruieren und identifizieren. Solche Identifikation kann dann auch über die einzelne Sitzung hinaus verwendet werden, um einen Client wiederzuerkennen.

Den Vorgang illustriert folgende Abbildung:

Abb.: Herstellung einer Logischen Sitzung durch Cookie

 Erklärung:
  1. der Client fordert per http eine Resource an
  2. der Server leitet die Anforderung per CGI an eine Anwendung weiter
  3. die Anwendung übergibt an http die Antwort + ein Cookie, das den Client identifiziert
  4. per http wird die Antwort + Cookie (mit Set-Cookie im http-Header) an Client gesandt und beim Client das Cookie auf das System geschrieben
  5. der Client sendet bei dem nächsten Teil der Interaktion das Cookie an den Server per Cookie im http-Header
  6. der Server übergibt das Cookie an die Anwendung
  7. die Anwendung antwortet
  8. der Server sendet die Antwort per http an den Client
  9. der Client sendet beim nächsten Teil der Interaktion das Cookie wieder an den Server
  10. usw. usw.

Cookies, die auf den eigenen Computer gesetzt wurden, kann man unter Windows im Verzeichnis: /WINDOWS/Cookies/ finden.

Das folgende Cookie hat den Filenamen "margarete payer@www.cookiecentral[2]". Auf dieses Cookie kann von außen nur der genannte Server zugreifen:

Cookie Erklärung
lastHereOn indentity
930829314790 indentity
www.cookiecentral.com/ Domain name
0
215222400 values, variables
29291225 values, variables
473985120 values, variables
29279155 values, variables
* End Of cookie

Was die Angaben zu values, variables bedeuten, kann man nur wissen, wenn man das CGI-Skript kennt (das der Nutzer normalerweise nicht kennt!).

Cookies werden vor allem genutzt zu:

Weiterführende Ressourcen:

Yahoo Categories:

WWW:

FAQ:

13.5.2.10.1.2. HTTPS -- HTTP over Secure Socket Layer (SSL)

Um sichere Übertragung mittels HTTP zu ermöglichen, hat Netscape HTTPS -- HTTP over Secure Socket Layer (SSL) entwickelt. 1998 wurde dem W3Consortium ein Entwurf für HTTP over TLS vorgelegt, der mit HTTPS kompatibel ist. Bei HTTPS wird zwischen die Anwendungsschicht und die Transportschicht des Internets SSL als Protokoll-Zwischenschicht eingefügt:

Anwendungsschicht http ftp telnet usw.
Transportschicht Secure Socket Layer (SSL)
TCP/IP

SSL ermöglicht drei Formen der Sicherheit:

13.5.2.10.1.3. S-HTTP -- Secure HTTP

S-HTTP -- Secure Hypertext Transfer Protocol ist eine Alternative zu HTTPS und soll ebenso wie dieses den Austausch von verschlüsselten Daten (z.B. Zahlungsanweisungen per Kreditkartenangaben) über das WWW ermöglichen. Im Unterschied zu HTTPS ist shttp ein eigenes http-Protokoll. Die Protokoll-Schichtstruktur ist also:

Anwendungsschicht s-http http ftp telnet usw.
Transportschicht TCP/IP

Das Grundprinzip von S-HTTP ist es, http-Dokumente in einer sicheren Form einzukapseln. Die Einkapselung hängt nicht von der exakten Syntax des eingekapselten HTTP ab, ist also unabhängig von der HTTP-Version.

Weiterführende Ressourcen:

Yahoo Categories:

13.5.2.10.1.4. HTTTP-ng -- HTTP next generation 

HTTP-ng soll gegenüber HTTP 1.1 wesentlich verschieden sein. Die Arbeiten sind aber noch in einem so frühen Stadium, dass Aussagen darüber, wie HTTP-ng aussehen wird, noch nicht möglich sind.

Weiterführende Ressourcen:

Yahoo Categories:

Organisationen:

13.5.2.10.2. URI: URN, URL, URC

Weiterführende Ressourcen zu URI, URN, URL, URC :

WWW:

Yahoo Categories:

Um gezielt auf Dienste und Ressourcen im Internet zugreifen zu können, wird inzwischen als Lösung das Benutzen eines Uniform Resource Identifiers vorgeschlagen. (So wie das Verwenden von ISBN's).

Ein solcher Uniform Resource Identifier (URI) besteht aus drei Angaben:

An diese Standards werden u.a. folgende Anforderungen gestellt:

13.5.2.10.2.1. Uniform Resource Locator (URL)

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.

Struktur des URL -- Uniform Resource Locator:

Vereinfachte Syntax einer URL:

Zugangsprotokoll://Hostadresse:Port/Pfad
Erklärung

Beispiel:
http://www.well.com/user/payer/

Erklärung:

Folgende verbreitete Webserver Software greift, falls im Pfad kein File angegeben ist, automatisch auf Files mit den betreffenden Namen zu:

Webserver Standardfilenamen
NCSA HTTPD index.html
CERN HTTPD Welcome.html
  welcome.html
  index.html
WinHTTP index.htm
MacHTTP default.html

Übergabe von Suchbegriffen durch die URL:

Suchbegriffe für Such-Server können in der URL übergeben werden, indem man die Suchstrings, durch + verbunden mittels eines Fragezeichens an die eigentliche URL anhängt:

URL?Suchbegriff+Suchbegriff+Suchbegriff...

Tilde (~) in URL-Pfaden:

Nutzer auf manchen UNIX-Servern können allgemein zugängliche HTML-Dokumente in ihren eigenen home directories unterhalten. Die Pfade zu solchen Dokumenten haben eine Tilde (~) vor dem ersten Pfadeintrag. z.B.:

http://machno.hbi-stuttgart.de/~payer/infoq.html

Reservierte Zeichen in URL-Pfaden (Kodierung mit %):

In ULS sind nur US-ASCII-Zeichen zulässig, die nicht für die Kodierung reserviert sind. Verwendet man in Pfadangaben und Filenamen andere Zeichen, müssen sie kodiert werden.

Die folgende Liste gibt die wichtigsten Kodierungen an:

Spatium %20
/ %2F
@ %40
& %26
% %25
\ %5C

Ein Filename "Einnahmen 1998.doc" müsste also kodiert werden als "Einnahmen%201998.doc".

Probleme der URL:

  1. 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.
  2. 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). Diese Problem suchen zu lösen (s. unten):
  3. die Zugangsmethode ändert sich (z.B. gopher oder telnet wird in http umgewandelt).

Zukünftige URLs:

Das Internet wird zunehmend auch für Anwendungen verwendet, für die es ursprünglich nicht vorgesehen war, wie:

Dafür sind die jetzigen URLs nicht besonders geeignet, deshalb wird es wohl demnächst URLs folgender Arten geben:

Weiteres zu zukünftigen Entwicklungen der URLs s.: http://www.w3.org/Addressing/. -- Zugriff am 4.7.1999

Weiterführende Resosurcen zu URL:

Yahoo Categories:

Virtual Libraries:

13.5.2.10.2.2. Uniform Resource Name (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.

RFC 1737 stellt folgende Anforderungen an ein URN-System:

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.

Syntax der URN: eine URN besteht aus drei Teilen, die jeweils durch Doppelpunkt voneinander getrennt sind

urn:[Namespace Identifier -- NID]:[Namespace Specific String -- NSS] 
urn:[Namespace Identifier -- NID]:[Naming Authority]:[Opaque String]
  1. die Angabe URN
  2. die Angabe des Standards bzw. der Normbezeichnung (Namespace Identifier -- NID) z.B. INET, ISBN, ISSN,
  3. der für den jeweiligen Standard spezifischen Identifikation (Namespace Specific String NSS). Die NSS besteht -- durch Doppelpunkt getrennt -- zumeist aus:
    1. die Angabe der verantwortlichen Stelle d.h. der Stelle, die das Recht hat, eine URN zu erstellen (Naming Authority) z.B. dstc.edu.au
    2. der Angabe einer Ziffern- oder Buchstabenfolge, die von der verantwortlichen Stelle speziell für das einzelne Objekt vergeben wird (Opaque String)

Beispiele für URNs aus Testprojekten:

Die Vorgänge bei der Auflösung einer vollen URN zeigt folgendes Schaubild:

Abb.: Auflösung einer URN

Erklärung:

  1. Der Client will eine Ressource mit einer bestimmten URN, aber unbekannter URL. Der Client sendet an einen Resolver Discovery Service (RDS) den Namespace Identifier (NID). Dieser hat gespeichert, welcher URN_Resolver für welche NIDs zuständig ist. 

  2. Der RDS meldet dem Client die Adresse des zuständigen URN-Resolvers.

  3. Der Client sendet an den URN-Resolver den Namespace Specific String (NSS). Der URN-Resolver bestimmt die URL(s) für die zugehörige Ressource

  4. Der URN-Resolver sendet diese URL an den Client

  5. Der Client fordert beim für diese URL zuständigen Server die Ressource an

  6. Der Server sendet an den Client die Ressource

Die Vorgänge 1 und 2 können auch entfallen, wenn der URN-Resolver bekannt ist (z.B. weil seine Adresse im Namespace Specific String genannt wird).

Bevor die URN zum Standard erklärt wird, muss 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, dass man sich eher für nur eine URN entscheiden will, damit der Benutzer nicht viele URN´s aufsuchen muss, nur um dann festzustellen, dass es sich um einen identischen Text handelt.

Weiterführende Ressourcen zu URN:

Yahoo Categories:

Mailing-List:

13.5.2.10.2.2.1. Persistent Uniform Resource Locator (PURL)

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 dass 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.

Syntax einer PURL:

http://[Resolver Adress]/[Name]
z.B.:

http://purl.oclc.org/OCLC/OLUC/32127398 

Gebildet werden diese PURL´s also 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.

Beispiele von PURLs:

oder ohne OCLC: http://purl.somewhere.edu/library/catalog

PURL  kann man in sogenannten Service Requests verwendet werden. Die folgenden Beispiele machen die verschiedenen Möglichkeiten des Zugriffs klar:

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) erfasst, damit die darin enthaltene Information erhalten bleibt. Selbstverständlich muss gleichzeitig die URL in die OCLC-PURL-Resolver-Datenbank geschrieben werden.

Vorgänge bei der Auflösung einer PURL:

Abb.:  Vorgänge bei der Auflösung einer PURL

Man stellt sich von OCLC aus vor, dass 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. Dass zwei identische PURL´s entstehen, wird durch Programm verhindert. OCLC erwartet, dass Ä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, dass 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.

Die zukünftige Umwandlung von PURLs in URNs stellt man sich so vor:

PURL http:// Resolver Adress Name
http:// purl.oclc.org /keith/home
URN URN:/ Naming Authority Name
URN:/ org/oclc/purl /keith/home

PURL Server können auch Handles (s. unten) auflösen. Beispiel:

http://purl.oclc.org/hdl/cnri-1/cnri_home löst die Handle cnri-1/cnri_home auf [Zugriff am 1.7.1999]

Was sind die Vorteile der PURL?

Weiterführende Ressourcen zu PURL:

PURL Server:

13.5.2.10.2.2.2. Handle System

Das Handle System® wurde vom CNRI (Corporation for National Research Inititiatives) entwickelt. Es ist ein System von beständigen Namen, die schnell in Adressen umgewandelt werden können.

An Handle nehmen teil:

Ein Handle Resolver ist als Extension für den Netscape und MS Internet Browser frei erhältlich: URL: http://www.handle.net/resolver/index.html. -- Zugriff am 1.7.1999.

Syntax einer handle:

[Naming Authority]/[Item ID]
z.B.:

10.1000/44

Die Naming Authority wird auch Prefix genannt, die Item ID Suffix.

Beispiele von Handles (können ausprobiert werden, wenn Sie zuvor den Resolver auf Ihrem Computer installieren):

Funktionsweise eines Handle-systems:

Abb.: Handle System Architecture & Operation

[Quelle und © der Abbildung: http://www.handle.net/overviews/hs-version4.html. -- Zugriff am 1.7.1999]

Erklärung:

Auflösung der  Handle

Verwaltung des Handle Systems:

Anwendungen von Handle:

Weiterführende Ressourcen zum Handle System:

13.5.2.10.2.3. Uniform Resource Characteristics (URC)

Bei der URC handelt es sich um eine Beschreibung einer Internet-Ressource, die beliebig tief gehen kann. Man stellt sich vor, dass man mit einer minimalen Beschreibung beginnt und jemand anderes, z.B. ein 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, dass sie in unterschiedlichste Systeme übernommen werden können.

Die URC muss 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:

Jedes dieser Elemente kann verschiedene Ausführlichkeitsgrade haben:

z.B. Element Verfasser:

Was verspricht man sich im wesentlichen von der URC?

Die Vorschläge zur URC werden zur Zeit diskutiert, besonders:

Nachdem vom W3Consortium RDF -- Resource Description Framework [Siehe: http://www.w3.org/RDF/. -- Zugriff am 16.6.1999] entwickelt worden ist, ist mit einer erhöhten Aufmerksamkeit für URC zu rechnen. Auch das Dublin Core (s. unten) soll RDF-konform gemacht werden.

S. auch unten zum META Tag in HTML.

Weiterführende Ressourcen zu URC:

Yahoo Categories:

Mailing-List:

13.5.2.10.2.4. Dublin Metadata Core Element Set

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 bewusst war, dass eine traditionelle Beschreibung auf viele Objekte im Netz nicht anwendbar ist. Außerdem will man erreichen, dass der jeweilige Verfasser selbst diese Daten in standardisierter Form seinen Texten beigibt, so dass 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. Am Anfang der Entwicklung legte man wert darauf, dass der Standard sehr einfach ist, und dass es möglich sein sollte, mit Minimalangaben auszukommen, damit jeder Verfasser eine Beschreibung für seinen Text liefern kann. Die Elemente für die Minimalangaben wurden so ausgewählt, dass 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 bewusst keine genaue Definition gab: im weitesten Sinne handelt es sich um Text. Als Beispiele wurden genannt: elektronische Version eines Zeitschriftenartikels, ein Wörterbuch, aber nicht eine elektronische Version einer Karte.

Offiziell gibt es seit 1996 15 Metadata-Elemente (ursprünglich 13), die aber in den meisten laufenden Anwendungen keineswegs alle genommen werden:

Bei der Anwendung dieser Elemente ist allgemein folgendes zu beachten:

Da man inzwischen erkannt hat, dass man einen Großteil der Elemente sinnvoll nur nutzen kann, wenn sie sich an ein normiertes Schema halten, - also z.B. bei Schlagworten einen verbindlichen Thesaurus, oder bei Namensansetzungen eine Normliste, wurden Dublin Core Qualifiers eingeführt. Außerdem muss man aus Gründen des Datentausches und des verlässlichen Retrievals in weiteren Elementen zusätzliche Angaben machen. Man unterscheidet bei den DC Qualifiers daher zwischen:

Wegen dieser Ausweitung der Regeln dürfte es inzwischen für die meisten Verfasser von Internettexten nicht mehr möglich sein, die verlangten Angaben zu erbringen. Die Projekte, in denen DC eingesetzt werden, bieten daher den Verfassern Erfassungsformulare (sog. Templates) an, die dann von den entsprechenden Institutionen korrigiert werden (das geht bis zum sog. Hochkatalogisieren).

Beispiel des Templates des Bibliotheksservicezentrums Baden-Württemberg, Konstanz (gekürzt):

Quelle: http://www.swbv.uni-konstanz.de/wwwroot/metadata/tp_dc00.html. -- Zugriff am 2.7.1999

 

Dublin Core Metadaten-Generator

DC-Template
Erfassungs-Template für DC-Metadaten

*** Entwicklungsversion ***
Version 1 // Stand: 23.09.1997

Thomas Dierig -- E-Mail: thomas.dierig@bsz-bw.de
Joachim Goeft -- E-Mail: joachim.goeft@bsz-bw.de

(C) Copyright : BSZ - Bibliotheksservice-Zentrum Baden-Württemberg
CaroLine : Constance advanced research open Library network


Erfassung der DC-Daten
Beachte:
Die Erfassungsschablone (Template) ist ausschließlich zur Beschreibung von Web-Seiten gedacht, d.h. von Dokumenten o. ä., die im Web angeboten werden. Das Template deckt andere Dublin Core Anwendungen nicht ab.




1 TITLE (Titel des zu beschreibenden Dokuments in Vorlageform):
Voller Wortlaut des Titels
Zusatz zum Titel

2 CREATOR (Name des Verfassers in der Form Familienname, Vorname):

1. Verfasser Autor oder Körperschaft
2. Verfasser Autor oder Körperschaft
3. Verfasser Autor oder Körperschaft

3 SUBJECT : Schlagwörter (Stichworte zum Thema des Dokuments, mehrere getrennt durch ","):

Deutsches Vokabular nach SWD

abweichende, weitere Stichwort-Systeme

verwendetes Stichwort-System
Das Symbol =:= besagt, dass durch durch "Doppelklick" das Stichwortverzeichnis aufgeruefen werden kann.

3 SUBJECT : Klassifikation (Notationen zum Thema des Dokuments, mehrere getrennt durch ","):

Klassifikations-System
Das Symbol =:= besagt, dass durch durch "Doppelklick" das Verzeichnis der Klassifikation aufgerufen werden kann.

4 DESCRIPTION (Abstrakt, Beschreibung des Inhalts):

5 PUBLISHER (Verleger, Herausgeber, Universität etc.):

6 CONTRIBUTORS (Name einer weiteren beteiligten Person in der Form Familienname, Vorname):

Autor oder Körperschaft
Autor oder Körperschaft
Autor oder Körperschaft

7 DATE (current date = Datum)

Der Eintrag des Datums wird automatisch aus dem Maschinendatum erzeugt.

8 TYPE (Art des Dokuments):

9 FORMAT (Datentechnisches Format des Dokuments, MIME type):

MIME Type

10 IDENTIFIER (ISBN, ISSN, URL o.ä. des vorliegenden Dokuments betr. eindeutiger Identifikation):

URL URN
ISBN ISSN

11 SOURCE : (SWB-ID-Nr der Titelaufnahme des vorliegenden Dokuments in der SWB-Verbunddatenbank):

SWB-ID-Nr (8-stellig)

11 SOURCE (Werk, gedruckt oder elektronisch, aus dem das vorliegende Dokument stammt):

Verbale Form des Werks
ISBN oder ISSN

12 LANGUAGE (Sprache des Inhalts des Dokuments)

deutsch englisch französisch spanisch italienisch
Liste mit anderen Sprachen



Um den Wildwuchs in den entstehenden Regeln und die Auseinandersetzungen zwischen Gruppen mit unterschiedlichen Einstellungen in den Griff zu bekommen, gibt es seit 1998 offizielle Gremien [siehe: http://purl.org/DC/about/index.htm. -- Zugriff am 2.7.1999]

 Auch die Internet Engineering Task Force (IETF) setzt sich inzwischen für DC ein: RFC 2413 (Dublin Core Metadata for Resource Discovery) [URL: http://www.cis.ohio-state.edu/htbin/rfc/rfc2413.html. -- Zugriff am 2.7.1999] ist bekannt als DC 1.0. Diese RFC liegt zur Zeit der NISO (National Information Standards Organization) und der CEN (Center for European Normalization) vor. Bedingung für eine Anerkennung als offizielle Norm ist aber eine eindeutige Definition, die bei den Elementen von DC bisher nicht zu erkennen ist. So versucht man, die Bedeutung der Elemente mit der ISO-Norm 11179 (Specification and Standardization of Data Elements)  in Übereinstimmung zu bringen.

Ein Beispiel aus dem SWB:

Element Markierung im HTML-HEAD
DC.DATE.CURRENT <META NAME="DC.DATE.CURRENT"      CONTENT="(SCHEME=ANSI.X3.30-1985) 19970715">
DC.TITLE <META NAME="DC.TITLE"             CONTENT="Kreieren eines Dublin Core Metadaten-Eintrags">
DC.CREATOR.NAME <META NAME="DC.CREATOR.NAME"      CONTENT="Dierig, Thomas">
DC.SUBJECT <META NAME="DC.SUBJECT"           CONTENT="Dublin Core, Metadaten">
DC.DESCRIPTION <META NAME="DC.DESCRIPTION"       CONTENT="Konventionen zur Anwendung von Dublin Core Metadaten 
               innerhalb Caroline. Innerhalb Caroline ist dies ein Teilbereich, in dem Werkzeuge 
               zur Erfassung von Metadaten bereitgestellt werden.">
DC.PUBLISHER <META NAME="DC.PUBLISHER"         CONTENT="BSZ - Bibliotheksservice-Zentrum Baden-Württemberg">
DC.CONTRIBUTORS.NAME <META NAME="DC.CONTRIBUTORS.NAME" CONTENT="Wolf, Stephan">
DC.TYPE <META NAME="DC.TYPE"              CONTENT="Service">
DC.FORMAT <META NAME="DC.FORMAT"            CONTENT="(SCHEME=imt) text/html">
DC.IDENTIFIER <META NAME="DC.IDENTIFIER"         CONTENT="(SCHEME=URL)
http://www.swbv.uni-konstanz.de/wwwroot/metadata/an_dc01.html">
DC.SOURCE <META NAME="DC.SOURCE"            CONTENT="SWB-IDNR/00471187">
DC.LANGUAGE <META NAME="DC.LANGUAGE"          CONTENT="(SCHEME=NISOZ39.53) GER">
DC.COVERAGE <META NAME="DC.COVERAGE"          CONTENT="Germany">
DC.RIGHTS <META NAME="DC.RIGHTS"            CONTENT="Public domain">

[Quelle: http://www.swbv.uni-konstanz.de/wwwroot/metadata/an_dc01.html -- Zugriff am 2.7.1999

Weiterführende Ressourcen zu Dublin Metacore:

Organisationen:

Darstellung des Stands April 1999:

Zum nächsten Kapitel: WWW2: HTML und CSS  (Computervermittelte Kommunikation)