Technische Angaben zum ICRA-Kennzeichnungssystem

Die ICRA gibt es, um Benutzer dabei zu unterstützen, gewünschte Inhalte zu finden, denen sie vertrauen können und Inhalte zu vermeiden, die sie als ungeeignet für sich selbst oder für ihre Kinder erachten. Es wird ein Vokabular bereitgestellt, das verwendet werden kann, um jegliche digitale Inhalte auf eine Weise zu beschreiben, die eine umfassende Bandbreite der Bedenken von Eltern weltweit widerspiegelt.2. Das System dahinter jedoch ist in der Lage, Metadaten für beliebige Zwecke zu übermitteln.

Die Beschreibungen sind rechnerlesbar und können daher für eine Vielzahl von Vermittlungsdiensten wie Filtern, Suchmaschinen und Hilfsanwendungen verwendet werden, die Zusatzinformationen für Benutzer anzeigen.

ICRA-Kennzeichnungen sind in RDF3 codiert, einer der Kerntechnologien hinter dem Semantischen Web4. Dieses Dokument weist nicht spezifisch auf die zahlreichen Vorteile hin, die sich für Inhaltsanbieter durch das semantische Web ergeben, es wird lediglich darauf hingewiesen, dass Merkmale wie RSS, Shared Bookmarks, Blogs und Wikis zu den dazu beisteuernden Elementen gehören.

Hinweis: Die ICRA bietet zusammen mit dem Verknüpfungs-Tag auch eine vereinfachte PICS-Version der Kennzeichnung, um ältere Systeme, insbesondere den Inhaltsberaters des Internet Explorer zu unterstützen. Dieses Thema wird in einem eigenen Dokument behandelt.

Der Namensraum des RDF-Schema, der den Rahmen für ICRA-Kennzeichnungen bietet, ist http://www.w3.org/2004/12/q/contentlabel#, und der empfohlene QName lautet label. Die entsprechende Dokumentation befindet sich unter http://www.w3.org/2004/12/q/doc/content-labels-schema.htm.

Der Namensraum für das ICRA-Vokabular ist http://www.icra.org/rdfs/vocabularyv03#, und der emfpohlene QName lautet icra. Die einfache Textversion des ICRA-Vokabulars und dessen ergänzender Definitionen befindet sich unter http://www.icra.org/vocabulary.

Eine Inhaltskennzeichnung ist eine Beschreibung, d. h. ein Satz von Metadaten, der für verschiedene Ressourcen verwendet werden kann. Eine oder mehrere Kennzeichnungen werden in einer Datei hinterlegt, und Ressourcen werden damit entweder über einen (X)HTML-Verknüpfungs-Ttag oder einen HTTP- Response-Header verknüpft.

Die Datei, in der die Kennzeichnungen enthalten sind, ist eine RDF-Instanz und heißt in der Regel labels.rdf. Dies ist der Dateiname, der im Zuge der ICRA-Kennzeichungserstellung vergeben wird (siehe Abschnitt 2.3), an sich jedoch keine spezielle Bedeutung hat und in einen beliebigen Namen geändert werden kann.

Ressourcen könnten mit einer bestimmten Kennzeichnung oder mit einem Datensatz verknüpft werden, der es Clients ermöglicht, den URI der Ressource mit einer Reihe von Regeln abzugleichen, anhand der die korrekte Kennzeichnung ermittelt werden kann.

Inhaltsanbieter können somit wählen, ob die Zuordnung einer Ressource zu ihrer Kennzeichnung Client-seitig oder Server-seitig erfolgen soll.

Abbildung 1 Server-seitige Zuordnung von Inhalten zu Kennzeichnungen

Abbildung 1 zeigt jede Ressource mit einer bestimmten Kennzeichnung verknüpft. Wenn die RDF-Instanz labels.rdf benannt ist, sich im Stammverzeichnis der Website befindet und eine Ressource mit einer Kennzeichnung namens “label_1” verknüpft werden soll, sieht der Verknüpfungs-Tag wie in Beispiel 1 dargestellt aus:

Beispiel 1 Ein typischer Verknüpfungs-Link, der eine bestimmte Kennzeichnung einer Ressource zuordnet

Der entsprechende HTTP-Response-Header sieht wie folgt aus:

Link: ; /=”/”; rel=”meta” type=”application/rdf+xml”; title=”ICRA labels”;

Beispiel 2 Der dem Beispiel 1 entsprechende HTTP-Response-Header

Bitte beachten Sie, dass die spezielle Kennzeicnung innerhalb der RDF-Instanz durch das URL-Fragment im Attribut href identifiziert wird. Das Attribut title ist optional, wird jedoch aus Gründen der Übersichtlichkeit empfohlen. Der Speicherort der Datei labels.rdf ist unerheblich. Es kann sich um einen beliebigen Speicherpfad auf einem beliebigen Server handen, allerdings muss der Pfad natürlich im Attribut href angegeben werden.

Abbildung 2 zeigt einen Alternativansatz. Alle Ressourcen werden mit der RDF-Instanz verknüpft, aber die Verknüpfung gibt nicht die Kennzeichnung an. Stattdessen definiert die RDF-Instanz eine Standardkennzeichnung und kann ferner eine Abfolge von Regeln definieren, die auf regulären Perl 5-Ausdrücken beruhen und den Standard außer Kraft setzen können. Die erste zu erfüllende Regel der Abfolge gibt die richtige Kennzeichnung an.

Abbildung 2 Client-seitige Zuordnung von Inhalten zu Kennzeichnungen

Wenn die RDF-Instanz labels.rdf benannt ist und sich im Stammverzeichnis der Website befindet, sieht der Verknüpfungs-Tag wie in Beispiel 3 aus:

Beispiel 3 Typischer Tag für die Verknüpfung einer Ressource mit einer RDF-Instanz, die Regeln für die Identifikation der richtigen Kennzeichnung enthält.

Der entsprechende HTTP-Response-Header sieht wie folgt aus:

Link: ; /=”/”; rel=”meta” type=”application/rdf+xml”; title=”ICRA labels”;

Beispiel 4 Der dem Beispiel 3 entsprechende HTTP-Response-Header.

Wie bei Beispiel 1 sind der Speicherort und der Name der RDF-Instanz unerheblich.

Die ICRA bietet auf ihrer Website ein Tool zum Erstellen der RDF-Instanz und der notwendigen Tags, das als Kennzeichnungserzeugung5 bezeichnet wird. Es eignet sich gleichermaßen für Personen mit geringen oder keinen Kenntnissen über die Erstellung von Webinhalten wie für fortgeschrittene Benutzer. Die Kennzeichnungserzeugung erstellt die RDF-Instanz basierend auf dem oben beschriebenen Client-seitigen Verarbeitungsmodell (Abschnitt 2.2), wenngleich sie ebenso für das Server-seitige Modell verwendet werden kann.

Die RDF-Instanz muss eine oder mehrere Kennzeichnungen definieren. Insbesondere muss sie zumindest eine Instanz der RDF-Klasse “Content Label” nach Definition von http://www.w3.org/2004/12/q/contentlabel#ContentLabel definieren.

Hinweis: RDF-Inhaltskennzeichnungen können Anweisungen von einem beliebigen RDF-Schema enthalten; dieses Dokument allerdings befasst sich nur mit der Implementierung der ICRA.

Die RDF-Instanz kann ferner null oder mehr der folgenden Elemente definieren:

  1. Den/die Host(s), für den/die die Kennzeichnung(en) gilt/gelten. Darunter fallen auch Subdomänen.
  2. Eine zusätzliche Zeichenkette, die dem URI der Ressource für Kennzeichnungen in der anzuwendenden RDF-Instanz entspricht.
  3. Die Standardkennzeichnung.
  4. Eine geordnete Regelabfolge, die dem URI einer Ressource entsprechen sollte. Wird eine Regel erfüllt, muss eine Kennzeichnung vorgesehen sein, die den Standard außer Kraft setzt.
  5. Eine Beschreibung der RDF-Instanz selbst, aus der hervorgeht, wo zusätzlich Informationen über die Kennzeichnung zu finden sind und wie ihre Gültigkeit beurteilt werden kann.

Diese Elemente werden im Detail unter Bezugnahme auf Beispiel 5 erklärt. Wie alle Beispiele in diesem Dokument und anderen von der ICRA erstellten Dokumenten wird RDF in XML serialisiert. Dies ist jedoch keine Voraussetzung – andere Serialisierungen wie N36 sind gleichermaßen gültig.

 1 

 2 
  

    

    http://www.icra.org/rdfs/vocabularyv03#

    

  
 3 
  

    

      

        example.org

        example.com

      

    

    

 4 
    

      

        photography

        

      

  

     

       guestbook

        messages

        

      

    

  
 5 
  

    Label for all/most of website

    No nudity, no sexual content, no violence, no

     potentially offensive language, no potentially harmful

     activities, no user-generated content

    1

    1

    1

    1

    1

    1

  



  

    Label for photography section

    Exposed breasts, Bare buttocks, No sexual

    content, no violence, no potentially offensive language,

    no potentially harmful activities, no user-generated

    content, This material appears in an artistic

    context

    1

    1

    1

    1

    1

    1

    1

    

  



  

    Label for guestbook and message board

    

    No nudity, no sexual content, no violence, no

    potentially offensive language, no potentially harmful

    activities, user-generated content

    (moderated)

    1

    1

    1

    1

    1

    1

  



Beispiel 5 Ein Beispiel einer RDF-Instanz, die ICRA-Kennzeichnungen enthält

Die Namensräume werden deklariert. Die QNamen label und icra werden für ihre jeweiligen Namensräume empfohlen.

3.1.2 Abschnitt 2

Dieser kurze Abschnitt deklariert, dass die Kennzeichnungen durch die ICRA erstellt wurden und dass weitere Informationen unter www.icra.org verfügbar sind. Da es möglich ist, Beschreibungen auf der Grundlage anderer Schmene zu inkludieren, legt dieser Abschnitt fest, dass www.icra.org nur Informationen über den ICRA-Namensraum aufweist.

3.1.3 Abschnitt 3

Aus diesem Abschnitt gehen die Hosts hervor, für die die Daten gelten. In dieser Instanz wird deklariert, dass die Kennzeichnungen sowohl für example.org als auch für example.com angewendet werden können. Auch Subdomänen wie z. B. www.example.org, sub.example.com etc werden abgedeckt.

Dieser Abschnitt deklariert ferner, dass die Standardinhaltskennzeichnung für Material auf diesen Hosts “label_1” ist (siehe 3.1.5).

Wenn Kennzeichnungen auf einen bestimmten Bereich der Hosts example.org und example.com eingeschränkt werden sollten, sähe dies so aus:

foo

Kennzeichnungen in dieser RDF-Instanz würden dann nur Ressourcen mit URIs auf den Hosts example.org oder example.com abdecken, die außerdem ‘foo’ enthalten Diese Funktion ist primär für Internet-Dienstanbieter vorgesehen, die persönlichen Webspate mit URLs wie www.example.org/username bereitstellen. Ist mehr als eine Eigenschaft “hasURI” enthalten, gelangt ein URI zur Anwendung, wenn eine davon zutrifft.

3.1.4 Abschnitt 4

Als nächstes werden die Regeln deklariert, die bestimmen, wann die Standardkennzeichnung durch eine andere Kennzeichnung außer Kraft zu setzen ist. In diesem Beispiel wird alles im Abschnitt ‘photography’ von sowohl example.com als auch example.org “label_2” zugeordnet, während alles mit entweder dem Wort “guestbook ” oder ” messages” in der URL “label_3” zugeordnet wird. Ansonsten gilt der Standard.

Die Zuordnung erfolgt über reguläre Perl 5-Anweisungen7. Soll eine Regel also beispielsweise für “alle URLs, die mit .jpg enden” gelten, würde dies als \.jpg$ ausgedrückt.

Die Verwendung von rdf:parseType=”Collection” gewährleistet, dass Regeln der Reihe nach verarbeitet werden. Die erste Regel, die erfüllt wird, ist jene, die verwendet wird, und die Verarbeitung endet an dieser Stelle.

3.1.5 Abschnitt 5

Letztlich werden die Kennzeichnungen selbst definiert. In dem Beispiel gibt “label_2” an, dass nackte Brüste und Gesäße vorhanden sind und das Material jeweils in einem künstlerischen Zusammenhang vorkommt. “Label_3” deklariert, dass moderierte, benutzergenerierte Inhalte vorhanden sind, und “label_1” besagt “”Keine oder obigen Angaben trifft zu” in allen Kategorien des ICRA-Vokabulars.

Der korrekte MIME-Typ für RDF-Instanzen ist application/rdf+xml8. Standardmäßig unterstützt Ihr Server dies unter Umständen nicht9. Ist dies der Fall, müssen Sie eine von zwei Vorgangsweisen wählen:

  1. Idealerweise fügen Sie den MIME-Typ application/rdf+xml hinzu, der in der Regel der Dateierweiterung .rdf zugeordnet ist.
  2. Wenn Sie dazu aus irgendeinem Grund nicht in der Lage sind, versuchen Sie, den Namen der RDF-Instanz in label.xml zu ändern. Der XML-MIME-Typ (application/xml) ist eine akzeptable Alternative und ist verbreiteter in standardmäßigen Serverkonfigurationen enthalten.
  3. Manche Server können auch text/xml als MIME-Typ für Dateien mit der Erweiterung .xml anbieten. Dies führt aller Wahrscheinlichkeit nach zu keinen Problemen für Clients, die nach ICRA-Kennzeichnungen suchen, sollte aber nicht verwendet werden, wenn Sie ICRA-Kennzeichnungen in ein aufwändigeres Datenumfeld wie eine Datenbank aufnehmen oder wenn der Zeichensatz nicht iso-8859-1 (Latin-1) ist.

Wird keine dieser Optionen befolgt, kann Ihr Server einen standardmäßigen MIME-Type wie text/plain verwenden. In diesem Fall kann ein Client die Daten als RDF erkennen oder auch nicht und demgemäß korrekt verarbeiten oder auch nicht.

Falls Sie IIS-Server betreiben und nicht sicher sind, wie Sie neue MIME-Typen hinzufügen können, lesen Sie bitte den nachfolgenden Abschnitt 5.3.

Wird Ihr Server durch eine Firewall geschützt, müssen Sie gegebenenfalls auch diese entsprechend konfigurieren.

Nachdem Sie die RDF-Instanz erstellt haben, besteht der nächste Schritt darin, die Verknüpfungen darin einzufügen. Damit eine Website als vollständig gekennzeichnet betrachtet werden kann, müssen Verknüpfungen auf jeder (X)HTML-Seite und sollten idealerweise auch in allen Ressourcen enthalten sein.

Die Möglichkeit, die Kennzeichnungsverarbeitung vom Server auf den Client zu verlagern, bietet einen entscheidenden Vorteil: es kann in allen Ressourcen ein identischer Link eingefügt werden. Das gilt gleichermaßen für Kennzeichnungen, die eine kleine Website abdecken wie für solche, die ein weltweites Netzwerk von Internetplattformen erfassen.

Am effizientesten ist es, den/die Server so zu konfigurieren, dass die Verknüfpung in den HTTP-Response-Headers enthalten ist. Dadurch wird auch verhindert, dass der Tag versehentlich gelöscht (oder vergessen) wird, wenn Seiten umgestaltet werden. Die Kontrolle der Kennzeichnungen befindet sich dann fest in den Händen der Person (oder Abteilung), die für die Verwaltung der RDF-Instanz zuständig ist. Dabei kann es sich um dieselbe Person (oder Abteilung) handeln, die für die Inhaltserstellung verantwortlich ist, was jedoch nicht unbedingt der Fall sein muss. Alternativ kann ein (X)HTML-Verknüpfungs-Tag (ähnlich Beispiel 1 oder Beispiel 3, je nach Fall) in eine Dokumentvorlage eingefügt werden bzw. kann jedes sonstige Verfahren verwendet werden, auf dass Sie üblicherweise zurückgreifen, um dieselben Daten in den -Abschnitt jeder Seite einzufügen.

Ja. Wenn ein Benutzer Ihre Website zum ersten Mal besucht, erkennt dessen Client die Kennzeichnungen nur, wenn eine Verknüpfung vorhanden ist. Ist die Verknüpfung beispielsweise nur auf der Startseite vorhanden, profitieren Benutzer, die über andere Seiten auf Ihre Website gelangen, nicht davon.

Für die Steuerung von Apaches HTTP-Response-Headern gibt es mehrere Möglichkeiten. Wenn Sie bereits aus anderen Gründen Header einstellen, können Sie beim selben Verfahren bleiben. Falls nicht, ist nachstehend eine robuste, funktionierende Methode angegeben.

5.2.1 Installieren von Mod_Headers

Mod_Headers ist grundsätzlich nicht in der Standardkonfiguration vorgesehen, aber so gut wie sicher in Ihrer Apache-Installation enthalten und braucht daher nur “aktiviert” zu werden, indem das Kommentarsymbol vor zwei Zeilen in der Datei httpd.conf entfernt wird.

Es gibt für Apache zahlreiche verschiedene “bevorzugte Möglichkeiten”, was nachfolgend beschrieben wird, kommt den Anforderungen jedoch vermutlich zumindest nahe.

Suchen Sie im DSO-Abschnitt der Datei httpd.conf nach:

LoadModule headers_module     modules/mod_headers.so

Bei manchen Versionen genügt dies; andere erfordern zudem den nachfolgenden Befehl:

AddModule mod_headers.c

Die Kommentare in Ihrer Konfigurationsdatei sowie das Vorhandensein (oder Fehlen) ähnlicher Befehle für andere Module gibt Ihnen Hinweise darauf, was zu tun ist.

5.2.2 Einstellen desselben Response-Headers für alle Ressourcen

Unter der Annahme, dass die RDF-Instanz labels.rdf benannt ist und sich im Dokumentenstammverzeichnis des Webservers befindet, erzielt der folgende, in die Datei httpd.conf eingefügte Befehl das gewünschte Ergebnis.

Header set Link ‘; /=”/”; rel=”meta” type=”application/rdf+xml”; title=”ICRA labels”;’

Anmerkung: Diese Befehl sollte insgesamt in einer Zeile aufscheinen.

5.2.3 Verknüpfen zu spezifischen Kennzeichnungen mit HTTP-Response-Headern

Wie andere Apache-Konfigurationsoptionen können auch HTTP-Response-Header innerhalb von Blockanweisungen eingestellt werden. Beispiel 6 stellt die Verknüpfung auf “label_2” für alle Ressourcen in /var/www/images/.

  Header add Link ‘; /=”/”;   rel=”meta” type=”application/rdf+xml”;   title=”ICRA labels”;’

Example 6 Eine einfache Blockanweisung, die einen Header für alle Ressourcen im Verzeichnis images einstellt

Wie oben sollte der Befehl Header add Link in einer einzigen Zeile aufscheinen.

Blockanweisungen ermöglichen im Bedarfsfall auch eine sehr verfeinerte Kontrolle der HTTP-Response-Header*. Beispiel7 stellt einen Header ein, der auf “label_1” verweist, und zwar für alle Ressourcen im Verzeichnis /var/www/ (und dessen Unterverzeichnissen), aber wenn der Dateiname auf .gif, .jpg, .jpeg oder .png endet, wird die Header-Verknüpfung zu “label_2” aufgerufen.

  Header add Link ‘; /=”/”;   rel=”meta” type=”application/rdf+xml”;’       Header unset Link     Header add Link ‘; /=”/”;     rel=”meta” type=”application/rdf+xml”;’  

Beispiel 7 Eine genistete Blockanweisung, die einen unterschiedlichen Header für Grafikdateien und sonstige Dateien innerhalb desselben Blocks einstellt.

Beachten Sie in Beispiel 7, dass der Link in der Datei-Blockanweisung mit unset aufgehoben wird. Der Grund dafür ist, dass, wenn eine Ressource mit einer bestimmten Kennzeichnung verknüpft ist, diese Kennzeichnung die höchste Priorität erhält und nicht außer Kraft gesetzt werden kann (siehe Abschnitt 7). Es entspricht daher einem Fehler, mehr als eine Verknüpfung zu bestimmten Kennzeichnungen einzubauen, und das zu erwartende Verhalten von Clients ist unter diesen Umständen nicht definiert10.

* Manche Versionen von Apache gestatten unter Umständen nicht, dass Headers in einer Virtual Host-Blockanweisung eingestellt werden.

Microsoft gestaltet es äußerst einfach, Server so zu konfigurieren, dass Verknüpfungs-Tags eingebaut werden. Die Header-Informationen werden im Website-Eigenschaftendialogfeld unter Verwendung der Funktion für die benutzerdefinierte Anpassung von HTTP-Headern festgelegt. IIS verwendet eine hierarchische Struktur, bei der die Eigenschaftenseite von HTTP-Headern auf den folgenden Ebenen konfigurierbar ist:

  • Webserver
  • Startverzeichnis / Website (IIS 4 und höher unterstützen mehrere Websites)
  • Virtuelles Verzeichnis
  • Ordner
  • Seite

Um die HTTP-Header-Eigenschaften einzustellen, wählen Sie die gewünschte Ebene aus der IIS-Systemsteuerung, klicken diese mit der rechten Maustaste an und wählen zunächst die Eigenschaften und anschließend die Eigenschaftenseite für HTTP-Header. Der nachstehende Bildschirmausdruck zeigt die HTTP-Header-Eigenschaftenseite für die Standard-Website.

Abbildung 3 Das Eigenschaftendialogfeld in IIS

Klicken Sie auf die Schaltfläche “Hinzufügen”.

Geben Sie, wie in Abbildung 4 gezeigt, Link in das Feld “Custom Header Name” ein. In das Feld “Custom Header Value” geben Sie folgendes ein:

; /=”/”; rel=”meta” type=”application/rdf+xml”; title=”ICRA labels”;

Abbildung 4 Die Felder “Custom Header Name” und “Custom Header Value” in IIS

Klicken Sie auf OK, um zum Dialogfeld der Webeigenschaften zurückzukehren. Fügen Sie nun den RDF-MIME-Typ hinzu, sofern Sie dies noch nicht getan haben. Klicken Sie im Abschnitt “MIME Map” (siehe Abbildung 3) auf “Dateitypen” und geben Sie wie in Abbildung 5 gezeigt die Informationen ein.

Abbildung 5 Hinzufügen des RDF-MIME-Typs in IIS

Anmerkung: Bitte ignorieren Sie die Inhaltsfilterungsoptionen (diese verwenden ein überholtes System).

Viele Inhaltsanbieter werden nur eine einzige Kennzeichnung oder höchstens eine Handvoll Kennzeichnungen für ihre Website benötigen. Der Regelsatz jedoch bietet große Flexibilität und eine verfeinerte Kontrolle darüer, welche Kennzeichnung welchen Ressourcen zuzuordnen ist. Es stehen drei Regelgrundarten zur Verfügung:

Eine einfache Regel, die einen einzigen regulären Ausdruck in einem hasURI-Element deklariert, das, wenn der Ausdruck vorkommt, die korrekte Kennzeichnung identifiziert.

Eine Regel, die zwei oder mehr reguläre Ausdrücke in hasURI-Elementen enthält, die, wenn ein beliebiger Ausdruck davon vorkommt, eine korrekte Kennzeichnung identifizieren.

Eine Regel, die zwei oder mehr reguläre Ausdrücke in hasURI-Elementen enthält, die, wenn alle davon vorkommen, eine korrekte Kennzeichnung identifizieren.

In Beispiel 5 werden zwei Regeln deklariert:

  photography  

Jede Ressource, deren URI die Zeichenkette “photography” enthält (und die sich auf einem der deklarierten Hosts befindet) wird durch “label_2” beschrieben.

  guestbook   messages  

Wenn ein URI nicht der ersten Regel entspricht, versucht ein Client, ihn gegen “guestbook” und “messages” abzufragen. Tritt eine Entsprechung (für einen der beiden Begriffe) auf, gelangt “label_3” zur Anwendung.

Wie in Beispiel 8 gezeigt, ist es möglich, Regeln zu nisten. “Label_2” würde gelten, wenn die URL sowohl “colour” als auch “image” oder sowohl “monochrome” als auch “image” enthielte. Beachten Sie, dass hasLabel eine Eigenschaft der “äußeren” Regel ist.

   colour image   monochrome image   

  

  

  

Beispiel 9 Beschreibung eines Films mit Häufigkeitsergänzungen

Häufigkeitsergänzungen haben einen Bereich von label:ContentLabel. Das heißt, sie MÜSSEN zu einer Klasse dieses Typs verknüpfen.

Inhaltskennzeichnungen, Hostrestriktionen, Regeln – all das sind lediglich RDF-Fragmente. Nicht alle müssen in einer einzigen Datei namens labels.rdf enthalten sein. Wenn Sie mit RDF vertraut sind, können Sie sich ICRA-Kennzeichnungen schlicht als Teil Ihrer Metadaten vorstellen.

Wenn Sie zahlreiche Websites verwalten, die dieselbe ICRA-Kennzeichnung aufweisen sollten, erstellen Sie eine Datei, die die Kennzeichnung enthält, und fertigen im Rahmen Ihrer üblichen Vorlage einen Verknüpfungs-Tag an, der darauf verweist.. Vergessen Sie nicht: Die Kennzeichnungen müssen nicht auf demselben Server gespeichert sein, sie können sich überall befinden.

Sie brauchen keine Hostrestriktion vorzusehen- wenn eine Ressource auf eine Kennzeichnung verweist und in der RDF-Instanz keine Hostrestriktionen angegeben sind, ist die Kennzeichnung gültig. Der Nachteil daran ist, dass grundsätzlich jeder auf Ihre Kennzeichnung verweisen kann, was für Ihren Server eine erhebliche Zusatzbelastung bedeuten könnte.

Wenn Sie eine Hostrestriktion vorsehen möchten, kann dies in einer völlig getrennten Datei erfolgen. Beispiel 10 zeigt, wie dies bewerkstelligt werden kann. Die zwei RDF-Fragmente können sich in derselben Datei (wie hier dargestellt) oder in getrennten Dateien auf unterschiedlichen Servern befinden. In diesem Fall müssten Sie einen vollständigen URI (einschließlich der Fragmentidentifikation) als rdf:resource angeben.


  

   ...







  gt;example.com

  gt;example.org



Beispiel 10 Ein Regelsatz, der zu einer “externen” Liste von Hostrestriktionen verknüpft

Dies ermöglicht es Ihnen, eine stabile Datei für die Kennzeichnungen einzurichten und danach bei Bedarf die Liste der Hostrestriktionen dynamisch zu generieren.

Kennzeichnungen, die sich auf eine einzige Ressource beziehen, können in einer eigenen Datei abgelegt werden. Sie könnten beispielsweise eine Standard-Kennzeichnungsdatei (mit einem Regelsatz) einrichten, alles damit verknüpfen und anschließend eine völlig eigenständige Kennzeichnungsdatei für eine bestimmte Seite mit einem spezifischen Link zu der Kennzeichnung erstellen.

Überlegen Sie am besten, was für Sie am geeignetsten ist. In der Praxis wird es höchstwahrscheinlich funktionieren.

Die ICRA-Website bietet ein Online-Tool, das die korrekte Kennzeichnung für eine angegebene URL14 ermittelt.

Version 1.0.1: Abschnitt über Verknüpfung zu icra.org/sitelabel hinzugefügt (Abschnitt 9). Nachfolgende Abschnitte neu nummeriert.

Version 1.0.2 Dokumentation über hostRestriction dahingehend geändert, dass die Eigenschaft hasHostRestrictions und Hostklassen darin abgedeckt werden.

Version 1.0.3 Abschnitt bezüglich PICS-Kennzeichnungsdokument hinzugefügt.

Links und Bezugsquellen