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.
ZusammenfassungDiese 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 DokumentsDieser 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.
InhaltsverzeichnisDieser 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ätWie 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ätEs 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.
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.
3.1 Zusätzliche RDFa-VerarbeitungsregelnDokumente, 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.
3.3 Die Sprache für ein Literal bestimmenEntsprechend 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.
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:
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 EigenschaftskopierenNach 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 ?targetrdfa:copy-Angaben und rdfa:Pattern-Quellen vom Ausgabegraphen zu entfernen: Regelname Enthält Ausgabegraph dann entferne pattern-clean ?subject rdfa:copy ?targetAnmerkung
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-SyntaxZur 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:
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.
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-AttributenEs 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.
5.5.2 Verarbeitung von RDFa-AttributenEs 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:
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.
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 ÃnderungenDieser 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 AnerkennungenDieser 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 QuellenRetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3