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.
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:
- Der voreingestellte Vokabular-URI ist nicht definiert.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.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:
- Befindet sich das XML-Fragment in einem einzelnen Wurzelelement,
MUSS es als wohlgeformtes XML validieren.
Die normative Sprache, die ein wohlgeformtes XML-Dokument beschreibt, ist im
Abschnitt 2.1 "Wohlgeformte
XML-Dokumente" der XML-Spezifikation angegeben.
- Befindet sich das XML-Fragment in einem einzelnen Wurzelelement,
MUSS es alle aktiven Namensrauminformationen
erhalten. Die aktuell aktiven Attribute, die über
@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:
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:
- 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:
| 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
|
- Schlussendlich verwende diese Regel, um verwendete
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
|
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.
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.3 Namensräume über Coercion zu Infoset erhalten
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:
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.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:
- 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.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:
- 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