Schicht 7 -- Application Layer, Teil 2

 

Die Anwendungsschicht im Internet: WWW -- World Wide Web

- HTTP und URI -

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.

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:

• URL = wie man eine Ressource lokalisiert
• HTTP = wie man eine Hypertext-Ressource erhält
• HTML = wie man eine Hypertext-Ressource darstellt

Weiterführende Ressourcen zu WWW-Browsern:

Virtual Libraries:

• Browsers. -- URL: http://www.stars.com/Vlib/Software/Browsers.html

Weiterführende Ressourcen zum WWW allgemein:

Virtual Libraries:

• The Virtual Library of WWW Development. -- URL: http://www.stars.com/Vlib/ ["A comprehensive illustrated encyclopedia of web technology, The Web Developer's Virtual Library is a well-organised goldmine of tutorials, examples, and links to great resources. It's for webmasters and Internet developers who are creating web sites with HTML, CGI, Java, JavaScript, graphics, VRML, multimedia, animation, etc."]

WWW:

• WWW-Pages des World Wide Web Consortium [W3C]. -- URL: http://www.w3.org/pub/WWW/

HTTP -- HyperText Transfer Protocol

(HTTP: siehe auch Netzwerk Protokolle - HTTP)

• HTTP 1.0: RFC 1945
• HTTP 1.1: RFC 2068
• TCP Port 80

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
• response von Server an Client

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:

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:

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:

Beispiel:

HTTP/1.0 200 OK [bei erfolgreichem Request]

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

Wichtige Status-codes sind:

• 200 = OK
• 301 = Moved permanently
• 302 = Moved temporarily
• 400 = Bad Request (= Syntaxfehler)
• 401 = Unauthorized
• 403 = Forbidden
• 404 = Not Found
• 500 = Internal Server Error
• 503 = Service Unavailable [= Server ist überlastet oder momentan außer Betrieb]

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

Virtual Libraries:

• HTTP. -- URL: http://www.stars.com/Internet/Protocols/HTTP/

Cookies

• RFC 2109

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: der Client fordert per http eine Resource an der Server leitet die Anforderung per CGI an eine Anwendung weiter die Anwendung übergibt an http die Antwort + ein Cookie, das den Client identifiziert per http wird die Antwort + Cookie (mit Set-Cookie im http-Header) an Client gesandt und beim Client das Cookie auf das System geschrieben der Client sendet bei dem nächsten Teil der Interaktion das Cookie an den Server per Cookie im http-Header der Server übergibt das Cookie an die Anwendung die Anwendung antwortet der Server sendet die Antwort per http an den Client der Client sendet beim nächsten Teil der Interaktion das Cookie wieder an den Server 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:

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:

• Online-Kommerz: der Nutzer muss nicht jedes Mal seine Daten neu eingeben, sondern wird aufgrund des Cookie identifiziert, auch sind dadurch Warenkörbe und Ähnliches realisierbar
• Personalisierung: die aufgerufene Web-Site "kennt" die Bedürfnisse des Nutzers, wann er das letzte Mal da war (dann wird ihm nur das seit damals Neue angezeigt) u.ä. 
• Website-Tracking: das Verhalten des Nutzers wird ausgewertet (!!)
• gezielte Reklame

HTTPS -- HTTP over Secure Socket Layer (SSL)

• RFC 2246

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:

• Vertraulichkeit (privacy): symetrische Kryptographie
• Authentikation mittels Public-Key-Verfahren
• Integrität der übertragenen Daten wird mit MAC (Message Authentication Code) geprüft

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:

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.

Organisationen:

• IETF HTTP-ng Working Group. --  http://www.w3.org/Protocols/HTTP-NG/

URI: URN, URL, URC

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:

• Uniform Resource Name (URN): identifiziert die Ressource / Quelle eindeutig.
• Uniform Resource Locator (URL): identifizert den Standort einer Ressource / Quelle eindeutig (vergleichbar mit einer Signatur)
• Uniform Resource Characteristics (URC): gibt Informationen über die Ressource / Quelle an wie Zugangsbeschränkungen, Verfallsdatum. Erst im Draft-Stadium

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

• der Zeichensatz muss allgemein gültig sein (US-ASCII)
• der Transport muss über die gängigen Internet-Protokolle möglich sein (also TCP, FTP, Telnet usw.)
• die maschinelle Verarbeitbarkeit muss gewährleistet sein, d.h. ein Programm muss die Angaben interpretieren und verarbeiten können
• die Daten müssen vom Menschen gelesen und eingetippt werden können
• die Daten müssen problemlos druckbar sein
• die Standards müssen erweiterbar sein.
• bestehende Standards sollen möglichst integrierbar sein (z.B. ISBN in URN)

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:

Erklärung

• Zugangsprotokoll:
  • http
  • https
  • ftp
  • telnet
  • wais
  • gopher

  Struktur: gopher://Hostadresse/Gopher_type_codeSelector_string
  Gopher Type code = Gopher Resource Identifier Code (obsolete)
  Selector_string entspricht dem Pfad

  • file (für Files auf dem local host)
  • mailto

  Struktur: mailto:Mailadresse

  • news (für USENET auf dem News-Server des Client)

  Struktur: news:Name der USENET-Gruppe

  • nntp (für USENET auf einem bestimmten News-Server)

  Struktur: nntp://Serveradresse/Name der USENET-Gruppe
  (Da News Server sehr oft eine Zugangslegitimation verlangen, sollte man, wenn immer möglich das Linking mit news: verwenden.)

  • lsdp (gemäß Lightweight Directory Access Protocol -- LDAP: für Anfrage an Directory Server)
• Hostadresse: IP-Adresse oder Domain-Name
• Port: nicht nötig, wenn Standardport verwendet wird
• Pfad: voller Pfad inkl. evtl. Filename

Erklärung:

• http: Zugangsprotokoll: Hypertext-Transport-Protokoll
• www.well.com: Hostadresse: WWW auf der WELL in San Francisco, Californien, USA
• keine Portnummer: (in diesem Fall der Standardport 80 für http)
• user/payer/: der Pfad (in diesem Fall wird WELL-intern automatisch das File index.html, die home page von user "payer", aufgerufen: "Tuepfli's Global Village Library")

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):
   • URN
   • PURL
   • Handle System
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:

• Telephon
• Fax
• WebTV
• Video Game Consoles

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

• phone://[Telefonnummer] z.B.:phone://0707112345
• fax://[Faxnummer]
• tv://[TV-Kanal] z.B.: tv://12
• u.ä.

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

Weiterführende Resosurcen zu URL:

Virtual Libraries:

• URL: http://www.wdvl.com/Internet/Protocols/URL.html

Uniform Resource Name (URN)

• RFC 1737: Functional Requirements for Uniform Resource Names.
• RFC 2141: URN Syntax

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:

• eine URN soll standortunabhängig sein (global scope)
• eine URN muss weltweit einmalig sein (global uniqueness)
• eine URN muss beständig sein: sie muss so lange gültig sein, wie sie nicht explizit gelöscht wird (persistence)
• eine URN muss so gestaltet sein, dass sie nicht geändert werden muss, wenn die Anzahl der Ressourcen im Netz beträchtlich wächst (scalability)
• jedes URN-Schema muss so gestaltet sein, dass es leicht erweiterbar ist (ohne bestehende URNs zu tangieren) (extensibility)
• in URNs müssen bestehende Ressourcenidentifikationssysteme (z.B. ISBN) integrierbar sein (legacy support)
• die URNs vergebenden Autoritäten sollen voneinander unabhängig sein: jede URN-vergebende Autorität bestimmt selbst, wem und wie sie URNs vergibt (independence)
• URNs müssen so gestaltet sein, dass ihnen aufgrund einer einheitlichen Vorgehensweise Adressen (URLs) zugeordnet werden können (resolution)

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

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:

• DSTC URN Resolver: [Näheres darüber: http://www.dstc.edu.au/RDU/TURNIP/burns.html]
  • urn:inet:dstc.edu.au:dstc/tr017
  • urn:inet:dstc.edu.au:rdu/tr009
  • urn:inet:dstc.edu.au:renato:home
• CEO URN Resolver: [Näheres darüber: http://me-www.jrc.it/~dirkx/ewse-urn-turnip.html]
  • urn:inet:ceo.org:user.7301
  • urn:inet:ceo.org:user.7301.full

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

Abb.: Auflösung einer URN

Erklärung: 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.  Der RDS meldet dem Client die Adresse des zuständigen URN-Resolvers. 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 Der URN-Resolver sendet diese URL an den Client Der Client fordert beim für diese URL zuständigen Server die Ressource an 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:

Mailing-List:

• URN hypermail archive : http://smash.gatech.edu/archives/urn/. -- [Archiv der URN mailing list]

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:

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:

• http://purl.oclc.org/keith/home.
• http://purl.oclc.org/OCLC/PURL/summary
• http://purl.oclc.org/keith/test1.
  

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:

• http://purl.oclc.org/SERVICE/DISPLAY/keith/home
• http://purl.oclc.org/SERVICE/DISPLAY/http://purl.oclc.org/keith/home.
• http://purl.oclc.org/net/service/display/InterCat. Besonders dieses Beispiel einer oft veränderten Ressource ist sehr aufschlussreich:

  PURL Information Display Resolver Address: purl.oclc.org:80 (currently ignored) Local Name: /NET/INTERCAT PURL http://purl.oclc.org/NET/INTERCAT URL http://orc.rsch.oclc.org:6990 Maintainers EJUL Creation Date Fri Jan 5 14:45:30 1996 Last Modified Tue Feb 17 11:23:15 1998 Change Category User_Edited History Modified by EJUL Modified Tue Feb 17 11:21:58 1998 Change Category User_Edited URL http://www.oclc.org usw. usw.

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 auflösen. Beispiel:

http://purl.oclc.org/hdl/cnri-1/cnri_home löst die Handle cnri-1/cnri_home auf

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.

PURL Server:

• http://purl.oclc.org.
• http://purl.access.gpo.gov.
• http://purl.dk.
• http://purl.nla.gov.au
• http://purl.sdln.net.

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:

• the Networked Computer Science Technical Reference Library (NCSTRL) . -- URL: http://www.ncstrl.org.
• the Library of Congress. -- URL: http://www.cnri.reston.va.us/NDLP.html.
• the Defense Technical Information Center (DTIC) . -- URL: http://www.cnri.reston.va.us/dtic.html
• the United States Information Agency (USIA) . -- URL: http://www.cnri.reston.va.us/USIA.html
• the National Library of Medicine 
• the National Music Publishers Association
• the International DOI Foundation's Digital Object Identifier (DOI) project. -- URL: http://www.doi.org/

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.

Syntax einer handle:

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):

• hdl:4263537/4006.

• hdl:10.1000/31.

• hdl:cnri.dlib/february97-arms.

Funktionsweise eines Handle-systems:

Abb.: Handle System Architecture & Operation

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

Erklärung:

Auflösung der  Handle

• 1. Ein Client stoßt auf eine Handle (als Hyperlink), z.B. 10.123/456. Er sendet dies zu einem Handle System zur Auflösung

• 2. Das Handle System besteht aus einer Anzahl von Handle Services. Jeder Service ist logisch und physisch auf eine Anzahl von Servern verteilt und kann gespiegelt werden. Eine einzige Global Handle Registry verwaltet die Adressen der für die einzelnen Naming Authorities zuständigen Local Handle Services

• 3. & 4. Jede Handle ist im entsprechenden Handle Service mit (mindestens) einer Adresse (URL) und einem Protokoll Namens RAP verknüpft. URL und RAP werden dem Client übermittelt, der damit auf die Ressource zugreifen kann

Verwaltung des Handle Systems:

• 5. Administrative Clients können Handles und die Verknüpfung mit URLs und RAP erzeugen

• 6. Das Handle System meldet dem Administrative Client, ob seine Hinzufügung einer Handle erfolgreich war oder nicht (weil z.B. fehlerhaft). Batch mode für Hinzufügungen und zum Editieren ist vorgesehen

Anwendungen von Handle:

• Digital Object Identifiers (DOI) System der Association of American Publishers und anderer Verleger: http://www.doi.org/ .
• National Digital Library Program (NDLP) der Library of Congress: http://lcweb2.loc.gov/ammem/award/docs/handle-server.html . Die Library of Congress veranstaltet auch einen Wettbewerb für den Gebrauch von Persistent Identifiers: LC/Ameritech National Digital Library Competition. -- URL: http://lcweb2.loc.gov/ammem/award/ .
• Networked Computer Science Technical Reports Library (NCSTRL), unter Führung der Cornell University: entwickelt open architecture using handles: http://www.ncstrl.org/Dienst/htdocs/Info/ncstrl.html . 
• National Music Publishers' Association (NMPA): entwickelt ein System zur Vereinfachung der Registrierung und Lizensierung von Musikwerken mit Copyright: Musical Digital Object Identifiers  (MDOI) unter Verwendung von CORDS (Copyright Office Electronic Registration, Recordation and Deposit System) Systems (URL: http://cords.loc.gov)

Weiterführende Ressourcen zum Handle System:

• http://www.handle.net/.  [Dort auch Beispiele von Handles, die ausprobiert werden können, wenn man den Resolver installiert hat]

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:

• 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: Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann.
  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 muss
• 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
• dass der Benutzer sicher sein kann, den richtigen Text zu erhalten (deshalb soll die Signatur angegeben werden).

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

• die Anwendung der XML (Extensible Markup Language)
• das Verhältnis zu MARC, AACR2 und ähnlichem

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:

Mailing-List:

• Mailing list zu URC: Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann. '; document.write( '' ); document.write( addy_text54056 ); document.write( '<\/a>' ); //--> Diese E-Mail-Adresse ist gegen Spambots geschützt! JavaScript muss aktiviert werden, damit sie angezeigt werden kann. ; Text: subscribe urc-l [Vorname] [Nachname]
• HyperMail Archive zur URC mailing list: http://smash.gatech.edu/archives/urc/.

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:

• 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, dass 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
• Description = Inhaltliche Beschreibung
• Rights Management = Rechtliche Bedingungen

Bei der Anwendung dieser Elemente ist allgemein folgendes zu beachten:

• es geht darum, den intellektuellen Inhalt des Werkes zu beschreiben, nicht so sehr die physische Form
• kein Element muss 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, dass sie in anerkannten Standards wie MARC verwendet werden können
• die Beschreibung (durch die Autoren) sollte zumindest soweit nutzbar sein, dass sie als Grundlage für qualifizierte Katalogisierung benutzt werden kann.

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:

• Common qualifiers (gelten für alle Element): dazu gehört die Angabe der Sprache des Elements und die Angabe des Zeichensatzes des Elements
  z.B.:
  <META name="DC.creator" lang="fr" content="Arnaud Le Hors">
• auf die Einzelelemente bezogene Qualifiers:
  • Scheme = die Norm, nach der angesetzt worden ist. Z.B. LCSH
    z.B.
    <META name="DC.subject" scheme="DDC" content="541.34">
  • Type = die Art des Elements. Z. B. beim Titel: Kurztitel, Alternativtitel ...

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.

Dublin Core Metadaten-Generator DC-Template Erfassungs-Template für DC-Metadaten *** Entwicklungsversion *** Version 1 // Stand: 23.09.1997

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

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

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

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

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):

7 DATE (current date = Datum)

8 TYPE (Art des Dokuments):

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

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

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

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

12 LANGUAGE (Sprache des Inhalts des Dokuments)

1 TITLE (Titel des zu beschreibenden Dokuments in Vorlageform):

  Voller Wortlaut des Titels

  Zusatz zum Titel

 

  1. Verfasser Autor oder Körperschaft

  2. Verfasser Autor oder Körperschaft

  3. Verfasser Autor oder Körperschaft

 

  Deutsches Vokabular nach SWD

abweichende, weitere Stichwort-Systeme

 

AAT =:= Art and Architecture ThesaurusLCSH = Library of Congress Subject HeadingMeSH = Medical Subject Headings verwendetes Stichwort-System

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

 

 

DDC =:= Dewey Decimal ClassificationLCC =:= Library of Congress Class.NLM = National Library of Medicine Class.UDC = Universal Decimal ClassificationKlassifikations-System

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

 

 

 

 

 

  Autor oder Körperschaft

  Autor oder Körperschaft

  Autor oder Körperschaft

 

Der Eintrag des Datums wird automatisch aus dem Maschinendatum erzeugt.

 

 ArtikelBild (Image)BuchDiplomarbeitDissertationGedichtJournalKollektionMagazinManualMusikPreprintServiceTechn. ReportunveröffentlichtVideoVorabdruck (Preprint)BookletInBookInCollectionResearchPaperProceedingsInProceedingsHonoursThesisAdvertismentDatasetOrganisationInfoPersonalInfoMessageOnModeratedMailingListMessageOnUnmoderatedMailingListPostingToModeratedNewsgroupPostingToUnmoderatedNewsgroupMisc

 

 text/htmlMIME Type

 

  URL URN

  ISBN ISSN

 

  SWB-ID-Nr (8-stellig)

 

  Verbale Form des Werks

  ISBN oder ISSN

 

  deutsch englisch französisch spanisch italienisch

 dänischdeutschdeutsch, Middle High (ca. 1050-1500)deutsch, Old High (ca. 750-1050)deutsch (Other)englischenglisch, Middle (1100-1500)englisch, Old (ca. 450-1100)finnischfranzösischfranzösisch, Middle (ca. 1400-1600)französisch, Old (ca. 842-1400)griechisch, Ancient (to 1453)griechisch, Modern (1453- )holländischholländisch, Middle (ca. 1050-1350)irischisländischitalienischlateinischnorwegischportugisischpolnischrussischschwedischslovakischslovenischspanischtschechischAchineseAcoliAdangmeAfrihili (Artificial language)AfrikaansAfro-Asiatic (Other)AkkadianAlbanianAleutAlgonquian languagesAljamiaAltaic (Other)AmharicApache languagesArabicAramaicArapahoAraucanianArawakArmenianArtificial (Other)AssameseAthapascan languagesAustronesian (Other)AvaricAvestanAwadhiAymaraAzerbaijaniAztecBalineseBaltic (Other)BaluchiBambaraBamileke languagesBandaBasaBashkirBasqueBejaBembaBengaliBerber languagesBhojpuriBikolBiniBrajBretonBugineseBulgarianBurmeseByelorussianCaddoCaribCatalanCaucasian (Other)CebuanoCeltic languagesCentral American Indian (Other)ChagataiChamorroChechenCherokeeCheyenneChibchaChineseChinook jargonChoctawChurch SlavicChuvashCopticCornishCreeCreekCreoles and Pidgins (Other)Creoles and Pidgins, English-based (Other)Creoles and Pidgins, French-based (Other)Creoles and Pidgins, Portuguese-based (Other)Cushitic (Other)CzechDakotaDanishDelawareDinkaDogriDravidian (Other)DualaDutchDutch, Middle (ca. 1050-1350)DyulaEfikEgyptianEkajukElamiteEnglishEnglish, Middle (1100-1500)English, Old (ca. 450-1100)EskimoEsperantoEstonianEthiopicEweEwondoFangFantiFaroeseFijianFinnishFinno-Ugrian (Other)FonFrenchFrench, Middle (ca. 1400-1600)French, Old (ca. 842-1400)FriesianFulaGþGaelic (Scots)GalleganGandaGayoGeorgianGermanGerman, Middle High (ca. 1050-1500)German, Old High (ca. 750-1050)Germanic (Other)GilberteseGondiGothicGreboGreek, Ancient (to 1453)Greek, Modern (1453- )GuaraniGujaratiHaidaHausaHawaiianHebrewHereroHiligaynonHimachaliHindiHiri MotuHungarianHupaIbanIcelandicIgboIjoIlokoIndic (Other)Indo-European (Other)IndonesianInterlingua (International Auxiliary Language Association)Iranian (Other)IrishIroquoian languagesItalianJapaneseJavaneseJudeo-ArabicJudeo-PersianKabyleKachinKambaKannadaKanuriKara-KalpakKarenKashmiriKawiKazakhKhasiKhmerKhoisan (Other)KhotaneseKikuyuKinyarwandaKirghizKongoKonkaniKoreanKpelleKruKuanyamaKurdishKurukhKusaieKutenaiLadinoLahndLambaLangue d'oc (post-1500)LaoLappLatinLatvianLingalaLithuanianLoziLuba-KatangaLuisenoLundaLuo (Kenya and Tanzania)MacedonianMadureseMagahiMaithiliMakasarMalagasyMalayMalayalamMalteseMandingoManipuriManobo languagesManxMaoriMarathiMarshallMarwariMasaiMayan languagesMendeMicmacMinangkabauMiscellaneous (Other)MohawkMoldavianMon-Khmer (Other)MongoMongolianMossiMultiple languagesMunda (Other)NavajoNdebele (Zimbabwe)NdongaNepaliNewariNiger-Kordofanian (Other)NiueanNorth American Indian (Other)Northern SothoNorwegianNubian languagesNyamweziNyanjaNyankoleNyoroNzimaOjibwaOld Persian (ca. 600-400 B.C.)OriyaOromoOsageOsseticOtomian languagesPahlaviPalauanPaliPampangaPangasinanPanjabiPapiamentoPapuan-Australian (Other)PersianPolishPonapePortuguesePrakrit languagesProvencal, Old (to 1500)PushtoQuechuaRaeto-RomanceRajasthaniRarotonganRomance (Other)RomanianRomanyRundiRussianSalishan languagesSamaritan AramaicSamoanSandaweSangoSanskritScotsSelkupSemitic (Other)Serbo-Croatian (Cyrillic)Serbo-Croatian (Roman)SererShanShonaSidamoSiksikaSindhiSinhaleseSino-Tibetan (Other)Siouan languagesSlavic (Other)SlovakSlovenianSomaliSonghaiSorbian languagesSothoSouth American Indian (Other)SpanishSukumaSumerianSundaneseSusuSwahiliSwaziSyriacTagalogTahitianTajikTamilTatarTeluguTerenoThaiTibetanTigreTigrinyaTimneTiviTlingitTonga (Nyasa)Tonga (Tonga Islands)TrukTsimshianTsongaTswanaTumbukaTurkishTurkish, OttomanTurkmenTwiUgariticUighurUkrainianUmbunduUndeterminedUrduUzbekVaiVendaVietnameseVoticWakashan languagesWalamoWarayWashoWelshWolofXhosaYaoYapYiddishYorubaZapotecZenagaZuluZuni 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]

• Dublin Core Directorate, betreut vom OCLC Office of Research in Dublin,Ohio, mit der offiziellen Dublin Core Homepage: http://purl.org/DC/.
• Technical Advisory Committee, zustaendig z.B. für die Einbindung von DC in HTML (zur Zeit als Internet Draft)
• Policy Advisory Committee

 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] 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) ">
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]

Weiterführende Ressourcen zu Dublin Metacore:

Organisationen:

• Dublin Core Metadata  Initiative. -- URL:http://purl.org/DC/. [Zugangspunkt zu allen relevanten Informationen, Beispielen, Tools usw.]

Darstellung des Stands April 1999:

• Weibel, Stuart: The State of the Dublin Core Metadata Initiative April 1999. -- In: D-Lib Magazine. -- 
  Volume 5, Number 4 (April 1999). -- ISSN 1082-9873. -- URL: http://www.dlib.org/dlib/april99/04weibel.html.