- Cette version :
- http://www.w3.org/TR/2008/REC-rdfa-syntax-20081014
- Dernière version :
- http://www.w3.org/TR/rdfa-syntax
- Version précédente :
- http://www.w3.org/TR/2008/PR-rdfa-syntax-20080904
- Différence par rapport à la version précédente :
- rdfa-syntax-diff.html
- Rédacteurs :
- Ben Adida, Creative Commons ben@adida.net
- Mark Birbeck, webBackplane mark.birbeck@webBackplane.com
- Shane McCarron, Applied Testing and Technology, Inc. shane@aptest.com
- Steven Pemberton, CWI
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 à:
- ceux qui cherchent à créer un analyseur RDFa (RDFa parser),
qui ont donc besoin d'une description détaillées des règles d'analyse ;
- ceux qui cherchent à recommander l'utilisation de RDFa au sein de leur organisation,
et qui voudraient créer un mode d'emploi pour leurs utilisateurs ;
- quiconque connaît RDF et veut mieux comprendre ce qui se passe « sous le capot » d'un analyseur RDFa.
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 :
- @rel
- une liste d'adresses CURIE, séparées par des caractères blancs,
utilisée pour exprimer des relations entre deux ressources (des prédicats (predicates)
dans la terminologie RDF) ;
- @rev
- une liste d'adresses CURIE, séparées par des caractères blancs,
utilisée pour exprimer des relations entre deux ressources (des « prédicats » aussi);
- @content
- une chaîne, pour fournir le contenu interprétable par une machine d'un littéral (un « objet littéral ordinaire » (plain literal object)
dans la terminologie RDF) ;
- @href
- une adresse URI
pour exprimer la ressource partenaire d'une relation (un « objet ressource » (resource object)
dans la terminologie RDF) ;
- @src
- une adresse URI
pour exprimer la ressource partenaire d'une relation lorsque la ressource est incorporée (un « objet ressource » aussi).
Les nouveaux atttributs — spécifiques de RDFa — sont les suivants :
- @about
- une valeur de type URIorSafeCURIE, utilisée pour déclarer à propos de quoi
sont les données (un « sujet » (subject) dans la terminologie RDF) ;
- @property
- une liste d'adresses CURIE, séparées par des caractères blancs,
utilisée pour exprimer des relations entre un sujet et un texte littéral (également un « prédicat ») ;
- @resource
- une valeur de type URIorSafeCURIE pour exprimer la ressource partenaire
d'une relation non destinée à être « cliquable » (également un « objet ») ;
- @datatype
- une adresse CURIE représentant un type de données, pour exprimer le type de donnée
d'un littéral ;
- @typeof
- une liste d'adresses CURIE, séparées par des caractères blancs,
qui indique le(s) type(s) RDF à associer à un sujet.
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">
- Il DEVRAIT y avoir un attribut @version
sur l'élément
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]).
Dans cette section, notez que les explications à propos du modèle de traitement ou les conseils aux implémenteurs
se présentent dans un cadre comme celui-ci.
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 :
- La [base] (base).
Ce sera habituellement l'adresse URL du document traité, mais ça pourrait être une autre adresse URL,
établie par un autre mécanisme tel que l'élément XHTML
base. Ce qui importe c'est qu'elle établisse
une adresse URL par rapport à laquelle les chemins relatifs peuvent être résolus ;
- Le [sujet parent] (parent subject).
Il aura la même valeur initiale que celle de [base], mais elle changera normalement au cours du traitement ;
- L'[objet parent] (parent object).
Dans certaines situations, l'objet d'une déclaration devient le sujet de déclarations imbriquées, et cette propriété sert à véhiculer cette valeur.
Notez que cette valeur peut être un nœud anonyme (bnode), puisque parfois plusieurs déclarations imbriquées
sont regroupées sur un seul nœud anonyme. Cela signifie que le nœud anonyme doit être établi dans la déclaration contenante et passé
en aval, et cette propriété sert à communiquer cette valeur.
- Une liste des [liaisons URI] (URI mappings) courantes dans le champs ;
- Une liste des [triplets incomplets].
Un triplet est incomplet lorsqu'aucune ressource d'objet n'est fournie avec un prédicat qui exige une ressource
(c'est-à-dire @rel ou @rev). Les triplets peuvent être complétés lorsqu'une ressource
devient disponible, ce qui sera le cas lorsque le sujet suivant est spécifié, lors d'une étape du processus appelée
[chaînage] (chaining).
- La [langue] (language).
Notez qu'il n'y a pas de langue par défaut.
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 :
- Une liste de [liaisons URI], initialement vide,
appelée la [liste locale des liaisons URI] ;
- Une [liste des triplets incomplets], initialement vide,
appelée la [liste locale des triplets incomplets] ;
- Une valeur de [langue], initialement vide ;
- Un drapeau de [récursion] (recurse). Le traitement continue en général récursivement à travers
l'arbre entier des éléments disponibles. En revanche, si un auteur indique qu'une branche de l'arbre devrait être traitée comme un
littéral XML, aucun traitement ultérieur ne devrait intervenir sur cette branche ; cet effet est obtenu en mettant le
drapeau à « faux » ;
- Un drapeau de [saut d'élément] (skip element),
qui indique si l'[élément courant] peut être ignoré en toute sécurité
car il n'a pas d'attributs RDFa pertinents. Notez que les éléments descendants seront encore traités ;
- Une valeur de [sujet nouveau], qui une fois calculée établira la propriété
de [sujet parent] dans un [contexte d'évaluation],
et servira à compléter les [triplets incomplet], comme décrit dans la section suivante ;
- Une valeur pour le [littéral objet courant], lequel est le littéral à utiliser
lors de la création de triplets qui ont un objet littéral ;
- Une valeur pour la [ressource objet courante], laquelle est la ressource à utiliser
lors de la création de triplets qui ont un objet ressource.
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 :
- Couper l'adresse CURIE au caractère DEUX-POINTS pour obtenir le préfixe et la ressource ;
- À l'aide du préfixe et des liaisons visibles courantes, obtenir l'adresse URI à laquelle le préfixe est associé ;
- Concaténer l'adresse URI associée avec la valeur de ressource, pour obtenir une adresse URI absolue.
Notez que l'on considère comme une bonne idée de ne pas utiliser des chemins relatifs dans les déclarations d'espace de noms,
mais puisqu'il se trouvera sans doute un auteur pour ignorer ce conseil, il est en outre possible que l'adresse
URI obtenue à partir d'une
adresse
CURIE soit relative. En revanche, puisque toutes les adresses
URI doivent être résolues par rapport à
la [
base] avant de pouvoir s'en servir pour créer des triplets, l'utilisation de chemins relatifs
ne devrait avoir aucun effet sur le traitement.
L'utilisation des adresses CURIE par les attributs se fera de plusieurs façons, et leur traitement sera différent. Les voici :
- L'attribut ne peut admettre qu'une ou plusieurs valeurs CURIE, en refusant d'autres types de valeur. Auquel cas,
toute valeur qui n'est pas de type
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 ;
- L'attribut peut admettre une ou plusieurs valeurs qui sont un mélange d'adresses CURIE et d'adresses URI complètes.
Auquel cas, toute valeur non entourée de crochets, comme défini par la production
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 :
- @about et @resource acceptent soit une adresse URI, soit une adresse CURIE
exprimée comme [adresse CURIE sûre]) ;
- @href et @src n'acceptent qu'une adresse URI ;
- @property, @datatype et @typeof n'acceptent que des valeurs CURIE ;
- @rel et @rev acceptent à la fois les types de lien XHTML et les adresses CURIE.
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 :
- la [base] est fixée soit à l'adresse URL du document, soit à la valeur spécifiée
dans l'élément
base si présent ;
Notez que
XHTML 1.1, et donc
XHTML+RDFa,
ne permet pas l'utilisation de
@xml:base, et la seule façon de changer la [
base] est par l'élément
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 [sujet parent] reçoit la valeur de la [base] ;
- l'[objet parent] est mis à la valeur nulle ;
- la [liste des liaisons URI] est vide ;
- la [liste des triplets incomplets] est vide ;
- la [langue] est mise à la valeur nulle.
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 :
- Les valeurs locales sont d'abord initialisées, comme suit :
Notez que certaines variables locales sont des conteneurs temporaires de valeurs qui seront passées aux
éléments descendants via un [
contexte d'évaluation]. Les conteneurs auront parfois
le même nom, et donc pour préciser duquel il s'agit dans les étapes suivantes, nous désignerons généralement la version locale en tant que telle..
- Ensuite, l'[élément courant] est analysé à la recherche de
[liaisons URI], qui s'ajouteront à la
[liste locale des liaisons URI]. Notez qu'une
[liaison URI] remplacera simplement toute liaison courante de même nom dans la liste ;
Les liaisons sont fournies par des attributs
@xmlns. La valeur à lier est indiquée
par le préfixe d'espace de noms
XML, et la valeur à associer est la valeur de l'attribut — une adresse
URI.
Notez que l'adresse
URI n'est traitée d'aucune façon ; en particulier, s'il s'agit d'un chemin relatif, il n'est pas résolu
par rapport à la [
base] courante. On conseille aux auteurs d'adopter les pratiques exemplaires
d'utilisation des espaces de noms, y compris ne pas utiliser de chemins relatifs.
- L'[élément courant] est également analysé à la recherche d'une information de langue qui,
si présente, établit la [langue courante] ;
L'information de langue peut être fournie avec l'attribut
XML d'utilisation générale
@xml:lang.
- Si l'[élément courant] ne contient ni attribut @rel,
ni attribut @rev, l'étape suivante est alors d'établir la valeur du [nouveau sujet].
N'importe quel attribut portant une ressource peut établir un [nouveau sujet] ;
Le [
nouveau sujet] prend l'adresse
URI obtenue
à la première règle correspondante suivante :
- en utilisant l'adresse URI de @about, si présent, obtenue selon la section
Traitement des adresses CURIE et URI ;
- sinon, en utilisant l'adresse URI de @src, si présent, obtenue selon la section
Traitement des adresses CURIE et URI ;
- sinon, en utilisant l'adresse URI de @resource, si présent, obtenue selon la section
Traitement des adresses CURIE et URI;
- sinon, en utilisant l'adresse URI de @href, si présent, obtenue selon la section
Traitement des adresses CURIE et URI.
Si aucune adresse URI n'est fournie par un attribut de ressource, alors la première règle correspondante suivante s'appliquera :
- Si l'[élément courant] contient un attribut @rel
ou @rev, alors l'étape suivante est d'établir à la fois une valeur de
[nouveau sujet] et une valeur de [ressource objet courante] :
Le [
nouveau sujet] reçoit l'adresse
URI obtenue
à la première règle correspondante suivante :
Si aucune adresse URI n'est fournie, alors la première règle correspondante suivante s'appliquera :
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.
- Si, dans l'une des étapes précédentes, un [nouveau sujet] prend une valeur non nulle,
il sert maintenant à fournir un sujet pour les valeurs de type ;
On peut définir un ou plusieurs « types » pour le [
nouveau sujet]
en utilisant l'attribut
@typeof. Si présent, l'attribut doit contenir une ou plusieurs adresses
URI,
obtenues selon la section
Traitement des adresses CURIE et URI,
chacune servant à générer un triplet comme suit :
- sujet
- [nouveau sujet]
- prédicat
- http://www.w3.org/1999/02/22-rdf-syntax-ns#type
- objet
- adresse URI complète du type
Notez que rien dans ce bloc n'est exécuté s'il n'y a aucune valeur [
nouveau sujet],
c'est-à-dire que [
nouveau sujet] reste à la valeur nulle.
- Si, dans l'une des étapes précédentes, une [ressource objet courante]
prend une valeur non nulle, elle sert maintenant à générer des triplets :
Les prédicats pour la [
ressource objet courante]
peuvent être établis en utilisant l'un des attributs
@rel ou
@rev, ou les deux :
- Par contre, si la [ressource objet courante] était mise à la valeur nulle,
et que des prédicats sont présents, ceux-ci doivent alors être stockés comme des
[triplets incomplets], en attendant la découverte d'un sujet pouvant être utilisé comme objet.
On devrait également établir la [ressource objet courante] comme étant un
[nœud anonyme] nouvellement créé ;
Les prédicats pour les [
triplets incomplets] peuvent être établis
en utilisant l'un des attributs
@rel ou
@rev, ou les deux :
- L'étape d'itération suivante est d'établir un [littéral objet courant] ;
Les prédicats pour le [
littéral objet courant]
peuvent être établis en utilisant l'attribut
@property. Si présent, une ou plusieurs adresses
URI
sont obtenues selon la section
Traitement des adresses CURIE et URI,
et la valeur littérale réelle s'obtient comme suit :
- comme un [littéral typé] si :
- l'attribut @datatype est présent, n'a pas une valeur vide, et n'a pas la valeur "
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.
- comme un [littéral ordinaire] si :
- l'attribut @content est présent ;
- ou tous les fils (children) de l'[élément courant]
sont des nœuds de texte ;
- ou il n'y a aucun nœud fils (child node), auquel cas la valeur littérale est la chaîne vide ;
- ou le corps de l'[élément courant] contient bien des nœuds fils non textuels
mais l'attribut @datatype est présent avec une valeur vide.
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.
- comme un [littéral XML] si :
- l'[élément courant] a des nœuds fils qui ne sont pas de simples nœuds de texte,
et que l'attribut @datatype n'est pas présent, ou est présent mais avec la valeur "
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 :
- sujet
- [nouveau sujet]
- prédicat
- adresse URI complète
- objet
- [littéral objet courant]
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 ».
- Si le drapeau de [saut d'élément] est à « faux »,
et que le [nouveau sujet] a une valeur non nulle, alors tous les
[triplets incomplets] dans le contexte courant devraient être complétés :
Notez que chaque [
triplet incomplet]
a une valeur de [
direction] qui sert à déterminer ce qui deviendra le sujet et ce qui deviendra
l'objet de chaque triplet généré :
- Si le drapeau de [récursion] est « vrai », touts les éléments fils de
l'[élément courant] sont traités en utilisant les règles décrites ici, avec un nouveau
[contexte d'évaluation], initialisé comme suit :
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 :
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 :