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.
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.
Copyright © 2009-2013 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. W3C liability, trademark and document use rules apply.
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.
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.
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 [email protected] (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.
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.
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.
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:
<!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]:
[] 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.
Die RDFa-Prozessorkonformitätskriterien sind folgend aufgelistet, alle müssen erfüllt werden:
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:
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.
Dokumente, die zu den Regeln dieser Spezifikation konform sind, werden nach [RDFA-CORE] verarbeitet, mit den folgenden Erweiterungen:
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.base
-Element bestimmt werden. In XHTML5+RDFa 1.1-Dokumenten
kann die
Basis auch
durch das Attribut @xml:base
bestimmt werden.@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.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:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
, or<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.1//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-2.dtd">
, orapplication/xhtml+xml
ausgeliefert werden und keine
DOCTYPE-Deklaration enthalten und kein @version
-Attribut angeben,
MÜSSEN als XHTML5+RDFa 1.1-Dokument interpretiert
werden.@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.
@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.
@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.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.@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.
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.
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.
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.
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.
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:
@xmlns
und
@xmlns:
deklariert wurden, die im aktuellen
Evaluierungskontext
des RDFa-Prozessors in den IRI-Abbildungen
gespeichert sind,
MÜSSEN im erzeugten XMLLiteral erhalten werden.
Der PREFIX-Wert für @xmlns:PREFIX
MUSS vollständig in Kleinbuchstaben umgewandelt
werden, wenn der Wert im XMLLiteral bewahrt wird. Alle aktiven Namensräume, die
über @xmlns
, @xmlns:
und @prefix
deklariert sind,
MÜSSEN in jedem Element der höchsten Ebene im
erzeugten XMLLiteral eingetragen werden ohne zuvor bestehende Namensraumwerte zu
überschreiben.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:
<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:
<> <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:
<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:
<>
<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> .
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:
<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:
<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:
@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:
<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:
@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.
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:
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:
Regelname | Enthält der Ausgabegraph | dann füge hinzu |
---|---|---|
pattern-copy |
?subject rdfa:copy ?target ?target rdf:type rdfa:Pattern ?target ?predicate ?object | ?subject ?predicate ?object |
rdfa:copy
-Angaben
und rdfa:Pattern
-Quellen vom Ausgabegraphen zu
entfernen:
Regelname | Enthält Ausgabegraph | dann 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 |
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.
Alternative Regeln können verwendet werden, um den Ausgabegraphen zu aktualisieren, solange das Ergebnis das gleiche ist.
Zur vollständigen Unterstützung von RDFa wurden einige Attribute als Erweiterungen zur HTML5-Syntax hinzugefügt:
@vocab
, @typeof
,
@property
, @resource
und
@prefix
. Alle anderen Attribute, die RDFa verarbeiten
könnte, wie @href
und @src
, sind nur gestattet,
wenn sie gemäß der HTML5-Spezifikation im Inhaltsmodell für jenes
Element definiert sind.@vocab
,
@typeof
, @property
, @resource
,
@prefix
, @content
, @about
,
@rel
, @rev
, @datatype
und
@inlist
. Alle anderen Attribute, die RDFa verarbeiten
könnte, wie @href
und @src
, sind nur gestattet,
wenn sie gemäß der HTML5-Spezifikation im Inhaltsmodell für jenes
Element definiert sind.@property
in den Elementen
link
oder meta
enthalten, dann MÜSSEN sie als konform angesehen werden, sofern sie im
body
des Dokuments verwendet werden. Insbesondere wenn die
Elemente link
oder meta
das Attribut
@property
enthalten und im body
eines HTML5-Dokuments
verwendet werden, MÜSSEN sie als
fließender Inhalt
(flow content) betrachtet werden.@property
im Element link
enthalten, ist das Attribut @rel
nicht erforderlich.@resource
im Element link
enthalten, ist das Element @href
nicht erforderlich.@property
im Element meta
enthalten, sind weder die Attribute @name
,
@http-equiv
, noch @charset
erforderlich und das
Attribut @content
MUSS
angegeben werden.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.
@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.
@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.
Kommentar des Übersetzers
Einige Autoren von W3C-Spezifikationen bevorzugen komplizierte Ausdrücke
und Begriffe, die manchmal schwer zu verstehen sind. Expression Of Art werden sie
gerne genannt. Web-historisch gewachsene Kunstausdrücke.
Coercion gehört zu diesen Kunstausdrücken. 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:
<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.
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.
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:
@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.
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:
<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.
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:
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.
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:
@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.@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.
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:
<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.
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:
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.
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.
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.
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