Veuillez consulter la page des errata de ce document, laquelle peut contenir des corrections normatives.
Ce document est également disponible dans les formats non normatifs suivants : version PostScript, version PDF, archive ZIP et archive TAR Gzip.
La version anglaise de cette spécification est la seule version normative. Des traductions non normatives sont éventuellement disponibles.
Copyright © 2007-2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
Le Web actuel est principalement composé d'un nombre énorme de documents créés avec HTML. Ces documents contiennent des quantités considérables de données structurées, largement inacessibles aux outils et aux applications. Si les éditeurs pouvaient exprimer plus complètement ces données et les outils les lire, un monde nouveau de fonctionnalités s'ouvrirait aux utilisateurs, en laissant les utilisateurs transférer des données entre les applications et les sites web, et en permettant aux applications de navigation d'améliorer l'expérience d'utilisateur : un événement sur une page web serait directement importé dans une application de calendrier de l'utilisateur ; la licence d'utilisation d'un document serait détectée et les utilisateurs automatiquement informés de leurs droits ; pour une photographie, l'auteur, les paramètres de l'appareil photo, la résolution, le lieu et le sujet seraient publiés aussi facilement que la photo originale elle-même, en permettant les recherches structurées et les échanges.
RDFa est une spécification d'attributs pour exprimer des données structurées dans n'importe quel langage de balisage. Ce document spécifie comment utiliser RDFa avec XHTML. Les données hypertextes rendues de XHTML sont réutilisées par le balisage RDFa, et les éditeurs n'ont donc pas besoin de répéter les données importantes dans le contenu du document. La représentation abstraite sous-jacente est du RDF [RDF-PRIMER], qui laisse les éditeurs construire leur propre vocabulaire, en étendre d'autres et faire évoluer leur vocabulaire avec une interopérabilité maximale dans le temps. La structure exprimées est étroitement liée aux données, de sorte que les données rendues peuvent être copiées et collées en même temps que la structure pertinente.
L'interprétation des données obéit à des règles génériques, et il n'y a donc pas besoin de règles différentes pour d'autres formats ; cela permet aux auteurs et aux éditeurs de données de définir leurs propres formats sans qu'il faille mettre à jour de logiciel, enregistrer des formats auprès d'une autorité centrale, ou s'inquiéter des interférences possibles de deux formats.
RDFa partage quelques cas d'utilisation avec les microformats [MICROFORMATS]. Tandis que les microformats spécifient à la fois une syntaxe pour incorporer des données structurées dans les documents HTML et un vocabulaire de termes spécifiques pour chaque microformat, RDFa spécifie seulement une syntaxe et s'appuie sur les spécifications indépendantes de termes (souvent appelés des vocabulaires ou taxonomies) réalisées par d'autres. RDFa permet de mélanger librement les termes de plusieurs vocabulaires développés indépendamment et est conçu de telle sorte que le langage puisse être analysé sans connaissance du vocabulaire de termes spécifiques utilisé.
Ce document est une spécification de syntaxe détaillée de RDFa qui s'adresse à:
Pour ceux recherchant une introduction à l'utilisation de RDFa et des exemples du monde réel, veuillez consulter l'Introduction à RDFa.
Si vous connaissez déjà RDFa et que vous voulez examiner les règles d'analyse — peut-être pour créer un analyseur — alors la section Modèle de traitement sera du plus grand intérêt. Elle contient une vue d'ensemble de chacune des étapes de traitement, suivie de sections plus détaillées, une pour chaque règle.
Si vous ne connaissez pas RDFa mais connaissez RDF, alors vous trouverez utile de lire la section Vue d'ensemble de la syntaxe avant de passer au Modèle de traitement, puisqu'elle donne un ensemble d'exemples de balisage XHTML utilisant RDFa. Voir quelques exemples d'abord devrait faciliter la lecture des règles de traitement.
Si vous ne connaissez pas RDF, alors vous jetterez un œil à la section Terminologie RDF avant d'aller plus loin avec RDFa. Bien que RDFa soit conçu pour faciliter la création — et les auteurs n'ont pas besoin de comprendre RDF pour l'employer, quiconque écrit des applications consommant du RDFa devra comprendre RDF. Il y a beaucoup de documentation pour RDF sur le Web, et une gamme croissante d'outils compatibles avec RDFa, donc tout ce que nous essayons de faire dans ce document est de fournir une base RDF suffisante pour éclaircir les objectifs de RDFa.
Enfin, si vous ne connaissez ni RDFa ni RDF, et souhaitez simplement ajouter du RDFa à vos documents, alors l'introduction à RDFa [RDFaPRIMER] sera peut-être un meilleur choix.
Cette section décrit le statut de ce document au moment de sa publication. D'autres documents peuvent venir le remplacer. On trouvera la liste des publications actuelles du W3C et la dernière révision de ce rapport technique dans l'index des rapports techniques du W3C à http://www.w3.org/TR/.
Ce document qui a été revu par des membres du W3C, par des développeurs de logiciels, d'autres groupes du W3C et des tiers intéressés est approuvé par le Directeur comme recommandation du W3C. C'est un document stable qui être utilisé comme document de référence ou cité par un autre document. Le rôle du W3C en produisant la recommandation est d'attirer l'attention sur la spécification et d'en promouvoir le large déploiement. Cela participe à la fonctionnalité et à l'interopérabilité du Web.
Les membres du public sont invités à envoyer les commentaires sur cette recommandation à public-rdf-in-xhtml-tf@w3.org (avec des archives publiques).
Un exemple d'infrastructure de test est disponible. Cet ensemble de tests n'est pas exhaustif. Les utilisateurs verront peut-être dans ces tests des exemples pratiques d'utilisation de RDFa. Un rapport de mise en œuvre liste plusieurs mises en œuvre de cette spécification testées au cours de la période de recommandation candidate. Une page wiki tenue par la communauté contient les mises à jour ultérieures.
Ce document a été produit conjointement par le groupe de travail Semantic Web Deployment et le groupe de travail XHTML 2 sous l'égide de l'activité Semantic Web et de l'activité HTML. Il contient des modifications éditoriales mineures suite aux commentaires reçus au cours de la révision de la recommandation proposée ; cf. la version marquée en différence (diff-marked) pour des détails.
Ce document a été produit par des groupes agissant sous couvert de la politique de brevet du W3C du 5 février 2004. Le W3C tient une liste publiques des divulgations de brevet effectuées en rapport avec les produits livrables du groupe de travail XHTML 2 ainsi qu'une liste publique des divulgations de brevet effectuées en rapport avec les produits livrables du groupe de travail Semantic Web Deployment ; ces pages contiennent également des instructions pour divulguer un brevet. Quiconque a connaissance réelle d'un brevet qu'il estime contenir des revendications essentielles doit divulguer cette information conformément à la section 6 de la politique de brevet du W3C.
Cette section est informative.
Le langage RDF/XML [RDF-SYNTAX] offre suffisamment de flexibilité pour représenter tous les concepts abstraits en RDF [RDF-CONCEPTS]. Néanmoins, il présente de nombreux défis ; d'abord il est difficile voire impossible de valider les documents contenant du RDF/XML en utilisant des schémas XML Schema ou des définitions DTD, ce qui rend donc difficile l'import de RDF/XML dans d'autres langages de balisage. Bien que des langages de schéma nouveaux tels que RELAX NG [RELAXNG] permettent effectivement de valider les documents contenant du RDF/XML arbitraire, il faudra attendre encore longtemps avant qu'ils ne soient largement adoptés.
Deuxièmement, même si on pouvait ajouter du RDF/XML directement dans un dialecte XML comme XHTML, il y aurait recopie importante des données entre les données rendues et les données à structure RDF/XML. Il serait de beaucoup préférable d'ajouter le RDF à un document sans répéter les données existantes du document. Par exemple, un document XHTML qui rend (render) explicitement le nom de son auteur dans le texte — peut-être comme une signature (byline) sur un site de nouvelles — ne devrait pas avoir besoin de répéter ce nom pour l'expression RDF du même concept : on devrait pouvoir compléter le balisage existant de telle façon qu'il puisse aussi être interprété comme RDF.
Une autre raison d'aligner les données rendues sur les données structurées est qu'il est très avantageux d'exprimer la structure de données du web « dans le contexte » ; comme les utilisateurs veulent souvent transférer les données structurées d'une application à une autre, parfois vers ou depuis une application non-Web, l'expérience d'utilisateur peut s'en trouver améliorée. Par exemple, on pourrait présenter à l'utilisateur des informations à propos des données rendues spécifiques via des « clics droits » sur un élément d'intérêt.
Auparavant, beaucoup d'attributs étaient « câblés » (hard-wired) directement dans le langage de balisage pour représenter des concepts spécifiques. Par exemple, dans XHTML 1.1 [XHTML11] et HTML [HTML4] il y a l'attribut @cite ; celui-ci permet à l'auteur d'ajouter des informations à un document utilisé pour indiquer l'origine d'une citation.
Toutefois, ces attributs « câblés » rendent difficile la définition d'un processus générique pour extraire les métadonnées d'un document puisque l'analyseur aurait besoin de connaître chacun des attributs spéciaux. Une motivation de RDFa a été de concevoir un moyen par lequel ajouter des métadonnées à un document d'une manière générale plutôt que câblée. On y est parvenu en créant un ensemble fixe d'attributs et de règles d'analyse, tout en laissant ces attributs contenir des propriétés issues du nombre croissant de vocabulaires RDF disponibles. Dans la plupart des cas, les valeurs de ces propriétés sont les informations qui sont déjà dans le document XHTML d'un auteur.
RDFa réduit la pression sur les auteurs de formats XML d'anticiper toutes les exigences structurelles que pourraient avoir les utilisateurs de leurs formats, en dessinant une nouvelle syntaxe de RDF qui s'appuie seulement sur des attributs XML. Cette spécification traite spécifiquement de l'utilisation de RDFa dans XHTML, et définit une liaison RDF (RDF mapping) pour plusieurs attributs XHTML, mais on peut facilement importer RDFa dans d'autres langages de balisage fondés sur XML.
Cette section est informative.
Les exemples suivants sont destinés à aider les lecteurs non familiarisés avec RDFa à se faire rapidement une idée de son fonctionnement. Pour une introduction plus complète, veuillez consulter l'Introduction à RDFa [RDFaPRIMER].
Pour la lisibilité, dans ces exemples et à travers ce document, supposez que les préfixes de vocabulaire suivants ont été définis :
biblio: | http://example.org/biblio/0.1 |
cc: | http://creativecommons.org/ns# |
dbp: | http://dbpedia.org/property/ |
dbr: | http://dbpedia.org/resource/ |
dc: | http://purl.org/dc/elements/1.1/ |
ex: | http://example.org/ |
foaf: | http://xmlns.com/foaf/0.1/ |
rdf: | http://www.w3.org/1999/02/22-rdf-syntax-ns# |
rdfs: | http://www.w3.org/2000/01/rdf-schema# |
taxo: | http://purl.org/rss/1.0/modules/taxonomy/ |
xhv: | http://www.w3.org/1999/xhtml/vocab# |
xsd: | http://www.w3.org/2001/XMLSchema# |
RDFa dans XHTML utilise plusieurs attributs XHTML et en fournit quelques uns en plus. Les attributs qui existent déjà en XHTML auront la même signification qu'en XHTML, quoique leur syntaxe puisse être légèrement modifiée. Par exemple, dans XHTML, @rel définit déjà la relation entre un document et un autre. En revanche, dans XHTML, il n'existe pas de méthode claire d'ajouter de nouvelles valeurs ; le langage RDFa se propose de résoudre explicitement ce problème et le fait en admettant des adresses URI comme valeurs. Il introduit également le concept d'« adresse URI compacte » — appelée adresse CURIE dans ce document — qui permet d'exprimer une valeur URI complète de manière concise.
Les attributs XHTML pertinents sont les suivants :
Les nouveaux atttributs — spécifiques de RDFa — sont les suivants :
Pour une définition normative de ces attributs, cf. le module des attributs de métainformation XHTML.
En tant qu'auteur XHTML, vous connaissez déjà l'utilisation des attributs meta
et link
pour ajouter d'autres informations à vos documents :
<html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Page 7</title> <meta name="author" content="Mark Birbeck" /> <link rel="prev" href="page6.html" /> <link rel="next" href="page8.html" /> </head> <body>...</body> </html>
RDFa emploie ce concept, en l'améliorant par la capacité d'utiliser d'autres vocabulaires avec des adresses URI compactes :
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:foaf="http://xmlns.com/foaf/0.1/" xmlns:dc="http://purl.org/dc/elements/1.1/" > <head> <title>My home-page</title> <meta property="dc:creator" content="Mark Birbeck" /> <link rel="foaf:topic" href="http://www.formsPlayer.com/#us" /> </head> <body>...</body> </html>
Quoique peu employé, XHTML gère l'utilisation des attributs @rel et @rev
sur l'élément a
. Cela se révèle plus utile dans RDFa qui ajoute la gestion de vocabulaires différents :
This document is licensed under a <a xmlns:cc="http://creativecommons.org/ns#" rel="cc:license" href="http://creativecommons.org/licenses/by-nc-nd/3.0/"> Creative Commons License </a>.
Non seulement les adresses URL dans le document peuvent être réutilisées pour fournir des métadonnées mais aussi le texte inclus (inline text) :
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:cal="http://www.w3.org/2002/12/cal/ical#" > <head><title>Jo's Friends and Family Blog</title></head> <body> <p> I'm holding <span property="cal:summary"> one last summer Barbecue </span>, on September 16th at 4pm. </p> </body> </html>
Si un texte affiché est différent de la « valeur » réelle qu'il représente, on peut ajouter des valeurs plus précises, qui peuvent inclure en option des types de données :
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:cal="http://www.w3.org/2002/12/cal/ical#" xmlns:xsd="http://www.w3.org/2001/XMLSchema" > <head><title>Jo's Friends and Family Blog</title></head> <body> <p> I'm holding <span property="cal:summary"> one last summer Barbecue </span>, on <span property="cal:dtstart" content="2007-09-16T16:00:00-05:00" datatype="xsd:dateTime"> September 16th at 4pm </span>. </p> </body> </html>
Souvent, un bloc de balisage contiendra plusieurs propriétés qui se rapportent au même élément (item) ; il est possible avec RDFa d'indiquer le type de cet élément :
<html
xmlns="http://www.w3.org/1999/xhtml"
xmlns:cal="http://www.w3.org/2002/12/cal/ical#"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
>
<head><title>Jo's Friends and Family Blog</title></head>
<body>
<p typeof="cal:Vevent">
I'm holding
<span property="cal:summary">
one last summer Barbecue
</span>,
on
<span property="cal:dtstart" content="2007-09-16T16:00:00-05:00"
datatype="xsd:dateTime">
September 16th at 4pm
</span>.
</p>
</body>
</html>
Les fonctionnalités de métadonnée disponibles dans XHTML permettent seulement d'exprimer une information à propos du document même. RDFa permet au document de contenir des informations de métadonnée à propos d'autres documents et ressources :
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:biblio="http://example.org/" xmlns:dc="http://purl.org/dc/elements/1.1/" > <head> <title>Books by Marco Pierre White</title> </head> <body> I think White's book '<span about="urn:ISBN:0091808189" typeof="biblio:book" property="dc:title"> Canteen Cuisine </span>' is well worth getting since although it's quite advanced stuff, he makes it pretty easy to follow. You might also like <span about="urn:ISBN:1596913614" typeof="biblio:book" property="dc:description"> White's autobiography </span>. </body> </html>
Cette section est informative.
La section précédente donnait des exemples de balisage typique afin d'illustrer à quoi ressemble RDFa dans du XHTML. Mais ce que le RDFa dans XHTML représente est du RDF. Pour créer du RDFa dans XHTML, il n'est pas nécessaire de comprendre RDF, quoique ça puisse sûrement aider. En revanche, si vous bâtissez un système qui consomme la sortie RDF du code RDFa dans un document XHTML, vous serez pratiquement dans l'obligation de comprendre RDF. Dans cette section, nous introduisons les concepts de base et la terminologie de RDF. Pour une explication plus approfondie de RDF, veuillez consulter le document des concepts RDF [RDF-CONCEPTS] et le document de la syntaxe RDF [RDF-SYNTAX].
Les données structurées auxquelles RDFa donne accès est une collection de déclarations (statements). Une déclaration est une unité d'information de base construite dans un format spécifique pour en faciliter le traitement. À leur tour, en cassant les grands ensembles d'informations en une collection de déclarations, on peut traiter des métadonnées même très complexes en utilisant des règles simples.
Pour l'illustrer, supposons que nous ayons l'ensemble de faits suivant :
Albert was born on March 14, 1879, in Germany. There is a picture of him at the web address, http://en.wikipedia.org/wiki/Image:Albert_Einstein_Head.jpg.
Une machine aurait beaucoup de difficulté à traiter ces informations et elles ne sont certainement pas dans un format que l'on pourrait passer d'une application de données à une autre. Par contre, si nous convertissons l'information en un ensemble de déclarations, elle devient plus facile à manier. La même information pourrait ainsi être représentée par les « déclarations » plus courtes suivantes :
Albert was born on March 14, 1879. Albert was born in Germany. Albert has a picture at http://en.wikipedia.org/wiki/Image:Albert_Einstein_Head.jpg.
Pour que cette information puisse être interprétée par une machine, RDF définit la structure de ces déclarations. Une déclaration est appelée formellement un [triplet] (triple), indiquant qu'elle est constituée de trois composants. Le premier est le sujet du triple, à propos duquel nous faisons nos déclarations. Dans tous ces exemples, le sujet est "Albert".
La deuxième partie d'un triplet est la propriété du sujet que nous voulons définir. Ici dans les exemples, les propriétés seraient « est né le » (was born on), « est né en » (was born in) et « a une photo à » (has a picture at). On les appelle habituellement des prédicats en RDF.
La dernière partie d'un triplet est appelée l'objet. Ici, les trois objets ont les valeurs "March 14, 1879", "Germany" et "http://en.wikipedia.org/wiki/Image:Albert_Einstein_Head.jpg".
Casser une information complexe en unités manipulables nous aide à être plus spécifiques à propos de nos données, mais il reste toujours des ambiguïtés. Par exemple, de quel « Albert » parlons-nous ? Si un autre système détient plus de faits à propos d'Albert, comment pourrions-nous savoir s'ils concernent la même personne, et donc les ajouter à la liste des choses que nous connaissons à propos de cette personne ? Si nous voulions trouver des personnes nées en Allemagne, comment pourrions-nous savoir que le prédicat « est né en » a le même but que le prédicat « lieu de naissance » qui existerait dans un autre système ? RDF résoud ce problème en remplaçant nos termes vagues par des références URI (URI references).
Les adresses URI sont plus couramment utilisées pour identifier des pages web, mais RDF les utilise comme un moyen de fournir des identificateurs uniques pour des concepts. Par exemple, nous pourrions identifer le sujet de toutes nos déclarations (la première partie de chaque triplet) en utilisant l'adresse URI DBPedia [http://dbpedia.org] pour Albert Einstein, au lieu de la chaîne "Albert", ambiguë :
<http://dbpedia.org/resource/Albert_Einstein> has the name Albert Einstein. <http://dbpedia.org/resource/Albert_Einstein> was born on March 14, 1879. <http://dbpedia.org/resource/Albert_Einstein> was born in Germany. <http://dbpedia.org/resource/Albert_Einstein> has a picture at http://en.wikipedia.org/wiki/Image:Albert_Einstein_Head.jpg.
Les références URI servent aussi à identifier uniquement les objets dans les déclarations de métadonnée (la troisième partie de chaque triplet). La photo d'Einstein est déjà une adresse URI, mais nous pourrions également utiliser une adresse URI pour identifier uniquement le pays Allemagne. En même temps, nous indiquerons que le nom et la date de naissance sont en réalité des littéraux (et non des adresses URI), en les plaçant entre des guillemets :
<http://dbpedia.org/resource/Albert_Einstein> has the name "Albert Einstein". <http://dbpedia.org/resource/Albert_Einstein> was born on "March 14, 1879". <http://dbpedia.org/resource/Albert_Einstein> was born in <http://dbpedia.org/resource/Germany>. <http://dbpedia.org/resource/Albert_Einstein> has a picture at <http://en.wikipedia.org/wiki/Image:Albert_Einstein_Head.jpg>.
Les références URI sont également utilisables pour s'assurer que les prédicats soient univoques ; nous pouvons maintenant être sûrs que « birthplace », « place of birth », « Lieu de naissance », et ainsi de suite, signifient tous la même chose :
<http://dbpedia.org/resource/Albert_Einstein> <http://xmlns.com/foaf/0.1/name> "Albert Einstein". <http://dbpedia.org/resource/Albert_Einstein> <http://dbpedia.org/property/dateOfBirth> "March 14, 1879". <http://dbpedia.org/resource/Albert_Einstein> <http://dbpedia.org/property/birthPlace> <http://dbpedia.org/resource/Germany>. <http://dbpedia.org/resource/Albert_Einstein> <http://xmlns.com/foaf/0.1/depiction> <http://en.wikipedia.org/wiki/Image:Albert_Einstein_Head.jpg>.
Bien que l'on utilise toujours des ressources URI pour les sujets et les prédicats, la partie objet d'un triplet peut être soit une adresse URI, soit un [littéral] (literal). Dans les triplets en exemple, le nom d'Einstein est représenté par un [littéral ordinaire] (plain literal), signifiant qu'il s'agit d'une chaîne de base sans information de type ou de langue :
<http://dbpedia.org/resource/Albert_Einstein>
<http://xmlns.com/foaf/0.1/name> "Albert Einstein".
Certains littéraux, tels que les dates et les nombres, ont des significations très spécifiques, et ainsi RDF fournit
un mécanisme pour indiquer le type d'un littéral. Un [littéral typé] (typed literal)
est indiqué en attachant une adresse URI à la fin d'un [littéral ordinaire],
et cette adresse URI indique le type de donnée du littéral. Habituellement, cette adresse se fonde sur les types de données
définis dans la spécification des types de données XML Schema [XMLSCHEMA].
On utiliserait la syntaxe suivante pour exprimer sans ambiguïté la date de naissance d'Einstein comme étant un littéral de type http://www.w3.org/2001/XMLSchema#date
:
<http://dbpedia.org/resource/Albert_Einstein>
<http://dbpedia.org/property/dateOfBirth> "1879-03-14"^^<http://www.w3.org/2001/XMLSchema#date>.
Le langage RDF en soi n'a pas de méthode établie pour exprimer des triplets, puisque les concepts clés de RDF sont le triplet et l'utilisation d'adresses URI, et non une quelconque syntaxe particulière. Toutefois, il existe plusieurs mécanismes pour exprimer des triplets, tels que RDF/XML, Turtle [TURTLE] et bien sûr RDFa. Beaucoup de discussions de RDF emploient la syntaxe Turtle pour expliquer leurs idées, car elle est très compacte. Les exemples que nous venons de voir utilisent déjà cette syntaxe, et nous continuerons de l'utiliser tout au long de ce document lorsque nous aurons besoin de parler du RDF qui serait généré à partir de RDFa. Turtle permet d'abréger les adresses URI longues en utilisant une liaison URI (URI mapping), que l'on peut utiliser pour exprimer une adresse URI compacte comme suit :
@prefix dbp: <http://dbpedia.org/property/> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . <http://dbpedia.org/resource/Albert_Einstein> foaf:name "Albert Einstein" . <http://dbpedia.org/resource/Albert_Einstein> dbp:birthPlace <http://dbpedia.org/resource/Germany> .
Ici le préfixe dbp: a été associé à l'adresse URI de DBPedia, et foaf: à l'adresse URI de la taxonomie Friend of a Friend.
On pourrait abréger toute adresse URI dans Turtle de cette façon. Cela signifie que nous aurions également pu employer la même technique pour abréger l'identificateur d'Einstein ainsi que l'indicateur de type de données :
@prefix dbp: <http://dbpedia.org/property/> . @prefix dbr: <http://dbpedia.org/resource/> . @prefix foaf: <http://xmlns.com/foaf/0.1/> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . dbr:Albert_Einstein dbp:dateOfBirth "1879-03-14"^^xsd:date . dbr:Albert_Einstein foaf:depiction <http://en.wikipedia.org/wiki/Image:Albert_Einstein_Head.jpg> .
Dans l'écriture des exemples, vous verrez souvent l'adresse URI suivante dans la représentation Turtle :
<>
Elle indique le « document courant », c'est-à-dire le document en cours de traitement. En réalité, il y aura toujours une adresse URI fondée sur l'adresse du document, mais cette abréviation sert à rendre les exemples plus compacts. Notez en particulier que la technique d'abréviation dans son ensemble est simplement un moyen de rendre les exemples plus compacts, et les triplets réels générés utiliseront toujours les adresses URI complètes.
Une collection de triplets est appelée un graphe (graph).
Pour plus de renseignements sur les concepts décrits ci-dessus, cf. [RDF-CONCEPTS]. RDFa définit en plus les termes suivants :
Pour l'expression compacte des déclarations RDF, RDFa permet la contraction de toutes les [références URI] dans une forme appelée une « adresse URI compacte » (compact URI), ou adresse CURIE. On trouvera une discussion détaillée de ce mécanisme à la section Traitement des adresses CURIE et URI.
Notez que les adresses CURIE sont seulement utilisées dans le balisage et les exemples Turtle, et elles n'apparaîtront jamais dans les [triplet] générés, lesquels sont définis en RDF pour utiliser des [références URI].
Nous détaillerons le traitement des adresses CURIE à la section intitulée Traitement des adresses CURIE et URI.
Une tendance croissante dans l'utilisation des métadonnées incorporées est de prendre des fragments de balisage pour les déplacer d'un document à l'autre. Cela peut avoir lieu au travers d'outils, tels que le glisser-déposer (drag-and-drop) dans un navigateur, ou au travers de petits bouts (snippets) de code fournis aux auteurs pour inclure dans leurs documents. (Un bon exemple de ce dernier type est le fragment de licence fourni par Creative Commons).
Toutefois, ceux impliqués dans la création de fragments (soit en construisant des outils, soit en créant des bouts de code) devraient savoir que cette spécification ne dit pas comment traiter les fragments de XHTML+RDFa pendant qu'ils se trouvent « à l'extérieur » d'un document XHTML+RDFa (quoique des versions futures de cette spécification ou de spécifications liées puissent le faire).
Les développeurs d'outils qui traitent des fragments, ou les auteurs de fragments à inclure manuellement, devraient également garder à l'esprit ce qu'il adviendra de leurs fragments une fois ceux-ci inclus dans un document XHTML+RDFa, et sont invités à évaluer soigneusement la quantité d'information de « contexte » qui sera nécessaire pour assurer une interprétation correcte des fragments.
Voici une brève description de RDFa d'après la terminologie RDF introduite ici. Elle peut être utile aux lecteurs ayant une expérience en RDF :
Le but de RDFa est de permettre le portage d'un seul [graphe RDF] (RDF graph) dans plusieurs types de balisage de document. Toutefois, cette spécification ne traite que de RDFa dans XHTML. Un [graphe RDF] comprend des [nœuds] (nodes) liés par des relations. L'unité de base d'un [graphe RDF] est le [triplet], dans lequel un [nœud] sujet est lié à un [nœud] objet via un [prédicat] (predicate). Le [nœud] [sujet] est toujours soit une [référence URI], soit un [nœud anonyme] (bnode), le [prédicat] est toujours une [référence URI] et l'objet d'une déclaration peut être une [référence URI], un [littéral] ou un [nœud anonyme].
Dans RDFa, une [référence URI] sujet est généralement indiquée par l'attribut @about, et les prédicats sont représentés par l'un des attributs @property, @rel ou @rev. Les objets qui sont des [références URI] sont représentés par les attributs @href, @resource ou @src, tandis que les objets qui sont des [littéraux] sont représentés soit par l'attribut @content, soit par le contenu de l'élément en question (avec un type de données optionnel exprimé avec l'attribut @datatype).
Cette section est normative.
Les mots-clés « DOIT », « NE DOIT PAS », « OBLIGATOIRE », « DEVRA », « NE DEVRA PAS », « DEVRAIT », « RECOMMANDÉ », « PEUT » et « OPTIONNEL » dans ce document doivent s'interpréter comme décrit dans le document [RFC2119].
Notez que tous les exemples dans ce document sont informatifs et ne sont pas à interpréter comme des exigences normatives.
Un document XHTML+RDFa strictement conforme est un document qui n'exige que les facilités décrites comme obligatoires dans cette spécification. Un tel document satisfait aux critères suivants :
Le document DOIT respecter les contraintes exprimées dans les schémas de l'Annexe A — Définition de type de document XHTML+RDFa ;
La partie locale de l'élément racine du document DOIT être « html
» ;
La balise ouvrante de l'élément racine du document DOIT contenir explicitement une
déclaration d'espace de noms par défaut pour l'espace de noms XHTML [XMLNS].
L'adresse URI d'espace de noms de XHTML est « http://www.w3.org/1999/xhtml
» ;
Exemple d'élément racine :
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
html
avec la valeur "XHTML+RDFa 1.0
"Exemple de document XHTML+RDFa 1.0 :
<?xml version="1.0" encoding="UTF-8"?> <html xmlns="http://www.w3.org/1999/xhtml" version="XHTML+RDFa 1.0" xml:lang="en"> <head> <title>Virtual Library</title> </head> <body> <p>Moved to <a href="http://example.org/">example.org</a>.</p> </body> </html>
Notez ici que la déclaration XML est incluse. Une déclaration XML telle que la précédente n'est pas obligatoire dans tous les documents XML. Les auteurs de documents XHTML DEVRAIENT employer des déclarations XML dans tous leurs documents. Les auteurs de documents XHTML DOIVENT utiliser une déclaration XML lorsque le codage des caractères du document est différent du codage UTF-8 par défaut ou du codage UTF-16, et qu'aucun codage n'est spécifié par un protocole de niveau supérieur.
Les documents XHTML+RDFa DEVRAIENT être étiquetés avec le type de média Internet "application/xhtml+xml" comme défini dans [RFC3236]. Pour d'autres renseignements sur l'utilisation des types de média avec les langages de balisage de la famille XHTML, cf. la note informative [XHTMLMIME].
Un agent utilisateur conforme DOIT gérer toutes les fonctionnalités exigées dans cette spécification. Un agent utilisateur conforme DOIT également supporter les exigences de conformité de l'agent utilisateur telles que définies dans la Modularisation XHTML [XHTMLMOD], section Conformité de l'agent utilisateur de la famille XHTML.
Un processeur RDFa conforme DOIT fournir, à une application consommatrice, un seul [graphe RDF] contenant tous les triplets possibles générés en utilisant les règles de la section Modèle de traitement. Cette spécification emploie le terme [graphe par défaut] (default graph) pour indiquer tous les triplets affirmés par un document, conformément à la section Modèle de traitement.
Un processeur RDFa conforme PEUT fournir des triplets supplémentaires utilisant des règles non décrites ici, mais ces triplets NE DOIVENT PAS apparaître dans le [graphe par défaut]. (Que la fourniture de ces triplets supplémentaires ait lieu dans un ou plusieurs [graphes RDF] supplémentaires dépend de la mise en œuvre, et elle n'est donc pas définie ici.)
Puisque XHTML+RDFa est fondé sur la modularisation XHTML [XHTMLMOD], et que la modularisation XHTML impose de conserver les caractères blancs (whitespace), les processeurs conformes DOIVENT les conserver dans les [littéraux ordinaires] et les [littéraux XML] (XML literals). Toutefois, il peut arriver que l'architecture dans laquelle agit le processeur ne mette pas à disposition tous les caractères blancs. Il est donc conseillé aux auteurs, qui voudraient que leurs documents soient consommables à travers des processeurs différents, de supprimer tous les caractères blancs superflus dans leur balisage.
Cette section est normative.
Cette section examine un ensemble générique de règles de traitement pour la création d'un jeu de triplets représentant les données structurées présentes dans un document XHTML+RDFa. Le traitement n'est pas obligé de suivre la technique de traversée DOM indiquée ici, à condition que l'effet d'un autre traitement soit le même que si le traitement exposé ici avait été suivi. Le modèle de traitement est expliqué en utilisant le concept de la traversée DOM (DOM traversal) qui rend sa description plus facile (particulièrement en regard du [contexte d'évaluation]).
L'analyse d'un document à la recherche de triplets RDFa commence à l'objet document puis se poursuit en visitant chacun de ses éléments fils (child elements) à son tour, dans l'ordre du document, en appliquant les règles de traitement. Le traitement est récursif en cela que pour chaque élément fils le processeur visite également chacun de ses sous-éléments et applique les mêmes règles de traitement.
(Notez que dans certains environnements, il y aura peu de différences à commencer à l'élément racine du document ou à commencer à l'objet document lui-même. Quoiqu'il en soit, nous le définissons de cette manière puisque dans certains environnements des informations importantes sont présentes au niveau de l'objet document, qui ne le sont pas sur l'élément racine).
Au fur et à mesure du traitement, des règles sont appliquées qui peuvent générer des triplets et aussi changer l'information de [contexte d'évaluation] qui sera utilisée ensuite pour le traitement des éléments descendants.
Remarquez que nous ne disons rien sur ce qui devrait advenir des triplets générés, ou s'il faudrait générer plus de triplets qu'exposés ici pendant le traitement. En revanche, pour être conforme, un processeur RDFa doit agir au moins comme si les règles de cette section étaient appliquées, et un seul [graphe RDF] produit. Comme décrit à la section Conformité du processeur RDFa, les triplets supplémentaires qui seraient générés NE DOIVENT PAS apparaître dans le [graphe par défaut].
Pendant le traitement, chaque règle est appliquée en utilisant les informations fournies par un [contexte d'évaluation]. Un contexte initial est créé au début du traitement, avec l'ensemble de valeurs suivant :
base
. Ce qui importe c'est qu'elle établisse
une adresse URL par rapport à laquelle les chemins relatifs peuvent être résolus ;Au cours du traitement, de nouveaux [contextes d'évaluation] sont créés et passés à chaque sous-élément. Les règles décrites ci-dessous détermineront les valeurs des éléments (items) dans le contexte. De plus, d'autres règles provoqueront la création de nouveaux triplets en combinant les informations fournies par un élément et celles du [contexte d'évaluation].
Pendant le traitement, un certain nombre de valeurs à visibilité locale sont nécessaires, ainsi :
RDFa a la notion de [chaînage] qui vise à combiner les déclarations d'une façon aussi intuitive que possible, afin d'éviter des répétitions de balisage superflues. Par exemple, si un auteur devait ajouter des déclarations comme enfants d'un objet qui est une ressource, ces déclarations seraient interprétées comme liées à cette ressource :
<div about="http://dbpedia.org/resource/Albert_Einstein"> <span property="foaf:name">Albert Einstein</span> <span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span> <div rel="dbp:birthPlace" resource="http://dbpedia.org/resource/Germany"> <span property="dbp:conventionalLongName">Federal Republic of Germany</span> </div> </div>
Dans cet exemple, nous pouvons voir qu'une ressource objet (Germany) est devenue le sujet de déclarations imbriquées. Ce balisage illustre aussi le modèle de chaînage de base de « A a un B a un C » (c'est-à-dire, Einstein a pour le lieu de naissance Germany, qui a pour nom long "Federal Republic of Germany").
Le sujet de déclarations imbriquées a aussi la possibilité de fournir l'objet de déclarations contenantes — essentiellement le symétrique de l'exemple que nous venons de voir. Afin de l'illustrer, nous prendrons l'exemple du type de chaînage juste décrit et montrerons comment on pourrait le baliser plus efficacement. Pour commencer, nous marquons le fait qu'Albert Einstein avait à la fois les nationalités allemande et américaine :
<div about="http://dbpedia.org/resource/Albert_Einstein"> <div rel="dbp:citizenship" resource="http://dbpedia.org/resource/Germany"></div> <div rel="dbp:citizenship" resource="http://dbpedia.org/resource/United_States"></div> </div>
Maintenant, nous montrons la même information mais cette fois en créant un [triplet incomplet] à partir de la partie nationalité (citizenship) puis un nombre quelconque d'autres sujets pour « compléter » ce triplet, comme suit :
<div about="http://dbpedia.org/resource/Albert_Einstein" rel="dbp:citizenship"> <span about="http://dbpedia.org/resource/Germany"></span> <span about="http://dbpedia.org/resource/United_States"></span> </div>
Dans cet exemple, le [triplet incomplet] est en réalité complété deux fois, une fois pour l'Allemagne et une fois pour les États-Unis, en donnant exactement les mêmes informations que celles de l'exemple précédent :
<http://dbpedia.org/resource/Albert_Einstein> dbp:citizenship <http://dbpedia.org/resource/Germany> . <http://dbpedia.org/resource/Albert_Einstein> dbp:citizenship <http://dbpedia.org/resource/United_States> .
Le chaînage fait parfois intervenir des éléments contenant relativement peu de balisage, par exemple en ne montrant qu'une seule
ressource, ou qu'un seul prédicat. Ici l'élément img
sert à porter une photographie d'Einstein :
<div about="http://dbpedia.org/resource/Albert_Einstein"> <div rel="foaf:depiction"> <img src="http://en.wikipedia.org/wiki/Image:Albert_Einstein_Head.jpg" /> </div> </div>
Lorsqu'un tel balisage minimal est employé, n'importe lequel des attributs liés à la ressource peut faire office de sujet ou d'objet dans le chaînage :
<div about="http://dbpedia.org/resource/Albert_Einstein"> <div rel="dbp:citizenship"> <span about="http://dbpedia.org/resource/Germany"></span> <span about="http://dbpedia.org/resource/United_States"></span> </div> </div>
Puisque RDFa est en définitive un moyen pour transporter du RDF, puis un concept clé est une ressource et sa manifestation comme adresse URI. Puique RDF traite des adresses URI complètes (et non des chemins relatifs), alors pour convertir le RDFa en triplets, toutes les adresses URI relatives devront être résolues par rapport à l'adresse URI de base, en utilisant l'algorithme défini dans le document RFC 3986 [URI], section 5 Résolution des références.
Beaucoup d'attributs qui portent des adresses URI peuvent aussi porter des « adresses URI compactes », ou adresses CURIE. Une adresse CURIE est un moyen commode de représenter une adresse URI longue, en remplaçant une section de tête de l'adresse URI par un atome de substitution. Les auteurs ont la possibilité de définir plusieurs atomes de substitution comme bon leur semblent ; l'adresse URI complète est obtenue en recherchant l'association définie par un atome dans la liste des atomes visibles (in-scope tokens) puis en concaténant simplement la deuxième partie de l'adresse CURIE à la valeur associée.
Par exemple, l'adresse URI pour Albert Einstein sur DPPedia est la suivante :
http://dbpedia.org/resource/Albert_Einstein
Les auteurs peuvent la raccourcir pour en faciliter la manipulation en utilisant une adresse CURIE. La première étape pour l'auteur est de créer une liaison de préfixe qui associe un préfixe à un segment de tête de l'adresse URI. Dans RDFa, ces liaisons sont exprimées avec la syntaxe des espaces de noms XML :
<div xmlns:db="http://dbpedia.org/">
...
</div>
Le préfixe une fois établi, l'auteur peut alors l'utiliser pour raccourcir une adresse URI comme ceci :
<div xmlns:db="http://dbpedia.org/">
<div about="[db:resource/Albert_Einstein]">
...
</div>
</div>
L'auteur est libre de rompre l'adresse URI en tout point, tant qu'elle commence à l'extrémité gauche. Toutefois, puisqu'une utilisation courante des adresses CURIE est de mettre à disposition des bibliothèques de termes et de valeurs, le préfixe sera habituellement associé au segment commun offrant le plus grand réemploi, souvent fourni par les personnes gérant la bibliothèque de termes. Par exemple, puisque DBPedia contient une liste considérable de ressources, il vaut mieux créer une liaison de préfixe qui utilise l'adresse de base des ressources :
<div xmlns:dbr="http://dbpedia.org/resource/"> <div about="[dbr:Albert_Einstein]"> ... </div> <div about="[dbr:Baruch_Spinoza]"> ... </div> </div>
Puisque les liaisons CURIE sont créées par les auteurs via la syntaxe des espaces de noms XML [XMLNS], le processeur RDFa DOIT tenir compte de la nature hiérarchique des déclarations de préfixe. Par exemple, les adresses URI exprimées par les deux adresses CURIE suivantes sont différentes, malgré un préfixe commun, parce que les liaisons de préfixe ont une visibilité locale :
<div xmlns:dbr="http://dbpedia.org/resource/"> <div about="[dbr:Albert_Einstein]"> ... </div> </div> <div xmlns:dbr="http://someotherdb.org/resource/"> <div about="[dbr:Albert_Einstein]"> ... </div> </div>
Puisqu'une adresse CURIE est simplement une méthode d'abréviation d'une adresse URI, sa valeur est une adresse URI, plutôt que la forme abrégée. Obtenir une adresse URI à partir d'une adresse CURIE implique les étapes suivantes :
L'utilisation des adresses CURIE par les attributs se fera de plusieurs façons, et leur traitement sera différent. Les voici :
curie
, selon la Définition de la syntaxe CURIE,
DOIT être ignorée ; cela signifie non seulement qu'il y n'aura pas de signalisation d'erreur mais aussi que
le processeur RDFa devrait agir comme si la valeur n'existait tout simplement pas ;safe_curie
à la section Définition de la syntaxe CURIE,
sera traitée comme s'il s'agissait d'une adresse URI. Si la valeur est contenue entre des crochets, alors elle doit être
conforme à la production curie
, sinon, comme précédemment, la valeur DOIT être ignorée.Un exemple d'attribut qui peut contenir des valeurs CURIE et non-CURIE est celui de @about. Comme décrit, toutes les adresses CURIE exprimées dans l'attribut doivent respecter le format d'une [adresse CURIE sûre] (safe CURIE). Donc, pour exprimer directement une adresse URI, l'auteur devrait faire ceci :
<div about="http://dbpedia.org/resource/Albert_Einstein">
...
</div>
tandis que pour exprimer une adresse CURIE, il ferait cela :
<div about="[dbr:Albert_Einstein]">
...
</div>
Puisque les valeurs non-CURIE DOIVENT être ignorées, cette valeur-ci dans l'attribut @about n'établira pas de nouveau sujet, puisque l'adresse CURIE n'a pas de séparateur de préfixe :
<div about="[Albert_Einstein]">
...
</div>
Par contre, ce balisage étabira un sujet, puisque ce n'est pas une adresse CURIE mais une adresse URI relative :
<div about="Albert_Einstein">
...
</div>
Il existe une exception à ça : les attributs @rel et @rev peuvent aussi accepter une valeur de la liste donnée à la section L'attribut rel, et toute valeur correspondante DOIT être traitée comme s'il s'agissait d'une adresse URI complète avec le vocabulaire XHTML en préfixe de liaison. Ceci est expliqué en détail dans la section suivante.
La règle générale expliquée à la section précédente s'applique aux attributs RDFa des façons suivantes :
Notez que, contrairement aux attributs @about et @resource, les attributs @rel et @rev ne différencient pas leurs deux types de données en utilisant des [adresses CURIE sûres]. Plutôt, toute valeur qui correspond à une entrée dans la liste des types de lien à la section L'attribut rel DOIT être traitée comme s'il s'agissait d'une adresse URI au sein du vocabulaire XHTML, et toutes les autres valeurs doivent être des adresses CURIE. Cela signifie que l'un ou l'autre des exemples suivants :
<link rel="next" href="http://example.org/page2.html" /> <link rel="xhv:next" href="http://example.org/page2.html" />
générera ce triplet :
<> <http://www.w3.org/1999/xhtml/vocab#next> <http://example.org/page2.html> .
Notez que seules les valeurs dans la liste des types de lien ont ce comportement spécial, ce qui signifie qu'une valeur non dans la liste et non une adresse CURIE valide NE DOIT PAS générer de triplets dans le [graphe par défaut]. Par exemple, le balisage suivant ne générerait aucun triplet dans le [graphe par défaut] :
<link rel="foobar" href="http://example.org/page7.html" />
Dans RDFa, il est possible d'établir des relations en utilisant divers types de références de ressource, dont les [nœuds anonymes] (bnodes). Si un sujet ou un objet est défini avec une adresse CURIE et que cette adresse nomme explicitement un [nœud anonyme], alors un analyseur conforme DOIT créer le nœud anonyme quand il est rencontré au cours de l'analyse. L'analyseur DOIT également s'assurer qu'aucun des nœuds anonymes créés automatiquement (en résultat d'un [chaînage]) n'ait un nom qui entre en conflit avec les noms anonymes définis par référence explicite dans une adresse CURIE.
Soit l'exemple suivant :
<link about="[_:john]" rel="foaf:mbox" href="mailto:john@example.org" /> <link about="[_:sue]" rel="foaf:mbox" href="mailto:sue@example.org" /> <link about="[_:john]" rel="foaf:knows" resource="[_:sue]" />
Dans ce fragment, deux nœuds sont créés explicitement comme sujet de triplets. Ces nœuds anonymes sont référencés ensuite pour démontrer les relations entre les parties. Après traitement, les triples suivants seront générés :
_:john foaf:mbox <mailto:john@example.org> . _:sue foaf:mbox <mailto:sue@example.org> . _:john foaf:knows _:sue .
Le traitement commence normalement après le chargement complet du document à analyser. Quoiqu'il en soit, ce n'est pas obligatoire,
et il est tout à fait possible d'utiliser une approche de flux (stream-based approach),
telle que SAX [http://en.wikipedia.org/wiki/SAX], pour extraire l'information RDFa. Toutefois, si on suit une autre approche
que la technique de traversée du DOM définie ici, il importe de s'assurer que les éléments meta
ou
link
, traités dans la tête (head
) du document, honorent les éléments base
qui peuvent apparaître
après ces éléments. (En d'autres termes, les règles de traitement XHTML doivent toujours être appliquées, même si
le traitement du document a lieu dans un environnement non-HTML tel qu'un indexeur de recherche).
Au début du traitement, un [contexte d'évaluation] initial est créé, comme suit :
base
si présent ;
base
.
Si un autre dialecte XML supportant @xml:base implémente RDFa,
un analyseur RDFa conforme pour ce langage hôte traitera vraisemblablement @xml:base et utilisera
sa valeur pour établir la [base].Le traitement commence par l'application des règles de traitement en-dessous de l'objet document, dans le cadre de son [contexte d'évaluation] initial. Tous les éléments dans l'arbre sont également traités selon les règles décrites ci-dessous, d'abord en profondeur, même si le [contexte d'évaluation] utilisé pour chaque ensemble de règles sera fondé sur les règles précédentes qui auront été appliquées.
Les règles de traitement sont les suivantes :
Si aucune adresse URI n'est fournie par un attribut de ressource, alors la première règle correspondante suivante s'appliquera :
head
ou body
, alors agir comme si un attribut @about vide était présent,
et le traiter conformément à la règle pour @about, ci-dessus ;Si aucune adresse URI n'est fournie, alors la première règle correspondante suivante s'appliquera :
head
ou body
, alors agir comme si un attribut @about
était présent, et le traiter conformément à la règle pour @about ci-dessus ;Ensuite la [ressource objet courante] prend l'adresse URI obtenue à la première règle correspondante suivante :
Notez que la valeur finale de la [ressource objet courante] sera soit la valeur nulle (de l'initialisation), soit une adresse URI complète.
rdf:XMLLiteral
".Le littéral réel est la valeur de l'attribut @content (si présent) ou une chaîne créée en concaténant la valeur de tous les nœuds de texte descendants de l'[élément courant] chacune à leur tour. La chaîne finale inclut l'adresse URI du type de données, comme décrit dans [RDF-CONCEPTS], qui aura été obtenue selon la section Traitement des adresses CURIE et URI.
En outre, s'il y a une valeur de [langue courante], alors la valeur du [littéral ordinaire] devrait inclure cette information de langue, comme décrit dans [RDF-CONCEPTS]. Le littéral réel est la valeur de l'attribut @content (si présent) ou une chaîne créée en concaténant le contenu textuel de chacun des éléments descendants de l'[élément courant] dans l'ordre du document.
rdf:XMLLiteral
".La valeur du [littéral XML] est une chaîne créée en sérialisant en texte
tous les nœuds descendants de l'[élément courant], c'est-à-dire sans inclure l'élément en question
et en lui attribuant le type de données rdf:XMLLiteral
.
Le [littéral objet courant] est alors utilisé avec chaque prédicat pour générer un triplet comme suit :
Une fois le triplet créé, si le [type de donnée] du
[littéral objet courant] est rdf:XMLLiteral
,
alors le drapeau de [récursion] est mis à « faux ».
Cette section est normative.
Cette section examine en profondeur les étapes du traitement décrites précédemment. Elle inclut également des exemples qui pourront éclairer quelques unes des étapes concernées.
La clé du traitement est qu'un triplet est généré à chaque fois qu'une combinaison prédicat/objet est détectée. Le triplet réel généré incluera un sujet qui aura pu être établi précédemment, qui est donc stocké dans le [contexte d'évaluation] courant et appelé le [sujet parent]. Puisque par défaut le sujet se résoud au document courant s'il n'a pas été établi explicitement, une combinaison prédicat/objet est donc toujours suffisante pour générer un ou plusieurs triplets.
Les attributs pour établir un prédicat sont @rel, @rev et @property, tandis que les attributs pour établir un objet sont @resource, @href, @content et @src. L'attribut @typeof est particulier en cela qu'il établit en même temps à la fois un prédicat et un objet (et aussi un sujet s'il apparaît en absence d'autres attributs qui seraient susceptibles d'établir un sujet). Un contenu inclus (inline content) peut également établir un objet, si @content est absent mais que @property est présent.
Lorsque les triplets sont créés, ils sont toujours en relation avec une ressource sujet fournie soit par le [nouveau sujet] (s'il y a des règles sur l'élément courant qui ont établi un sujet), soit par le [sujet parent], tels qu'ils sont passés via le [contexte d'évaluation]. Cette section examine les voies spécifiques par lesquelles ces valeurs sont établies. Notez que la façon dont on arrive au sujet n'a pas d'importance, ainsi dans cette section nous employons l'idée du [sujet courant] qui peut être soit le [nouveau sujet], soit le [sujet parent].
Au début de l'analyse, le [sujet courant] sera l'adresse URI du document
analysé, ou une valeur établie par l'élément base
selon les règles de traitement XHTML normales.
Cela signifie que toute métadonnée trouvée dans l'élément head
du document concernera le document même :
<html> <head> <title>Jo's Friends and Family Blog</title> <link rel="foaf:primaryTopic" href="#bbq" /> <meta property="dc:creator" content="Jo" /> </head> <body> ... </body> </html>
Les triplets suivants seraient générés :
<> foaf:primaryTopic <#bbq> . <> dc:creator "Jo" .
Les données peuvent apparaître ailleurs dans le document :
<html>
<head>
<title>Jo's Blog</title>
</head>
<body>
<h1><span property="dc:creator">Jo</span>'s blog</h1>
<p>
Welcome to my blog.
</p>
</body>
</html>
ce qui générerait toujours le triplet :
<> dc:creator "Jo" .
La valeur de l'élément base
peuvent changer la valeur initiale du [sujet courant] :
<html>
<head>
<base href="http://www.example.org/jo/blog" />
<title>Jo's Friends and Family Blog</title>
<link rel="foaf:primaryTopic" href="#bbq" />
<meta property="dc:creator" content="Jo" />
</head>
<body>
...
</body>
</html>
Un analyseur générerait alors les triplets suivants, indépendamment de l'adresse URL à laquelle le document XHTML est servi :
<http://www.example.org/jo/blog> foaf:primaryTopic <#bbq> . <http://www.example.org/jo/blog> dc:creator "Jo" .
Au fur et à mesure du traitement, tous les attributs @about changeront le [sujet courant].
La valeur de l'attribut @about est une adresse URI ou CURIE. Si c'est une adresse URI relative,
elle doit être résolue par rapport à la valeur [base] courante. Pour illustrer la façon dont cela affecte
les déclarations, dans le balisage suivant, notez comment les propriétés dans l'élément body
vont faire partie d'un
nouvel événement de calendrier, au lieu de se rapporter au document comme elles le font dans la tête du document :
<html> <head> <title>Jo's Friends and Family Blog</title> <link rel="foaf:primaryTopic" href="#bbq" /> <meta property="dc:creator" content="Jo" /> </head> <body> <p about="#bbq" typeof="cal:Vevent"> I'm holding <span property="cal:summary"> one last summer barbecue </span>, on <span property="cal:dtstart" content="2007-09-16T16:00:00-05:00" datatype="xsd:dateTime"> September 16th at 4pm </span>. </p> </body> </html>
Pour ce balisage, un analyseur générerait les triplets suivants :
<> foaf:primaryTopic <#bbq> . <> dc:creator "Jo" . <#bbq> rdf:type cal:Vevent . <#bbq> cal:summary "one last summer barbecue" . <#bbq> cal:dtastart "2007-09-16T16:00:00-05:00"^^xsd:dateTime .
D'autres types de ressources sont utilisables pour établir le [sujet courant], pas uniquement des références de pages web. Même si ce n'est pas conseillé, on pourrait utiliser des adresses électroniques pour représenter une personne :
John knows <a about="mailto:john@example.org" rel="foaf:knows" href="mailto:sue@example.org">Sue</a>. Sue knows <a about="mailto:sue@example.org" rel="foaf:knows" href="mailto:jim@example.org">Jim</a>.
Les triplets suivants seraient générés :
<mailto:john@example.org> foaf:knows <mailto:sue@example.org> . <mailto:sue@example.org> foaf:knows <mailto:jim@example.org> .
De même, les auteurs peuvent faire des déclarations à propos d'images :
<div about="photo1.jpg">
this photo was taken by
<span property="dc:creator">Mark Birbeck</span>
</div>
ce qui générerait les triplets suivants :
<photo1.jpg> dc:creator "Mark Birbeck" .
Si l'attribut @about est absent, l'attribut @src est alors le suivant dans l'ordre de priorité pour établir le sujet d'une déclaration. Une utilisation typique serait d'indiquer le type de licence d'une image :
<img src="photo1.jpg" rel="license" resource="http://creativecommons.org/licenses/by/2.0/" />
Puisqu'il n'y a aucune différence entre @src et @about, alors on pourrait exprimer l'information exprimée dans le dernier exemple de la section sur @about (le créateur de l'image) comme suit :
<img src="photo1.jpg"
rel="license" resource="http://creativecommons.org/licenses/by/2.0/"
property="dc:creator" content="Mark Birbeck"
/>
Puisque les règles de chaînage normales s'appliquent, on peut aussi utiliser l'adresse URL de l'image pour compléter les triplets en attente :
<div about="http://www.blogger.com/profile/1109404" rel="foaf:img">
<img src="photo1.jpg"
rel="license" resource="http://creativecommons.org/licenses/by/2.0/"
property="dc:creator" content="Mark Birbeck"
/>
</div>
Le balisage complet produit trois triplets :
<http://www.blogger.com/profile/1109404> foaf:img <photo1.jpg> . <photo1.jpg> xhv:license <http://creativecommons.org/licenses/by/2.0/> . <photo1.jpg> dc:creator "Mark Birbeck" .
Alors que l'attribut @about crée explicitement un nouveau contexte pour les déclarations,
l'attribut @typeof le fait implicitement. L'attribut @typeof fonctionne différemment
des autres méthodes de création d'un prédicat, puisque le prédicat est toujours rdf:type
, ce qui signifie que le processeur
n'exige qu'un seul attribut, la valeur du type.
Puisque @typeof établit le type d'un élément, cela veut dire que si l'élément n'existe pas, il en serait automatiquement créé un. C'est-à-dire de générer un nouveau nœud anonyme, ce que l'on approfondira plus loin ; on le mentionne ici parce que le nœud anonyme utilisé par le nouvel élément deviendra le sujet d'autres déclarations.
Par exemple, l'auteur souhaitera peut-être créer un balisage pour une personne en utilisant le vocabulaire FOAF, mais sans disposer d'un identificateur clair pour l'élément :
<div typeof="foaf:Person">
<span property="foaf:name">Albert Einstein</span>
<span property="foaf:givenname">Albert</span>
</div>
Ce balisage entraînera la création d'un nœud anonyme ayant pour « type » foaf:Person
, ainsi que des
propriétés de nom et de prénom :
_:a rdf:type foaf:Person . _:a foaf:name "Albert Einstein" . _:a foaf:givenname "Albert" .
_:a
et les distinguer de celles de
_:b
. Mais en n'exposant pas ces valeurs aux logiciels externes, il est possible d'avoir un contrôle complet de l'identificateur,
et d'éviter que ne soient faites d'autres déclarations à propos de l'élément.Comme décrit dans les deux sections précédentes, l'attribut @about sera toujours prioritaire et marquera un nouveau sujet, mais si aucune valeur @about n'est disponible, alors l'attribut @typeof fera le même travail, quoiqu'en utilisant un identificateur implicite, c'est-à-dire un nœud anonyme.
Mais si ni @about ni @typeof ne sont présents, il existe plusieurs moyens de parvenir au sujet. L'un d'eux est d'« hériter » du sujet de la déclaration contenante, la valeur à hériter étant fixée explicitement ou implicitement.
La méthode la plus courante d'établir un sujet hérité serait celle où la déclaration parente a un objet qui est une ressource. En revenant à un exemple précédent, dans lequel s'ajoutait le nom long de l'Allemagne (Germany), on utilisait le balisage suivant :
<div about="http://dbpedia.org/resource/Albert_Einstein">
<span property="foaf:name">Albert Einstein</span>
<span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span>
<div rel="dbp:birthPlace" resource="http://dbpedia.org/resource/Germany" />
<span about="http://dbpedia.org/resource/Germany"
property="dbp:conventionalLongName">Federal Republic of Germany</span>
</div>
Dans une illustration précédente, le sujet et l'objet pour Germany étaient élidés en supprimant l'attribut @resource, en s'appuyant sur l'attribut @about pour établir l'objet :
<div about="http://dbpedia.org/resource/Albert_Einstein">
<span property="foaf:name">Albert Einstein</span>
<span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span>
<div rel="dbp:birthPlace">
<span about="http://dbpedia.org/resource/Germany"
property="dbp:conventionalLongName">Federal Republic of Germany</span>
</div>
</div>
Mais les auteurs peuvent aussi obtenir le même effet en supprimant l'attribut @about et en laissant l'attribut @resource :
<div about="http://dbpedia.org/resource/Albert_Einstein">
<span property="foaf:name">Albert Einstein</span>
<span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span>
<div rel="dbp:birthPlace" resource="http://dbpedia.org/resource/Germany">
<span property="dbp:conventionalLongName">Federal Republic of Germany</span>
</div>
</div>
Dans cette situation, toutes les déclarations « contenues » par la ressource objet représentant Germany (la valeur dans @resource) auront le même sujet, facilitant l'ajout de déclarations supplémentaires pour les auteurs :
<div about="http://dbpedia.org/resource/Albert_Einstein">
<span property="foaf:name">Albert Einstein</span>
<span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span>
<div rel="dbp:birthPlace" resource="http://dbpedia.org/resource/Germany">
<span property="dbp:conventionalLongName">Federal Republic of Germany</span>
<span rel="dbp:capital" resource="http://dbpedia.org/resource/Berlin" />
</div>
</div>
En regardant les triplets qui seraient générés par un analyseur, nous pouvons voir qu'il y a en réalité deux groupes de déclarations ; le premier groupe se rapporte à l'attribut @about qui les contient :
<http://dbpedia.org/resource/Albert_Einstein> foaf:name "Albert Einstein" . <http://dbpedia.org/resource/Albert_Einstein> dbp:dateOfBirth "1879-03-14"^^xsd:date . <http://dbpedia.org/resource/Albert_Einstein> dbp:birthPlace <http://dbpedia.org/resource/Germany> .
tandis que le deuxième groupe se rapporte à l'attribut @resource qui les contient :
<http://dbpedia.org/resource/Germany> dbp:conventionalLongName "Federal Republic of Germany" . <http://dbpedia.org/resource/Germany> dbp:capital <http://dbpedia.org/resource/Berlin> .
Notez aussi que le même principe décrit ici s'applique aux attributs @src et @href.
Il y aura des occasions où l'auteur voudra élider le sujet et l'objet comme montré ci-dessus, sans se soucier de nommer la ressource qui est commune aux deux déclarations (c'est-à-dire l'objet de la première déclaration, qui est le sujet de la deuxième). Par exemple, on aurait pu tout aussi bien utiliser le balisage suivant pour indiquer qu'Einstein était influencé par Spinoza :
<div about="http://dbpedia.org/resource/Baruch_Spinoza" rel="dbp:influenced"> <div about="http://dbpedia.org/resource/Albert_Einstein"> <span property="foaf:name">Albert Einstein</span> <span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span> </div> </div>
L'analyseur devrait générer les triplets suivants :
<http://dbpedia.org/resource/Baruch_Spinoza> dbp:influenced <http://dbpedia.org/resource/Albert_Einstein> . <http://dbpedia.org/resource/Albert_Einstein> foaf:name "Albert Einstein" . <http://dbpedia.org/resource/Albert_Einstein> dbp:dateOfBirth "1879-03-14"^^xsd:date .
Néanmoins, l'auteur pouvait tout aussi simplement dire que Spinoza avait influencé quelque chose nommée Albert Einstein, née le 14 mars 1879 :
<div about="http://dbpedia.org/resource/Baruch_Spinoza" rel="dbp:influenced"> <div> <span property="foaf:name">Albert Einstein</span> <span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span> </div> </div>
En terme RDF, l'élément qui « représente » Einstein est anonyme, puisqu'il n'a pas d'adresse URI pour l'identifier. Quoiqu'il en soit, l'élément reçoit un nœud anonyme généré automatiquement, et c'est sur cet identificateur que s'attachent les déclarations filles (child statements) :
L'analyseur devrait générer les triplets suivants :
<http://dbpedia.org/resource/Baruch_Spinoza> dbp:influenced _:a . _:a foaf:name "Albert Einstein" . _:a dbp:dateOfBirth "1879-03-14"^^xsd:date .
Notez que l'élément div
est superflu, et l'analyseur devrait créer l'objet intermédiaire même si l'élément est supprimé :
<div about="http://dbpedia.org/resource/Baruch_Spinoza" rel="dbp:influenced"> <span property="foaf:name">Albert Einstein</span> <span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span> </div>
Un modèle alternatif est de garder l'élément div
et de déplacer l'attribut @rel sur lui :
<div about="http://dbpedia.org/resource/Baruch_Spinoza">
<div rel="dbp:influenced">
<span property="foaf:name">Albert Einstein</span>
<span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span>
</div>
</div>
Du point de vue du balisage, cette dernière forme est à privilégier, puisque elle attire l'attention sur l'« attribut rel en attente » (pending rel). Mais du point de vue d'un analyseur, cela impose de gérer toutes ces permutations.
Lorsqu'un nouveau sujet est calculé, il sert également à compléter les triplets incomplets en attente. Cette situation se produit lorsque l'auteur veut « chaîner » plusieurs déclarations. Par exemple, l'auteur pourrait faire une déclaration selon laquelle Albert Einstein est né en Allemagne :
<div about="http://dbpedia.org/resource/Albert_Einstein">
<span property="foaf:name">Albert Einstein</span>
<span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span>
<div rel="dbp:birthPlace" resource="http://dbpedia.org/resource/Germany" />
</div>
puis une autre déclaration selon laquelle le « nom long » pour Germany est Federal Republic of Germany :
<span about="http://dbpedia.org/resource/Germany" property="dbp:conventionalLongName">Federal Republic of Germany</span>
RDFa permet aux auteurs d'insérer cette déclaration comme une unité autonome dans d'autres contextes :
<div about="http://dbpedia.org/resource/Albert_Einstein">
<span property="foaf:name">Albert Einstein</span>
<span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span>
<div rel="dbp:birthPlace" resource="http://dbpedia.org/resource/Germany" />
<span about="http://dbpedia.org/resource/Germany"
property="dbp:conventionalLongName">Federal Republic of Germany</span>
</div>
Mais cela permet également aux auteurs d'éviter les répétitions inutiles et de « normaliser » les identificateurs en double, ici celui de Germany :
<div about="http://dbpedia.org/resource/Albert_Einstein">
<span property="foaf:name">Albert Einstein</span>
<span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span>
<div rel="dbp:birthPlace">
<span about="http://dbpedia.org/resource/Germany"
property="dbp:conventionalLongName">Federal Republic of Germany</span>
</div>
</div>
Lorsque cela se produit, l'attribut @rel du « lieu de naissance » est vu comme un « attribut rel en attente » parce qu'il n'a pas encore généré de triplets, mais ces « triplets incomplets » sont complétés par l'attribut @about qui apparaît à la ligne suivante. La première étape est donc de stocker les deux parties du triplets que l'analyseur possède effectivement mais sans objet :
<http://dbpedia.org/resource/Albert_Einstein> dbp:birthPlace ? .
Puis le traitement se poursuivant, l'analyseur rencontre le sujet de la déclaration à propos du nom long pour Germany, qui est utilisé de deux façons. D'abord pour compléter les « triplets incomplets » :
<http://dbpedia.org/resource/Albert_Einstein> dbp:birthPlace <http://dbpedia.org/resource/Germany> .
deuxièmement, pour générer son propre triplet :
<http://dbpedia.org/resource/Germany> dbp:conventionalLongName "Federal Republic of Germany" .
Notez que chaque apparition de @about complètera tous les triplets incomplets. Par exemple, pour marquer le fait qu'Albert Einstein avait les deux nationalités allemande et américaine, l'auteur n'a besoin de spécifier qu'une seule valeur @rel qui est ensuite utilisée avec plusieurs valeurs @about :
<div about="http://dbpedia.org/resource/Albert_Einstein" rel="dbp:citizenship"> <span about="http://dbpedia.org/resource/Germany" /> <span about="http://dbpedia.org/resource/United_States" /> </div>
Dans cet exemple, il y a un triplet incomplet :
<http://dbpedia.org/resource/Albert_Einstein> dbp:citizenship ? .
Lorsque le processeur rencontre chacune des valeurs @about, ce triplet est complété, en donnant :
<http://dbpedia.org/resource/Albert_Einstein> dbp:citizenship <http://dbpedia.org/resource/Germany> . <http://dbpedia.org/resource/Albert_Einstein> dbp:citizenship <http://dbpedia.org/resource/United_States> .
Ces exemples montrent comment @about complète les triplets, mais il y a d'autres situations qui peuvent produire le même effet. Par exemple, lorsque @typeof crée un nouveau nœud anonyme (comme décrit précédemment), il sera utilisé pour compléter les « triplets incomplets ». Pour l'illustrer, on pourrait utiliser le balisage suivant pour indiquer que Spinoza a influencé Einstein et Schopenhauer :
<div about="http://dbpedia.org/resource/Baruch_Spinoza"> <div rel="dbp:influenced"> <div typeof="foaf:Person"> <span property="foaf:name">Albert Einstein</span> <span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span> </div> <div typeof="foaf:Person"> <span property="foaf:name">Arthur Schopenhauer</span> <span property="dbp:dateOfBirth" datatype="xsd:date">1788-02-22</span> </div> </div> </div>
D'abord, on stocke le triplet incomplet suivant :
<http://dbpedia.org/resource/Baruch_Spinoza> dbp:influenced ? .
Ensuite, lorsque l'analyseur traite les deux apparitions de @typeof, chacune génère un nœud anonyme, qui est utilisé à la fois pour compléter les « triplets incomplets » et pour établir le sujet des déclarations suivantes :
<http://dbpedia.org/resource/Baruch_Spinoza"> dbp:influenced _:a . _:a rdf:type foaf:Person . _:a foaf:name "Albert Einstein" . _:a dbp:dateOfBirth "1879-03-14"^^xsd:date . <http://dbpedia.org/resource/Baruch_Spinoza"> dbp:influenced _:b . _:b rdf:type foaf:Person . _:b foaf:name "Arthur Schopenhauer" . _:b dbp:dateOfBirth "1788-02-22"^^xsd:date .
Les triplets sont également « complétés » en présence d'un attribut @property, @rel ou @rev. En revanche, contrairement à la situation où @about ou @typeof sont présents, tous les prédicats sont attachés à un seul nœud anonyme :
<div about="http://dbpedia.org/resource/Baruch_Spinoza" rel="dbp:influenced"> <span property="foaf:name">Albert Einstein</span> <span property="dbp:dateOfBirth" datatype="xsd:date">1879-03-14</span> <div rel="dbp:citizenship"> <span about="http://dbpedia.org/resource/Germany" /> <span about="http://dbpedia.org/resource/United_States" /> </div> </div>
Cet exemple recèle deux « attributs rel en attente », et donc deux situations où des « triplets incomplets » seront créés. Le traitement se poursuivra ainsi ; d'abord, le stockage d'un triplet incomplet :
<http://dbpedia.org/resource/Baruch_Spinoza> dbp:influenced ? .
Ensuite, l'analyseur traite les valeurs de prédicat de foaf:name, dbp:dateOfBirth et dbp:citizenship, mais notez que seul le premier a besoin de compléter l'« attribut rel en attente ». Le traitement de foaf:name génère donc deux triplets :
<http://dbpedia.org/resource/Baruch_Spinoza> dbp:influenced _:a . _:a foaf:name "Alber Einstein" .
mais le traitement de dbp:dateOfBirth n'en génère qu'un seul :
_:a dbp:dateOfBirth "1879-03-14"^^xsd:date .
Le traitement de dbp:citizenship utilise également le même nœud anonyme, mais notez qu'il génère aussi son propre « triplet incomplet » :
_:a dbp:citizenship ? .
Comme auparavant, les deux apparitions de @about complètent le « triplet incomplet », une fois chaque :
_:a dbp:citizenship <http://dbpedia.org/resource/Germany> . _:a dbp:citizenship <http://dbpedia.org/resource/United_States> .
Le jeu entier des triplets que l'analyseur devrait générer est le suivant :
<http://dbpedia.org/resource/Baruch_Spinoza> dbp:influenced _:a . _:a foaf:name "Alber Einstein" . _:a dbp:dateOfBirth "1879-03-14"^^xsd:date . _:a dbp:citizenship <http://dbpedia.org/resource/Germany> . _:a dbp:citizenship <http://dbpedia.org/resource/United_States> .
Bien que les objets aient été abordés dans les sections précédents, pour l'explication de la résolution des sujets, du chaînage, des contextes d'évaluation, etc., ils seront examinés en détails dans cette section.
Il y a deux types d'objet : les [ressources URI] et les [littéraux].
On peut établir un objet [littéral] en utilisant l'attribut @property pour exprimer un [prédicat], puis en utilisant soit l'attribut @content, soit le texte inclus (inline text) dans l'élément où se trouve l'attribut @property. Notez que l'emploi de @content interdit l'inclusion de balisage riche dans le littéral. Si le contenu textuel d'un élément représente exactement l'objet, alors les documents devraient s'y tenir plutôt que de recopier ces données en utilisant l'attribut @content.
On peut établir un objet [ressource URI] en utilisant l'un des attributs @rel ou @rev pour exprimer un [prédicat], puis en utilisant soit l'un des attributs @href, @resource ou @src pour fournir explicitement une ressource objet, soit les techniques de chaînage décrites précédemment pour obtenir un objet à partir d'un sujet imbriqué ou d'un nœud anonyme.
Un [littéral objet] sera généré si l'attribut @property est présent. L'attribut @property fournit le prédicat, et les sections suivantes décrivent comment est déterminé le littéral réel à générer.
On peut utiliser l'attribut @content pour indiquer un [littéral ordinaire], comme suit :
<meta about="http://internet-apps.blogspot.com/"
property="dc:creator" content="Mark Birbeck" />
Le [littéral ordinaire] peut également être spécifié en utilisant le contenu de l'élément :
<span about="http://internet-apps.blogspot.com/"
property="dc:creator">Mark Birbeck</span>
Ces deux exemples donnent le triplet suivant :
<http://internet-apps.blogspot.com/> dc:creator "Mark Birbeck" .
La valeur de @content a priorité sur le contenu de l'élément, et le balisage suivant donnerait exactement le même triplet :
<span about="http://internet-apps.blogspot.com/"
property="dc:creator" content="Mark Birbeck">John Doe</span>
RDF permet aux [littéraux ordinaires] d'avoir une étiquette de langue, comme illustré par l'exemple suivant, provenant de [RDFTESTS-RDFMS-XMLLANG-TEST006] :
<http://example.org/node>
<http://example.org/property> "chat"@fr .
Dans RDFa, on utilise l'attribut de langue XML @xml:lang pour ajouter cette information, que le littéral ordinaire soit indiqué par l'attribut @content ou par le texte contenu dans l'élément :
<meta about="http://example.org/node"
property="ex:property" xml:lang="fr" content="chat" />
Notez la valeur de langue est héritable comme défini dans [XML-LANG], donc la syntaxe suivante donnera le même triplet que précédemment :
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:ex="http://www.example.com/ns/" xml:lang="fr">
<head>
<title xml:lang="en">Example</title>
<meta about="http://example.org/node"
property="ex:property" content="chat" />
</head>
...
</html>
On peut donner un type de données aux littéraux avec l'attribut @datatype.
En RDFa, on peut le représenter comme suit :
<span property="cal:dtstart" content="2007-09-16T16:00:00-05:00"
datatype="xsd:dateTime">
September 16th at 4pm
</span>.
Les triplets générés par ce balisage incluent le type de données après le littéral :
<> cal:dtstart "2007-09-16T16:00:00-05:00"^^xsd:dateTime .
Les documents XML ne peuvent pas contenir de balisage XML dans leurs attributs, ce qui veut dire qu'il n'est pas possible de représenter du XML dans @content (le balisage suivant provoquerait une erreur avec un analyseur XML) :
<head>
<meta property="dc:title"
content="E = mc<sup>2</sup>: The Most Urgent Problem of Our Time" />
</head>
L'échappement du contenu n'est pas une solution, puisque la sortie serait simplement une chaîne avec beaucoup d'esperluettes :
<> dc:title "E = mc<sup>2&lt;/sup>: The Most Urgent Problem of Our Time" .
RDFa permet donc l'utilisation d'un balisage normal pour exprimer des littéraux XML, au moyen de l'attribut @datatype :
<h2 property="dc:title" datatype="rdf:XMLLiteral">
E = mc<sup>2</sup>: The Most Urgent Problem of Our Time
</h2>
Cela générerait le triplet suivant, en préservant le XML dans le littéral :
<> dc:title "E = mc<sup>2</sup>: The Most Urgent Problem of Our Time"^^rdf:XMLLiteral .
Notez que cela oblige à définir au préalable une liaison URI pour le préfixe rdf
. Pour faciliter la création,
s'il y a des éléments fils et pas d'attribut @datatype, alors l'effet est le même que si on avait défini
explicitement un attribut @datatype avec rdf:XMLLiteral
:
<h2 property="dc:title"> E = mc<sup>2</sup>: The Most Urgent Problem of Our Time </h2>
Dans les exemples donnés ici, l'élément sup
fait partie en réalité de la signification du littéral, mais il y aura des
situations où le balisage supplémentaire ne signifiera rien et pourra donc être ignoré. Dans la situation suivante, on peut utiliser
une valeur @datatype vide pour modifier (override) le comportement du littéral XML :
<p>You searched for <strong>Einstein</strong>:</p>
<p about="http://dbpedia.org/resource/Albert_Einstein">
<span property="foaf:name" datatype="">Albert <strong>Einstein</strong></span>
(b. March 14, 1879, d. April 18, 1955) was a German-born theoretical physicist.
</p>
Malgré la mise en exergue dans cette page du terme recherché par l'utilisateur, le rien de l'attribut @datatype force l'interprétation des données comme un littéral ordinaire, en donnant les triplets suivants :
<http://dbpedia.org/resource/Albert_Einstein> foaf:name "Albert Einstein" .
Notez que la valeur de ce [littéral XML] est la canonisation exclusive de la valeur de l'élément RDFa.
Bien que le modèle de traitement RDFa impose de visiter chaque élément dans l'arbre, si le processeur rencontre un [littéral XML], alors il NE DOIT PAS poursuivre plus loin le traitement en descendant l'arbre. Ceci pour empêcher la génération de triplets à partir d'un balisage qui n'est pas réellement dans la hiérarchie. Par exemple, nous pourrions vouloir établir le titre d'un balisage XHTML qui contient lui-même du RDFa :
<h2 property="dc:title">
Example 3: <span about="#bbq" typeof="cal:Vevent">...</span>
</h2>
Dans cet exemple, le RDFa imbriqué ne devrait pas être interprété. Cela signifie effectivement que la présence d'un attribut @property sans un attribut @content empêchera la poursuite du traitement, et les auteurs devraient donc surveiller les attributs égarés, spécialement s'ils constatent obtenir moins de triplets que prévus.
On trouvera la plupart des règles régissant le traitement des objets qui sont des ressources dans les descriptions de traitement données ci-dessus, puisqu'elles sont importantes pour l'établissement du sujet. Cette section vise à éclairer des concepts généraux et tout ce qui aurait pu échapper.
Un ou plusieurs [objets URI] sont nécessaires lorsque les attributs @rel ou @rev sont présents. Chaque attribut entraînera la génération de triplets s'il est utilisé avec un attribut @href, @resource ou @src, ou avec la valeur de sujet d'une déclaration imbriquée si aucun de ces attributs n'est présent.
Les attributs @rel et @rev sont essentiellement le symétrique de l'autre ; tandis que @rel établit une relation entre le [sujet courant] comme sujet et la [ressource objet courante] comme objet, @rev fait exactement l'inverse, et utilise la [ressource objet courante] comme sujet et le [sujet courant] comme objet.
RDFa fournit l'attribut @resource comme moyen d'établir l'objet de déclarations. Cela est particulièrement utile pour référencer des ressources qui ne sont pas elles-mêmes des liens navigables :
<html>
<head>
<title>On Crime and Punishment</title>
<base href="http://www.example.com/candp.xhtml" />
</head>
<body>
<blockquote about="#q1" rel="dc:source" resource="urn:ISBN:0140449132" >
<p id="q1">
Rodion Romanovitch! My dear friend! If you go on in this way
you will go mad, I am positive! Drink, pray, if only a few drops!
</p>
</blockquote>
</body>
</html>
L'élément blockquote
génère le triplet suivant :
<http://www.example.com/candp.xhtml#q1> <http://purl.org/dc/elements/1.1/source> <urn:ISBN:0140449132> .
Si aucun attribut @resource n'est présent, alors l'attribut @href est le prochain dans l'ordre de priorité pour l'établissement de l'objet.
Lorsqu'un prédicat a été exprimé avec l'attribut @rel, on utilise l'attribut @href sur l'élément de la [déclaration RDFa] pour identifier l'objet avec une [référence URI]. Il a le type URI :
<link about="mailto:john@example.org"
rel="foaf:knows" href="mailto:sue@example.org" />
Il est également possible d'utiliser les attributs @rel et @rev en même temps sur un élément. Cela est particulièrement utile lorsque deux choses se tiennent dans deux relations différentes l'une avec l'autre, par exemple lorsqu'une photo est prise par Mark mais que cette photo le représente aussi :
<img src="photo1.jpg" rel="dc:creator" rev="foaf:img"
href="http://www.blogger.com/profile/1109404" />
ce qui produit donc deux triplets :
<photo1.jpg> dc:creator <http://www.blogger.com/profile/1109404> . <http://www.blogger.com/profile/1109404> foaf:img <photo1.jpg> .
Lorsque le prédicat d'un triplet a été exprimé avec les attributs @rel ou @rev, mais en absence d'attributs @href, @src ou @resource sur le même élément, il y a un « attribut rel en attente ». Cela entraîne le stockage du sujet courant et de tous les prédicats possibles (avec un indicateur selon lequel ils sont « en avant », c'est-à-dire les valeurs @rel, ou non, c'est-à-dire les valeurs @rev) comme des « triplets incomplets » attendant la découverte d'un sujet susceptible de les « compléter ».
Ce processus est décrit plus en détails à la section Compléter les « triplets incomplets ».
Cette section est normative.
Le composant clé de RDF est l'adresse URI, mais celle-ci est habituellement longue et encombrante. RDFa supporte donc un mécanisme d'abréviation des adresses URI, dès lors appelées des « adresses URI compactes » ou plus simplement des « adresses CURIE ».
Une adresse CURIE comprend deux composants : un préfixe et une référence. Le préfixe est séparé de la
référence par un caractère DEUX-POINTS « : ». En utilisation générale, il est possible d'omettre le préfixe
et donc de créer une adresse CURIE utilisant la liaison de « préfixe par défaut » ; dans RDFa, la
liaison de préfixe par défaut est http://www.w3.org/1999/xhtml/vocab#
. En général, il est également possible d'omettre
le préfixe et le caractère DEUX-POINTS, et donc de créer une adresse CURIE
qui contient juste une référence utilisant la liaison « sans préfixe ». Toutefois, RDFa ne définit pas de liaison sans préfixe,
c'est-à-dire que cette forme d'adresse CURIE n'est pas reconnue.
La syntaxe générale d'une adresse CURIE peut se résumer comme suit :
curie := [ [ prefix ] ':' ] reference prefix := NCName reference := irelative-ref (as defined in [IRI])
Dans certaines situations, un attribut admettra soit une adresse CURIE, soit une adresse URI normale. Comme il est difficile de distinguer les adresses CURIE des adresses URI, la syntaxe CURIE ajoute la notion d'[adresse CURIE sûre]. La syntaxe consiste simplement à entourer l'adresse CURIE avec des crochets :
safe_curie := '[' curie ']'
Pour l'évaluation normale des adresses CURIE, il faudrait fournir l'information de contexte suivante :
:p
) ;p
) ;_:p
).Dans RDFa, ces valeurs sont définies ainsi :
Une adresse CURIE est une représentation d'une adresse URI complète. Cette adresse URI
est obtenue en prenant la liaison visible courante associée au préfixe et en la concaténant avec la référence. L'adresse URI
produite DOIT être une adresse IRI [IRI] de syntaxe valide.
Pour une explication plus détaillée, cf. la section Traitement des adresses CURIE et URI.
Notez que, bien que l'espace lexical d'une adresse CURIE soit tel que défini dans la production curie
ci-dessus,
l'espace de valeur est l'ensemble des adresses IRI.
Cette section est normative.
Le type de document XHTML+RDFa est un type de document entièrement fonctionnel. C'est un surensemble de [XHTML11].
Le type de document XHTML+RDFa 1.0 est constitué des modules XHTML suivants. Les éléments, attributs et modèles de contenu associés à ces modules sont définis dans la spécification Modularisation XHTML [XHTMLMOD]. Les éléments sont listés ici à titre d'information mais les définitions dans la Modularisation XHTML devraient être vues comme autoritaires. Dans la version en ligne de ce document, les noms de module dans la liste ci-dessous lient aux définitions des modules dans la version courante de la Modularisation XHTML.
body
, head
, html
, title
abbr
, acronym
, address
, blockquote
, br
, cite
, code
, dfn
, div
, em
, h1
, h2
, h3
, h4
, h5
, h6
, kbd
, p
, pre
, q
, samp
, span
, strong
, var
a
et @href sont disponibles sur tous les éléments.dl
, dt
, dd
, ol
, ul
, li
object
, param
b
, big
, hr
, i
, small
, sub
, sup
, tt
del
, ins
bdo
button
, fieldset
, form
, input
, label
, legend
, select
, optgroup
, option
, textarea
caption
, col
, colgroup
, table
, tbody
, td
, tfoot
, th
, thead
, tr
img
area
, map
ismap
sur img
meta
noscript
, script
style
link
base
XHTML+RDFa utilise aussi le module d'annotation ruby telle que définie dans [RUBY] :
ruby
, rbc
, rtc
, rb
, rt
, rp
Ce type de document ne requiert pas de définitions supplémentaires. Une mise en œuvre de ce type de document sous forme de DTD XML est définie à l'Annexe A.
Cette section est normative.
Le module des attributs de métainformation définit la collection d'attributs Metainformation
. Cette collection permet
d'annoter les éléments par des métadonnées partout dans un document de la famille XHTML. Lorsque ce module est inclus dans un
langage de balisage, cette collection s'ajoute à la collection d'attributs Common
comme définie dans
[XHTMLMOD].
Certains attributs dans cette section utilisent les types de données suivants :
Type de donnée | Description |
---|---|
CURIE | Une adresse URI compacte (Compact URI) ou curie. |
CURIEs | Une liste d'adresses CURIE séparées par des caractères blancs (whitespace). |
URIorSafeCURIE | Une adresse URI ou une adresse CURIE sûre (safe_curie). |
Notez que ces types de données sont spécifiés dans une définition DTD XML et dans un schéma XML Schema à l'Annexe B.
Les attributs suivants sont inclus dans la collection d'attributs, et prennent des valeurs dans le type de donnée associé :
Attributs | Notes |
---|---|
about (URIorSafeCURIE) | |
content (CDATA) | |
datatype (CURIE) | Si non spécifié, alors la valeur par défaut est string , comme défini dans [XMLSCHEMA]. |
typeof (CURIEs) | |
property (CURIEs) | |
rel (mot réservé | CURIE)+ | Cf. la liste des valeurs réservées à la section Valeurs des attributs @rel/@rev |
resource (URIorSafeCURIE) | |
rev (mot réservé | CURIE)+ | Cf. la liste des valeurs réservées à la section Valeurs des attributs @rel/@rev |
On trouvera une mise en œuvre de ce module à l'Annexe A.
La liste des valeurs réservées pour les attributs @rel et @rev est la suivante :
cite
est utilisée pour
référencer le livre d'où la citation est tirée :
La valeur cite
comme référence bibliographique
As Gandalf the White said in
<span rel="cite" resource="http://www.example.com/books/the_two_towers">
The Two Towers
</span>,
<quote xml:lang="en">"The hospitality of
your hall is somewhat lessened of late, Theoden King."</quote>
qui générerait le triplet suivant :
<> xhv:cite <http://www.example.com/books/the_two_towers> .
cite
est également utile pour référencer des spécifications :
La valeur cite
pour référencer une autre spécification
More information can be found in
<span rel="cite" resource="http://www.w3.org/TR/REC-xml">[XML]</cite>.
qui générerait le triplet suivant :
<> xhv:cite <http://www.w3.org/TR/REC-xml> .
start
et top
).start
.Cette annexe est normative.
Cette annexe contient une implémentation du langage XHTML+RDFa 1.0 comme définition DTD XML. Il est implémenté en combinant la définition DTD XHTML 1.1 et le module des attributs de métainformation XHTML. On le réalise en utilisant un module de modèle de contenu puis un module de pilote (driver module). Des liens directs vont vers les divers fichiers, et les fichiers se trouvent également contenus dans les archives « TAR Gzip » et « Zip » reliées au début de ce document. Veuillez noter que les fichiers visés par les liens « dernière version » pourront lentement changer avec le temps. Cf. la page d'accueil du groupe de travail XHTML 2 du W3C pour plus de renseignements.
Vous pouvez charger cette version du fichier à http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014/DTD/xhtml-metaAttributes-1.mod. La dernière version est disponible à http://www.w3.org/MarkUp/DTD/xhtml-metaAttributes-1.mod.
<!-- ...................................................................... --> <!-- XHTML MetaAttributes Module ......................................... --> <!-- file: xhtml-metaAttributes-1.mod This is XHTML-RDFa, modules to annotate XHTML family documents. Copyright 2007-2008 W3C (MIT, ERCIM, Keio), All Rights Reserved. Revision: $Id: xhtml-metaAttributes-1.mod,v 1.7 2008/08/01 19:57:13 ahby Exp $ This DTD module is identified by the PUBLIC and SYSTEM identifiers: PUBLIC "-//W3C//ENTITIES XHTML MetaAttributes 1.0//EN" SYSTEM "http://www.w3.org/MarkUp/DTD/xhtml-metaAttributes-1.mod" Revisions: (none) ....................................................................... --> <!ENTITY % XHTML.global.attrs.prefixed "IGNORE" > <!-- Placeholder Compact URI-related types --> <!ENTITY % CURIE.datatype "CDATA" > <!ENTITY % CURIEs.datatype "CDATA" > <!ENTITY % SafeCURIE.datatype "CDATA" > <!ENTITY % SafeCURIEs.datatype "CDATA" > <!ENTITY % URIorSafeCURIE.datatype "CDATA" > <!ENTITY % URIorSafeCURIEs.datatype "CDATA" > <!-- Common Attributes This module declares a collection of meta-information related attributes. %NS.decl.attrib; is declared in the XHTML Qname module. This file also includes declarations of "global" versions of the attributes. The global versions of the attributes are for use on elements in other namespaces. --> <!ENTITY % about.attrib "about %URIorSafeCURIE.datatype; #IMPLIED" > <![%XHTML.global.attrs.prefixed;[ <!ENTITY % XHTML.global.about.attrib "%XHTML.prefix;:about %URIorSafeCURIE.datatype; #IMPLIED" > ]]> <!ENTITY % typeof.attrib "typeof %CURIEs.datatype; #IMPLIED" > <![%XHTML.global.attrs.prefixed;[ <!ENTITY % XHTML.global.typeof.attrib "%XHTML.prefix;:typeof %CURIEs.datatype; #IMPLIED" > ]]> <!ENTITY % property.attrib "property %CURIEs.datatype; #IMPLIED" > <![%XHTML.global.attrs.prefixed;[ <!ENTITY % XHTML.global.property.attrib "%XHTML.prefix;:property %CURIEs.datatype; #IMPLIED" > ]]> <!ENTITY % resource.attrib "resource %URIorSafeCURIE.datatype; #IMPLIED" > <![%XHTML.global.attrs.prefixed;[ <!ENTITY % XHTML.global.resource.attrib "%XHTML.prefix;:resource %URIorSafeCURIE.datatype; #IMPLIED" > ]]> <!ENTITY % content.attrib "content CDATA #IMPLIED" > <![%XHTML.global.attrs.prefixed;[ <!ENTITY % XHTML.global.content.attrib "%XHTML.prefix;:content CDATA #IMPLIED" > ]]> <!ENTITY % datatype.attrib "datatype %CURIE.datatype; #IMPLIED" > <![%XHTML.global.attrs.prefixed;[ <!ENTITY % XHTML.global.datatype.attrib "%XHTML.prefix;:datatype %CURIE.datatype; #IMPLIED" > ]]> <!ENTITY % rel.attrib "rel %CURIEs.datatype; #IMPLIED" > <![%XHTML.global.attrs.prefixed;[ <!ENTITY % XHTML.global.rel.attrib "%XHTML.prefix;:rel %CURIEs.datatype; #IMPLIED" > ]]> <!ENTITY % rev.attrib "rev %CURIEs.datatype; #IMPLIED" > <![%XHTML.global.attrs.prefixed;[ <!ENTITY % XHTML.global.rev.attrib "%XHTML.prefix;:rev %CURIEs.datatype; #IMPLIED" > ]]> <!ENTITY % Metainformation.extra.attrib "" > <!ENTITY % Metainformation.attrib "%about.attrib; %content.attrib; %datatype.attrib; %typeof.attrib; %property.attrib; %rel.attrib; %resource.attrib; %rev.attrib; %Metainformation.extra.attrib;" > <!ENTITY % XHTML.global.metainformation.extra.attrib "" > <![%XHTML.global.attrs.prefixed;[ <!ENTITY % XHTML.global.metainformation.attrib "%XHTML.global.about.attrib; %XHTML.global.content.attrib; %XHTML.global.datatype.attrib; %XHTML.global.typeof.attrib; %XHTML.global.property.attrib; %XHTML.global.rel.attrib; %XHTML.global.resource.attrib; %XHTML.global.rev.attrib; %XHTML.global.metainformation.extra.attrib;" > ]]> <!ENTITY % XHTML.global.metainformation.attrib "" > <!-- end of xhtml-metaAttributes-1.mod -->
Vous pouvez charger cette version du fichier à http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014/DTD/xhtml-rdfa-model-1.mod. La dernière version est disponible à http://www.w3.org/MarkUp/DTD/xhtml-rdfa-model-1.mod.
<!-- ....................................................................... --> <!-- XHTML+RDFa Document Model Module ..................................... --> <!-- file: xhtml-rdfa-model-1.mod This is XHTML+RDFa. Copyright 1998-2008 W3C (MIT, ERCIM, Keio), All Rights Reserved. Revision: $Id: xhtml-rdfa-model-1.mod,v 1.2 2008/01/03 18:45:34 ahby Exp $ SMI This DTD module is identified by the PUBLIC and SYSTEM identifiers: PUBLIC "-//W3C//ENTITIES XHTML+RDFa Document Model 1.0//EN" SYSTEM "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-model-1.mod" Revisions: (none) ....................................................................... --> <!-- XHTML+RDFa Document Model This module describes the groupings of elements that make up common content models for XHTML elements. XHTML has three basic content models: %Inline.mix; character-level elements %Block.mix; block-like elements, eg., paragraphs and lists %Flow.mix; any block or inline elements Any parameter entities declared in this module may be used to create element content models, but the above three are considered 'global' (insofar as that term applies here). The reserved word '#PCDATA' (indicating a text string) is now included explicitly with each element declaration that is declared as mixed content, as XML requires that this token occur first in a content model specification. --> <!-- Extending the Model While in some cases this module may need to be rewritten to accommodate changes to the document model, minor extensions may be accomplished by redeclaring any of the three *.extra; parameter entities to contain extension element types as follows: %Misc.extra; whose parent may be any block or inline element. %Inline.extra; whose parent may be any inline element. %Block.extra; whose parent may be any block element. If used, these parameter entities must be an OR-separated list beginning with an OR separator ("|"), eg., "| a | b | c" All block and inline *.class parameter entities not part of the *struct.class classes begin with "| " to allow for exclusion from mixes. --> <!-- .............. Optional Elements in head .................. --> <!ENTITY % HeadOpts.mix "( %script.qname; | %style.qname; | %meta.qname; | %link.qname; | %object.qname; )*" > <!-- ................. Miscellaneous Elements .................. --> <!-- ins and del are used to denote editing changes --> <!ENTITY % Edit.class "| %ins.qname; | %del.qname;" > <!-- script and noscript are used to contain scripts and alternative content --> <!ENTITY % Script.class "| %script.qname; | %noscript.qname;" > <!ENTITY % Misc.extra "" > <!-- These elements are neither block nor inline, and can essentially be used anywhere in the document body. --> <!ENTITY % Misc.class "%Edit.class; %Script.class; %Misc.extra;" > <!-- .................... Inline Elements ...................... --> <!ENTITY % InlStruct.class "%br.qname; | %span.qname;" > <!ENTITY % InlPhras.class "| %em.qname; | %strong.qname; | %dfn.qname; | %code.qname; | %samp.qname; | %kbd.qname; | %var.qname; | %cite.qname; | %abbr.qname; | %acronym.qname; | %q.qname;" > <!ENTITY % InlPres.class "| %tt.qname; | %i.qname; | %b.qname; | %big.qname; | %small.qname; | %sub.qname; | %sup.qname;" > <!ENTITY % I18n.class "| %bdo.qname;" > <!ENTITY % Anchor.class "| %a.qname;" > <!ENTITY % InlSpecial.class "| %img.qname; | %map.qname; | %object.qname;" > <!ENTITY % InlForm.class "| %input.qname; | %select.qname; | %textarea.qname; | %label.qname; | %button.qname;" > <!ENTITY % Inline.extra "" > <!ENTITY % Ruby.class "| %ruby.qname;" > <!-- %Inline.class; includes all inline elements, used as a component in mixes --> <!ENTITY % Inline.class "%InlStruct.class; %InlPhras.class; %InlPres.class; %I18n.class; %Anchor.class; %InlSpecial.class; %InlForm.class; %Ruby.class; %Inline.extra;" > <!-- %InlNoRuby.class; includes all inline elements except ruby, used as a component in mixes --> <!ENTITY % InlNoRuby.class "%InlStruct.class; %InlPhras.class; %InlPres.class; %I18n.class; %Anchor.class; %InlSpecial.class; %InlForm.class; %Inline.extra;" > <!-- %NoRuby.content; includes all inlines except ruby --> <!ENTITY % NoRuby.content "( #PCDATA | %InlNoRuby.class; %Misc.class; )*" > <!-- %InlNoAnchor.class; includes all non-anchor inlines, used as a component in mixes --> <!ENTITY % InlNoAnchor.class "%InlStruct.class; %InlPhras.class; %InlPres.class; %I18n.class; %InlSpecial.class; %InlForm.class; %Ruby.class; %Inline.extra;" > <!-- %InlNoAnchor.mix; includes all non-anchor inlines --> <!ENTITY % InlNoAnchor.mix "%InlNoAnchor.class; %Misc.class;" > <!-- %Inline.mix; includes all inline elements, including %Misc.class; --> <!ENTITY % Inline.mix "%Inline.class; %Misc.class;" > <!-- ..................... Block Elements ...................... --> <!-- In the HTML 4.0 DTD, heading and list elements were included in the %block; parameter entity. The %Heading.class; and %List.class; parameter entities must now be included explicitly on element declarations where desired. --> <!ENTITY % Heading.class "%h1.qname; | %h2.qname; | %h3.qname; | %h4.qname; | %h5.qname; | %h6.qname;" > <!ENTITY % List.class "%ul.qname; | %ol.qname; | %dl.qname;" > <!ENTITY % Table.class "| %table.qname;" > <!ENTITY % Form.class "| %form.qname;" > <!ENTITY % Fieldset.class "| %fieldset.qname;" > <!ENTITY % BlkStruct.class "%p.qname; | %div.qname;" > <!ENTITY % BlkPhras.class "| %pre.qname; | %blockquote.qname; | %address.qname;" > <!ENTITY % BlkPres.class "| %hr.qname; " > <!ENTITY % BlkSpecial.class "%Table.class; %Form.class; %Fieldset.class;" > <!ENTITY % Block.extra "" > <!-- %Block.class; includes all block elements, used as an component in mixes --> <!ENTITY % Block.class "%BlkStruct.class; %BlkPhras.class; %BlkPres.class; %BlkSpecial.class; %Block.extra;" > <!-- %Block.mix; includes all block elements plus %Misc.class; --> <!ENTITY % Block.mix "%Heading.class; | %List.class; | %Block.class; %Misc.class;" > <!-- ................ All Content Elements .................. --> <!-- %Flow.mix; includes all text content, block and inline --> <!ENTITY % Flow.mix "%Heading.class; | %List.class; | %Block.class; | %Inline.class; %Misc.class;" > <!-- end of xhtml-rdfa-model-1.mod -->
Vous pouvez charger cette version du fichier à http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014/DTD/xhtml-rdfa-1.dtd. La dernière version est disponible à http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd.
<!-- ....................................................................... --> <!-- XHTML 1.1 + RDFa DTD ................................................. --> <!-- file: xhtml-rdfa-1.dtd --> <!-- XHTML 1.1 + RDFa DTD This is an example markup language combining XHTML 1.1 and the RDFa modules. XHTML+RDFa Copyright 1998-2008 World Wide Web Consortium (Massachusetts Institute of Technology, European Research Consortium for Informatics and Mathematics, Keio University). All Rights Reserved. Permission to use, copy, modify and distribute the XHTML DTD and its accompanying documentation for any purpose and without fee is hereby granted in perpetuity, provided that the above copyright notice and this paragraph appear in all copies. The copyright holders make no representation about the suitability of the DTD for any purpose. It is provided "as is" without expressed or implied warranty. --> <!-- This is the driver file for version 1 of the XHTML + RDFa DTD. Please use this public identifier to identify it: "-//W3C//DTD XHTML+RDFa 1.0//EN" --> <!ENTITY % XHTML.version "XHTML+RDFa 1.0" > <!-- Use this URI to identify the default namespace: "http://www.w3.org/1999/xhtml" See the Qualified Names module for information on the use of namespace prefixes in the DTD. Note that XHTML namespace elements are not prefixed by default, but the XHTML namespace prefix is defined as "xhtml" so that other markup languages can extend this one and use the XHTML prefixed global attributes if required. --> <!ENTITY % NS.prefixed "IGNORE" > <!ENTITY % XHTML.prefix "xhtml" > <!-- Be sure to include prefixed global attributes - we don't need them, but languages that extend XHTML 1.1 might. --> <!ENTITY % XHTML.global.attrs.prefixed "INCLUDE" > <!-- Reserved for use with the XLink namespace: --> <!ENTITY % XLINK.xmlns "" > <!ENTITY % XLINK.xmlns.attrib "" > <!-- For example, if you are using XHTML 1.1 directly, use the public identifier in the DOCTYPE declaration, with the namespace declaration on the document element to identify the default namespace: <?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"> ... </html> Revisions: (none) --> <!-- reserved for future use with document profiles --> <!ENTITY % XHTML.profile "" > <!-- ensure XHTML Notations are disabled --> <!ENTITY % xhtml-notations.module "IGNORE" > <!-- Bidirectional Text features This feature-test entity is used to declare elements and attributes used for bidirectional text support. --> <!ENTITY % XHTML.bidi "INCLUDE" > <!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: --> <!-- Pre-Framework Redeclaration placeholder .................... --> <!-- this serves as a location to insert markup declarations into the DTD prior to the framework declarations. --> <!ENTITY % xhtml-prefw-redecl.module "IGNORE" > <!ENTITY % xhtml-prefw-redecl.mod "" > <![%xhtml-prefw-redecl.module;[ %xhtml-prefw-redecl.mod; <!-- end of xhtml-prefw-redecl.module -->]]> <!-- we need the datatypes now --> <!ENTITY % xhtml-datatypes.module "INCLUDE" > <![%xhtml-datatypes.module;[ <!ENTITY % xhtml-datatypes.mod PUBLIC "-//W3C//ENTITIES XHTML Datatypes 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-datatypes-1.mod" > %xhtml-datatypes.mod;]]> <!-- bring in the RDFa attributes cause we need them in Common --> <!ENTITY % xhtml-metaAttributes.module "INCLUDE" > <![%xhtml-metaAttributes.module;[ <!ENTITY % xhtml-metaAttributes.mod PUBLIC "-//W3C//ENTITIES XHTML MetaAttributes 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-metaAttributes-1.mod" > %xhtml-metaAttributes.mod;]]> <!ENTITY % xhtml-events.module "INCLUDE" > <!ENTITY % Common.extra.attrib "href %URI.datatype; #IMPLIED %Metainformation.attrib;" > <!-- Inline Style Module ........................................ --> <!ENTITY % xhtml-inlstyle.module "INCLUDE" > <![%xhtml-inlstyle.module;[ <!ENTITY % xhtml-inlstyle.mod PUBLIC "-//W3C//ELEMENTS XHTML Inline Style 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-inlstyle-1.mod" > %xhtml-inlstyle.mod;]]> <!-- declare Document Model module instantiated in framework --> <!ENTITY % xhtml-model.mod PUBLIC "-//W3C//ENTITIES XHTML+RDFa Document Model 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-model-1.mod" > <!-- Modular Framework Module (required) ......................... --> <!ENTITY % xhtml-framework.module "INCLUDE" > <![%xhtml-framework.module;[ <!ENTITY % xhtml-framework.mod PUBLIC "-//W3C//ENTITIES XHTML Modular Framework 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-framework-1.mod" > %xhtml-framework.mod;]]> <!-- Post-Framework Redeclaration placeholder ................... --> <!-- this serves as a location to insert markup declarations into the DTD following the framework declarations. --> <!ENTITY % xhtml-postfw-redecl.module "IGNORE" > <!ENTITY % xhtml-postfw-redecl.mod ""> <![%xhtml-postfw-redecl.module;[ %xhtml-postfw-redecl.mod; <!-- end of xhtml-postfw-redecl.module -->]]> <!-- Text Module (Required) ..................................... --> <!ENTITY % xhtml-text.module "INCLUDE" > <![%xhtml-text.module;[ <!ENTITY % xhtml-text.mod PUBLIC "-//W3C//ELEMENTS XHTML Text 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-text-1.mod" > %xhtml-text.mod;]]> <!-- Hypertext Module (required) ................................. --> <!ENTITY % a.attlist "IGNORE" > <!ENTITY % xhtml-hypertext.module "INCLUDE" > <![%xhtml-hypertext.module;[ <!ENTITY % xhtml-hypertext.mod PUBLIC "-//W3C//ELEMENTS XHTML Hypertext 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-hypertext-1.mod" > %xhtml-hypertext.mod;]]> <!ATTLIST %a.qname; %Common.attrib; charset %Charset.datatype; #IMPLIED type %ContentType.datatype; #IMPLIED hreflang %LanguageCode.datatype; #IMPLIED accesskey %Character.datatype; #IMPLIED tabindex %Number.datatype; #IMPLIED > <!-- Lists Module (required) .................................... --> <!ENTITY % xhtml-list.module "INCLUDE" > <![%xhtml-list.module;[ <!ENTITY % xhtml-list.mod PUBLIC "-//W3C//ELEMENTS XHTML Lists 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-list-1.mod" > %xhtml-list.mod;]]> <!-- ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: --> <!-- Edit Module ................................................ --> <!ENTITY % xhtml-edit.module "INCLUDE" > <![%xhtml-edit.module;[ <!ENTITY % xhtml-edit.mod PUBLIC "-//W3C//ELEMENTS XHTML Editing Elements 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-edit-1.mod" > %xhtml-edit.mod;]]> <!-- BIDI Override Module ....................................... --> <!ENTITY % xhtml-bdo.module "%XHTML.bidi;" > <![%xhtml-bdo.module;[ <!ENTITY % xhtml-bdo.mod PUBLIC "-//W3C//ELEMENTS XHTML BIDI Override Element 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-bdo-1.mod" > %xhtml-bdo.mod;]]> <!-- Ruby Module ................................................ --> <!ENTITY % Ruby.common.attlists "INCLUDE" > <!ENTITY % Ruby.common.attrib "%Common.attrib;" > <!ENTITY % xhtml-ruby.module "INCLUDE" > <![%xhtml-ruby.module;[ <!ENTITY % xhtml-ruby.mod PUBLIC "-//W3C//ELEMENTS XHTML Ruby 1.0//EN" "http://www.w3.org/TR/ruby/xhtml-ruby-1.mod" > %xhtml-ruby.mod;]]> <!-- Presentation Module ........................................ --> <!ENTITY % xhtml-pres.module "INCLUDE" > <![%xhtml-pres.module;[ <!ENTITY % xhtml-pres.mod PUBLIC "-//W3C//ELEMENTS XHTML Presentation 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-pres-1.mod" > %xhtml-pres.mod;]]> <!ENTITY % link.attlist "IGNORE" > <!-- Link Element Module ........................................ --> <!ENTITY % xhtml-link.module "INCLUDE" > <![%xhtml-link.module;[ <!ENTITY % xhtml-link.mod PUBLIC "-//W3C//ELEMENTS XHTML Link Element 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-link-1.mod" > %xhtml-link.mod;]]> <!ATTLIST %link.qname; %Common.attrib; charset %Charset.datatype; #IMPLIED hreflang %LanguageCode.datatype; #IMPLIED type %ContentType.datatype; #IMPLIED media %MediaDesc.datatype; #IMPLIED > <!-- Document Metainformation Module ............................ --> <!ENTITY % meta.attlist "IGNORE" > <!ENTITY % xhtml-meta.module "INCLUDE" > <![%xhtml-meta.module;[ <!ENTITY % xhtml-meta.mod PUBLIC "-//W3C//ELEMENTS XHTML Metainformation 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-meta-1.mod" > %xhtml-meta.mod;]]> <!ATTLIST %meta.qname; %Common.attrib; http-equiv NMTOKEN #IMPLIED name NMTOKEN #IMPLIED scheme CDATA #IMPLIED > <!-- Base Element Module ........................................ --> <!ENTITY % xhtml-base.module "INCLUDE" > <![%xhtml-base.module;[ <!ENTITY % xhtml-base.mod PUBLIC "-//W3C//ELEMENTS XHTML Base Element 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-base-1.mod" > %xhtml-base.mod;]]> <!-- Scripting Module ........................................... --> <!ENTITY % script.attlist "IGNORE" > <!ENTITY % xhtml-script.module "INCLUDE" > <![%xhtml-script.module;[ <!ENTITY % xhtml-script.mod PUBLIC "-//W3C//ELEMENTS XHTML Scripting 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-script-1.mod" > %xhtml-script.mod;]]> <!ATTLIST %script.qname; %XHTML.xmlns.attrib; %id.attrib; %Metainformation.attrib; href %URI.datatype; #IMPLIED xml:space ( preserve ) #FIXED 'preserve' charset %Charset.datatype; #IMPLIED type %ContentType.datatype; #REQUIRED src %URI.datatype; #IMPLIED defer ( defer ) #IMPLIED > <!-- Style Sheets Module ......................................... --> <!ENTITY % style.attlist "IGNORE" > <!ENTITY % xhtml-style.module "INCLUDE" > <![%xhtml-style.module;[ <!ENTITY % xhtml-style.mod PUBLIC "-//W3C//ELEMENTS XHTML Style Sheets 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-style-1.mod" > %xhtml-style.mod;]]> <!ATTLIST %style.qname; %XHTML.xmlns.attrib; %id.attrib; %title.attrib; %I18n.attrib; %Metainformation.attrib; href %URI.datatype; #IMPLIED xml:space ( preserve ) #FIXED 'preserve' type %ContentType.datatype; #REQUIRED media %MediaDesc.datatype; #IMPLIED > <!-- Image Module ............................................... --> <!ENTITY % xhtml-image.module "INCLUDE" > <![%xhtml-image.module;[ <!ENTITY % xhtml-image.mod PUBLIC "-//W3C//ELEMENTS XHTML Images 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-image-1.mod" > %xhtml-image.mod;]]> <!-- Client-side Image Map Module ............................... --> <!ENTITY % area.attlist "IGNORE" > <!ENTITY % xhtml-csismap.module "INCLUDE" > <![%xhtml-csismap.module;[ <!ENTITY % xhtml-csismap.mod PUBLIC "-//W3C//ELEMENTS XHTML Client-side Image Maps 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-csismap-1.mod" > %xhtml-csismap.mod;]]> <!ATTLIST %area.qname; %Common.attrib; shape %Shape.datatype; 'rect' coords %Coords.datatype; #IMPLIED nohref ( nohref ) #IMPLIED alt %Text.datatype; #REQUIRED tabindex %Number.datatype; #IMPLIED accesskey %Character.datatype; #IMPLIED > <!-- Server-side Image Map Module ............................... --> <!ENTITY % xhtml-ssismap.module "INCLUDE" > <![%xhtml-ssismap.module;[ <!ENTITY % xhtml-ssismap.mod PUBLIC "-//W3C//ELEMENTS XHTML Server-side Image Maps 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-ssismap-1.mod" > %xhtml-ssismap.mod;]]> <!-- Param Element Module ....................................... --> <!ENTITY % param.attlist "IGNORE" > <!ENTITY % xhtml-param.module "INCLUDE" > <![%xhtml-param.module;[ <!ENTITY % xhtml-param.mod PUBLIC "-//W3C//ELEMENTS XHTML Param Element 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-param-1.mod" > %xhtml-param.mod;]]> <!ATTLIST %param.qname; %XHTML.xmlns.attrib; %id.attrib; %Metainformation.attrib; href %URI.datatype; #IMPLIED name CDATA #REQUIRED value CDATA #IMPLIED valuetype ( data | ref | object ) 'data' type %ContentType.datatype; #IMPLIED > <!-- Embedded Object Module ..................................... --> <!ENTITY % xhtml-object.module "INCLUDE" > <![%xhtml-object.module;[ <!ENTITY % xhtml-object.mod PUBLIC "-//W3C//ELEMENTS XHTML Embedded Object 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-object-1.mod" > %xhtml-object.mod;]]> <!-- Tables Module ............................................... --> <!ENTITY % xhtml-table.module "INCLUDE" > <![%xhtml-table.module;[ <!ENTITY % xhtml-table.mod PUBLIC "-//W3C//ELEMENTS XHTML Tables 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-table-1.mod" > %xhtml-table.mod;]]> <!-- Forms Module ............................................... --> <!ENTITY % xhtml-form.module "INCLUDE" > <![%xhtml-form.module;[ <!ENTITY % xhtml-form.mod PUBLIC "-//W3C//ELEMENTS XHTML Forms 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-form-1.mod" > %xhtml-form.mod;]]> <!-- Target Attribute Module .................................... --> <!ENTITY % xhtml-target.module "INCLUDE" > <![%xhtml-target.module;[ <!ENTITY % xhtml-target.mod PUBLIC "-//W3C//ELEMENTS XHTML Target 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-target-1.mod" > %xhtml-target.mod;]]> <!-- Legacy Markup ............................................... --> <!ENTITY % xhtml-legacy.module "IGNORE" > <![%xhtml-legacy.module;[ <!ENTITY % xhtml-legacy.mod PUBLIC "-//W3C//ELEMENTS XHTML Legacy Markup 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-legacy-1.mod" > %xhtml-legacy.mod;]]> <!-- Document Structure Module (required) ....................... --> <!ENTITY % html.attlist "IGNORE" > <!ENTITY % head.attlist "IGNORE" > <!ENTITY % title.attlist "IGNORE" > <!ENTITY % xhtml-struct.module "INCLUDE" > <![%xhtml-struct.module;[ <!ENTITY % xhtml-struct.mod PUBLIC "-//W3C//ELEMENTS XHTML Document Structure 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-struct-1.mod" > %xhtml-struct.mod;]]> <!ENTITY % profile.attrib "profile %URI.datatype; '%XHTML.profile;'" > <!ENTITY % XHTML.version.attrib "version %FPI.datatype; #FIXED '%XHTML.version;'" > <!ATTLIST %html.qname; %Common.attrib; %XSI.schemaLocation.attrib; %XHTML.version.attrib; > <!ATTLIST %head.qname; %Common.attrib; %profile.attrib; > <!ATTLIST %title.qname; %Common.attrib; > <!-- end of XHTML-RDFa DTD ................................................ --> <!-- ....................................................................... -->
Cette section contient la définition au format Open Catalog SGML [CATALOG] des identificateurs publics de XHTML+RDFa 1.0.
Vous pouvez charger cette version du fichier à http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014/DTD/xhtml-rdfa.cat. La dernière version est disponible à http://www.w3.org/MarkUp/DTD/xhtml-rdfa.cat.
-- .......................................................................... -- -- File catalog ............................................................ -- -- XHTML+RDFa Catalog Data File Revision: $Revision: 1.2 $ See "Entity Management", SGML Open Technical Resolution 9401 for detailed information on supplying and using catalog data. This document is available from OASIS at URL: <http://www.oasis-open.org/html/tr9401.html> -- -- .......................................................................... -- -- SGML declaration associated with XHTML .................................. -- OVERRIDE YES SGMLDECL "xml1.dcl" -- :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: -- -- XHTML+RDFa modules .............................................. -- PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "xhtml-rdfa-1.dtd" PUBLIC "-//W3C//ENTITIES XHTML+RDFa Document Model 1.0//EN" "xhtml-rdfa-model-1.mod" PUBLIC "-//W3C//ENTITIES XHTML MetaAttributes 1.0//EN" "xhtml-metaAttributes-1.mod" -- End of catalog data ..................................................... -- -- .......................................................................... --
Cette section est informative.
Pour faciliter l'utilisation des adresses CURIE dans les langages de balisage, cette spécification définit des
types de données supplémentaires dans l'espace de types de données XHTML (http://www.w3.org/1999/xhtml/datatypes/
).
Les langages de balisage utilisant XHTML Modularization pourront trouver ces définitions normatives dans le
fichier de support de modularisation "datatypes" de leur grammaire de schéma :
Spécifiquement, les types de données suivants sont introduits :
La définition XML Schema informative suivante pour ces types de données est incluse en exemple :
<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://www.w3.org/1999/xhtml/datatypes/" xmlns:xh11d="http://www.w3.org/1999/xhtml/datatypes/" targetNamespace="http://www.w3.org/1999/xhtml/datatypes/" elementFormDefault="qualified" > <xs:simpleType name="CURIE"> <xs:restriction base="xs:string"> <xs:pattern value="(([\i-[:]][\c-[:]]*)?:)?.+" /> <xs:minLength value="1"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="CURIEs"> <xs:list itemType="xh11d:CURIE"/> </xs:simpleType> <xs:simpleType name="SafeCURIE"> <xs:restriction base="xs:string"> <xs:pattern value="\[(([\i-[:]][\c-[:]]*)?:)?.+\]" /> <xs:minLength value="3"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="SafeCURIEs"> <xs:list itemType="xh11d:SafeCURIE"/> </xs:simpleType> <xs:simpleType name="URIorSafeCURIE"> <xs:union memberTypes="xs:anyURI xh11d:SafeCURIE" /> </xs:simpleType> <xs:simpleType name="URIorSafeCURIEs"> <xs:list itemType="xh11d:URIorSafeCURIE"/> </xs:simpleType> </xs:schema>
La définition DTD XML informative suivante est incluse en exemple :
<!ENTITY % CURIE.datatype "CDATA" > <!ENTITY % CURIEs.datatype "CDATA" > <!ENTITY % SafeCURIE.datatype "CDATA" > <!ENTITY % SafeCURIEs.datatype "CDATA" > <!ENTITY % URIorSafeCURIE.datatype "CDATA" > <!ENTITY % URIorSafeCURIEs.datatype "CDATA" >
Cette section est informative.
Les documents écrits avec le langage de balisage défini dans cette spécification peuvent être validés en utilisant la définition DTD de l'Annexe A. Si l'auteur d'un document veut faciliter une telle validation, il peut inclure la déclaration suivante au début de son document :
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
Le document dans l'espace de noms XML associé à la famille de langages de balisage XHTML utilise le
mécanisme de transformation des documents XHTML+RDFa en RDF qui est défini par [GRDDL].
Les auteurs qui veulent être certains pour leurs documents qu'ils soient transformables par tous les processeurs [GRDDL]
peuvent également inclure un attribut profile
sur l'élément head
avec une référence
à l'adresse URI du vocabulaire XHTML http://www.w3.org/1999/xhtml/vocab
.
Cette section est normative.
Cette section est informative.
Cette section est informative.
2008-06-03 : Ajouté une section informative sur les fragments XHTML. Vérifié aussi de bien dire « espace de noms » quand on désigne un espace de noms XML, et « préfixe » pour désigner la première partie d'une adresse CURIE. [ShaneMcCarron]
2008-05-15 : Déplacé la section sur les références de nœud anonyme dans les adresses CURIE au chapitre 5 (qui est normatif). Corrigé également quelques définitions de terme qui désignaient par « document » une « ressource ». [ShaneMcCarron]
2008-05-12 : Changé les règles de traitement 4 et 5 pour rechercher la présence des attributs @rel et @rev, plutôt que d'examiner la validité de leurs valeurs. La vérification a lieu plus tard. [MarkBirbeck]
2008-05-09 : Supprimé la référence aux « valeurs réservées » dans le contexte de l'attribut @about : l'attribut about ne prend pas de valeurs réservées. [ShaneMcCarron]
2008-05-08 : Ajouté une référence informative au document de définition du vocabulaire XHTML. [ShaneMcCarron]
2008-05-01 : Changé le nom de type de donnée URIorCURIE en URIorSafeCURIE. Ajouté l'implémentation des types de données dans l'annexe B. Ajouté du texte à propos de la préférence du contenu sur l'attribut @content, de façon à ne pas perdre la possibilité d'avoir un balisage riche. [ShaneMcCarron]
2008-04-29 : Changé les règles de traitement afin de permettre la génération de triplets avec des objets qui sont des nœuds anonymes, même si ces nœuds anonymes n'apparaissent jamais dans un triplet en tant que sujet. [MarkBirbeck]
2008-04-28 : Mise à jour des règles de traitement afin que les éléments ne contenant pas d'attributs RDFa n'aient aucun effet. À un moment donné, cette étape omettait de vérifier l'attribut @property, c'est-à-dire que les éléments contenant seulement @property étaient ignorés. [MarkBirbeck]
2008-04-03 : Changé instanceof
pour @typeof. [ShaneMcCarron]
2008-01-23 : Mis à jour pour refléter les dernières réflexions du groupe d'étude — le traitement des valeurs existantes dans les attributs @rel et @rev. Dans le cadre de ce travail, rendu beaucoup plus clair le traitement entier des adresses CURIE et URI. [MarkBirbeck]
2008-01-03 : Mis à jour pour refléter les dernières réflexions du groupe d'étude — le modèle de traitement, en particulier concernant le « chaînage » et le comportement de instanceof
. [MarkBirbeck]
2007-10-19 : Mis à jour pour refléter les dernières réflexions du groupe d'étude — le modèle de traitement. Intégré la définition des modules XHTML et le balisage hybride. Terminé le développement en tant que première ébauche publique. [ShaneMcCarron], [MarkBirbeck]
2007-09-04 : Migré vers le système de publication du groupe de travail XHTML 2. Converti vers un format cohérent avec les document du suivi des recommandations. Mis à jour pour refléter le modèle de traitement courant. Ajouté la définition normative des adresses CURIE. Commencé à mettre à jour la prose pour la cohérence avec les accords de coopération courants. [ShaneMcCarron], [StevenPemberton], [MarkBirbeck]
2007-04-06 : Corrigé le discours pour parler de « structure » plutôt que de métadonnées. Ajouté une note à propos des valeurs séparées par des espaces dans les prédicats dénotant des attributs. [BenAdida]
2006-01-16 : Rendu cohérente l'utilisation du type CURIE pour les attributs @rel, @rev, @property à travers le document (en particulier, la section 2.4 était fausse). [BenAdida]
Cette section est informative.
Au moment de la publication, les membres du groupe de travail Semantic Web Deployment étaient les suivants :
Au moment de la publication, les membres du groupe de travail XHTML 2 étaient les suivants :