RDFa dans XHTML — Syntaxe et traitement

Une collection d'attributs et de règles de traitement pour étendre XHTML et gérer RDF

Recommandation du W3C du 14 octobre 2008

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.

Résumé

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.

Comment lire ce document

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.

Statut de ce document

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.

Table des matières

1. Motivation

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.

2. Vue d'ensemble de la syntaxe

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 :

2.1. Les attributs RDFa

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.

2.2. Exemples

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>

3. Terminologie RDF

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].

3.1. Déclarations

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.

3.2. Triplets

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".

3.3. Références URI

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>.

3.4. Littéraux ordinaires

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".

3.5. Littéraux typés

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>.

3.6. Turtle

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.

3.7. Graphes

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 :

3.8. Adresses URI compactes

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.

3.9. Fragments XHTML et RDFa

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.

3.10. Une description de RDFa en termes RDF

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).

4. Exigences de conformité

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.

4.1. Conformité du document

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 :

1. Le document DOIT respecter les contraintes exprimées dans les schémas de l'Annexe A — Définition de type de document XHTML+RDFa ;

2. La partie locale de l'élément racine du document DOIT être « html » ;

3. 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">
   

4. Il DEVRAIT y avoir un attribut @version sur l'élément html avec la valeur "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].

4.2. Conformité de l'agent utilisateur

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.

4.3. Conformité du processeur RDFa

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.

5. Modèle de traitement

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]).

5.1. Vue d'ensemble

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].

5.2. Contexte d'évaluation

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.

5.3. Chaînage

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>
  

5.4. Traitement des adresses CURIE et URI

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>

5.4.1. Visibilité des liaisons de préfixe

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>

5.4.2. Conversion d'une adresse CURIE en adresse URI

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 :

1. Couper l'adresse CURIE au caractère DEUX-POINTS pour obtenir le préfixe et la ressource ;
2. À l'aide du préfixe et des liaisons visibles courantes, obtenir l'adresse URI à laquelle le préfixe est associé ;
3. Concaténer l'adresse URI associée avec la valeur de ressource, pour obtenir une adresse URI absolue.

5.4.3. Utilisation générale des adresses CURIE dans les attributs

L'utilisation des adresses CURIE par les attributs se fera de plusieurs façons, et leur traitement sera différent. Les voici :

1. 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 ;
2. 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.

5.4.4. Utilisation des adresses CURIE dans les attributs spécifiques

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" />

5.4.5. Référencement des nœuds anonymes

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 .

5.5. Séquence

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 :

1. Les valeurs locales sont d'abord initialisées, comme suit :
   • le drapeau de [récursion] est mis à « vrai » ;
   • le drapeau de [saut d'élément] est mis à « faux » ;
   • le [nouveau sujet] est mis à la valeur nulle ;
   • la [ressource objet courante] est mise à la valeur nulle ;
   • la [liste locale des liaisons URI] prend la liste des liaisons URI du [contexte d'évaluation] ;
   • la [liste locale des triplets incomplets] est mise à la valeur nulle ;
   • la [langue courante] prend la valeur de [langue] du [contexte d'évaluation].
   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..
2. 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.
3. 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.
4. 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 :

   • s'il s'agit de l'élément 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 l'attribut @typeof est présent, obtenu selon la section Traitement des adresses CURIE et URI, alors le [nouveau sujet] est établi comme étant un [nœud anonyme] nouvellement créé ;
   • sinon, si l'[objet parent] est présent, le [nouveau sujet] prend la valeur de l'[objet parent]. En outre, si l'attribut @property n'est pas présent, alors le drapeau de [saut d'élément] est mis à « vrai » ;
5. 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 :

   • en utilisant l'adresse URI de l'attribut @about, si présent, obtenue selon la section Traitement des adresses CURIE et URI;
   • sinon, en utilisant l'adresse URI de l'attribut @src, si présent, selon la section Traitement des adresses CURIE et URI.

   Si aucune adresse URI n'est fournie, alors la première règle correspondante suivante s'appliquera :

   • s'il s'agit de l'élément 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 ;
   • si l'attribut @typeof est présent, obtenu selon la section Traitement des adresses CURIE et URI, alors le [nouveau subjet] est établi comme étant un [nœud anonyme] nouvellement créé ;
   • sinon, si l'[objet parent] est présent, le [nouveau sujet] prend sa valeur.

   Ensuite la [ressource objet courante] prend l'adresse URI obtenue à la première règle correspondante suivante :

   • en utilisant l'adresse URI de l'attribut @resource, si présent, obtenue selon la section Traitement des adresses CURIE et URI ;
   • sinon, en utilisant l'adresse URI de l'attribut @href, si présent, obtenue selon la section Traitement des adresses CURIE et URI.

   Notez que la valeur finale de la [ressource objet courante] sera soit la valeur nulle (de l'initialisation), soit une adresse URI complète.

6. 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.
7. 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 :

   • Si présent, l'attribut @rel peut 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

     adresse URI complète

     objet

     [ressource objet courante]

   • Si présent, l'attribut @rev peut 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

     [ressource objet courante]

     prédicat

     adresse URI complète

     objet

     [nouveau sujet]

8. 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 :

   • Si présent, l'attribut @rel doit contenir une ou plusieurs adresses URI, obtenues selon la section Traitement des adresses CURIE et URI, chacune s'ajoutant à la [liste locale des triplets incomplets] comme suit :

     prédicat

     adresse URI complète

     direction

     en avant (forward)

   • Si présent, l'attribut @rev doit contenir une ou plusieurs adresses URI, obtenues selon la section Traitement des adresses CURIE et URI, chacune s'ajoutant à la [liste locale des triplets incomplets] comme suit :

     prédicat

     adresse URI complète

     direction

     en arrière (reverse)

9. 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 ».

10. 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 :
    La [liste des triplets incomplets] du [contexte d'évaluation] courant (pas la [liste locale des triplets incomplets]) contiendra zéro ou plus adresses URI de prédicat. Cette liste est itérée et chacun des prédicats est utilisé avec le [sujet parent] et le [nouveau sujet] pour générer un triplet. Notez qu'à chaque niveau se trouvent deux listes de [triplets incomplets] : l'une pour le niveau de traitement courant (qui est passée à chaque élément fils dans l'étape précédente) et l'autre reçue comme partie du [contexte d'évaluation]. C'est cette dernière qui est utilisée pour le traitement pendant cette étape.
    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 la [direction] est « en avant » (forward), alors le triplet suivant est généré :

      sujet

      [sujet parent]

      prédicat

      le prédicat du [triplet incomplet] itéré

      objet

      [nouveau sujet]

    • Si la [direction] n'est pas « en avant », alors ce triplet-ci est généré :

      sujet

      [nouveau sujet]

      prédicat

      le prédicat du [triplet incomplet] itéré

      objet

      [sujet parent]

11. 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 :
    • Si le drapeau de [saut d'élément] est « vrai », alors le nouveau [contexte d'évaluation] est une copie du contexte courant qui a été passé à ce niveau de traitement, les valeurs de [langue] et de la [liste des liaisons URI] étant remplacées par les valeurs locales ;
    • Sinon, les valeurs sont les suivantes :
      • la [base] prend la valeur de [base] du [contexte d'évaluation] courant ;
      • le [sujet parent] prend la valeur du [nouveau sujet], si non nulle, ou la valeur du [sujet parent] du [contexte d'évaluation] courant ;
      • l'[objet parent] prend la valeur de la [ressource objet courante], si non nulle, ou la valeur du [nouveau sujet], si non nulle, ou la valeur du [sujet parent] du [contexte d'évaluation] courant ;
      • la [liste des liaisons URI] est celle de la [liste locale des liaisons URI] ;
      • la [liste des triplets incomplets] est celle de la [liste locale des triplets incomplets] ;
      • la [langue] prend la valeur de la [langue courante].

6. Traitement RDFa en détails

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.

6.1. Changement du contexte d'évaluation

6.1.1. Établir le sujet courant

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].

6.1.1.1. Le document courant

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" .

6.1.1.2. Utilisation de l'attribut @about

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" .

6.1.1.3. Utilisation de l'attribut @src

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" .

6.1.1.4. Créer un nouvel élément avec @typeof

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" .

6.1.1.5. Déterminer le sujet sans @about ni @typeof

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.

6.1.1.5.1. Hériter le sujet à partir de @resource

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.

6.1.1.5.2. Hériter un sujet anonyme

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.

6.2. Compléter les « triplets incomplets »

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> .

6.3. Résolution des objets

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.

6.3.1. Résolution des objets littéraux

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.

6.3.1.1. Littéraux ordinaires

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>

6.3.1.1.1. Étiquettes de langue

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>

6.3.1.2. Littéraux typés

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 .

6.3.1.3. Littéraux XML

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&lt;sup&gt;2&amp;lt;/sup&gt;: 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.

6.3.2. Résolution des objets URI

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.

6.3.2.1. Utilisation de @resource pour établir l'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> .

6.3.2.2. Utilisation de @href

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> .

6.3.2.3. Triplets incomplets

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 ».

7. Définition de la syntaxe CURIE

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 :

• un jeu de liaisons des préfixes aux adresses URI ;
• une liaison à utiliser avec le préfixe par défaut (par exemple, :p) ;
• une liaison à utiliser quand il n'y a pas de préfixe (par exemple, p) ;
• une liaison à utiliser avec le préfixe « _ », qui sert à générer des identificateurs uniques (par exemple, _:p).

Dans RDFa, ces valeurs sont définies ainsi :

• l'ensemble des liaisons des préfixes aux adresses URI est fourni par les déclarations de préfixe visible courantes (current in-scope prefix declarations) de l'[élément courant] pendant l'analyse ;
• la liaison à utiliser avec le préfixe par défaut est la liaison de préfixe par défaut courante ;
• la liaison à utiliser quand il n'y a pas de préfixe n'est pas définie, ce qui interdit effectivement l'utilisation des adresses CURIE ne contenant pas de caractère DEUX-POINTS ;
• la liaison à utiliser avec le préfixe « _ » n'est pas déclarée explicitement mais puisqu'elle est utilisée pour générer les [nœuds anonymes], sa mise en œuvre doit être compatible avec la définition RDF.

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.

8. Définition XHTML+RDFa

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.

Module de structure

body, head, html, title

Module de texte

abbr, acronym, address, blockquote, br, cite, code, dfn, div, em, h1, h2, h3, h4, h5, h6, kbd, p, pre, q, samp, span, strong, var

Module hypertexte

a et @href sont disponibles sur tous les éléments.

Module de liste

dl, dt, dd, ol, ul, li

Module d'objet

object, param

Module de présentation

b, big, hr, i, small, sub, sup, tt

Module d'édition

del, ins

Module de texte bidirectionnel

bdo

Module de formulaire

button, fieldset, form, input, label, legend, select, optgroup, option, textarea

Module de table

caption, col, colgroup, table, tbody, td, tfoot, th, thead, tr

Module d'image

img

Module d'image sensible côté client

area, map

Module d'image sensible côté serveur

Attribut ismap sur img

Module des événements intrinsèques

Attributs des événements

Module de métainformation

meta

Module de script

noscript, script

Module de feuille de style

Élément style

Module des attributs de style (à éviter)

@style

Module de cible

@target

Module de lien

link

Module de base

base

Module des attributs de métainformation

@about, @content, @datatype, @typeof, @property, @rel, @resource, @rev

XHTML+RDFa utilise aussi le module d'annotation ruby telle que définie dans [RUBY] :

Module d'annotation 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.

9. Module des attributs de métainformation

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].

9.1. Types de données

Certains attributs dans cette section utilisent les types de données suivants :

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.

9.2. Collection des attributs de métaiformation

Les attributs suivants sont inclus dans la collection d'attributs, et prennent des valeurs dans le type de donnée associé :

On trouvera une mise en œuvre de ce module à l'Annexe A.

9.3. Valeurs des attributs @rel/@rev

La liste des valeurs réservées pour les attributs @rel et @rev est la suivante :

alternate

Désigne les versions alternatives d'une ressource.

appendix

Se rapporte à une ressource servant d'annexe dans une collection.

bookmark

Se rapporte à un signet. Un signet est un lien vers un point d'entrée clé au sein d'un document étendu. L'attribut @title peut servir, par exemple, à intituler le signet. Notez que plusieurs signets peuvent être définis pour un document.

cite

Se rapporte à une ressource qui définit une citation. Dans l'exemple suivant, la valeur 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> .

La valeur 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> .

chapter

Se rapporte à une ressource servant de chapitre dans une collection.

contents

Se rapporte à une ressource servant de table des matières.

copyright

Se rapporte à une déclaration de droits d'auteur pour la ressource.

first

Se rapporte au premier article dans une collection (cf. également start et top).

glossary

Se rapporte à une ressource fournissant un glossaire des termes.

help

Se rapporte à une ressource offrant une aide (plus d'informations, des liens vers d'autres sources d'information, etc.)

icon

Se rapporte à une ressource qui représente une icone.

index

Se rapporte à une ressource fournissant un index.

last

Se rapporte à la dernière ressource dans une collection de ressources.

license

Se rapporte à une ressource qui définit la licence associée à une ressource.

meta

Se rapporte à une ressource qui fournit des métadonnées, par exemple en RDF.

next

Se rapporte à la ressource suivante (après celle courante) dans une collection ordonnée.

p3pv1

Se rapporte à un fichier de référence de politique P3P. Cf. [P3P].

prev

Se rapporte à la ressource précédente (avant celle courante) dans une collection ordonnée.

role

Indique le but de la ressource. Pour quelques valeurs possibles, cf. [XHTMLVOCAB].

section

Se rapporte à une ressource servant de section dans une collection.

stylesheet

Se rapporte à une ressource agissant comme feuille de style d'une ressource.

subsection

Se rapporte à une ressource servant de sous-section dans une collection.

start

Se rapporte à la première ressource dans une collection de ressources. Un cas d'utilisation typique serait celui d'une collection de chapitres dans un livre.

top

Synonyme de start.

up

Se rapporte à une ressource « supérieure » dans un ensemble à structure hiérarchique.

A. Définition DTD XHTML+RDFa

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.

A.1. Module des attributs de métainforamtion XHTML

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 -->

A.2. Module de modèle de contenu XHTML+RDFa

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 -->

A.3. Module de pilote XHTML+RDFa

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  ................................................ -->
<!-- ....................................................................... -->

A.4. Entrée Open Catalog SGML de XHTML+RDFa

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  ..................................................... --
-- .......................................................................... --

B. Types de données CURIE

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 :

• DTD xhtml-datatypes.mod
• XML Schema xhtml-datatypes.xsd

Spécifiquement, les types de données suivants sont introduits :

CURIE

Une seule adresse de type curie

CURIEs

Une liste d'adresses de type CURIE séparées par des caractères blancs

SafeCURIE

Une seule adresse de type safe_curie

SafeCURIEs

Une liste d'adresses de type SafeCURIE séparées par des caractères blancs

URIorSafeCURIE

Une adresse de type URI ou SafeCURIE (puisque l'on a besoin d'une adresse de type SafeCURIE pour distinguer sans ambiguïté une adresse URI d'une adresse CURIE)

URIorSafeCURIEs

Une liste d'adresses de type URIorSafeCURIE séparées par des caractères blancs

B.1. Définition XML Schema

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>

B.2. Définition DTD XML

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" >

C. Conseil de déploiement

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.

D. Références

D.1. Spécifications liées

Cette section est normative.

[IRI]

Identificateurs de ressource internationalisés (IRI), RFC 3987, M.Duerst, M. Suignard, janvier 2005.
Disponible à : http://www.ietf.org/rfc/rfc3987.txt

[P3P]

La spécification de la plateforme de préférences de confidentialité 1.0 (P3P 1.0), Recommandation du W3C, L. Cranor et al., 16 avril 2002.
Disponible à : http://www.w3.org/TR/2002/REC-P3P-20020416/

[RFC2119]

Mots-clés à utiliser dans les documents RFC pour indiquer les niveaux d'exigence, RFC 2119, S. Bradner, mars 1997.
Disponible à : http://www.rfc-editor.org/rfc/rfc2119.txt

[RFC3236]

Le type de média "application/xhtml+xml", M. Baker, P. Stark, janvier 2002.
Disponible à : http://www.ietf.org/rfc/rfc3236.txt

[RUBY]

L'annotation ruby, recommandation du W3C, Marcin Sawicki, et al., 31 mai 2001.
Cf. http://www.w3.org/TR/2001/REC-ruby-20010531

[URI]

Identificateur de ressource uniforme (URI) — Syntaxe générique, RFC 3986, T. Berners-Lee, R. Fielding, L. Masinter, janvier 2005.
Disponible à : http://www.ietf.org/rfc/rfc3986.txt

[XMLBASE]

XML Base, recommandation du W3C, J. Marsh, ed., 27 juin 2001.
Disponible à : http://www.w3.org/TR/2001/REC-xmlbase-20010627/

[XMLNS]

Les espaces de noms en XML, recommandation du W3C, T. Bray et al., eds., 14 janvier 1999.
Disponible à : http://www.w3.org/TR/1999/REC-xml-names-19990114

[XML-LANG]

Langage de balisage extensible (XML) 1.0 (troisième édition), recommandation du W3C, T. Bray et al., eds., 4 février 2004.
Disponible à : http://www.w3.org/TR/2004/REC-xml-20040204

[XHTMLMOD]

XHTML Modularization 1.1, recommandation du W3C, Shane McCarron, et al., 8 octobre 2008
Cf. http://www.w3.org/TR/2008/REC-xhtml-modularization-20081008

[XMLSCHEMA]

XML Schema tome 1 — Structures (deuxième édition), recommandation du W3C, H. S. Thompson et al., eds., 28 octobre 2004.
Disponible à : http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/
Cf. également XML Schema tome 2 — Types de données (deuxième édition), disponible à : http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/

D.2. Autres références

Cette section est informative.

[CATALOG]

Entity Management: OASIS Technical Resolution 9401:1997 (Amendment 2 to TR 9401), Paul Grosso, Chair, Entity Management Subcommittee, SGML Open, 10 septembre 1997.
Cf. http://www.oasis-open.org/html/a401.htm

[DBPEDIA]

DBPedia (cf. http://dbpedia.org/.)

[DC]

Dublin Core Metadata Initiative (DCMI) (cf. http://dublincore.org/.)

[FOAF-PROJECT]

The FOAF Project (cf. http://www.foaf-project.org.)

[GRDDL]

Glâner les descriptions de ressource des dialectes de langages (GRDDL), recommandation du W3C, D. Connolly, ed., 11 septembre 2007.
Disponible à : http://www.w3.org/TR/2007/REC-grddl-20070911

[HTML4]

Spécification HTML 4.01, recommandation du W3C, D. Raggett et al., eds., 24 décembre 1999.
Disponible à : http://www.w3.org/TR/1999/REC-html401-19991224

[MICROFORMATS]

Cf. microformats.org.

[RDFHTML]

RDF-in-HTML Task Force (cf. http://www.w3.org/2001/sw/BestPractices/HTML/.)

[RDFa Primer]

Introduction à RDFa 1.0 — Incorporation de données structurées dans les pages web (cf. http://www.w3.org/TR/xhtml-rdfa-primer/.)

[RDF-CONCEPTS]

Cadre de description des ressources (RDF) — Concepts et syntaxe abstraite (cf. http://www.w3.org/TR/rdf-concepts/.)

[RDF-PRIMER]

Introduction à RDF (cf. http://www.w3.org/TR/rdf-primer/.)

[RDF-SYNTAX]

Syntaxe et grammaire RDF/XML (cf. http://www.w3.org/TR/rdf-syntax-grammar/.)

[RDFTESTS-DATATYPES-TEST001]

datatypes/test001.nt (cf. http://www.w3.org/2000/10/rdf-tests/rdfcore/datatypes/test001.nt.)

[RDFTESTS-RDFMS-XMLLANG-TEST006]

rdfms-xmllang/test006.nt (cf. http://www.w3.org/2000/10/rdf-tests/rdfcore/rdfms-xmllang/test006.nt.)

[RELAXNG]

Page d'accueil RELAX NG (cf. http://www.relaxng.org/.)

[SWD-WG]

Groupe de travail Semantic Web Deployment (cf. http://www.w3.org/2006/07/SWD/.)

[TURTLE]

Turtle — Terse RDF Triple Language, David Beckett, Tim Berners-Lee, janvier 2008.
Cf. http://www.w3.org/TeamSubmission/turtle/

[XHTML 1.1]

XHTML 1.1 — XHTML fondé sur des modules, recommandation du W3C, M. Altheim, S. McCarron, 31 mai 2001.
Disponible à : http://www.w3.org/TR/2001/REC-xhtml11-20010531/.

[XHTML2-WG]

Groupe de travail XHTML 2 (cf. http://www.w3.org/MarkUp/.)

[XHTMLMIME]

Types de média XHTML, Masayasu Ishikawa, 1 août 2002.
Dernière version disponible à : http://www.w3.org/TR/xhtml-media-types

[XHTMLVOCAB]

Vocabulaire XHTML, groupe de travail XHTML 2.
Disponible à : http://www.w3.org/1999/xhtml/vocab

E. Historique des changements

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]

F. Remerciements

Cette section est informative.

Au moment de la publication, les membres du groupe de travail Semantic Web Deployment étaient les suivants :

• Ben Adida, Creative Commons (secrétaire du groupe d'étude RDFa)
• Thomas Baker, Kompetenzzentrum Interoperable Metadaten (KIM) (vice-président)
• Sean Bechhofer, University of Manchester
• Diego Berrueta, Fundación CTIC
• Jeremy Carroll, TopQuadrant
• Michael Hausenblas, K-Space
• Antoine Isaac, Vrije Universiteit
• Elisa Kendall, Sandpiper Software, Inc.
• Alistair Miles, Science & Technology Facilities Council
• Vit Novacek, DERI Galway at the National University of Ireland
• Simone Onofri, International Webmasters Association / HTML Writers Guild (IWA-HWG)
• Jon Phipps, expert invité
• Clay Redding, Library of Congress
• Quentin Reul, University of Aberdeen
• Daniel Rubin, Stanford University
• Guus Schreiber, Vrije Universiteit (vice-président)
• Margherita Sini, UN Food and Agriculture Organization (expert invité)
• Manu Sporny, Digital Bazaar (expert invité)
• Ed Summers, Library of Congress
• Ralph Swick, W3C

Au moment de la publication, les membres du groupe de travail XHTML 2 étaient les suivants :

• Roland Merrick, IBM (vice-président du groupe de travail XHTML 2)
• Steven Pemberton, CWI (vice-président du groupe de travail XHTML 2)
• Mark Birbeck, webBackplane (expert invité)
• Susan Borgrink, Progeny Systems
• Christina Bottomley, Society for Technical Communication (STC)
• Alessio Cartocci, International Webmasters Association / HTML Writers Guild (IWA-HWG)
• Alexander Graf, University of Innsbruck
• Tina Holmboe, Greytower Technologies (expert invité)
• John Kugelman, Progeny Systems
• Luca Mascaro, International Webmasters Association / HTML Writers Guild (IWA-HWG)
• Shane McCarron, Applied Testing and Technology, Inc. (expert invité)
• Michael Rawling, IVIS Group Limited
• Gregory Rosmaita, expert invité
• Sebastian Schnitzenbaumer, Dreamlab Technologies AG
• Richard Schwerdtfeger, IBM
• Elias Torres, IBM
• Masataka Yakura, Mitsue-Links Co., Ltd.
• Toshihiko Yamakami, ACCESS Co., Ltd.