HTML+RDFa 1.1 - Deutsche Übersetzung der W3C-Empfehlung

Übersetzung vom 22.09.2013

Die einzige normative Version ist die englische Version unter:
http://www.w3.org/TR/2013/REC-html-rdfa-20130822/

Diese Übersetzung ist zu finden unter:
http://www.schumacher-netz.de/TR/2013/REC-html-rdfa-20130822.de.html

Diese Übersetzung kann Fehler enthalten. Kommentare oder Korrekturvorschläge zu dieser deutschen Übersetzung bitte per E-Mail an den Übersetzer.

Weitere Übersetzungen von W3C-Dokumenten finden Sie auf den Seiten des Übersetzers.

Übersetzer: Stefan Schumacher (www.schumacher-netz.de)
Informationen zum Urheberrecht.

Im Text der Spezifikation können sich Kommentare des Übersetzers befinden. Diese Kommentare sind mit der gleichen Hintergrundfarbe wie dieser Absatz hinterlegt. Sie sind nicht Teil der Spezifikation und dienen nur der Erläuterung einzelner Begriffe oder Abschnitte.

W3C

HTML+RDFa 1.1

Unterstützung für RDFa in HTML4 and HTML5

W3C-Empfehlung vom

Diese Version:
http://www.w3.org/TR/2013/REC-html-rdfa-20130822/
Zuletzt veröffentlichte Version:
http://www.w3.org/TR/html-rdfa/
vorherige Version:
http://www.w3.org/TR/2013/PR-html-rdfa-20130625/
Test suite:
http://rdfa.info/test-suite/
Editor:
Manu Sporny, Digital Bazaar, Inc.
Autoren:
Shane McCarron, Applied Testing and Technology, Inc.
Ben Adida, Creative Commons
Mark Birbeck, Sidewinder Labs
Gregg Kellogg, Kellogg Associates
Ivan Herman, W3C
Steven Pemberton, CWI

Bitte konsultieren Sie die Errata zu diesem Dokument, die einige normative Korrekturen enthalten könnten.

Dieses Dokument ist auch in diesem nicht normativen Format erhältlich: Diff zur vorherigen Version.

Die englische Version dieser Spezifikation ist die einzige normative Version. Nicht normative Übersetzungen könnten auch verfügbar sein.


Zusammenfassung

Diese Spezifikation definiert Regeln und Richtlinien, um die Spezifikationen RDFa Core 1.1 und RDFa Lite 1.1 zur Verwendung in HTML5 und XHMTL5 anzupassen. Die in dieser Spezifikation definierten Regeln gelten nicht nur für HTML5-Dokumente im Nicht-XML-Modus und im XML-Modus, sondern auch für HTML4- und XHTML-Dokumente, die durch HTML5-Verarbeitungsregeln interpretiert werden.

Status dieses Dokuments

Dieser Abschnitt beschreibt den Status dieses Dokuments zur Zeit seiner Veröffentlichung, andere Dokumente könnten dieses Dokument ersetzen. Eine Liste mit aktuellen W3C-Veröffentlichungen und die aktuelle Revision dieses Technischen Berichts kann im Index für Technische Berichte des W3C unter http://www.w3.org/TR/ gefunden werden.

Dieses Dokument wurde von W3C-Mitgliedern, von Software-Entwicklern und von anderen W3C-Gruppen und Interessierten überprüft und ist vom Direktor als eine W3C-Empfehlung anerkannt worden. Es ist ein stabiles Dokument und kann als Referenzmaterial verwendet oder von anderen Dokumenten zitiert werden. Die Aufgabe des W3C bei der Erstellung der Empfehlung ist es, die Aufmerksamkeit auf diese Spezifikation zu lenken und ihre weitläufige Verbreitung zu fördern. Dies verbessert die Funktionalität und die Interoperabilität des Webs.

Diese Spezifikation ist eine Erweiterung der Sprache HTML5. Jeglicher normativer Inhalt in der Spezifikation HTML5, außer ausdrücklich von dieser Spezifikation überschrieben, ist als Basis für diese Spezifikation anzusehen.

Anmerkung

Es gibt zwei Eigenschaften in dieser Spezifikation, @datetime-Verarbeitung und rdf:HTML-Literale, die zur Zeit als nicht normative Eigenschaften definiert sind. Die Absicht dahinter besteht darin, dass diese Eigenschaften letztendlich normative Eigenschaften werden, sobald die Spezifikation, die das Attribut @datetime beschreibt [HTML5] und die Spezifikation, die rdf:HTML definiert [RDF-CONCEPTS], W3C-Empfehlungen werden. Implementierer sollten diese Eigenschaften jetzt implementieren; eine zweite (oder spätere) Edition dieser Spezifikation wird die langfristige Stabilität jener Eigenschaften klarstellen. Auf Grundlage der Diskussion zwischen der Arbeitsgruppe RDFa, der Arbeitsgruppe HTML und der Arbeitsgruppe RDF, wird nicht erwartet, dass Implementierungsveränderungen notwendig sein werden, wenn HTML5 und RDF 1.1 zur Empfehlung aufsteigen.

Eine Testumgebung mit Beispielen steht für Software-Entwickler bereit. Diese Tests erheben keinen Anspruch auf Vollständigkeit. Eine von der Community unterhaltene Internetseite enthält mehr Informationen zu weiterführender Lektüre und zu Entwicklerwerkzeugen und Softwarebibliotheken, die verwendet werden können, um RDFa-Daten aus Web-Dokumenten zu extrahieren und zu verarbeiten. Der endgültige, vom Direktor bedachte Implementierungsbericht wurde der Öffentlichkeit zur Verfügung gestellt.

Dieses Dokument wurde von der Arbeitsgruppe RDFa als eine Empfehlung veröffentlicht. Wenn Sie wünschen, Kommentare zu diesem Dokument abzugeben, schicken Sie diese bitte auf Englisch an public-rdfa-wg@w3.org (abonnieren, Archive). Alle Kommentare sind willkommen.

Diese Dokument wurde von einer Gruppe erstellt, die unter der W3C Patent Policy vom 5. Februar 2004 arbeitet. W3C unterhält eine öffentliche List mit allen Patentoffenlegungen, die in Verbindung mit den Ergebnissen dieser Gruppe stehen; jene Seite enthält auch Anweisungen für die Offenlegung eines Patents. Ein Individuum, das tatsächliches Wissen zu einem Patent hat, das nach Glauben des Individuums Essenzielle/n Ansprüche/Anspruch enthält, muss diese Informationen in Übereinstimmung mit Abschnitt 6 der W3C Patent Policy offenlegen.

Inhaltsverzeichnis

1. Einleitung

Dieser Abschnitt ist nicht normativ.

Das heutige Web ist überwiegend für menschliche Leser entwickelt worden. Auch wenn maschinenlesbare Daten sich langsam im Web verbreiten, werden sie normalerweise in getrennten Dateien mit getrennten Formaten verteilt, und die an Menschen und Maschinen gerichteten Versionen haben wenige gemeinsame Berührungspunkte. Als Folge daraus können Web-Browser dem Menschen nur wenig Hilfe bei der Analyse und Verarbeitung von Web-Seiten geben: Browser sehen nur Darstellungsinformationen. RDFa soll das Problem der Auszeichnung maschinenlesbarer Daten in HTML-Dokumenten lösen. RDFa stellt HTML-Attribute zur Verfügung, um visuelle Daten mit maschinenlesbaren Hinweisen zu versehen. Durch RDFa könnten Autoren ihre vorhandenen menschenlesbaren Texte und Verweise in maschinenlesbare Daten verwandeln, ohne Inhalt zu wiederholen.

2. Konformität

Wie alle Bereiche, die als nicht normativ gekennzeichnet sind, sind auch alle Autorenrichtlinien, Diagramme, Beispiele und Anmerkungen in dieser Spezifikation nicht normativ. Alles andere in dieser Spezifikation ist normativ.

Die Schlüsselworte MUSS, DARF NICHT, ERFORDERLICH, SOLLTE, SOLLTE NICHT, EMPFOHLEN, KANN und OPTIONAL in dieser Spezifikation sind zu interpretieren, wie es in [RFC2119] beschrieben ist.

2.1 Dokumentkonformität

Es gibt zwei verschiedene Arten der Dokumentkonformitätskriterien in HMTL-Dokumenten, die RDFa-Semantik enthalten; HTML+RDFa und HTML+RDFa Lite.

Die folgenden Konformitätskriterien gelten für jedes HTML-Dokument, das RDFa-Quelltext enthält:

Ein Beispiel eines konformen HTML+RDFa-Dokuments mit grün hervorgehobenen RDFa-Inhalten:

Beispiel 1: Beispiel eines HTML+RDFa 1.1-Dokuments
<!DOCTYPE html>
<html lang="de">
<head>
  <title>Beispieldokument</title>
</head>
<body vocab="http://schema.org/">
  <p typeof="Blog">
    Willkommen zu meinem <a property="url" href="http://example.org/">Blog</a>.
  </p>
</body>
</html>

Die folgenden Daten werden von einem konformen RDFa-Prozessor extrahiert werden, dargestellt im Turtle-Format [TURTLE]:

Beispiel 2: Turtle-Ausgabe des Beispieldokuments
[] a <http://schema.org/Blog>;
 <http://schema.org/url> <http://example.org/> .

HTML+RDFa 1.1-Dokumente, die nicht im XML-Modus sind, SOLLTEN mit dem Internetmedientypen text/html bezeichnet werden, wie es im Abschnitt 12.1 der HTML5-Spezifikation [HTML5] definiert ist.

XHTML5+RDFa 1.1-Dokumente im XML-Modus SOLLTEN mit dem Internetmedientypen application/xhtml+xml bezeichnet werden, wie es im Abschnitt 12.3 der HTML5-Spezifikation [HTML5] definiert ist, DÜRFEN KEINE DOCTYPE-Deklaration XHTML+RDFa 1.0 oder XHTML+RDFa 1.1 verwenden und SOLLTEN KEIN @version-Attribut verwenden.

2.2 RDFa-Prozessorkonformität

Die RDFa-Prozessorkonformitätskriterien sind folgend aufgelistet, alle müssen erfüllt werden:

2.3 Benutzerschnittstellenkonformität

Eine Benutzerschnittstelle wird als eine Art RDFa-Prozessor angesehen, wenn die Benutzerschnittstelle RDFa-Attribute und deren Werte speichert oder verarbeitet. Es gibt getrennte Bereiche für RDFa-Prozessorkonformität und Benutzerschnittstellenkonformität, weil ein Programm ein gültiger HTML5-RDFa-Prozessor sein kann, aber keine gültige HTML5-Benutzerschnittstelle (zum Beispiel durch eine eingeschränkte Darstellungsfunktionalität).

Die Konformitätskriterien für Benutzerschnittstellen sind folgend aufgelistet, alle müssen erfüllt werden:

3. Erweiterungen zu RDFa Core 1.1

Die RDFa Core 1.1-Spezifikation [RDFA-CORE] ist die Grundlage für diese Spezifikation. RDFa Core 1.1 gibt im Abschnitt 5: Attribute und Syntax die Attribute und die Syntax an und im Abschnitt 7: Verarbeitungsmodell das Verarbeitungsmodell zur Extrahierung von RDF aus einem Web-Dokument. Dieser Abschnitt umfasst Änderungen an den Attributen und dem Verarbeitungsmodell, die in RDFa Core 1.1 definiert sind, um die Extrahierung von RDF aus HTML-Dokumenten zu unterstützen.

Die Anforderungen und Regeln, die in RDFa Core angegeben sind und in diesem Dokument erweitert werden, gelten für alle HTML5-Dokumente. Ein RDFa-Prozessor, der sowohl mit HTML- als auch XHTML-Dokumenten arbeitet, insbesondere mit deren resultierenden DOMs oder Infosets, MUSS diese Verarbeitungsregeln für HTML4-, HTML5- und XHTML5-Serialisationen, DOMs und/oder Infosets anwenden.

3.1 Zusätzliche RDFa-Verarbeitungsregeln

Dokumente, die zu den Regeln dieser Spezifikation konform sind, werden nach [RDFA-CORE] verarbeitet, mit den folgenden Erweiterungen:

  1. Der voreingestellte Vokabular-URI ist nicht definiert.
  2. HTML+RDFa verwendet einen zusätzlichen voreingestellten Anfangskontext http://www.w3.org/2011/rdfa-context/html-rdfa-1.1, welcher nach dem Anfangskontext für [RDFA-CORE] (http://www.w3.org/2011/rdfa-context/rdfa-1.1) angewendet werden muss.
  3. Die Basis kann mit dem base-Element bestimmt werden. In XHTML5+RDFa 1.1-Dokumenten kann die Basis auch durch das Attribut @xml:base bestimmt werden.
  4. Die aktuelle Sprache kann mit den Attributen @lang oder @xml:lang bestimmt werden. Werden die Attribute @lang und @xml:lang im gleichen Element angegeben, hat das @xml:lang-Attribut Vorrang. Wenn sowohl @lang als auch @xml:lang im gleichen Element angegeben sind, MÜSSEN sie den gleichen Wert haben. Weitere Details zur Angabe der aktuellen Sprache können im Abschnitt 3.3 Die Sprache für ein Literal bestimmen gefunden werden.
  5. Zur Bestimmung der zu verwendenden RDFa-Verarbeitungsregeln für ein Dokument, das mit dem Medientypen application/xhtml+xml ausgeliefert wird, MUSS ein konformer RDFa-Prozessor nach dem Wert in der DOCTYPE-Deklaration des Dokuments suchen. Gibt es eine DOCTYPE-Deklaration, dann sind die Verarbeitungsregeln folgende:
    • XHTML1+RDFa 1.0 für DOCTYPE <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">, or
    • XHTML1+RDFa 1.1 für DOCTYPE <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.1//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-2.dtd">, or
    • XHTML5+RDFa 1.1 für alle anderen DOCTYPE-Werte.
    Dokumente, die als application/xhtml+xml ausgeliefert werden und keine DOCTYPE-Deklaration enthalten und kein @version-Attribut angeben, MÜSSEN als XHTML5+RDFa 1.1-Dokument interpretiert werden.
  6. Im Abschnitt 7.5: Verarbeitungsablauf, Verarbeitungsschritt 3; wird ein Prozessorgraph unterstützt und überschreibt eine IRI-Abbildung eine zuvor existierende Abbildung in der lokalen Liste der IRI-Abbildungen mit einem anderen Wert, dann MUSS der Prozessor eine entsprechende Warnung rdfa:PrefixRedefinition ausgeben und die damit verbundenen Tripel in den Prozessorgraphen übertragen.
  7. Im Abschnitt 7.5: Verarbeitungsablauf, direkt nach Verarbeitungsschritt 4; existiert das @property-Attribut und das @rel- und/oder @rev-Attribut im gleichen Element, werden die Werte von @rel und @rev, die weder CURIE noch URI sind, ignoriert. Ist als Folge hieraus der Wert von @rel und/oder @rev leer, dann MUSS der Prozessor sich so verhalten, als sei das entsprechende Attribut nicht vorhanden.
  8. In Abschnitt 7.5, Verarbeitungsschritt 5 und Verarbeitungsschritt 6; wird kein IRI durch ein Quellenattribut angegeben (zum Beispiel @about, @href, @resource oder @src), dann prüfe zuerst, ob das Element das head- oder body-Element ist. Liegt dieser Fall vor, dann setze neues Subjekt auf Elternobjekt.
  9. Im Abschnitt 7.5: Verarbeitungsablauf, Verarbeitungsschritt 11; das HTML5-Attribut @datetime MUSS verwendet werden, wenn der aktuelle Eigenschaftswert erzeugt wird, es sei denn, @content ist ebenfalls im gleichen Element vorhanden. Ansonsten, wenn @datetime vorhanden ist, muss der aktuelle Eigenschaftswert wie folgt erzeugt werden. Der Literalwert ist der Wert, der im @datetime-Attribut enthalten ist. Ist @datatype vorhanden, muss es entsprechend der Definition in den [RDFA-CORE]-Verarbeitungsregeln verwendet werden. Ansonsten, wenn der Wert von @datetime lexikalisch einem gültigen xsd:date, xsd:time, xsd:dateTime, xsd:duration, xsd:gYear oder xsd:gYearMonth entspricht, muss ein typisiertes Literal erzeugt werden; dessen Datentyp muss auf den entsprechenden xsd-Datentyp gesetzt werden. Ansonsten MUSS ein einfaches Literal unter Berücksichtigung der aktuellen Sprache erzeugt werden. Implementierer sollten beachten, dass die richtige Reihenfolge der Mustererkennung folgende sein sollte: xsd:duration, xsd:dateTime, xsd:date, xsd:time, xsd:gYearMonth und xsd:gYear. Diese Eigenschaft ist zur Zeit nicht normativ, beachten Sie die Anmerkung, wann sie normativ werden wird.
  10. Im Abschnitt 7.5: Verarbeitungsablauf, Verarbeitungsschritt 11; handelt es sich um das Element time und das Element hat weder ein @datetime- noch ein @content-Attribute, MUSS der Prozessor so verfahren, als gäbe es ein @datetime-Attribut, das genau den Textwert des Elements enthält. Diese Eigenschaft ist zur Zeit nicht normativ, beachten Sie die Anmerkung, wann sie normativ werden wird.
  11. Im Abschnitt 7.5: Verarbeitungsablauf, Schritt 11, direkt nach Unterschritt 2; ist das @datatype-Attribut vorhanden und ergibt dessen Auswertung http://www.w3.org/1999/02/22-rdf-syntax-ns#HTML, dann ist der Wert des HTML-Literals eine Zeichenkette, die durch Serialisierung aller Kindelemente zu Text erzeugt wird. Dies gilt für alle Knoten, die Nachfahren des aktuellen Elements sind, das Element selbst nicht eingeschlossen. Dem HTML-Literal wird der Datentyp http://www.w3.org/1999/02/22-rdf-syntax-ns#HTML gegeben, wie im Abschnitt 5.2: The rdf:HTML Datatype von [RDF-CONCEPTS] beschrieben ist. Diese Eigenschaft ist zur Zeit nicht normativ, beachten Sie die Anmerkung, wann sie normativ werden wird.
  12. Wurde der Ausgabegraph nach den Verarbeitungsschritten erzeugt, die in Abschnitt 7.5: Verarbeitungsablauf der Spezifikation RDFa Core 1.1 [RDFA-CORE] und in diesem Abschnitt beschrieben sind, führe die Operationen aus, die in Implementierung von Eigenschaftkopien beschrieben sind.

Das Attribut @version wird in HTML5 nicht unterstützt und ist nicht konform. Enthält ein HTML+RDFa-Dokument jedoch ein @version-Attribut im html-Element, MUSS ein konformer RDFa-Prozessor den Wert des Attributs untersuchen. Entspricht der Wert dem einer definierten RDFa-Version, dann MÜSSEN die Verarbeitungsregeln für diese Version verwendet werden. Entspricht der Wert keiner definierten Version oder gibt es kein @version-Attribut, dann MÜSSEN die Verarbeitungsregeln für die aktuelle Version von RDFa 1.1 verwendet werden.

3.2 Das Eingabedokument verändern

Durch die baumartigen Verarbeitungsregeln in RDFa, die in Abschnitt 7.5: Arbeitsablauf der Spezifikation RDFa Core 1.1 [RDFA-CORE] umrissen werden, können Eingabedokumente vor der Verarbeitung automatisch in jeglicher Weise berichtigt, gesäubert, neu angeordnet oder verändert werden, die durch die Wirtsprache erlaubt ist. Probleme mit der Verschachtelung von Elementen in HTML-Dokumenten SOLLTEN berichtigt werden, bevor das Eingabedokument in das DOM übertragen wird, ein gültiges baumbasiertes Modell, auf das die RDFa-Verarbeitungsregeln angewendet werden.

Jeder Mechanismus, der eine zum HTML5- oder XHTML5-DOM äquivalente Datenstruktur erzeugt, wie die html5lib-Bibliothek KANN als Mechanismus verwendet werden, um ein baumbasiertes Modell als Eingabe für die RDFa-Verarbeitungsregeln zu erzeugen.

3.3 Die Sprache für ein Literal bestimmen

Entsprechend RDFa Core 1.1 KANN die aktuelle Sprache durch die Wirtsprache angegeben werden. Um konform zu dieser Spezifikation zu sein, MÜSSEN RDFa-Prozessoren den Mechanismus verwenden, der im Abschnitt The lang and xml:lang attributes der Spezifikation [HTML5] beschrieben ist, um die Sprache eines Knotens zu bestimmen.

Ist während der Bearbeitung eines HTML-Fragments noch nicht über den endgültig umschließenden MIME-Typen entschieden, wird EMPFOHLEN, dass der Autor sowohl @lang als auch @xml:lang angibt; beide Attribute müssen den genau gleichen Wert besitzen.

Anmerkung

Die HTML5-Spezifikation berücksichtigt den HTTP-Header Content-Language, wenn die Sprache eines Elements bestimmt wird. Einige RDFa-Prozessoren, wie jene in JavaScript geschriebenen, haben eventuell keinen Zugriff auf diesen Header und sind in diesem Einzelfall, in dem die Sprache nur über den HTTP-Header Content-Language angegeben ist, nicht konform. In diesen Fällen werden RDFa-Dokumentautoren dringend gebeten, die Sprache im Dokument mit dem Attribute @lang im Element html anzugeben, um sicherzustellen, dass das Dokument von allen RDFa-Prozessoren richtig interpretiert wird.

3.4 Ungültige XMLLiteral-Werte

Werden Literale des Typs XMLLiteral erzeugt, MUSS der Prozessor sicherstellen, dass das ausgegebene XMLLiteral ein in Bezug auf den Namensraum wohlgeformtes XML-Fragment ist. Ein in Bezug auf den Namensraum wohlgeformtes XML-Fragment hat die folgenden Eigenschaften:

Ein RDFa-Prozessor, der das XML-Fragment transformiert, MUSS den Algorithmus Coercing an HTML DOM into an infoset verwenden, wie in der HTML5-Spezifikation beschrieben, gefolgt von dem Algorithmus, der im Abschnitt Serializing XHTML Fragments der HTML5-Spezifikaiton beschrieben ist. Gibt es an irgendeiner Stelle der Transformation einen Fehler oder einen Ausnahmefehler, DARF KEIN Tripel erzeugt werden, der das XMLLiteral enthält.

Die Transformation in ein in Bezug auf den Namensraum wohlgeformtes XML-Fragment ist erforderlich, weil eine Anwendung, die XMLLiterale verarbeitet, erwartet, dass die Daten aus Namensraum-wohlgeformten XML-Fragmenten bestehen.

Die Tranformation wird nicht für Texteingabedaten gefordert, die nur aus reinem Text bestehen, wie Literale, die ein @datatype-Attribut mit einem leeren Wert ("") enthalten oder Eingabedaten, die nur Textknoten enthalten.

Im Folgenden demonstriert eine Beispieltransformation die Erhaltung von Namensraumwerten. Das Symbol → wird verwendet, um anzudeuten, dass die Zeile eine Fortsetzung der vorherigen Zeile ist und ist nur zur besseren Lesbarkeit eingefügt worden:

Beispiel 3: Quelltext zur Namensraumerhaltung
<p xmlns:ex="http://example.org/vocab#"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
 Two rectangles (the example markup for them are stored in a triple):
 <svg xmlns="http://www.w3.org/2000/svg"
      property="ex:markup" datatype="rdf:XMLLiteral">
 →<rect width="300" height="100" style="fill:rgb(0,0,255);stroke-width:1; stroke:rgb(0,0,0)"/>
 →<rect width="50" height="50" style="fill:rgb(255,0,0);stroke-width:2;stroke:rgb(0,0,0)"/></svg>
</p>

Der Quelltext oben SOLLTE das folgende Tripel erzeugen, das die xmlns-Deklaration im Quelltext durch Einsetzen der @xmlns-Attribute in die rect-Elemente erhält:

Beispiel 4: Triple zur Namensraumerhaltung
<>
   <http://example.org/vocab#markup>
      """<rect xmlns="http://www.w3.org/2000/svg" width="300"
→height="100" style="fill:rgb(0,0,255);stroke-width:1; stroke:rgb(0,0,0)"/>
→<rect xmlns="http://www.w3.org/2000/svg" width="50"
→height="50" style="fill:rgb(255,0,0);stroke-width:2;
→stroke:rgb(0,0,0)"/>"""^^<http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral> .

Da die Namensräume ex und rdf in keinem der beiden rect-Elemente verwendet werden, bleiben sie nicht im XMLLiteral erhalten.

Ähnlich dazu müssen zusammengesetzte Dokumentelemente, die in verschiedenen Namensräumen residieren, ihre eigenen Namensraumdeklarationen erhalten:

Beispiel 5: Namensraumerhaltung für compound Dokumentelemente
<p xmlns:ex="http://example.org/vocab#"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:fb="http://www.facebook.com/2008/fbml">
 This is how you markup a user in FBML:
 <span property="ex:markup" datatype="rdf:XMLLiteral">
→<span><fb:user uid="12345">The User</fb:user></span>
→</span>
</p>

Der Quelltext oben SOLLTE den folgenden Tripel erzeugen, der den Namensraum fb im zugehörigen Tripel erhält:

Example 6: Namespace element preservation triple
<>
   <http://example.org/vocab#markup>
      """<span xmlns:fb="http://www.facebook.com/2008/fbml">
→<fb:user uid="12345"></fb:user>
→</span>"""^^<http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral> .

3.5 Eigenschaftskopieren (Property Copying)

Es kommt vor, dass Autoren viele Quellen in einer Seite haben, die einige gemeinsame Eigenschaften haben. Zum Beispiel könnten mehrere Musikaufführungen verschiedene Auftrittszeiten haben, aber den gleichen Ort, die gleiche Band und die gleichen Eintrittspreise. In diesem bestimmten Fall ist es vorteilhaft, eine Kurzschreibweise zu verwenden, die den RDFa-Prozessor anweist, die Auftrittszeiten, den Ort und die Eintrittspreise einzuschließen, ohne die Notwendigkeit den gesamten Quelltext, der die Daten beschreibt, zu wiederholen.

HTML+RDFa definiert den Mechanismus Eigenschaftskopieren, mit Hilfe dessen Eigenschaften, die mit einer Quelle verknüpft sind, zu einer anderen Quelle hinzukopiert werden können. Dieser Mechanismus kann mit dem Prädikat rdfa:copy aktiviert werden. Die Eigenschaft wird in den folgenden beiden Beispielen verdeutlicht:

Beispiel 7: Ereignisse mit gleichen Eigenschaften
<div vocab="http://schema.org/">
  <p typeof="MusicEvent">
   <link property="image" href="Muse1.jpg"/>
   <link property="image" href="Muse2.jpg"/>
   <link property="image" href="Muse3.jpg"/>
   <span property="name">Muse</span> im United Center.
   <time property="startDate" datetime="2013-03-03"> 3. März 2013</time>, 
   <a property="location" href="#united">United Center, Chicago, Illinois</a>
   ...
  </p>

  <p typeof="MusicEvent">
   <link property="image" href="Muse1.jpg"/>
   <link property="image" href="Muse2.jpg"/>
   <link property="image" href="Muse3.jpg"/>
   <span property="name">Muse</span> im Target Center.
   <time property="startDate" datetime="2013-03-07">7. März 2013</time>, 
   <a property="location" href="#target">Target Center, Minneapolis, Minnesota</a>
   ...
  </p>
</div>

In diesem Fall werden zwei Musikveranstaltungen mit den Eigenschaften image, name, startDate und location definiert. Die Werte image und name sind für beide Veranstaltungen identisch und werden im Quelltext unnötig doppelt niedergeschrieben. Mit der RDFa-Eigenschaft Eigenschaftskopieren kann ein Muster deklariert werden, das die gemeinsamen Eigenschaften ausdrückt. Dieses Muster kann dann in andere Quellen innerhalb des Dokuments hineinkopiert werden:

Beispiel 8: Gemeinsame Eigenschaften kopieren
<div vocab="http://schema.org/">
  <div resource="#muse" typeof="rdfa:Pattern">
    <link property="image" href="Muse1.jpg"/>
    <link property="image" href="Muse2.jpg"/>
    <link property="image" href="Muse3.jpg"/>
    <span property="name">Muse</span>
  </div>

  <p typeof="MusicEvent">
    <link property="rdfa:copy" href="#muse"/>
    Muse im United Center.
    <time property="startDate" datetime="2013-03-03">3. März 2013</time>, 
    <a property="location" href="#united">United Center, Chicago, Illinois</a>
    ...
  </p>

  <p typeof="MusicEvent">
    <link property="rdfa:copy" href="#muse"/>
    Muse at the Target Center.
    <time property="startDate" datetime="2013-03-07">7. März 2013</time>, 
    <a property="location" href="#target">Target Center, Minneapolis, Minnesota</a>
    ...
  </p>
</div>

In diesem Fall werden die gemeinsamen Eigenschaften aller Veranstaltungen im ersten div-Element ausgedrückt. Die gemeinsamen Eigenschaften werden in jede einzelne Veranstaltungsquelle über das Prädikat rdfa:copy kopiert. Die Ausgabe für die vorherigen beiden Beispiele ist die gleiche:

Beispiel 9: Turtle-Ausgabe des Beispiels für Eigenschaftskopieren
@prefix schema: <http://schema.org/> .
@prefix xsd: http://www.w3.org/2001/XMLSchema#> .

[] a schema:MusicEvent;
   schema:image <Muse1.jpg>, <Muse2.jpg>, <Muse3.jpg>;
   schema:name "Muse";
   schema:startDate "2013-03-03"^^xsd:date;
   schema:location <#united> .

[] a schema:MusicEvent;
   schema:image <Muse1.jpg>, <Muse2.jpg>, <Muse3.jpg>;
   schema:name "Muse";
   schema:startDate "2013-03-07"^^xsd:date;
   schema:location <#target> .

Der Kopiervorgang ist iterativ, Quellen können andere Quellen kopieren, die andere Quellen kopieren. Zum Beispiel:

Beispiel 10: Quellen können andere Quellen kopieren, die andere Quellen kopieren
<div vocab="http://schema.org/">
  <div typeof="Person">
    <link property="rdfa:copy" href="#lennon"/>
    <link property="rdfa:copy" href="#band"/>
  </div>
  <p resource="#lennon" typeof="rdfa:Pattern"> 
    Name: <span property="name">John Lennon</span>
  <p>
  <div resource="#band" typeof="rdfa:Pattern">
    <div property="band" typeof="MusicGroup">
      <link property="rdfa:copy" href="#beatles"/>
    </div>
  </div>
  <div resource="#beatles" typeof="rdfa:Pattern">
    <p>Band: <span property="name">The Beatles</span></p>
    <p>Size: <span property="size">4</span> Mitglieder</p>
  </div>
</div>

Im Beispiel oben werden die Eigenschaften von #lennon und #band in die erste Quelle kopiert. Dann werden die Eigenschaften von #beatles nach #band kopiert. Darauffolgend werden jene Eigenschaften wiederum in die erste Quelle kopiert, was zu folgender Ausgabe führt:

Beispiel 11: Beispielausgabe in Turtle für iteratives Kopieren
@prefix schema: <http://schema.org/> .

[ a schema:Person;
  schema:name "John Lennon" ;
  schema:band [
    a schema:MusicGroup;
    schema:name "The Beatles";
    schema:size "4"
  ]
] .

Ähnlich zur Vokabularerweiterung wie in [RDFA-CORE] definiert, arbeitet RDFa-Eigenschaftskopieren mit dem Ausgabegraphen, nachdem die Dokumentverarbeitung abgeschlossen ist.

3.5.1 Implementierung von Eigenschaftskopieren

Nach Erzeugen des Ausgabegraphen entsprechend Abschnitt 7.5: Verarbeitungsablauf der Spezifikation RDFa Core 1.1 [RDFA-CORE] und Erweiterungen zur HTML5-Syntax, definiert in dieser Spezifikation, MÜSSEN Prozessoren den Ausgabegraphen unter Berücksichtigung der folgenden Regeln aktualisieren:

  1. Verwende die folgende Regel für jede rdfa:copy-Angabe im Ausgabegraphen und für jede neue rdfa:copy-Angabe, die als Ergebnis von Eigenschaftkopieren hinzugefügt wurde, bis kein neuer Tripel mehr zum Ausgabegraphen hinzugefügt wird:
    RegelnameEnthält der Ausgabegraphdann füge hinzu
    pattern-copy ?subject rdfa:copy ?target
    ?target rdf:type rdfa:Pattern
    ?target ?predicate ?object
    ?subject ?predicate ?object
  2. Schlussendlich verwende diese Regel, um verwendete rdfa:copy-Angaben und rdfa:Pattern-Quellen vom Ausgabegraphen zu entfernen:
    RegelnameEnthält Ausgabegraphdann entferne
    pattern-clean ?subject rdfa:copy ?target
    ?target rdf:type rdfa:Pattern
    ?target ?predicate ?object
    ?subject rdfa:copy ?target
    ?subject rdf:type rdfa:Pattern
    ?target ?predicate ?object
Anmerkung

Implementierer sollten wissen, dass eine einfachste Implementierung der Regel pattern-copy zu einer unendlichen Schleife führen kann, wenn zirkuläre Abhängigkeiten verarbeitet werden. Ein Prozessor sollte die Bearbeitung der pattern-copy-Regel beenden, wenn keine eindeutigen Tripel mehr erzeugt werden.

Anmerkung

Alternative Regeln können verwendet werden, um den Ausgabegraphen zu aktualisieren, solange das Ergebnis das gleiche ist.

4. Erweiterungen zur HTML5-Syntax

Zur vollständigen Unterstützung von RDFa wurden einige Attribute als Erweiterungen zur HTML5-Syntax hinzugefügt:

5. Rückwärtskompatibilität

RDFa Core 1.1 erklärt die Verwendung von @xmlns: in RDFa 1.1-Dokumenten für veraltet. Autoren von Internetseiten SOLLTEN NICHT @xmlns: verwenden, um Präfixabbildungen in RDFa 1.1-Dokumenten auszudrücken. Autoren von Internetseiten SOLLTEN das Attribut @prefix verwenden, um Präfixabbildungen anzugeben.

Jedoch werden XHTML+RDFa 1.0-Dokumente in einigen Fällen vom Webserver mit dem MIME-Typen text/html ausgeliefert. Unter diesen Umständen fordert die HTML5-Spezifikation, dass das Dokument nach den Verarbeitungsregeln für den Modus nicht-XML verarbeitet wird. In diesen bestimmten Fällen ist es wichtig, dass die über @xmlns: deklarierten Präfixe für den RDFa-Prozessor erhalten bleiben, um die Rückwärtskompatibilität mit RDFa 1.0-Dokumenten zu gewährleisten. Die folgenden Abschnitte beschäftigen sich ausführlich mit den Anforderungen an RDFa-Prozessoren in Bezug auf die Rückwärtskompatibilität.

5.1 Attribute mit dem Präfix @xmlns:

Die Spezifikation RDFa Core 1.1 [RDFA-CORE] erklärt die Verwendung des @xmlns:-Mechanismus zur Deklarierung von CURIE-Präfixabbildungen für veraltet und setzt stattdessen auf das Attribut @prefix. Jedoch gibt es Fälle, in denen die Verwendung nicht zu vermeiden ist. Zum Beispiel bei der Veröffentlichung von Altdokumenten als HTML5 oder zur Unterstützung von älteren XHTML+RDFa 1.0-Dokumenten, die sich auf das Attribut @xmlns: stützen.

CURIE-Präfixabbildungen, die mit Attributen angegeben werden, denen ein @xmlns: vorsteht MÜSSEN entweder nach Abschnitt 4.1: URI-Abbildungen aus Infosets extrahieren für Infoset-basierte Prozessoren oder nach Abschnitt 4.5.1: URI-Abbildungen über DOM Level 2 extrahieren für DOM Level 2-basierte Prozessoren verarbeitet werden. Für CURIE-Präfixabbildungen mit @prefix-Attribut, MUSS Abschnitt 7.5: Verarbeitungsablauf, Schritt 3 verwendet werden, um Namensraumwerte zu verarbeiten.

Da CURIE-Präfixabbildungen mit @xmlns: angegeben wurden und da HTML-Attributnamen die Groß- und Kleinschreibung nicht beachten, SOLLTEN CURIE-Präfixnamen, die über das @xmlns:attributname-Muster xmlns:<PREFIX>="<URI>" deklariert werden, nur mit Kleinbuchstaben angegeben werden. Zum Beispiel SOLLTE der Text "@xmlns:" und der Text in "<PREFIX>" nur in Kleinbuchstaben angegeben werden. Dies soll sicherstellen, dass die Präfixabbildungen sowohl im Dokumenttyp HTML (keine Beachtung der Groß- und Kleinschreibung in Attributnamen) als auch im Dokumenttyp XHTML (Beachtung der Groß- und Kleinschreibung in Attributnamen) gleich interpretiert werden.

5.2 Konformitätskriterien für Attribute mit Präfix @xmlns:

Da RDFa 1.0-Dokumente Attribute enthalten könnten, die mit @xmlns: beginnen, um CURIE-Präfixe anzugeben, MÜSSEN alle Attribute, die mit der Zeichenkette "@xmlns:" beginnen, unabhängig von deren Groß- und Kleinschreibung, im DOM oder einem anderen baumbasierten Modell erhalten bleiben, wenn das betreffende Modell an den RDFa-Prozessor weitergereicht wird. In Dokumenten, die konform zu dieser Spezifikation sind, MÜSSEN Attribute als konform angenommen werden, die einen Namen "@xmlns:" in jeglicher Form der Groß- und Kleinschreibung enthalten. Konformitätsprüfprogramme SOLLTEN Attributnamen als konform akzeptieren, die ein Präfix "@xmlns:" haben, unabhängig von dessen Groß- und Kleinschreibung. Konformitätsprüfprogramme SOLLTEN Warnungen erzeugen, dass die Verwendung von "@xmlns:" veraltet ist. Konformitätsprüfprogramme KÖNNEN die Verwendung von xmlns: als Fehler melden.

Alle Attribute, die mit einem Präfix "@xmlns:" beginnen, unabhängig von dessen Groß- und Kleinschreibung, MÜSSEN konform zu den Produktionsregeln sein, die in Namensräume in XML [XML-NAMES11], Abschnitt 3: Namensräume deklarieren beschrieben werden. Dokumente, die @xmlns:-Attribute enthalten, die nicht konform zu Namensräume in XML sind, DÜRFEN NICHT als konform akzeptiert werden.

5.3 Namensräume über Coercion zu Infoset erhalten

Einige Autoren von W3C-Spezifikationen erfreuen sich an komplizierten Ausdrücken und Begriffen, die manchmal schwerer zu verstehen sind als ein einfacher Ausdruck, der eine Sache präzise beschreiben würde. Expression of art werden sie gerne genannt. Web-historisch gewachsene Kunstausdrücke.
Coercion ist eines dieser Worte. Coercion ist ein Zwang, in diesem Zusammenhang die Zwangsumwandlung von DOM zu Infoset. Eine Übersetzung ins Deutsche würde die Bedeutung und den Kunstanspruch der Autoren vernachlässigen. – Ob dieser Begriff wirklich eine gute Wahl der Autoren ist, sei der Meinung jedes einzelnen Lesers überlassen.

RDFa 1.0-Dokumente können das @xmlns:-Muster enthalten, um Präfixnamen zu deklarieren. Es ist wichtig, dass Namensrauminformationen, die in einem HTML5-Dokument deklariert sind, das im Nicht-XML-Modus ist, richig auf einem Infoset abgebildet werden. Um sicherzustellen, dass diese Abbildung richtig vollzogen wird, müssen die Regeln aus "Coercing an HTML DOM into an Infoset", die in [HTML5] definiert sind, um die folgende Regel erweitert werden:

Achtet die XML-API auf Namensräume, muss die Anwendung sicherstellen, dass Namensraumtupel ([Namensraumname], [lokaler Name], [normalisierter Wert]) erzeugt werden, wenn das DOM, das im Nicht-XML-Modus ist, in ein Infoset konvertiert wird. Für eine normale @xmlns:-Definition, xmlns:foo="http://example.org/bar#", ist der [Namensraumname] http://www.w3.org/2000/xmlns/, der [lokale Name] foo und der [normalisierte Wert] http://example.org/bar#, daraus folgend wäre das Namensraumtupel (http://www.w3.org/2000/xmlns/, foo, http://example.org/bar#).

Zum Beispiel folgender Eingabetext:

Beispiel 12
<div xmlns:com="https://w3id.org/commerce#">

Das div-Element oben sollte, wenn es von einem HTML-DOM in ein Infoset gezwungen wird, ein Attribut in der Liste [Namensraumattribute] enthalten, dessen [Namensraumname] auf "http://www.w3.org/2000/xmlns/", dessen [lokaler Name] auf com und dessen [normalisierter Wert] auf "https://w3id.org/commerce#" gesetzt ist.

5.4 Infoset-basierte Prozessoren

Während die Absicht hinter den RDFa-Verarbeitungsregeln darin besteht, Regeln anzubieten, die möglichst unabhängig von der Sprache und der Verarbeitungsweise sind, werden zur Vermeidung von Unklarheiten im Folgenden detailierte Methoden angegeben, die zur Extrahierung von RDFa-Inhalten aus Prozessoren führen, die mit einem XML Information Set arbeiten.

5.4.1 URI-Abbildungen aus Infosets extrahieren

Die Extrahierung von URI-Abbildungen, die über @xmlns: deklariert sind, kann mit Hilfe des folgenden Algorithmus erreicht werden, wenn die Verarbeitung mit einem RDFa-Prozessor erfolgt, der auf Infoset basiert:

Während der Verarbeitung eines Elements, wie beschrieben in [RDFA-CORE], Abschnitt 7.5: verarbeitungsablauf,Schritt #2:

  1. Für jedes Attribut in der Liste [Namensraumattribute], das einen [Präfix]wert hat, erzeuge eine [IRI-Abbildung] durch die Speicherung des [Präfix] als den abzubildenden Wert und den [normalisierten Wert] als den Wert, auf den abgebildet wird.
  2. Für jedes Attribut in der Liste der [Attribute], das keinen Wert für [Präfix] hat und einen [lokalen Namen], der mit @xmlns: anfängt, erzeuge eine [IRI-Abbildung] durch Speicherung des [lokalen Namens], aus dem die Zeichen @xmlns: entfernt wurden, als den abzubildenden Wert und den [normalisierten Wert] als den Wert, auf den abgebildet wird.
    Anmerkung

    Dieser Schritt ist unnötig, wenn die Regeln der Infoset-Coercion Namensräume bewahren, die im Nicht-XML-Modus angegeben sind.

Nehmen Sie zum Beispiel an, dass der folgende Quelltext von einem Infoset-basierten RDFa-Prozessor verarbeitet wird:

Beispiel 13
<div xmlns:ps="https://w3id.org/payswarm#" ...

Nachdem der Quelltext verarbeitet wurde, sollte eine [URI-Abbildung] in der [lokalen Liste der URI-Abbildungen] existieren, die eine Abbildung von ps auf https://w3id.org/payswarm# enthält.

5.4.2 Verarbeitung von RDFa-Attributen

Es gibt einige Attribute ohne Präfix, die mit der RDFa-Verarbeitung in HTML5 verbunden sind. Wird ein RDFa-Prozessor verwendet, der auf XML Informations Set basiert, um diese Attribute zu verarbeiten, sollte der folgende Algorithmus verwendet werden, um die Werte der Attribute zu erkennen und zu extrahieren.

Während der Verarbeitung von Infoset Attribute Information Items in Element Information Items wie beschrieben in [RDFA-CORE], Abschnitt 7.5: Verarbeitungsablauf, Schritt #4 bis Schritt #9:

  1. Für jedes Attribute Information Item in der Liste der Infoset-[Attribute], das RDFa betrifft und ein [Präfix] ohne Wert hat, extrahiere und verwende den [normalisierten Wert].

5.5 DOM Level 1 und Level 2-basierte Prozessoren

Die meisten RDFa-Prozessoren, die das DOM kennen, können auf die Methoden von DOM Level 1 [DOM-LEVEL-1] zurückgreifen, um Attribute in Elementen zu verarbeiten. Um alle CURIE-Präfixabbildungen über "@xmlns:" zu finden, kann über die Node.attributes NamedNodeMap iteriert werden. Jeder Attr.name, der mit der Zeichenkette @xmlns: beginnt, gibt eine CURIE-Präfixabbildung an. Der Wert, der abzubilden ist, ist die Zeichenkette nach @xmlns: in der Variable Attr.name und der Wert, auf den abgebildet wird, ist der Wert der Variable Attr.value.

Die Absicht hinter den RDFa-Verarbeitungsregeln besteht darin, Regeln anzubieten, die möglichst unabhängig von der Sprache und dem Verarbeitungsablauf sind. Sollten Entwickler sich dafür entscheiden, den Mechanismus der DOM1-Umgebung nicht zu nutzen, der im vorherigen Abschnitt umrissen ist, können sie den folgenden Mechanismus der DOM2-Umgebung [DOM-LEVEL-2-CORE] nutzen.

5.5.1 URI-Abbildungen über DOM Level 2 extrahieren

Die Extrahierung von URI-Abbildungen, die über @xmlns: deklariert sind, kann mit Hilfe des folgenden Algorithmus erreicht werden, Wenn die Verarbeitung mit einem RDFa-Prozessors erfolgt, der auf DOM Level 2 basiert:

Während der Verarbeitung eines jeden DOM2-[Elements] wie beschrieben in [RDFA-CORE], Abschnitt 7.5: Verarbeitungsablauf, Schritt #2:

  1. Für jedes [Attr] in der Liste [Node.attributes], das einen [Namensraumpräfix]wert @xmlns hat, erzeuge eine [IRI-Abbildung] durch die Speicherung des [lokalen Namens] als den abzubildenden Wert und den [Node.nodeValue] als den Wert, auf dem abgebildet wird.
  2. Für jedes [Attr] in der Liste der [Node.attributes], das einen [Namensraumpräfix]wert Null hat und einen [lokalen Namen], der mit @xmlns: beginnt, erzeuge eine [IRI-Abbildung] durch Speichern des [lokalen Namens]teils ohne die Zeichen für @xmlns: als den abzubildenden Wert und den [Node.nodeValue] als den Wert, auf dem abgebildet wird.
    Anmerkung

    Dieser Schritt ist nicht nötig, falls die DOMs im XML-Modus und im Nicht-XML-Modus namensraumkonsistent sind.

Nehmen Sie zum Beispiel an, dass der folgende Quelltext von einem DOM2-basierten RDFa-Prozessor verarbeitet wird:

Beispiel 14
<div xmlns:com="https://w3id.org/commerce#" ...

Nachdem der Quelltext verarbeitet wurde, sollte eine [URI-Abbildung] in der [lokalen Liste der URI-Abbildungen] existieren, die eine Abbildung von com auf https://w3id.org/commerce# enthält.

5.5.2 Verarbeitung von RDFa-Attributen

Es gibt einige Attribute ohne Präfix, die mit der RDFa-Verarbeitung in HTML5 verknüpft sind. Wird ein DOM2-basierter RDFa-Prozessor verwendet, um diese Attribute zu verarbeiten, sollte der folgende Algorithmus verwendet werden, um die Werte der Attribute zu erkennen und zu extrahieren.

Während der Verarbeitung eines Elements wie beschrieben in [RDFA-CORE], Abschnitt 5.5: Verarbeitungsablauf, Schritt #3 bis Schritt #9:

  1. Für jedes RDFa-Attribut in der Liste der [Node.attributes], das ein [Namensraumpräfix] besitzt, das Null ist, extrahiere und verwende [Node.nodeValue] als den Wert.
Note

Wenn Werte aus @href und @src extrahiert werden, sollten Autoren und Entwickler beachten, dass bestimmte Werte transformiert werden KÖNNTEN, wenn auf sie über das DOM zugegriffen wird, anstatt einem Nicht-DOM-Prozessor zu verwenden. Die Regeln zur Veränderung der URL-Werte können in der Hauptspezifikation HTML5 im Abschnitt 2.5: URLs gefunden werden.

A. Über dieses Dokument

A.1 Geschichte

Dieser Abschnitt ist nicht normativ.

Anfang 2004 veröffentlichte Mark Birbeck ein Dokument namens "RDF in XHTML" über die Arbeitsgruppe XHTML2, in dem er das Fundament für das legte, was einmal RDFa (The Resource Description Framework in Attributes) werden würde.

Im Jahre 2006 wurde die Arbeit von der Arbeitsgruppe Semantic Web Deployment mitgetragen, welche damit begann, die Technologie zum Ausdruck semantischer Daten in XHTML zu formalisieren. Diese Technologie wurde erfolgreich entwickelt und erreichte die Zustimmung beim W3C, um später als offizielle W3C-Empfehlung veröffentlicht zu werden. Während HTML einen Mechanismus zum Ausdruck der Struktur eines Dokuments anbietet (Titel, Absätze, Verweise), bietet RDFa einen Mechanismus, um die Bedeutungen in einem Dokument (Menschen, Orte, Ereignisse) auszudrücken.

Das Dokument namens "RDF in XHTML: Syntax and Processing" [XHTML-RDFA] definierte Attribute und Regeln zur Verarbeitung jener Attribute, die in der Ausgabe von maschinenlesbaren semantischen Daten mündete. Während das Dokument für XHTML gilt, waren die Regeln und Attribute immer dazu vorgesehen, über alle baum-basierten Strukturen zu funktionieren, die Attribute in Baumknoten enthalten (wie HTML4, SVG und ODF).

Während RDFa anfangs zur Verwendung in XHTML bestimmt war, hat die Übernahme von RDFa durch mehrere große Unternehmen im Web die Verwendung von RDFa in Sprachen angetrieben, die eben nicht XHTML sind. Seine Verwendung in HTML4, bevor eine offizielle Spezifikation für diese Sprachen erarbeitet wurde, hat Bedenken bezüglich der Dokumentkonformität erzeugt.

Über die Jahre hatten die Mitglieder der RDFa Community darüber diskutiert, ob die Möglichkeit besteht, die gleichen Attribute und Verarbeitungsregeln, die in der XHTML+RDFa-Spezifikaiton umrissen sind, auch auf alle Dokumente der HTML-Familie anzuwenden. Durch das Design war die Möglichkeit eines Mechnismus für den Ausdruck gemeinsamer semantischer Daten zwischen allen Dokumenten der HTML- und XHTML-Familie reell betrachtet im Bereich des Möglichen.

Im Jahre 2010 wurde eine RDFa-Arbeitsgruppe gegründet, um die Fragen zu erörtern, die eine sprachenübergreifende RDFa-Implementation betreffen. Das XHTML+RDFa-Dokument wurde in eine Grundspezifikation namens RDFa Core 1.1 [RDFA-CORE] aufgeteilt und in feinere Spezifikationen, die über RDFa Core 1.1 liegen. Die XHTML+RDFa 1.1-Spezifikation [XHTML-RDFA] ist ein Beispiel einer solchen feinen Spezifikation. Dieses Dokument, auch eine feine Spezifikation, ist auf HTML4, HTML5 und XHTML5 ausgerichtet.

Dieses Dokument beschreibt die Erweiterung zur Spezifikation RDFa Core 1.1, welche die Verwendung von RDFa in allen Dokumenten der HTML-Familie gestattet. Durch Verwendung der Attribute und Verarbeitungsregeln, die in RDFa Core 1.1 beschrieben sind und Beachtung der kleinen Änderungen in diesem Dokument, können Autoren einen Quelltext erzeugen, der die gleiche semantische Datenausgabe in HTML4, HTML5 und XHTML5 erzeugt.

A.2 Änderungen

Dieser Abschnitt ist nicht normativ.

2009-10-15: Erste Version von RDFa für HTML4, HTML5 and XHTML5.

2010-03-04: Aktualisierte Regeln für HTML5 Coercion zu Infoset, Erhaltung von Namensräumen in Infoset- und DOM2-basierten Prozessoren, klarstellen, wie RDFa-Attribute über Infoset extrahiert werden und wie RDFa-Attribute über DOM2 extrahiert werden.

2010-05-02: Vererbung von grundlegenden Verarbeitungsregeln von RDFa 1.1 [RDFA-CORE], anstatt von XHTML+RDFa 1.0 [RDFA-SYNTAX], Inklusion der voreingestellten Vokabularbegriffe aus HTML, Inklusion einer HTML 4.01 + RDFa 1.1-DTD für Validierungszwecke.

2010-06-24: Vererbung von grundlegenden Verarbeitungsregeln von RDFa 1.1 [RDFA-CORE], anstatt von XHTML+RDFa 1.0 [RDFA-SYNTAX], Inklusion der voreingestellten Vokabularbegriffe aus HTML, HTML 4.01 + RDFa 1.1-DTD für Validierungszwecke hinzugefügt. Normative Definition für das Attribut @version hinzugefügt.

2010-10-19: Entfernen des Attributs @version, HTML-Vokabularbegriffe in ein RDFa-Profil-Dokument migriert, Aussage hinzugefügt, Kommentare an den Bugtracker der Arbeitsgruppe HTML zu schicken.

2011-01-11: Marker für dezentralisierte Erweiterungsprobleme entfernt, Algorithmus zur Extrahierung von Präfixabbildungen in DOM Level 1 hinzugefügt.

2011-04-05: Alle Reglen zu xmlns: in den Abschnitt Rückwärtskompatibilität verschoben und Spezifikation auf einen Stand mit der Spezifikaiton RDFa Core 1.1 gebracht.

2011-05-12: Last Call-Dokument erzeugt, keine substantiellen Veränderungen.

2011-12-30: Zusatz normativer Abhängigkeiten für RDFa Lite 1.1. Regeln hinzugefügt, um die Elemente meta und link im flow- und phrasing-Inhalt zu gestatten, wenn sie mindestens ein RDFa-spezifisches Attribut enthalten. Unterstützung für die Verarbeitung von @datetime und value hinzugefügt.

2012-03-10: Klarstellung, wo jedes RDFa-Attribut verwendet werden darf. Feature at risk-Warnung für DTD-basierte Validierung von HTML4+RDFa.

2012-09-10: Kontrolle über die Veröffentlichung des HTML+RDFa-Dokuments ist von der AG HTML an die wiederbelebte AG RDFa übergeben worden. DTD-basierte Validierung wird von der Spezifikation entfernt.

2012-12-13: Zusatz neuer HTML-spezifischer Verarbeitungsregeln, um sowohl XHTML5- als auch HTML5-Dokumenten gerecht zu werden, xml:base, HTML-Literale, property und rel/rev im gleichen Element, und mehr Typen für das Attribut datetime.

2012-12-27: Abschnitt für Eigenschaftskopieren (Property Copying) hinzugefügt und besondere Verarbeitung für head und body.

2013-01-19: Verarbeitung von @value entfernt, Hinzufügen von @content überschreibt @datetime, wenn vorhanden, aufräumen und Vorbereitung für Last Call-Veröffentlichung in AG RDFa.

2013-06-06: Alle Last Call-Kommentare angewendet und redaktionelle Verbesserungen in Vorbereitung auf die Phase der Vorgeschlagenen Empfehlung.

2013-08-07: Falsche Datumsangaben, schlechte Grammatik verbessert, Status des Dokuments aktualisiert zur Veröffentlichung der Empfehlung.

A.3 Anerkennungen

Dieser Abschnitt ist nicht normativ.

Zur Zeit der Veröffentlichung bestand die RDFa-Arbeitsgruppe aus den Mitgliedern:

Ivan Herman (staff contact), Shane McCarron, Gregg Kellogg, Niklas Lindström, Steven Pemberton, Manu Sporny (Vorsitz), Ted Thibodeau und Stéphane Corlosquet.

Vielen Dank an alle, die Feedback zu der Spezifikation gegeben haben (die meisten sind unten aufgelistet):

Adam Powell, Alex Milowski, Andy Seaborne, Arto Bendiken, Austin William, BAI Xi, Benjamin Adrian, Benjamin Nowack, Bjoern Hoehrmann, Christian Langanke, Christoph Lange, Cindy Lewis, Corey Mwamba, Crisfer Inmobiliaria, Dan Brickley, Daniel Friesen, Dave Beckett, David Wood, D. Grant, Dominik Tomaszuk, Dominique Hazael-Massieux, Doug Schepers, Dr. Olaf , Edward O'Connor, Faye Harris, Felix Sasaki, Gavin Carothers, Grant Robertson, Guus Schreiber, Harry Halpin, Michael Hausenblas, Henri Bergius, Henri Sivonen, Henry Story, Holger Knublauch, Ian Hickson, Irene Celino, Alexander Kroener, Knud Möller, Philip Jägenstedt, Reto Bachmann-Gmür, Ivan Mikhailov, James Leigh, Jeff Sonstein, Jeni Tennison, Jens Haupert, Jochen Rau, John Breslin, John Cowan, John O'Donovan, Jonathan Rees, Julian Reschke, KANZAKI Masahide, Kingsley Idehen, Knud Hinnerk, Landong Zuo, Leif Halvard Silli, Liam R., Lin Clark, Maciej Stachowiak, Mark Nottingham, Markus Gylling, Martin Hepp, Martin McEvoy, Matthias Tylkowski, Darin McBeath, Melvin Carvalho, Michael Chan, Michael Hausenblas, Michael Steidl, Michael™ Smith, Mischa Tuffield, Misha Wolf, Nathan Rixham, Nathan Yergler, Nicholas Stimpson, Noah Mendelsohn, Paul Cotton, Paul Sparrow, Pete Cordell, Peter Frederick, Peter Mika, Peter Occil, Phil Archer, Reece Dunn, Richard Cyganiak, Robert Leif, Robert Weir, Ramanathan V. Guha, Sami Korhonen, Sam Ruby, Sandro Hawke, Sebastian Germesin, Sebastian Heath, Shelley Powers, Simon Grant, Simon Reinhardt, Stefan Schumacher, Tab Atkins Jr., Thomas Adamich, Thomas Baker, Thomas Roessler, Thomas Steiner, Tim Berners-Lee, Toby Inkster, Tom Adamich, Tantek Çelik, Ville Skyttä, Wayne Smith, and Will Clark

B. Quellen

B.1 Normative Quellen

[DOM-LEVEL-1]
Scott Isaacson; Steven B Byrne; Mike Champion; Ian Jacobs; Arnaud Le Hors; Gavin Nicol; Jonathan Robie; Robert S Sutor; Chris Wilson; Lauren Wood et al. Document Object Model (DOM) Level 1. 1. Oktober 1998. W3C-Empfehlung. URL: http://www.w3.org/TR/DOM-Level-1/
[DOM-LEVEL-2-CORE]
Arnaud Le Hors; Philippe Le Hégaret; Lauren Wood; Gavin Nicol; Jonathan Robie; Mike Champion; Steven B Byrne et al. Document Object Model (DOM) Level 2 Core Specification. 13. November 2000. W3C-Empfehlung. URL: http://www.w3.org/TR/DOM-Level-2-Core/
[HTML5]
Robin Berjon et al. HTML5. 6. August 2013. W3C Candidate Recommendation. URL: http://www.w3.org/TR/html5/
[RDFA-CORE]
Ben Adida; Mark Birbeck; Shane McCarron; Ivan Herman et al. RDFa Core 1.1 - Second Edition. 22. August 2013. W3C-Empfehlung. URL: http://www.w3.org/TR/rdfa-core/
[RDFA-LITE]
Manu Sporny. RDFa Lite 1.1. 7. Juni 2012. W3C-Empfehlung. URL: http://www.w3.org/TR/rdfa-lite/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. März 1997. Internet RFC 2119. URL: http://www.ietf.org/rfc/rfc2119.txt
[XML-NAMES11]
Tim Bray; Dave Hollander; Andrew Layman; Richard Tobin et al. Namespaces in XML 1.1 (Second Edition). 16. August 2006. W3C-Empfehlung. URL: http://www.w3.org/TR/xml-names11/

B.2 Informative Quellen

[RDF-CONCEPTS]
Richard Cyganiak, David Wood, Editoren. RDF 1.1 Concepts and Abstract Syntax World Wide Web Consortium (in Bearbeitung). 23. Juli 2013. Last Call Working Draft.
[RDFA-SYNTAX]
Ben Adida; Mark Birbeck; Shane McCarron; Steven Pemberton et al. RDFa in XHTML: Syntax and Processing. 14. Oktober 2008. W3C-Empfehlung. URL: http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014/
[TURTLE]
Eric Prud'hommeaux, Gavin Carothers. Turtle: Terse RDF Triple Language. 19. Februar 2013. W3C Candidate Recommendation. URL: http://www.w3.org/TR/turtle/
[XHTML-RDFA]
Shane McCarron. XHTML+RDFa 1.1 - Second Edition. 22. August 2013. W3C Proposed Edited Recommendation. URL: http://www.w3.org/TR/xhtml-rdfa/