Lisez-moi S.V.P. 
W3C

Spécification de la syntaxe RDF/XML (révisée)

Recommandation du W3C du 10 février 2004

Cette version :
http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/
Dernière version :
http://www.w3.org/TR/rdf-syntax-grammar/
Version précédente :
http://www.w3.org/TR/2003/PR-rdf-syntax-grammar-20031215/
Rédacteur :
Dave Beckett (University of Bristol)
Rédacteur de la série :
Brian McBride (Hewlett Packard Labs)

Veuillez consulter la page des errata→vf de ce document, laquelle peut contenir des corrections normatives.

Cf. également d'éventuelles traductions.


Résumé

Le cadre de description de ressource RDF (Resource Description Framework) est un langage d'utilisation générale pour représenter des informations sur le web.

Ce document définit une syntaxe XML pour RDF, appelée RDF/XML, en fonction des Espaces de noms en XML, de l'Ensemble d'information XML et de XML Base. La grammaire formelle de la syntaxe est annotée avec des actions générant les triplets du graphe RDF comme défini dans Concepts et syntaxe abstraite RDF. Les triplets sont écrits en utilisant le format de sérialisation de graphe RDF N-Triples qui permet un enregistrement de la mise en correspondance (mapping) plus précis dans une forme interprétable par une machine. Les mises en correspondances sont enregistrées comme des cas d'utilisation (use cases), réunis et publiés dans les Jeux d'essais RDF.

Statut de ce document

Ce document a été examiné par les membres du W3C et des tiers intéressés et il a été approuvé par le Directeur comme recommandation du W3C. 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.

Ce document fait partie d'un ensemple de six (Initiation, Concepts, Syntaxe, Sémantique, Vocabulaire et Jeux d'essais) destinés à remplacer conjointement les spécifications RDF originales, à savoir Modèle et syntaxe RDF (recommandation de 1999) et Schéma RDF (recommandation candidate de 2000). Il a été développé par le groupe de travail RDF Core sous l'égide de l'activité Semantic Web du W3C (déclaration d'activité, charte du groupe) pour une publicaiton le 10 février 2004.

Les changements effectués sur ce document depuis le projet de recommandation proposée sont détaillés dans le journal des changements.

Le public est invité à envoyer ses commentaires sur la liste de diffusion www-rdf-comments@w3.org (archives) et à discuter des questions générales de la technologie liée sur www-rdf-interest@w3.org (archives).

Une liste de mises en œuvre est disponible.

Le W3C tient une liste des divulgations de brevets en rapport à ce travail.

Cette section décrit le statut de ce document au moment de sa publication. D'autres documents peuvent venir le remplacer. On trouvera une liste des publications courantes 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/.


Table des matières

Annexes


1 Introduction

Ce document définit la syntaxe XML [XML] des graphes RDF, qui était définie à l'origine dans la recommandation du W3C Modèle et syntaxe RDF [RDF-MS]. Les mises en œuvre consécutives de cette syntaxe et la comparaison des graphes RDF ont montré qu'il y avait une ambiguïté — les mises en œuvre généraient des graphes différents et les implantations de certaines formes syntaxiques n'étaient pas courantes.

Ce document révise la grammaire RDF/XML originale en fonction des items d'information (information items) de l'Ensemble d'information XML [INFOSET] qui s'éloigne des détails plutôt de bas niveau de XML, tels que des formes particulières d'éléments vides. Cela permet d'enregistrer plus précisément la grammaire et de montrer plus clairement l'application de la syntaxe XML vers le graphe RDF. L'application vers le graphe RDF s'effectue en émettant des déclarations sous la forme définie dans la section N-Triples des Jeux d'essais RDF [RDF-TESTS], ce qui crée un graphe RDF dont la sémantique est définie par la Sémantique RDF [RDF-SEMANTICS].

La spécification de RDF complète se compose de plusieurs documents :

Pour une introduction plus approfondie à la syntaxe RDF/XML avec une perspective historique, cf. RDF — Comprendre la syntaxe RDF/XML entrelacée [STRIPEDRDF].

2 Une syntaxe XML pour RDF

Cette section introduit la syntaxe RDF/XML, décrit son codage des graphes RDF et l'explique avec des exemples. En cas de contradiction entre cette description informelle et la description formelle de la syntaxe et de la grammaire aux sections 6 Modèle de données de la syntaxe et 7 Grammaire RDF/XML, ces deux sections prévalent.

2.1 Introduction

Le document Concepts et syntaxe abstraite RDF [RDF-CONCEPTS] définit le modèle de données du graphe RDF (section 3.1) et la syntaxe abstraite du graphe RDF (section 6). Avec la Sémantique RDF [RDF-SEMANTICS], cela lui fournit une syntaxe abstraite et une sémantique formelle. Le graphe RDF a des nœuds (nodes) et des arcs (arcs) orientés étiquetés qui relient des couples de nœuds, ce qu'on représente par un ensemble de triplets RDF (RDF triples) où chaque triplet contient un nœud de sujet (subject node), un prédicat (predicate) et un nœud d'objet (object node). Les nœuds sont des références URI RDF (RDF URI references), des littéraux RDF (RDF litterals) ou des nœuds anonymes (blank nodes). Les nœuds anonymes peuvent recevoir un identificateur non-référence URI RDF local au document, appelé un identificateur de nœud anonyme (blank node identifier). Les prédicats sont des références URI RDF que l'on peut interpréter comme une relation entre les deux nœuds ou bien comme définissant la valeur d'attribut (le nœud d'objet) d'un nœud de sujet.

Pour coder le graphe en XML, les nœuds et prédicats doivent être représentés en termes XML — noms d'élément, noms d'attributs, contenus d'élément et valeurs d'attribut. RDF/XML utilise des noms qualifiés ou noms de type QName (QNames), définis dans la recommandation Espaces de noms dans XML [XML-NS], pour représenter les références URI RDF. Tous les noms qualifiés ont un nom d'espace de noms (namespace name) qui est une référence URI avec un nom local (local name) court. En outre, les noms qualifiés peuvent soit avoir un préfixe (prefix) court, soit être déclarés avec la déclaration d'espace de noms par défaut et n'avoir aucun préfixe (mais toujours un nom d'espace de noms).

La référence URI RDF représentée par un nom qualifié est déterminée en ajoutant la partie nom local du nom qualifié après la partie nom d'espace de noms (une référence URI) du nom qualifié. On s'en sert pour raccourcir les références URI RDF de tous les prédicats et de certains nœuds. Les références URI RDF identifiant les nœuds de sujet et objet peuvent aussi être stockées comme valeurs d'attribut XML. Les littéraux RDF, qui ne peuvent être que des nœuds d'objet, deviennent soit du contenu textuel d'un élément XML, soit des valeurs d'attribut XML.

On peut considérer un graphe comme une collection de chemins (paths) de la forme « nœud, arc de prédicat, nœud, arc de prédicat, nœud, arc de prédicat, … , nœud » qui couvre le graphe entier. En RDF/XML, ces chemins se traduisent par des séquences d'éléments dans des éléments, alternant les éléments pour les nœuds et ceux pour les arcs de prédicat. Ce que l'on appelé une séquence de lacis nœud/arc (node/arc stripes). Le nœud au début de la séquence se transforme en l'élément le plus externe, l'arc de prédicat suivant en un sous-élément (child element), et ainsi de suite. Les lacis commencent généralement au début d'un document RDF/XML et se terminent toujours par des nœuds.

Plusieurs exemples RDF/XML sont donnés dans les sections suivantes pour créer des documents RDF/XML complets. L'exemple 7 est le premier document RDF/XML complet.

2.2 Éléments de nœud et éléments de propriété

Graphe de l'exemple RDF/XML

Figure 1 — Graphe de l'exemple RDF/XML (version SVG)

La figure 1 montre un graphe RDF où les nœuds sont représentés par des ovales et contiennent leurs références URI RDF pour ceux qui en ont, où tous les arcs de prédicat sont étiquetés avec des références URI RDF et où les nœuds des littéraux ordinaires (plain litteral) s'écrivent dans des rectangles.

Si nous suivons un chemin « nœud, arc de prédicat, … , nœud » à travers le graphe montré en figure 2 :

Un chemin à travers le graphe

Figure 2 — Un chemin à travers le graphe (version SVG)

Le côté gauche du graphe de la figure 2 correspond aux lacis nœud/arc de prédicat suivants :

  1. Un nœud avec la référence URI RDF http://www.w3.org/TR/rdf-syntax-grammar
  2. Un arc de prédicat étiqueté avec la référence URI RDF http://example.org/terms/editor
  3. Un nœud sans référence URI RDF
  4. Un arc de prédicat étiqueté avec la référence URI RDF http://example.org/terms/homePage
  5. Un nœud avec la référence URI RDF http://purl.org/net/dajobe/

En RDF/XML, la séquence des cinq nœuds et arcs de prédicat à gauche de la figure 2 correspond à l'utilisation de cinq éléments XML de deux types, pour les nœuds et les arcs de prédicat du graphe. Par convention, on les appelle respectivement des éléments de nœud (node elements) et des éléments de propriété (property elements). Dans l'entrelacement (striping) montré en example 1, rdf:Description est l'élément de nœud (employé trois fois pour les trois nœuds), et ex:editor et ex:homePage sont les deux éléments de propriété.

Exemple 1 : RDF/XML entrelacé (nœuds et arcs de prédicat)
<rdf:Description>
  <ex:editor>
    <rdf:Description>
      <ex:homePage>
        <rdf:Description>
        </rdf:Description>
      </ex:homePage>
    </rdf:Description>
  </ex:editor>
</rdf:Description>

Le graphe de la figure 2 consiste en nœuds qui sont des références URI RDF (et d'autres qui ne le sont pas) et on peut l'ajouter au RDF/XML avec l'attribut rdf:about sur les éléments de nœud pour aboutir au résultat de l'exemple 2 :

Exemple 2 — Éléments de nœud avec des références URI RDF ajoutées
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
  <ex:editor>
    <rdf:Description>
      <ex:homePage>
        <rdf:Description rdf:about="http://purl.org/net/dajobe/">
        </rdf:Description>
      </ex:homePage>
    </rdf:Description>
  </ex:editor>
</rdf:Description>

L'ajout des deux autres chemins à travers du graphe de la figure 1 au RDF/XML dans l'exemple 2 aboutit au résultat de l'exemple 3 (cet exemple ne montre pas que le nœud anonyme est commun aux deux chemins, cf. la section 2.10) :

Exemple 3 — Description complète de tous les chemins de graphe
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
  <ex:editor>
    <rdf:Description>
      <ex:homePage>
        <rdf:Description rdf:about="http://purl.org/net/dajobe/">
        </rdf:Description>
      </ex:homePage>
    </rdf:Description>
  </ex:editor>
</rdf:Description>

<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
  <ex:editor>
    <rdf:Description>
      <ex:fullName>Dave Beckett</ex:fullName>
    </rdf:Description>
  </ex:editor>
</rdf:Description>

<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
  <dc:title>RDF/XML Syntax Specification (Revised)</dc:title>
</rdf:Description>

2.3 Éléments à plusieurs propriétés

Plusieurs abréviations sont utilisables pour noter plus facilement les utilisations communes (common uses). En particulier, il est courant pour un nœud de sujet dans le graphe RDF d'avoir plusieurs arcs de prédicat sortants (outgoing predicate arcs). RDF/XML pourvoit une abréviation de la syntaxe correspondante lorsqu'un élément de nœud à propos d'une ressource a plusieurs éléments de propriété. On peut l'abréger en utilisant plusieurs sous-éléments de propriété (child property elements) dans l'élément de nœud décrivant le nœud de sujet.

En prenant l'exemple 3, il y a deux éléments de nœud qui peuvent avoir plusieurs éléments de propriété. Le nœud de sujet avec la référence URI http://www.w3.org/TR/rdf-syntax-grammar a les éléments de propriété ex:editor et dc:title, et l'élément de nœud du nœud anonyme peut prendre ex:homePage et ex:fullName. Cette abréviation donne le résultat montré en exemple 4 (cet exemple présente en effet un seul nœud anonyme) :

Exemple 4 — Utiliser plusieurs éléments de propriété sur un élément de nœud
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
  <ex:editor>
    <rdf:Description>
      <ex:homePage>
        <rdf:Description rdf:about="http://purl.org/net/dajobe/">
        </rdf:Description>
      </ex:homePage>
      <ex:fullName>Dave Beckett</ex:fullName>
    </rdf:Description>
  </ex:editor>
  <dc:title>RDF/XML Syntax Specification (Revised)</dc:title>
</rdf:Description>

2.4 Éléments de propriété vides

Lorsqu'un arc de prédicat dans un graphe RDF pointe vers un nœud d'objet qui n'a pas d'autres arcs de prédicat, qui apparaît dans RDF/XML comme un élément de nœud vide <rdf:Description rdf:about="..."> </rdf:Description> (ou <rdf:Description rdf:about="..." />), cette forme peut être raccourcie. On le fait en utilisant la référence URI RDF du nœud d'objet comme valeur d'un attribut XML rdf:resource sur l'élément de propriété conteneur (containing property element) et en rendant l'élément de propriété vide.

Dans cet exemple, l'élément de propriété ex:homePage contient un élément de nœud vide avec la référence URI RDF http://purl.org/net/dajobe/. On peut y substituer la forme d'élément de propriété vide, donnant le résultat montré en exemple 5 :

Exemple 5 — Éléments de propriété vides
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
  <ex:editor>
    <rdf:Description>
      <ex:homePage rdf:resource="http://purl.org/net/dajobe/"/>
      <ex:fullName>Dave Beckett</ex:fullName>
    </rdf:Description>
  </ex:editor>
  <dc:title>RDF/XML Syntax Specification (Revised)</dc:title>
</rdf:Description>

2.5 Attributs de propriété

Lorsque le contenu d'un élément de propriété est un littéral chaîne (string literal), il est possible de l'utiliser comme attribut XML sur l'élément de nœud conteneur. On peut le faire pour plusieurs propriétés sur le même élément de nœud seulement si le nom de l'élément de propriété n'est pas répété (imposé par XML — les noms d'attribut sont uniques sur un élément XML) et si tous les attributs xml:lang dans le champ (in-scope) sur le littéral chaîne (le cas échéant) de l'élément de propriété sont les mêmes (cf. la section 2.7). Cette abréviation est connue sous le nom d'attribut de propriété (property attribute) et peut s'appliquer à tout élément de nœud.

On peut également utiliser cette abréviation lorsque l'élément de propriété est rdf:type et a un attribut rdf:resource dont la valeur est interprétée comme un nœud d'objet à référence URI RDF.

Dans l"exemple 5, il y a deux éléments de propriété avec un contenu de littéral chaîne : dc:title et ex:fullName. On peut les remplacer par des attributs de propriété, donnant le résultat montré en exemple 6 :

Exemple 6 — Remplacer les éléments de propriété avec un contenu de littéral chaîne par des attributs de propriété
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar"
                 dc:title="RDF/XML Syntax Specification (Revised)">
  <ex:editor>
    <rdf:Description ex:fullName="Dave Beckett">
      <ex:homePage rdf:resource="http://purl.org/net/dajobe/"/>
    </rdf:Description>
  </ex:editor>
</rdf:Description>

2.6 Compléter le document : élément de document et déclaration XML

Pour créer un document RDF/XML complet, la sérialisation du graphe en XML est normalement contenue dans un élément XML rdf:RDF, qui devient l'élément de document XML de premier niveau. Par convention, l'élément rdf:RDF sert aussi à déclarer les espaces de noms XML utilisés, sans que ce soit obligatoire. Lorsqu'il n'y a qu'un seul élément de nœud au niveau supérieur dans rdf:RDF, on peut omettre le rdf:RDF bien que les espaces de noms XML doivent toujours être déclarés.

La spécification XML autorise également une déclaration XML au début du document avec la version XML et éventuellement le codage de contenu XML. C'est optionnel mais recommandé.

On pourrait compléter le RDF/XML de chaque exemple de graphe complet et correct à compter de l'exemple 4, mais en prenant l'exemple 6 plus petit, et en ajoutant les derniers composants, on obtient une représentation RDF/XML complète du graphe original de la figure 1 dans l'exemple 7 :

Exemple 7 — Description RDF/XML complète du graphe de la figure 1 (example07.rdf sortie example07.nt)
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:dc="http://purl.org/dc/elements/1.1/"
         xmlns:ex="http://example.org/stuff/1.0/">
  <rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar"
         dc:title="RDF/XML Syntax Specification (Revised)">
    <ex:editor>
      <rdf:Description ex:fullName="Dave Beckett">
   <ex:homePage rdf:resource="http://purl.org/net/dajobe/" />
      </rdf:Description>
    </ex:editor>
  </rdf:Description>
</rdf:RDF>

On peut omettre rdf:RDF dans l'exemple 7 ci-dessus, puisqu'il n'y a qu'un seul élément rdf:Description dans rdf:RDF mais on ne le montre pas ici.

2.7 Langues : xml:lang

RDF/XML autorise l'emploi de l'attribut xml:lang, défini à la section 2.12 Identification de la langue de la spécification XML 1.0 [XML], afin d'identifier la langue du contenu. L'attribut xml:lang peut s'utiliser sur tout élément de nœud ou élément de propriété pour indiquer que son contenu est dans la langue donnée. Les littéraux typés qui contiennent des littéraux XML ne sont pas affectés par cet attribut. La langue la plus spécifique présente (le cas échéant) dans le champ est appliquée au contenu littéral chaîne des l'élément de propriété ou aux valeurs de l'attribut de propriété. La forme xml:lang="" indique l'absence d'un identificateur de langue.

L'exemple 8 montre quelques façons de marquer les langues du contenu des propriétés RDF :

Exemple 8 — Exemple complet de xml:lang (example08.rdf sortie example08.nt)
<?xml version="1.0" encoding="utf-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:dc="http://purl.org/dc/elements/1.1/">
  <rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
    <dc:title>RDF/XML Syntax Specification (Revised)</dc:title>
    <dc:title xml:lang="en">RDF/XML Syntax Specification (Revised)</dc:title>
    <dc:title xml:lang="en-US">RDF/XML Syntax Specification (Revised)</dc:title>
  </rdf:Description>

  <rdf:Description rdf:about="http://example.org/buecher/baum" xml:lang="de">
    <dc:title>Der Baum</dc:title>
    <dc:description>Das Buch ist außergewöhnlich</dc:description>
    <dc:title xml:lang="en">The Tree</dc:title>
  </rdf:Description>
</rdf:RDF>

2.8 Littéraux XML : rdf:parseType="Literal"

RDF permet l'attribution de littéraux XML ([RDF-CONCEPTS], section 5 Contenu XML dans un graphe RDF) comme nœud d'objet d'un prédicat. En RDF/XML, ils s'inscrivent en contenu d'un élément de propriété (pas d'un attribut de propriété) et sont indiqués par l'attribut rdf:parseType="Literal" sur l'élément de propriété conteneur.

L'exemple 9 montre l'écriture d'un littéral XML, où il y a un seul triplet RDF avec la référence URI RDF de nœud de sujet http://example.org/item01, la référence URI RDF de prédicat http://example.org/stuff/1.0/prop (à partir de ex:prop) et le nœud d'objet avec un contenu de littéral XML commençant à a:Box.

Exemple 9 — Exemple complet de rdf:parseType="Literal" (example09.rdf sortie example09.nt)
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ex="http://example.org/stuff/1.0/">
  <rdf:Description rdf:about="http://example.org/item01">
    <ex:prop rdf:parseType="Literal"
             xmlns:a="http://example.org/a#"><a:Box required="true">
         <a:widget size="10" />
         <a:grommit id="23" /></a:Box>
    </ex:prop>
  </rdf:Description>
</rdf:RDF>

2.9 Littéraux typés : rdf:datatype

RDF permet l'attribution de littéraux typés comme nœud d'objet d'un prédicat. Les littéraux typés se composent d'un littéral chaîne et de la référence URI RDF d'un type de données. En RDF/XML, ils s'écrivent en employant la même syntaxe que pour les nœuds de littéral chaîne dans la forme d'élément de propriété (pas d'attribut de propriété) mais avec un attribut rdf:datatype="datatypeURI" supplémentaire sur l'élément de propriété. Toute référence URI RDF peut être utilisée dans l'attribut.

L'exemple 10 montre un littéral typé RDF, où il y a un seul triplet RDF avec la référence URI RDF de nœud de sujet http://example.org/item01, la référence URI RDF de prédicat http://example.org/stuff/1.0/size (à partir de ex:size) et le nœud d'objet avec le littéral typé ("123", http://www.w3.org/2001/XMLSchema#int), à interpréter comme étant un type de données int du schéma XML du W3C [XML-SCHEMA2].

Exemple 10 — Exemple complet de rdf:datatype (example10.rdf sortie example10.nt)
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ex="http://example.org/stuff/1.0/">
  <rdf:Description rdf:about="http://example.org/item01">
    <ex:size rdf:datatype="http://www.w3.org/2001/XMLSchema#int">123</ex:size>
  </rdf:Description>
</rdf:RDF>

2.10 Identification des nœuds anonymes : rdf:nodeID

Les nœuds anonymes dans le graphe RDF sont distincts mais n'ont pas de référence URI RDF identificatrice. Dans le RDF/XML, il est parfois nécessaire de se référer à un nœud anonyme dans le même graphe à plusieurs endroits, tels qu'en position de sujet et d'objet de plusieurs triplets RDF. Auquel cas, on peut donner un identificateur de nœud anonyme (blank node identifier) au nœud anonyme pour l'identifier dans le document. Les identificateurs de nœud anonyme en RDF/XML sont confinés (scoped) à l'item d'information de document XML Infoset conteneur (containing XML Information Set document information item). On utilise un identificateur de nœud anonyme pour remplacer rdf:about="référence URI RDF" sur un élément de nœud ou rdf:resource="référence URI RDF" sur un élément de propriété par rdf:nodeID="identificateur de nœud anonyme" dans les deux cas.

En prenant l'exemple 7 et en donnant explicitement l'identificateur de nœud anonyme abc au nœud anonyme qui s'y trouve, on obtient le résultat montré en exemple 11. Le deuxième élément de propriété rdf:Description est à propos du nœud anonyme.

Exemple 11 — Description RDF/XML complète d'un graphe avec rdf:nodeID identifiant le nœud anonyme (example11.rdf sortie example11.nt)
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:dc="http://purl.org/dc/elements/1.1/"
         xmlns:ex="http://example.org/stuff/1.0/">
  <rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar"
         dc:title="RDF/XML Syntax Specification (Revised)">
    <ex:editor rdf:nodeID="abc"/>
  </rdf:Description>

  <rdf:Description rdf:nodeID="abc"
                   ex:fullName="Dave Beckett">
    <ex:homePage rdf:resource="http://purl.org/net/dajobe/"/>
  </rdf:Description>
</rdf:RDF>

2.11 Omission des nœuds anonymes : rdf:parseType="Resource"

Les nœuds anonymes (pas les nœuds à référence URI RDF) dans les graphes RDF peuvent s'écrire dans une forme permettant d'omettre le couple <rdf:Description> </rdf:Description>. L'omission est réalisée en plaçant un attribut rdf:parseType="Resource" sur l'élément de propriété conteneur, ce qui le transforme en élément de propriété et nœud (property-and-node element), lui-même pouvant avoir des éléments de propriété et des attributs de propriété. Les attributs de propriété et l'attribut rdf:nodeID ne sont pas permis sur les éléments de propriété et nœud.

En prenant l'exemple 7 précédent, on pourrait faire autrement de cette façon avec le contenu de l'élément de propriété ex:editor pour donner la forme montrée en exemple 12 :

Exemple 12 — Exemple complet utilisant rdf:parseType="Resource" (example12.rdf sortie example12.nt)
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:dc="http://purl.org/dc/elements/1.1/"
         xmlns:ex="http://example.org/stuff/1.0/">
  <rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar"
         dc:title="RDF/XML Syntax Specification (Revised)">
    <ex:editor rdf:parseType="Resource">
      <ex:fullName>Dave Beckett</ex:fullName>
      <ex:homePage rdf:resource="http://purl.org/net/dajobe/"/>
    </ex:editor>
  </rdf:Description>
</rdf:RDF>

2.12 Omission des nœuds : attributs de propriété sur un élément de propriété vide

Si tous les éléments de propriété sur un élément de nœud anonyme ont des valeurs de littéral chaîne avec la même valeur xml:lang (si présente) dans le champ, que chaque élément de propriété apparaît une fois au plus et qu'il y a un élément de propriété rdf:type au plus avec une référence URI RDF de nœud d'objet, alors on peut les abréger en les déplaçant en attributs de propriété sur l'élément de propriété conteneur qui devient un élément vide.

En prenant l'exemple 5 précédent, l'élément de propriété ex:editor contient un élément de nœud anonyme avec deux éléments de propriété : ex:fullname et ex:homePage. L'élément ex:homePage ne convient pas ici car il n'a pas une valeur de littéral chaîne, et il est donc ignoré pour les besoins de cet exemple. La forme abrégée supprime l'élément de propriété ex:fullName et ajoute un nouvel attribut de propriété ex:fullName avec la valeur de littéral chaîne de l'élément de propriété supprimé à l'élément de propriété ex:editor. L'élément de nœud anonyme devient implicite dans l'élément de propriété ex:editor désormais vide. Le résultat est montré en exemple 13 :

Exemple 13 — Exemple complet d'attributs de propriété sur un élément de propriété vide (example13.rdf sortie example13.nt)
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:dc="http://purl.org/dc/elements/1.1/"
         xmlns:ex="http://example.org/stuff/1.0/">
  <rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar"
         dc:title="RDF/XML Syntax Specification (Revised)">
    <ex:editor ex:fullName="Dave Beckett" />
    <!-- Note the ex:homePage property has been ignored for this example -->
  </rdf:Description>
</rdf:RDF>

2.13 Éléments de nœud typé

Les graphes RDF ont couramment des prédicats rdf:type à partir des nœuds de sujet. On les appelle conventionnellement des nœuds typés (typed nodes), ou des éléments de nœud typé (typed node elements) dans le RDF/XML. RDF/XML permet d'exprimer ce triplet de manière plus concise en remplaçant le nom de l'élément de nœud rdf:Description par l'élément à espace de noms (namespaced-element) correspondant à la référence URI RDF de la valeur de la relation de type. Il peut certes y avoir plusieurs prédicats rdf:type mais un seul peut être utilisé de cette façon, les autres doivent demeurer des éléments de propriété ou des attributs de propriété.

Les éléments de nœud typé sont souvent utilisés en RDF/XML avec les classes natives (built-in classes) du vocabulaire RDF : rdf:Seq, rdf:Bag, rdf:Alt, rdf:Statement, rdf:Property et rdf:List.

Ainsi, on pourrait écrire le RDF/XML dans l'exemple 14 comme montré en exemple 15.

Exemple 14 — Exemple complet avec rdf:type (example14.rdf sortie example14.nt)
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:dc="http://purl.org/dc/elements/1.1/"
         xmlns:ex="http://example.org/stuff/1.0/">
  <rdf:Description rdf:about="http://example.org/thing">
    <rdf:type rdf:resource="http://example.org/stuff/1.0/Document"/>
    <dc:title>A marvelous thing</dc:title>
  </rdf:Description>
</rdf:RDF>
Exemple 15 — Exemple complet utilisant un élément de nœud typé pour remplacer un rdf:type (example15.rdf sortie example15.nt)
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:dc="http://purl.org/dc/elements/1.1/"
         xmlns:ex="http://example.org/stuff/1.0/">
  <ex:Document rdf:about="http://example.org/thing">
    <dc:title>A marvelous thing</dc:title>
  </ex:Document>
</rdf:RDF>

2.14 Abréviation des références URI : rdf:ID et xml:base

RDF/XML permet d'abréger encore les références URI RDF dans les attributs XML de deux façons. L'ensemble d'information XML (XML Infoset) pourvoit l'attribut xml:base qui établit l'adresse URI de base (base URI) pour la résolution des références URI RDF relatives, sinon l'adresse URI de base est celle du document. L'adresse URI de base s'applique à tous les attributs RDF/XML qui ont trait aux références URI RDF, à savoir rdf:about, rdf:resource, rdf:ID et rdf:datatype.

On peut utiliser l'attribut rdf:ID sur un élément de nœud (pas sur un élément de propriété, où la signification est différente) à la place de rdf:about et donner une référence URI RDF relative, équivalente au caractère # concaténé à la valeur de l'attribut rdf:ID. Par exemple, si rdf:ID="name", cela équivaudrait à rdf:about="#name". L'attribut rdf:ID apporte une vérification supplémentaire puisque le même nom ne peut apparaître qu'une seule fois dans la portée (scope) d'une valeur xml:base (ou du document, si aucun nom n'est donné), il est donc utile pour définir un ensemble de termes distincts liés à la même référence URI RDF.

Les deux formes nécessitent de connaître une adresse URI de base, soit à partir d'un attribut xml:base dans le champ, soit à partir de l'adresse URI du document RDF/XML.

L'exemple 16 montre l'abréviation de la référence URI RDF du nœud de http://example.org/here/#snack en utilisant un attribut xml:base de http://example.org/here/ et un attribut rdf:ID sur l'élément de nœud rdf:Description. Le nœud d'objet du prédicat ex:prop est une référence URI RDF absolue, résolue à partir de la valeur de l'attribut XML rdf:resource en utilisant l'adresse URI de base dans le champ pour donner la référence URI RDF http://example.org/here/fruit/apple.

Exemple 16 — Exemple complet utilisant rdf:ID et xml:base pour raccourcir les adresses URI (example16.rdf sortie example16.nt)
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ex="http://example.org/stuff/1.0/"
         xml:base="http://example.org/here/">
  <rdf:Description rdf:ID="snack">
    <ex:prop rdf:resource="fruit/apple"/>
  </rdf:Description>
</rdf:RDF>

2.15 Éléments de propriété d'appartenance de conteneur : rdf:li et rdf:_n

RDF a un ensemble de propriétés d'appartenance de conteneur (container membership properties) et les éléments de propriété correspondant utilisés essentiellement avec des instances des classes rdf:Seq, rdf:Bag and rdf:Alt qui peuvent s'écrire comme des éléments de nœud typé. Les propriétés de liste sont rdf:_1, rdf:_2, etc. et peuvent s'écrire comme des éléments de propriété ou des attributs de propriété comme le montre l'exemple 17. Il y a un élément de propriété spécial rdf:li qui est équivalent à rdf:_1, rdf:_2 dans l'ordre, expliqué en détails à la section 7.4. La mise en correspondance (mapping) des propriétés d'appartenance de conteneur a toujours lieu dans l'ordre où les éléments de propriété spéciaux rdf:li apparaissent dans XML — l'ordre du document est important. L'équivalent RDF/XML de l'exemple 17 écrit dans cette forme est montré dans l'exemple 18.

Exemple 17 — Exemple complet utilisant les propriétés de liste RDF (example17.rdf sortie example17.nt)
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <rdf:Seq rdf:about="http://example.org/favourite-fruit">
    <rdf:_1 rdf:resource="http://example.org/banana"/>
    <rdf:_2 rdf:resource="http://example.org/apple"/>
    <rdf:_3 rdf:resource="http://example.org/pear"/>
  </rdf:Seq>
</rdf:RDF>
Exemple 18 — Exemple complet utilisant l'élément de propriété rdf:li pour les propriétés de liste (example18.rdf sortie example18.nt)
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <rdf:Seq rdf:about="http://example.org/favourite-fruit">
    <rdf:li rdf:resource="http://example.org/banana"/>
    <rdf:li rdf:resource="http://example.org/apple"/>
    <rdf:li rdf:resource="http://example.org/pear"/>
  </rdf:Seq>
</rdf:RDF>

2.16 Collections : rdf:parseType="Collection"

RDF/XML permet un attribut rdf:parseType="Collection" sur un élément de propriété afin que celui-ci puisse contenir plusieurs éléments de nœud. Ces éléments de nœud contenus donne l'ensemble des nœuds de sujet de la collection. Cette forme syntaxique correspond à un ensemble de triplets connectant la collection de nœuds de sujet, les triplets exacts générés sont décrits en détails à la section 7.2.19 Production parseTypeCollectionPropertyElt. La construction de la collection s'effectue toujours dans l'ordre où les éléments de nœud apparaissent dans le document XML. Que l'ordre de la collection de nœuds soit significatif, c'est une question du ressort de l'application, et il n'est pas défini ici.

L'exemple 19 montre une collection de trois éléments de nœud, à la fin de l'élément de propriété ex:hasFruit, qui utilise cette forme :

Exemple 19 — Exemple complet d'une collection RDF de nœuds utilisant rdf:parseType="Collection" (example19.rdf sortie example19.nt)
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ex="http://example.org/stuff/1.0/">
  <rdf:Description rdf:about="http://example.org/basket">
    <ex:hasFruit rdf:parseType="Collection">
      <rdf:Description rdf:about="http://example.org/banana"/>
      <rdf:Description rdf:about="http://example.org/apple"/>
      <rdf:Description rdf:about="http://example.org/pear"/>
    </ex:hasFruit>
  </rdf:Description>
</rdf:RDF>

2.17 Réification des déclarations : rdf:ID

L'attribut rdf:ID peut être utilisé sur un élément de propriété pour réifier (reify) le triplet qu'il génère (cf. la section 7.3 Règles de réification pour tous les détails). L'identificateur du triplet devrait être construit comme une référence URI RDF fabriquée à partir de la référence URI relative, # concaténé à la valeur de l'attribut rdf:ID, résolue par rapport à l'adresse URI de base dans le champ. Par exemple, si rdf:ID="triple", cela équivaudrait à la référence URI RDF formée à partir de la référence URI relative #triple par rapport à l'adresse URI de base. Chaque couple (valeur d'attribut rdf:ID, adresse URI de base) doit être unique dans un document RDF/XML, cf. la contrainte constraint-id.

L'exemple 20 montre un attribut rdf:ID utilisé pour réifier un triplet fabriqué à partir de l'élément de propriété ex:prop, en donnant au triplet réifié la référence URI RDF http://example.org/triples/#triple1.

Exemple 20 — Exemple complet de rdf:ID réifiant un élément de propriété (example20.rdf sortie example20.nt)
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:ex="http://example.org/stuff/1.0/"
         xml:base="http://example.org/triples/">
  <rdf:Description rdf:about="http://example.org/">
    <ex:prop rdf:ID="triple1">blah</ex:prop>
  </rdf:Description>
</rdf:RDF>

3 Terminologie

Les mots-clés « DOIT », « NE DOIT PAS », « OBLIGATOIRE », « DEVRA », « NE DEVRA PAS », « DEVRAIT », « NE DEVRAIT PAS », « RECOMMANDÉ », « PEUT » et « OPTIONNEL » dans ce document doivent s'interpréter comme décrit dans le document RFC 2119 [KEYWORDS].

Tout emploi d'une chaîne sans autre qualification se rapporte à une chaîne de caractères Unicode [UNICODE] ; une séquence de caractères représentés par un point de code dans Unicode. (Tel que défini dans [CHARMOD] à la section 3.4 Chaînes).

4 Type MIME RDF, extension de fichier et type de fichier Macintosh

Le type de média Internet ou type MIME pour RDF/XML est "application/rdf+xml" — cf. la section 8.18 du document RFC 3023 [RFC-3023].

Note d'enregistrement (informatif) : Pour l'état de l'enregistrement du type MIME, consultez les Types de média MIME IANA [IANA-MEDIA-TYPES].

Il est recommandé de donner l'extension ".rdf" (tout en minuscules) aux fichiers RDF/XML, sur toutes les plateformes.

Il est recommandé de donner le type de fichier "rdf " (tout en minuscules), la quatrième lettre est un caractère espace, aux fichiers RDF/XML stockés sur les systèmes de fichiers HFS Macintosh.

5 Questions générales

5.1 L'espace de noms et le vocabulaire RDF

Note (informatif) : Les noms aboutEach et aboutEachPrefix ont été supprimés du langage et du vocabulaire RDF par le groupe de travail RDF Core. Cf. la résolution des problèmes rdfms-abouteach et rdfms-abouteachprefix pour plus d'informations.

Note (informatif) : Les noms List, first, rest et nil ont été ajoutés pour le problème rdfms-seq-representation. Les noms XMLLiteral et datatype ont été ajoutés pour permettre le typage de données RDF. Le nom nodeID a été ajouté pour le problème rdfms-syntax-incomplete. Cf. la Liste des problèmes du RDF Core pour plus d'informations.

La référence URI de l'espace de noms RDF (ou nom d'espace de noms) est http://www.w3.org/1999/02/22-rdf-syntax-ns#, qui est typiquement utilisé en XML avec le préfixe rdf quoique l'on puisse choisir d'autres chaînes pour préfixe. Le vocabulaire RDF est identifié par ce nom d'espace de noms et contient seulement les noms suivants :

Noms de la syntaxe — pas les concepts

RDF Description ID about parseType resource li nodeID datatype

Noms de classe

Seq Bag Alt Statement Property XMLLiteral List

Noms de propriété

subject predicate object type value first rest _n
n est un entier décimal supérieur à zéro, sans zéros de tête.

Noms de ressource

nil

Aucun autre nom n'est défini et DEVRAIT générer un avertissement si rencontré, mais devrait se comporter normalement sinon.

Dans les documents RDF/XML, il n'est pas permis d'utiliser des espaces de noms XML dont le nom d'espace de noms est la ·référence URI de l'espace de noms RDF· concaténée avec des caractères supplémentaires.

Tout au long de ce document, nous utiliserons la terminologie rdf:nom pour indiquer un nom provenant du vocabulaire RDF et il aura une référence URI RDF formée par la concaténation de la ·référence URI de l'espace de noms RDF· et de nom. Par exemple, rdf:type a la référence URI RDF http://www.w3.org/1999/02/22-rdf-syntax-ns#type

5.2 Identificateurs

Le graphe RDF (Concepts et syntaxe abstraite RDF, section 3) définit trois types de nœuds et un type de prédicat :

Nœuds et prédicats de référence URI RDF

Les références URI RDF (Concepts et syntaxe abstraite RDF, section 3.1) peuvent être soit :

Dans RDF/XML, les noms qualifiés XML se transforment en références URI RDF en ajoutant le nom local XML à la fin du nom d'espace de noms (une référence URI). Par exemple, si le préfixe d'espace de noms XML foo a pour nom d'espace de noms (une référence URI) http://example.org/somewhere/, alors le nom qualifié foo:bar correspondrait à la référence URI RDF http://example.org/somewhere/bar. Notez que cela restreint les références URI RDF que l'on peut fabriquer, et que la même adresse URI peut être donnée de plusieurs façons.

Les valeurs rdf:ID se transforment en références URI RDF en ajoutant la valeur d'attribut après le caractère « # » à l'adresse URI de base dans le champ définie à la section 5.3 Résolution des adresses URI.

Nœuds de littéral (toujours des nœuds d'objet)

Les littéraux RDF (Concepts et syntaxe abstraite RDF, section 6.5) sont soit des littéraux ordinaires (idem), soit des littéraux typés (idem). Les derniers comprennent les littéraux XML (idem, section 5 Contenu XML dans un graphe RDF).

Identificateurs de nœud anonyme

Les nœuds anonymes ont une identité distincte dans le graphe RDF. Lorsqu'on écrit le graphe dans une syntaxe telle que RDF/XML, ces nœuds anonymes peuvent nécessiter des identificateurs locaux au graphe et une syntaxe pour conserver cette distinction. Ces identificateurs locaux sont appelés des identificateurs de nœud anonyme et sont utilisés dans RDF/XML comme valeurs de l'attribut rdf:nodeID selon la syntaxe donnée dans la production nodeIdAttr. Les identificateurs de nœud anonyme dans RDF/XML sont confinés à l'item d'information de document XML Infoset.

Si aucun identificateur de nœud anonyme n'est donné explicitement en valeur d'attribut rdf:nodeID, alors il faudra en générer un (en utilisant la production generated-blank-node-id, cf. la section 6.3.3). Ces identificateurs de nœud anonyme générés ne doivent pas entrer en conflit avec ceux dérivés de valeurs d'attribut rdf:nodeID. Cela peut être mis en œuvre par une méthode qui garde l'identité distincte de tous les nœuds anonymes dans le graphe, c'est-à-dire ne pas donner le même identificateur de nœud anonyme à des nœuds anonymes différents. Une méthode possible serait d'ajouter un préfixe constant à toutes les valeurs d'attribut rdf:nodeID et de s'assurer qu'aucun identificateur de nœud anonyme généré n'utilise jamais ce préfixe. Une autre méthode serait d'associer toutes les valeurs d'attribut rdf:nodeID aux nouveaux identificateurs de nœud anonyme et de réaliser cette mise en correspondance (mapping) sur toutes ces valeurs dans le document RDF/XML.

5.3 Résolution des adresses URI

RDF/XML utilise XML Base [XML-BASE] qui défini un sélecteur (accessor) ·base-uri· pour chaque ·événement de racine· (root event) et ·événement d'élément· (element event). Les références URI relatives se résolvent en références URI RDF conformément à l'algorithme défini dans XML Base [XML-BASE] (et dans le RFC 2396). Ces spécifications ne définissent pas d'algorithme pour résoudre un identificateur de fragment (fragment identifier) seul, tel que #foo, ou la chaîne vide "" en une référence URI RDF. En RDF/XML, un identificateur de fragment est transformé en une référence URI RDF en ajoutant l'identificateur de fragment à la fin de l'adresse URI de base dans le champ. La chaîne vide est transformée en une référence URI RDF en lui substituant l'adresse URI de base dans le champ.

Test : Indiqué par test001.rdf et test001.nt

Test : Indiqué par test004.rdf et test004.nt

Test : Indiqué par test008.rdf et test008.nt

Test : Indiqué par test013.rdf et test013.nt

Test : Indiqué par test016.rdf et test016.nt

Une référence vide de même document "" se résoud par rapport à la partie URI de l'adresse URI de base ; toute partie fragment est ignorée. Cf. Identificateurs de ressource uniformes (URI), section 4.2 [URIS].

Test : Indiqué par test013.rdf et test013.nt

Note de mise en œuvre (informatif) : Lorsqu'on utilise une adresse URI de base hiérarchique qui n'a pas de composant de chemin (/), on doit l'ajouter avant une utilisation comme adresse URI de base pour la résolution.

Test : Indiqué par test011.rdf et test011.nt

5.4 Contraintes

constraint-id
Chaque application de la production idAttr correspond à un attribut. Le couple formé par les sélecteurs ·string-value· et ·base-uri· de l'attribut associé est unique dans un seul document RDF/XML.

La syntaxe des noms doit correspondre à la production rdf-id.

Test : Indiqué par test014.rdf et test014.nt

5.5 Conformité

Définition : Un document RDF (RDF document) est une sérialisation d'un graphe RDF dans une syntaxe concrète.

Définition : Un document RDF/XML (RDF/XML document) est un document RDF écrit dans la syntaxe de transport XML (XML transfer syntax) recommandée pour RDF comme définie dans ce document.

Conformité : Un document RDF/XML est un document RDF/XML conforme (conforming RDF/XML document) s'il adhère à la spécification définie dans ce document.

6 Modèle de données de la syntaxe

Ce document définit la syntaxe de RDF/XML comme une grammaire sur un alphabet de symboles. Les symboles sont appelés des événements (events) dans le style de la cartographie de l'ensemble d'information [XPATH]. On dérive normalement une séquence d'événements d'un document XML, auquel cas ceux-ci sont dans l'ordre du document, comme défini ci-dessous à la section 6.2 Mise en correspondance de l'ensemble d'information. La séquence formée par ces événements est voulue similaire à la séquence d'événements produite par l'interface de programmation (API) XML [SAX2] à partir du même document XML. Les séquences d'événements peuvent être vérifiées auprès de la grammaire pour déterminer s'il s'agit ou non de RDF/XML syntaxiquement bien formé.

Les productions de grammaire peuvent inclure des actions qui se déclenchent lorsque la production est reconnue. Prises ensemble, ces actions définissent une transformation d'une séquence d'événements RDF/XML syntaxiquement bien formée en un graphe RDF représenté dans le langage N-Triples.

Le modèle fourni ici illustre une façon de créer une représentation d'un graphe RDF à partir d'un document RDF/XML. Cela ne rend aucunement obligatoire une quelconque méthode de réalisation (implementation method) — toute autre méthode aboutissant à une représentation du même graphe RDF peut être utilisée.

En particulier :

La syntaxe n'est pas compatible avec (support) les documents XML mal formés (non-well-formed) ni les documents qui sinon n'ont pas d'ensemble d'information XML ; par exemple, qui ne sont pas conformes avec les Espaces de noms dans XML [XML-NS].

L'ensemble d'information (Infoset) impose une compatibilité avec XML Base [XML-BASE]. RDF/XML utilise la propriété d'item d'information [adresse URI de base] (base URI), abordée à la section 5.3.

Cette spécification nécessite un ensemble d'information XML [INFOSET] qui reconnaît au moins les items d'information et propriétés suivants pour RDF/XML :

item d'information de document (document information item)
[élément de document] (document element), [sous-éléments] (children), [adresse URI de base] (base URI)
item d'information d'élément (element information item)
[nom local] (local name), [nom d'espace de noms] (namespace name), [sous-éléments], [attributs] (attributes), [parent] (parent), [adresse URI de base]
item d'information d'attribut (attribute information item)
[nom local], [nom d'espace de noms], [valeur normalisée] (normalized value)
item d'information de caractère (character information item)
[code de caractère] (character code)

Les items suivants ne sont pas appariés (mapped to) à des événements du modèle de données :

item d'information d'instruction de traitement (processing instruction information item)
item d'information de référence d'entité non expansée (unexpanded entity reference information item)
item d'information de commentaire (comment information item)
item d'information de déclaration de type de document (document type declaration information item)
item d'information d'entité non analysée (unparsed entity information item)
item d'information de notation (notation information item)
item d'information d'espace de noms (namespace information item)

D'autres items d'information et propriétés ne sont pas appariés à des événements du modèle de données de la syntaxe.

Les items d'information d'élément avec des noms XML réservés (cf Name dans XML 1.0) ne sont pas appariés aux événements d'élément du modèle de données. Ce sont tous ceux dont la propriété [préfixe] (prefix) commence par xml (comparaison indépendante de la casse), et tous ceux dont la propriété [préfixe] n'a pas de valeur et ont une propriété [nom local] commençant par xml (comparaison indépendante de la casse).

Tous les items d'information contenus dans les éléments XML correspondant à la production parseTypeLiteralPropertyElt forment des littéraux XML et ne suivent pas cet appariement. Cf. parseTypeLiteralPropertyElt pour plus d'informations.

Cette section est conçue pour satisfaire aux exigences de conformité dans la spécification [INFOSET]. Elle définit les items d'information et propriétés nécessaires pour mettre en œuvre la présente spécification.

6.1 Événements

Il y a neuf types d'événement définis dans les sous-sections suivantes. La plupart des événements sont construits à partir d'un item d'information Infoset (hormis la référence URI, le nœud anonyme, le littéral ordinaire et le littéral typé). L'action d'un constructeur d'événement est de créer un nouvel événement avec une identité unique, distinct de tous les autres événements. Les événements portent des fonctions de sélection (accessor operations) et, pour la plupart, ont le sélecteur string-value qui peut être une valeur statique ou calculée.

6.1.1 Événement de racine

Construit à partir d'un item d'information de document ; prend les sélecteurs et valeurs suivants :

document-element
Prend la valeur de la propriété d'item d'information de document [élément de document].
children
Prend la valeur de la propriété d'item d'information de document [sous-éléments].
base-uri
Prend la valeur de la propriété d'item d'information de document [adresse URI de base].
language
Prend la chaîne vide.

6.1.2 Événement d'élément

Construit à partir d'un item d'information d'élément ; prend les sélecteurs et valeurs suivants :

local-name
Prend la valeur de la propriété d'item d'information d'élément [nom local].
namespace-name
Prend la valeur de la propriété d'item d'information d'élément [nom d'espace de noms].
children
Prend la valeur de la propriété d'item d'information d'élément [sous-éléments].
base-uri
Prend la valeur de la propriété d'item d'information d'élément [adresse URI de base].
attributes
Fabriqué à partir de la valeur de la propriété d'information d'élément [attributs] qui est un ensemble d'items d'information d'attribut (attribute information items).

Si cet ensemble contient un item d'information d'attribut xml:lang (propriété [nom d'espace de noms] avec la valeur "http://www.w3.org/XML/1998/namespace" et propriété [nom local] de valeur "lang"), celui-ci est retiré de l'ensemble d'items d'information d'attribut et le sélecteur ·language· reçoit la valeur de la propriété [valeur normalisée] de l'item d'information d'attribut.

Tous les noms XML restants (cf. Name dans la spécification XML 1.0) sont ensuite retirés de l'ensemble. À savoir, tous les items d'information d'attribut dans l'ensemble avec une propriété [préfixe] commençant par xml (comparaison indépendante de la casse), et tous les items d'information d'attribut avec une propriété [préfixe] sans valeur et avec une propriété [nom local] commençant par xml (comparaison indépendante de la casse) sont supprimés. Notez que le sélecteur base-uri est calculé par XML Base avant que l'item d'information d'attribut xml:base ne soit supprimé.

Le reste des items d'information d'attribut est alors utilisé pour construire un nouvel ensemble d'événements d'attribut affecté comme valeur de ce sélecteur.

URI
Prend la valeur chaîne issue de la concaténation des valeurs des sélecteurs namespace-name et local-name.
URI-string-value
La valeur est la concaténation des chaînes suivantes dans cet ordre : « < », la valeur échappée (escaped value) du sélecteur ·URI· et « > ».

L'échappement du sélecteur ·URI· utilise le mécanisme d'échappement N-Triples pour les références URI, décrit à la section 3.3 Références URI.

li-counter
Prend la valeur entière 1.
language
Fixé à partir du sélecteur ·attributes· décrit ci-dessus. Si aucune valeur n'est fournie par le sélecteur attributes, la valeur est fixée à celle du sélecteur language sur l'événement parent (soit un événement de racine, soit un événement d'élément), qui peut être la chaîne vide.
subject
N'a aucune valeur initiale ; prend une valeur qui est un événement d'identificateur. Ce sélecteur est utilisé sur les éléments qui traitent d'un nœud dans le graphe RDF, celui-ci étant généralement le sujet d'une déclaration.

6.1.3 Événement d'élément de fin

N'a aucun sélecteur ; marque la fin de l'élément conteneur dans la séquence.

6.1.4 Événement d'attribut

Construit à partir d'un item d'information d'attribut ; prend les sélecteurs et valeurs suivants :

local-name
Prend la valeur de la propriété d'item d'information d'attribut [nom local].
namespace-name
Prend la valeur de la propriété d'item d'information d'attribut [nom d'espace de noms].
string-value
Prend la valeur de la propriété d'item d'information d'attribut [valeur normalisée] comme définie par [XML] (si la valeur normalisée d'un attribut est une chaîne de longueur nulle (zero-length string), alors le sélecteur string-value est également une chaîne de longueur nulle).
URI
Si le sélecteur ·namespace-name· est présent, prend la valeur chaîne issue de la concaténation des valeurs des sélecteurs ·namespace-name· et ·local-name·. Sinon, si le sélecteur ·local-name· est ID, about, resource, parseType ou type, prend la valeur chaîne issue de la concaténation de la ·référence URI de l'espace de noms RDF· et de la valeur du sélecteur ·local-name·. Les autres valeurs de sélecteur ·local-name· sans espace de noms (non-namespaced) sont interdites.

La gestion d'un ensemble limité de noms sans espace de noms est OBLIGATOIRE, car elle permet aux documents RDF/XML spécifiés dans [RDF-MS] de rester valides ; les nouveaux documents NE DEVRAIENT PAS employer ces attributs non qualifiés et les applications PEUVENT choisir de prévenir de la présence de la forme non qualifiée dans un document.

La construction de références URI RDF à partir d'attributs XML peut générer les mêmes références URI RDF à partir d'attributs XML différents. Cela peut entraîner une ambiguïté dans la grammaire lors de l'appariement (matching) des événements d'attributs (comme lorsque des attributs XML rdf:about et about sont tous deux présents). Les documents sont illégaux dans ce cas.

URI-string-value
La valeur issue de la concaténation des chaînes suivantes dans cet ordre : « < », la valeur échappée du sélecteur ·URI· et « > ».

L'échappement du sélecteur ·URI· utilise le mécanisme d'échappement N-Triples pour les références URI, décrit à la section 3.3 Références URI.

6.1.5 Événement de texte

Construit à partir d'une séquence d'un ou plusieurs items d'information de caractère consécutifs. A pour seul sélecteur :

string-value
Prend la valeur de la chaîne issue de la concaténation des valeurs de propriété [code de caractère] de tous les items d'information de caractère.

6.1.6 Événement de référence URI

Un événement de référence URI RDF qui a les sélecteurs suivants :

identifier
Prend une valeur chaîne utilisée comme référence URI RDF.
string-value
La valeur est la concaténation des chaînes suivantes : « < », la valeur échappée du sélecteur ·identifier· et « > ».

L'échappement de la valeur du sélecteur ·identifier· utilise le mécanisme d'échappement N-Triples pour les références URI, décrit à la section 3.3 Références URI.

Ces événements se construisent en donnant une valeur au sélecteur ·identifier·.

Pour plus de renseignements à propos des identificateurs dans le graphe RDF, cf. la section 5.2.

6.1.7 Événement d'identificateur de nœud anonyme

Un événement d'identificateur de nœud anonyme qui a les sélecteurs suivants :

identifier
Prend une valeur chaîne.
string-value
La valeur est fonction de celle du sélecteur ·identifier·. La valeur commence par la chaîne "_:" et la valeur entière DOIT correspondre à la production N-Triples nodeID. La fonction DOIT conserver l'identité distincte des nœuds anonymes, comme expliqué à la section 5.2 Identificateurs.

Ces événements se construisent en donnant une valeur au sélecteur ·identifier·.

Pour plus de renseignements à propos des identificateurs dans le graphe RDF, cf. la section 5.2.

6.1.8 Événement de littéral ordinaire

Un événement de littéral ordinaire qui peut avoir les sélecteurs suivants :

literal-value
Prend une valeur chaîne.
literal-language
Prend une valeur chaîne utilisée comme étiquette de langue (language tag) dans un littéral ordinaire RDF.
string-value
La valeur est calculée à partir des autres sélecteurs comme suit :

Si la valeur du sélecteur ·literal-language· est la chaîne vide, alors la valeur est la concaténation des chaînes suivantes : « " » (un guillemet double), la valeur échappée du sélecteur ·literal-value· et « " » (un guillemet double).

Sinon la valeur est la concaténation des chaînes suivantes : « " » (un guillemet double), la valeur échappée du sélecteur ·literal-value·, « "@ » (un guillemet double et un caractère '@') et la valeur du sélecteur ·literal-language·.

L'échappement du sélecteur ·literal-value· utilise le mécanisme d'échappement N-Triples pour les chaînes, décrit à la section 3.2 Chaînes pour échapper certains caractères tels que ".

Ces événements se construisent en donnant les valeurs des sélecteurs ·literal-value· et ·literal-language·.

Note à propos de l'interoperabilité (informatif) : Les littéraux commençant par un caractère combinatoire (combining character) Unicode sont permis, toutefois ils peuvent entraîner des problèmes d'interopérabilité. Cf. [CHARMOD] pour plus de renseignements.

6.1.9 Événement de littéral typé

Un événement de littéral typé qui peut avoir les sélecteurs suivants :

literal-value
Prend une valeur chaîne.
literal-datatype
Prend une valeur chaîne utilisée comme référence URI RDF.
string-value
La valeur est la concaténation des chaînes suivantes dans cet ordre : « " » (un guillemet double), la valeur échappée du sélecteur ·literal-value·, « " » (un guillemet double), « ^^< », la valeur échappée du sélecteur ·literal-datatype· et « >" ».

L'échappement de la valeur du sélecteur ·literal-value· utilise le mécanisme d'échappement N-Triples pour les chaînes, décrit à la section 3.2 Chaînes pour échapper certains caractères tels que « " ». L'échappement de la valeur du sélecteur ·literal-datatype· doit utiliser le mécanisme d'échappement N-Triples pour les références URI, décrit à la section 3.3 Références URI.

Ces événements se construisent en donnant des valeurs aux sélecteurs ·literal-value· et ·literal-datatype·.

Note à propos de l'interopérabilité (informatif) : Les littéraux commençant par un caractère combinatoire Unicode sont permis, toutefois ils peuvent entraîner des problèmes d'interopérabilité. Cf. [CHARMOD] pour plus de renseignements.

Note à propos de la mise en œuvre (informatif) : Dans la spécification XML Schema (tome 1) [XML-SCHEMA1], la normalisation des caractères blancs (white space normalization) intervient pendant la validation conformément à la valeur de la facette (facet) whiteSpace. La mise en correspondance syntaxique (syntax mapping) utilisée dans ce document intervient après, donc la facette whiteSpace n'a pas d'autre effet formel.

6.2 Mise en correspondance de l'ensemble d'information

Pour transformer l'ensemble d'information (Infoset) vers la séquence des événements dans l'ordre du document, chaque item d'information est transformé comme décrit ci-dessus pour générer un arbre des événements avec les sélecteurs et les valeurs. Chaque événement d'élément est ensuite remplacé comme suit pour transformer l'arbre des événements en une séquence dans l'ordre du document.

  1. L'événement d'élément original ;
  2. La valeur du sélecteur children transformée récursivement, une liste ordonnée d'événements éventuellement vide ;
  3. Un événement d'élément de fin

6.3 Notation de la grammaire

On utilise la notation suivante pour décrire la mise en correspondance de la séquence des événements du modèle de données telle qu'indiquée à la section 6 et les actions à effectuer pour les équivalences (matches). La grammaire RDF/XML est définie en fonction de la mise en correspondance de ces événements du modèle de données transformés (matched data model events) vers les triplets, en utilisant une notation de la forme :

nombre type d'événement contenu d'événement

action...

où le contenu d'événement est une expression correspondant à des types d'événement (comme défini à la section 6.1), en utilisant la notation donnée dans les sections suivantes. Le nombre sert pour des besoins de référence. L'action de la grammaire peut inclure la génération de nouveaux triplets vers le graphe, écrits dans le format N-Triples.

Les sections suivantes décrivent la notation générale employée et celle pour l'appariement des événements (event matching) et les actions.

6.3.1 Notation générale de la grammaire

Notation générale de la grammaire.
Notation Signification
événement.sélecteur La valeur d'un sélecteur d'événement.
rdf:X Une adresse URI comme définie à la section 5.1.
"ABC" Une chaîne de caractères A, B, C dans cet ordre.

6.3.2 Notation d'appariement d'événement de la grammaire

Notation d'appariement d'événement de la grammaire.
Notation Signification
A == B Le sélecteur d'événement A est égal à l'expression B.
A != B A n'est pas égal à B.
A | B | ... Les termes A, B, ... sont des options.
A - B Les termes dans A à l'exclusion de tous les termes dans B.
anyURI. Toute adresse URI.
anyString. Toute chaîne.
list(item1, item2, ...) ; list() Une liste ordonnée d'événements ; une liste vide.
set(item1, item2, ...) ; set() Un ensemble non ordonné d'événements ; un ensemble vide.
* Zéro ou plus terme précédent.
? Zéro ou un seul terme précédent.
+ Un ou plusieurs termes précédents.
root(acc1 == value1,
    acc2 == value2, ...)
Apparie un événement de racine avec des sélecteurs (accessors).
start-element(acc1 == value1,
    acc2 == value2, ...)
children
end-element()
Apparie une séquence d'événements d'élément avec des sélecteurs, une liste d'événements éventuellement vide comme contenu d'élément et un événement d'élément de fin.
attribute(acc1 == value1,
    acc2 == value2, ...)
Apparie un événement d'attribut avec des sélecteurs.
text() Apparie un événement de texte.

6.3.3 Notation d'action de la grammaire

Notation d'action de la grammaire.
Notation Signification
A := B Affecte la valeur B à A.
concat(A, B, ..) Une chaîne créée en concaténant les termes dans l'ordre.
resolve(e, s) Une chaîne créée en interprétant la chaîne s comme une référence URI relative au sélecteur ·base-uri· de e comme défini à la section 5.3 Résolution des adresses URI. La chaîne obtenue représente une référence URI RDF.
generated-blank-node-id() Une valeur chaîne pour un nouvel identificateur de nœud anonyme distinct généré comme défini à la section 5.2 Identificateurs.
événement.sélecteur := valeur Attribut la valeur donnée à un sélecteur d'événement.
uri(identifier := value) Crée un nouvel événement de référence URI.
bnodeid(identifier := value) Crée un nouvel événement d'identificateur de nœud anonyme. Cf. également la section 5.2 Identificateurs.
literal(literal-value := string,
    literal-language := language, ...)
Crée un nouvel événement de littéral ordinaire.
typed-literal(literal-value := string, ...) Crée un nouvel événement de littéral typé.

7 Grammaire RDF/XML

7.1 Récapitulatif de la grammaire

7.2.2 coreSyntaxTerms rdf:RDF | rdf:ID | rdf:about | rdf:parseType | rdf:resource | rdf:nodeID | rdf:datatype
7.2.3 syntaxTerms coreSyntaxTerms | rdf:Description | rdf:li
7.2.4 oldTerms rdf:aboutEach | rdf:aboutEachPrefix | rdf:bagID
7.2.5 nodeElementURIs anyURI - ( coreSyntaxTerms | rdf:li | oldTerms )
7.2.6 propertyElementURIs anyURI - ( coreSyntaxTerms | rdf:Description | oldTerms )
7.2.7 propertyAttributeURIs anyURI - ( coreSyntaxTerms | rdf:Description | rdf:li | oldTerms )
7.2.8 doc root(document-element == RDF, children == list(RDF))
7.2.9 RDF start-element(URI == rdf:RDF, attributes == set())
nodeElementList
end-element()
7.2.10 nodeElementList ws* (nodeElement ws* )*
7.2.11 nodeElement start-element(URI == nodeElementURIs
    attributes == set((idAttr | nodeIdAttr | aboutAttr )?, propertyAttr*))
propertyEltList
end-element()
7.2.12 ws Un événement de texte correspondant aux caractères blancs (white space) selon la définition [XML] « Caractères blancs » règle [3] S, à la section 2.3 Structures syntaxiques communes
7.2.13 propertyEltList ws* (propertyElt ws* ) *
7.2.14 propertyElt resourcePropertyElt | literalPropertyElt | parseTypeLiteralPropertyElt | parseTypeResourcePropertyElt | parseTypeCollectionPropertyElt | parseTypeOtherPropertyElt | emptyPropertyElt
7.2.15 resourcePropertyElt start-element(URI == propertyElementURIs ), attributes == set(idAttr?))
ws* nodeElement ws*
end-element()
7.2.16 literalPropertyElt start-element(URI == propertyElementURIs ), attributes == set(idAttr?, datatypeAttr?))
text()
end-element()
7.2.17 parseTypeLiteralPropertyElt start-element(URI == propertyElementURIs ), attributes == set(idAttr?, parseLiteral))
literal
end-element()
7.2.18 parseTypeResourcePropertyElt start-element(URI == propertyElementURIs ), attributes == set(idAttr?, parseResource))
propertyEltList
end-element()
7.2.19 parseTypeCollectionPropertyElt start-element(URI == propertyElementURIs ), attributes == set(idAttr?, parseCollection))
nodeElementList
end-element()
7.2.20 parseTypeOtherPropertyElt start-element(URI == propertyElementURIs ), attributes == set(idAttr?, parseOther))
propertyEltList
end-element()
7.2.21 emptyPropertyElt start-element(URI == propertyElementURIs ), attributes == set(idAttr?, ( resourceAttr | nodeIdAttr )?, propertyAttr*))
end-element()
7.2.22 idAttr attribute(URI == rdf:ID, string-value == rdf-id)
7.2.23 nodeIdAttr attribute(URI == rdf:nodeID, string-value == rdf-id)
7.2.24 aboutAttr attribute(URI == rdf:about, string-value == URI-reference)
7.2.25 propertyAttr attribute(URI == propertyAttributeURIs, string-value == anyString)
7.2.26 resourceAttr attribute(URI == rdf:resource, string-value == URI-reference)
7.2.27 datatypeAttr attribute(URI == rdf:datatype, string-value == URI-reference)
7.2.28 parseLiteral attribute(URI == rdf:parseType, string-value == "Literal")
7.2.29 parseResource attribute(URI == rdf:parseType, string-value == "Resource")
7.2.30 parseCollection attribute(URI == rdf:parseType, string-value == "Collection")
7.2.31 parseOther attribute(URI == rdf:parseType, string-value == anyString - ("Resource" | "Literal" | "Collection") )
7.2.32 URI-reference Une référence URI RDF.
7.2.33 literal Tout contenu d'élément XML permis selon la définition [XML] « Contenu des éléments » règle [43] content, à la section 3.1 Balises ouvrantes, balises fermantes et balises d'éléments vides
7.2.34 rdf-id Un attribut ·string-value· correspondant à un atome NCName [XML-NS] légal.

7.2 Productions de la grammaire

7.2.1 Début de la grammaire

Si le RDF/XML est document XML autonome (identifié par une présentation comme un objet de type MIME RDF application/rdf+xml, ou par d'autres moyens), alors la grammaire peut commencer par une production doc ou une production nodeElement.

Si le contenu est réputé être du RDF/XML par le contexte, comme lorsque le RDF/XML est incorporé dans un autre contenu XML, alors la grammaire peut commencer soit à l'événement d'élément RDF (seulement lorsque la présence de l'élément est légale à ce point dans le XML), soit à une production nodeElementList (seulement lorsque le contenu d'élément est légal, puisqu'il s'agit d'une liste d'éléments). Pour du tel RDF/XML incorporé, la valeur de ·base-uri· sur l'élément le plus à l'extérieur doit être initialisée à partir du XML contenant puisqu'aucun événement de racine ne sera disponible. Notez que si une telle incorporation se produit, la grammaire peut être entrée plusieurs fois mais aucune conservation d'état n'est à attendre.

7.2.2 Production coreSyntaxTerms

rdf:RDF | rdf:ID | rdf:about | rdf:parseType | rdf:resource | rdf:nodeID | rdf:datatype

Un sous-ensemble des termes de syntaxe du vocabulaire RDF à la section 5.1 utilisés en RDF/XML.

7.2.3 Production syntaxTerms

coreSyntaxTerms | rdf:Description | rdf:li

Tous les termes de syntaxe du vocabulaire RDF à la section 5.1 utilisés en RDF/XML.

7.2.4 Production oldTerms

rdf:aboutEach | rdf:aboutEachPrefix | rdf:bagID

Ce sont les noms du vocabulaire RDF qui ont été retirés du langage. Cf. les résolutions des problèmes rdfms-aboutEach-on-object, rdfms-abouteachprefix et du problème en dernier appel timbl-01 pour plus de renseignements.

Test de détection d'erreurs : Indiqué par error001.rdf et error002.rdf

7.2.5 Production nodeElementURIs

anyURI - ( coreSyntaxTerms | rdf:li | oldTerms )

Les références URI RDF qui sont permises sur les éléments de nœud.

7.2.6 Production propertyElementURIs

anyURI - ( coreSyntaxTerms | rdf:Description | oldTerms )

Les adresses URI qui sont permises sur les éléments de propriété.

7.2.7 Production propertyAttributeURIs

anyURI - ( coreSyntaxTerms | rdf:Description | rdf:li | oldTerms )

Les références URI RDF qui sont permises sur les attributs de propriété.

7.2.8 Production doc

root(document-element == RDF,
    children == list(RDF))

7.2.9 Production RDF

start-element(URI == rdf:RDF,
    attributes == set())
nodeElementList
end-element()

7.2.10 Production nodeElementList

ws* (nodeElement ws* )*

7.2.11 Production nodeElement

start-element(URI == nodeElementURIs
    attributes == set((idAttr | nodeIdAttr | aboutAttr )?, propertyAttr*))
propertyEltList
end-element()

Pour l'élément de nœud e, le traitement de certains attributs doit être effectué avant d'autres tâches telles que s'occuper des événements des sous-éléments (children events) ou d'autres attributs. Ces tâches peuvent être effectuées dans un ordre quelconque :

Si e.subject est vide, alors e.subject := bnodeid(identifier := generated-blank-node-id()).

Les tâches suivantes peuvent être effectuées dans un ordre quelconque :

7.2.12 Production ws

Un événement de texte correspondant aux caractères blancs de la définition [XML] « Caractères blancs » règle [3] S, à la section 2.3 Structures syntaxiques communes.

7.2.13 Production propertyEltList

ws* (propertyElt ws* ) *

7.2.14 Production propertyElt

resourcePropertyElt | literalPropertyElt | parseTypeLiteralPropertyElt | parseTypeResourcePropertyElt | parseTypeCollectionPropertyElt | parseTypeOtherPropertyElt | emptyPropertyElt

Si un élément e a e.URI = rdf:li, alors appliquer les règles d'expansion de liste sur l'élément e.parent de la section 7.4 pour donner une nouvelle adresse URI u et e.URI := u.

L'action de cette production doit être réalisée avant les actions des sous-équivalences (sub-matches) (resourcePropertyElt ... emptyPropertyElt). Autrement, le résultat doit être équivalent à celui qui aurait été obtenu si cette action avait été effectuée en premier, comme d'être effectué en première action de toutes les sous-équivalences.

7.2.15 Production resourcePropertyElt

start-element(URI == propertyElementURIs ),
    attributes == set(idAttr?))
ws* nodeElement ws*
end-element()

Pour un élément e, et le seul élément de nœud (nodeElement) n contenu, l'élément n doit d'abord être traité en utilisant la production nodeElement. Puis la déclaration suivante s'ajoute au graphe :

  e.parent.subject.string-value e.URI-string-value n.subject.string-value .

Si l'attribut rdf:ID a est donné, la déclaration ci-dessus est réifiée avec i := uri(identifier := resolve(e, concat("#", a.string-value))) en utilisant les règles de réification à la section 7.3 et e.subject := i

7.2.16 Production literalPropertyElt

start-element(URI == propertyElementURIs ),
    attributes == set(idAttr?, datatypeAttr?))
text()
end-element()

Notez que le cas du littéral vide est défini dans la production emptyPropertyElt.

Pour un élément e, et l'événement de texte t. La chaîne Unicode t.string-value DEVRAIT être dans la forme de normalisation C [NFC]. Si l'attribut rdf:datatype d est donné, alors o := typed-literal(literal-value := t.string-value, literal-datatype := d.string-value) sinon o := literal(literal-value := t.string-value, literal-language := e.language) et la déclaration suivante s'ajoute au graphe :

e.parent.subject.string-value e.URI-string-value o.string-value .

Si l'attribut rdf:ID a est donné, la déclaration ci-dessus est réifiée avec i := uri(identifier := resolve(e, concat("#", a.string-value))) en utilisant les règles de réification à la section 7.3 et e.subject := i.

7.2.17 Production parseTypeLiteralPropertyElt

start-element(URI == propertyElementURIs ),
    attributes == set(idAttr?, parseLiteral))
literal
end-element()

Pour un élément e et le littéral l qui est le contenu pour rdf:parseType="Literal". Le littéral l n'est pas transformé par la mise en correspondance du modèle de données de la syntaxe en événements (comme noté dans la section 6 Modèle de données de la syntaxe) mais reste un ensemble d'information XML d'items d'information XML.

Le littéral l est transformé dans la forme lexicale d'un littéral XML x (une chaîne Unicode) dans le graphe RDF par l'algorithme suivant. Cela ne rend aucunement obligatoire une quelconque méthode de réalisation — toute autre méthode donnant le même résultat peut être utilisée.

  1. Utiliser l pour construire un ensemble de nœuds XPath [XPATH] node-set (un sous-ensemble du document) ;
  2. Appliquer une canonisation XML exclusive [XML-XC14N] avec des commentaires et avec un paramètre InclusiveNamespaces PrefixList vide à cet ensemble de nœuds pour obtenir une séquence d'octets s ;
  3. On peut considérer cette séquence d'octets s comme étant un codage UTF-8 d'une chaîne Unicode x (une séquence de caractères Unicode) ;
  4. On utilise la chaîne Unicode x comme forme lexicale de l ;
  5. Cette chaîne Unicode x DEVRAIT être dans la forme de normalisation C [NFC]

Puis o := typed-literal(literal-value := x, literal-datatype := http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral ) et la déclaration suivante s'ajoute au graphe :

e.parent.subject.string-value e.URI-string-value o.string-value .

Test : Cas du littéral vide indiqué par test009.rdf et test009.nt

Si l'attribut rdf:ID a est donné, la déclaration ci-dessus est réifiée avec i := uri(identifier := resolve(e, concat("#", a.string-value))) en utilisant les règles de réification à la section 7.3 et e.subject := i.

7.2.18 Production parseTypeResourcePropertyElt

start-element(URI == propertyElementURIs ),
    attributes == set(idAttr?, parseResource))
propertyEltList
end-element()

Pour un élément e avec un contenu d'élément c éventuellement vide.

n := bnodeid(identifier := generated-blank-node-id()).

Ajouter la déclaration suivante au graphe :

e.parent.subject.string-value e.URI-string-value n.string-value .

Test : Indiqué par test004.rdf et test004.nt

Si l'attribut rdf:ID a est donné, la déclaration ci-dessus est réifiée avec i := uri(identifier := resolve(e, concat("#", a.string-value))) en utilisant les règles de réification à la section 7.3 et e.subject := i.

Si le contenu d'élément c n'est pas vide, alors utiliser l'événement n pour créer une nouvelle séquence d'événements comme suit :

start-element(URI := rdf:Description,
    subject := n,
    attributes := set())
c
end-element()

Puis traiter la séquence obtenue en utilisant la production nodeElement.

7.2.19 Production parseTypeCollectionPropertyElt

start-element(URI == propertyElementURIs ),
    attributes == set(idAttr?, parseCollection))
nodeElementList
end-element()

Pour un événement d'élément e avec une liste nodeElementList l éventuellement vide. Poser s:=list().

Pour chaque événement d'élément f dans l, n := bnodeid(identifier := generated-blank-node-id()) et ajouter (append) n à s pour donner une séquence d'événements.

Si s n'est pas vide, n est le premier identificateur d'événement dans s et la déclaration suivante s'ajoute au graphe :

e.parent.subject.string-value e.URI-string-value n.string-value .

sinon la déclaration suivante s'ajoute au graphe :

e.parent.subject.string-value e.URI-string-value <http://www.w3.org/1999/02/22-rdf-syntax-ns#nil> .

Si l'attribut rdf:ID a est donné, l'une ou l'autre des déclarations ci-dessus est réifiée avec i := uri(identifier := resolve(e, concat("#", a.string-value))) en utilisant les règles de réification à la section 7.3.

Si s est vide, aucune autre tâche n'est effectuée.

Pour chaque événement n dans s et l'événement d'élément correspondant f dans l, la déclaration suivante s'ajoute au graphe :

n.string-value <http://www.w3.org/1999/02/22-rdf-syntax-ns#first> f.string-value .

Pour chaque couple d'événements consécutifs et chevauchants (overlapping) (no) dans s, la déclaration suivante s'ajoute au graphe :

n.string-value <http://www.w3.org/1999/02/22-rdf-syntax-ns#rest> o.string-value .

Si s n'est pas vide, n est le dernier identificateur d'événement dans s, la déclaration suivante s'ajoute au graphe :

n.string-value <http://www.w3.org/1999/02/22-rdf-syntax-ns#rest> <http://www.w3.org/1999/02/22-rdf-syntax-ns#nil> .

7.2.20 Production parseTypeOtherPropertyElt

start-element(URI == propertyElementURIs ),
    attributes == set(idAttr?, parseOther))
propertyEltList
end-element()

Toutes les valeurs d'attribut rdf:parseType, sauf les chaînes "Resource", "Literal" et "Collection", sont traitées comme si la valeur était "Literal". Cette production correspond et agit comme si la production parseTypeLiteralPropertyElt correspondait. Aucun triplet supplémentaire n'est généré pour d'autres valeurs rdf:parseType.

7.2.21 Production emptyPropertyElt

start-element(URI == propertyElementURIs ),
    attributes == set(idAttr?, ( resourceAttr | nodeIdAttr )?, propertyAttr*))
end-element()

7.2.22 Production idAttr

attribute(URI == rdf:ID,
    string-value == rdf-id)

Contrainte : constraint-id s'applique aux valeurs d'attribut rdf:ID

7.2.23 Production nodeIdAttr

attribute(URI == rdf:nodeID,
    string-value == rdf-id)

7.2.24 Production aboutAttr

attribute(URI == rdf:about,
    string-value == URI-reference)

7.2.25 Production propertyAttr

attribute(URI == propertyAttributeURIs,
    string-value == anyString)

7.2.26 Production resourceAttr

attribute(URI == rdf:resource,
    string-value == URI-reference)

7.2.27 Production datatypeAttr

attribute(URI == rdf:datatype,
    string-value == URI-reference)

7.2.28 Production parseLiteral

attribute(URI == rdf:parseType,
    string-value == "Literal")

7.2.29 Production parseResource

attribute(URI == rdf:parseType,
    string-value == "Resource")

7.2.30 Production parseCollection

attribute(URI == rdf:parseType,
    string-value == "Collection")

7.2.31 Production parseOther

attribute(URI == rdf:parseType,
    string-value == anyString - ("Resource" | "Literal" | "Collection") )

7.2.32 Production URI-reference

Une référence URI RDF.

7.2.33 Production literal

Tout contenu d'élément XML autorisé selon la défintion [XML] definition « Contenu des éléments » règle [43] content à la section 3.1 Balises ouvrantes, balises fermantes et balises d'élément vide.

La valeur chaîne string-value de l'événement résultant est traitée à la section 7.2.17.

7.2.34 Production rdf-id

Un attribut ·string-value· correspondant à un atome NCName [XML-NS] légal.

7.3 Règles de réification

Pour l'événement de référence URI r et la déclaration avec les termes s, p et o correspondant au triplet N-Triples :

s p o .

ajouter les déclarations suivantes au graphe :

r.string-value <http://www.w3.org/1999/02/22-rdf-syntax-ns#subject> s .
r.string-value <http://www.w3.org/1999/02/22-rdf-syntax-ns#predicate> p .
r.string-value <http://www.w3.org/1999/02/22-rdf-syntax-ns#object> o .
r.string-value <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/1999/02/22-rdf-syntax-ns#Statement> .

7.4 Règles d'expansion de liste

Pour l'élément donné e, créer une nouvelle référence URI RDF u := concat("http://www.w3.org/1999/02/22-rdf-syntax-ns#_", e.li-counter), incrémenter la propriété e.li-counter de 1 et retourner u.

8 Sérialisation d'un graphe RDF en RDF/XML

Certains graphes RDF définis dans Concepts et syntaxe abstraite RDF ne peuvent pas être sérialisés en RDF/XML. Ces graphes :

Utilisent des noms de propriété qui ne peuvent pas être transformés en noms qualifiés d'un espace de noms XML.
Un nom qualifié d'un espace de noms XML (QName) exerce des restrictions quant à la légalité des caractères, telles que les adresses URI de propriété ne sont pas toutes exprimables par ces noms. Pour décomposer une adresse URI en un nom d'espace de noms et un nom local, on recommande aux réalisateurs de sérialisateurs RDF (RDF serializers) de la scinder après le dernier caractère XML non-NCName, en s'assurant que le premier caractère du nom soit une lettre (Letter) ou un caractère SOULIGNÉ « _ ». Si l'adresse URI se termine par un caractère non-NCName, alors lancer une exception ou une erreur « ce graphe n'est pas sérialisable en RDF/XML ».
Utilisent des noms réservés inappropriés comme propriétés.
Par exemple, une propriété avec la même adresse URI que l'une de la production syntaxTerms.

Note à propos de la mise en œuvre (informatif) : Lorsqu'un graphe RDF est sérialisé en RDF/XML et contient un type de données XML Schema (XSD), il DEVRAIT être écrit dans une forme qui n'oblige pas à un traitement des caractères blancs. La gestion de XSD n'est pas obligatoire avec RDF ou RDF/XML, et ce traitement est donc optionnel.

9 Utilisation de RDF/XML avec HTML et XHTML

Incorporer du RDF/XML dans du HTML ou du XHTML peut ajouter de nombreux éléments et attributs nouveaux, dont beaucoup ne seront pas dans la définition DTD appropriée. Cette incorporation entraîne l'échec de la validation par rapport à la définition DTD. La solution évidente consistant à changer ou étendre la définition DTD n'est pas pratique dans la plupart des cas. Sean B. Palmer a analysé le problème en profondeur dans RDF in HTML: Approaches [RDF-IN-XHTML], en concluant qu'il n'existe pas de méthode d'incorporation unique qui satisfasse toutes les applications tout en restant simple.

L'approche recommandée est de ne pas incorporer du RDF/XML dans du HTML ou XHTML mais plutôt d'utiliser leur élement <link> dans l'élément <head> pour pointer vers un document RDF/XML séparé. Cette approche est celle suivie depuis des années par le Dublin Core Metadata Initiative (DCMI) sur son site web.

Pour utiliser cette technique, l'attribut href de l'élément <link> devrait pointer vers l'adresse URI du contenu RDF/XML et son attribut type devrait utiliser la valeur "application/rdf+xml", le type MIME proposé pour RDF/XML, cf. la section 4.

On peut également fixer la valeur de l'attribut rel pour indiquer la relation ; cette valeur dépend de l'application. Le DCMI utilise et recommande rel="meta" pour une liaison dans le document RFC 2731 — Codage des métadonnées Dublin Core en HTML [RFC-2731], toutefois rel="alternate" peut aussi convenir. Cf. les types de lien HTML 4.01, XHTML Modularization — LinkTypes et XHTML 2.0 — ContentTypes pour plus de renseignements à propos des valeurs appropriées pour les différentes versions de HTML.

L'exemple 21 montre l'utilisation de cette méthode avec la balise link dans un document XHTML pour relier un document RDF/XML externe.

Exemple 21 — Utilisation de link en XHTML avec un document RDF/XML externe (example21.html reliant à example21.rdf)
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
    <title>My document</title>
    <meta http-equiv="Content-type" content='text/html; charset="utf-8"' />
    <link rel="alternate" type="application/rdf+xml" title="RDF Version" href="example21.rdf" />
  </head>
  <body>
    <h1>My document</h1>

  </body>
</html>

10 Utilisation de RDF/XML avec SVG (informatif)

Il existe une approche normalisée pour associer des métadonnées compatibles RDF à SVG — l'élément metadata conçu spécialement pour cet usage comme défini à la section 21 Métadonnées de la Spécification des graphiques vectoriels redimensionnables (SVG) 1.0 [SVG] et à la section 21 Métadonnées de la Spécification des graphiques vectoriels redimensionnables (SVG) 1.1 [SVG11].

Ce document contient deux exemples de graphes SVG avec du tel RDF/XML incorporé dans l'élément metadata : figure 1 et figure 2.

11 Remerciements (informatif)

Les contributions des personnes suivantes ont été précieuses au document :

Ce document est le produit de débats approfondis au sein du groupe de travail RDF Core, dont les membres furent : Art Barstow (W3C), Dave Beckett (ILRT), Dan Brickley (W3C/ILRT), Dan Connolly (W3C), Jeremy Carroll (Hewlett Packard), Ron Daniel (Interwoven Inc), Bill dehOra (InterX), Jos De Roo (AGFA), Jan Grant (ILRT), Graham Klyne (Clearswift and Nine by Nine), Frank Manola (MITRE Corporation), Brian McBride (Hewlett Packard), Eric Miller (W3C), Stephen Petschulat (IBM), Patrick Stickler (Nokia), Aaron Swartz (HWG), Mike Dean (BBN Technologies / Verizon), R. V. Guha (Alpiri Inc), Pat Hayes (IHMC), Sergey Melnik (Stanford University), Martyn Horner (Profium Ltd).

Cette spécification s'appuie également sur les documents antérieurs de modèle et syntaxe RDF rédigé par Ora Lassilla et Ralph Swick, et RDF Schema rédigé par Dan Brickley et R. V. Guha. Les membres des groupes de travail RDF et RDF Schema ayant contribué aux travaux précédents sont : Nick Arnett (Verity), Tim Berners-Lee (W3C), Tim Bray (Textuality), Dan Brickley (ILRT / University of Bristol), Walter Chang (Adobe), Sailesh Chutani (Oracle), Dan Connolly (W3C), Ron Daniel (DATAFUSION), Charles Frankston (Microsoft), Patrick Gannon (CommerceNet), RV Guha (Epinions, anciennement chez Netscape Communications), Tom Hill (Apple Computer), Arthur van Hoff (Marimba), Renato Iannella (DSTC), Sandeep Jain (Oracle), Kevin Jones, (InterMind), Emiko Kezuka (Digital Vision Laboratories), Joe Lapp (webMethods Inc.), Ora Lassila (Nokia Research Center), Andrew Layman (Microsoft), Ralph LeVan (OCLC), John McCarthy (Lawrence Berkeley National Laboratory), Chris McConnell (Microsoft), Murray Maloney (Grif), Michael Mealling (Network Solutions), Norbert Mikula (DataChannel), Eric Miller (OCLC), Jim Miller (W3C, emeritus), Frank Olken (Lawrence Berkeley National Laboratory), Jean Paoli (Microsoft), Sri Raghavan (Digital/Compaq), Lisa Rein (webMethods Inc.), Paul Resnick (University of Michigan), Bill Roberts (KnowledgeCite), Tsuyoshi Sakata (Digital Vision Laboratories), Bob Schloss (IBM), Leon Shklar (Pencom Web Works), David Singer (IBM), Wei (William) Song (SISU), Neel Sundaresan (IBM), Ralph Swick (W3C), Naohiko Uramoto (IBM), Charles Wicksteed (Reuters Ltd.), Misha Wolf (Reuters Ltd.), Lauren Wood (SoftQuad).

12 Références

Références normatives

[RDF-MS]
Spécification du modèle et de la syntaxe du cadre de description de ressource (RDF), O. Lassila et R. Swick, Editors. World Wide Web Consortium. 22 février 1999. Cette version est celle à http://www.w3.org/TR/1999/REC-rdf-syntax-19990222. La dernière version est disponible à http://www.w3.org/TR/REC-rdf-syntax.
[XML]
Langage de balisage extensible (XML) 1.0 deuxième édition, T. Bray, J. Paoli, C.M. Sperberg-McQueen et E. Maler, rédacteurs. World Wide Web Consortium. 6 octobre 2000. Cette version est à http://www.w3.org/TR/2000/REC-xml-20001006. La dernière version est disponible à http://www.w3.org/TR/REC-xml.
[XML-NS]
Espaces de noms dans XML, T. Bray, D. Hollander et A. Layman, rédacteurs. World Wide Web Consortium. 14 janvier 1999. Cette version est à http://www.w3.org/TR/1999/REC-xml-names-19990114. La dernière version est disponible à http://www.w3.org/TR/REC-xml-names.
[INFOSET]
Ensemble d'information XML, J. Cowan et R. Tobin, rédacteurs. World Wide Web Consortium. 24 octobre 2001. Cette version est à http://www.w3.org/TR/2001/REC-xml-infoset-20011024. La dernière version est disponible à http://www.w3.org/TR/xml-infoset.
[URIS]
RFC 2396 : Identificateurs de ressource uniformes (URI) — Syntaxe générique, T. Berners-Lee, R. Fielding et L. Masinter, IETF, août 1998. Ce document est à http://www.isi.edu/in-notes/rfc2396.txt.
[RDF-CONCEPTS]
Cadre de description de ressource (RDF) — Concepts et syntaxe abstraite, Klyne G., Carroll J. (rédacteurs), recommandation du W3C, 10 février 2004. Cette version est à http://www.w3.org/TR/2004/REC-rdf-primer-20040210/. La dernière version est à http://www.w3.org/TR/rdf-concepts/.
[RDF-TESTS]
Jeux d'essais RDF, Grant J., Beckett D. (rédacteurs), recommandation du W3C, 10 février 2004. Cette version est à http://www.w3.org/TR/2004/REC-rdf-testcases-20040210/. La dernière version est à http://www.w3.org/TR/rdf-testcases/.
[KEYWORDS]
RFC 2119 : Mots-clés à utiliser dans les RFC pour indiquer les niveaux d'exigence, S. Bradner, IETF. mars 1997. Ce document est à http://www.ietf.org/rfc/rfc2119.txt.
[RFC-3023]
RFC 3023 : Types de média XML, M. Murata, S. St.Laurent, D.Kohn, IETF. Janvier 2001. Ce document est à http://www.ietf.org/rfc/rfc3023.txt.
[IANA-MEDIA-TYPES]
Types de média MIME, The Internet Assigned Numbers Authority (IANA). Ce document est à http://www.iana.org/assignments/media-types/ . L'enregistrement du type application/rdf+xml est archivé à http://www.w3.org/2001/sw/RDFCore/mediatype-registration
[XML-BASE]
XML Base, J. Marsh, rédacteur, recommandation du W3C. World Wide Web Consortium, 27 juin 2001. Cette version est à http://www.w3.org/TR/2001/REC-xmlbase-20010627. La dernière version est à http://www.w3.org/TR/xmlbase.
[XML-XC14N]
Canonisation XML exclusive version 1.0, J. Boyer, D.E. Eastlake 3rd, J. Reagle, auteurs/rédacteurs. Recommandation du W3C. World Wide Web Consortium. 18 juillet 2002. Cette version est à http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718. La dernière version est à http://www.w3.org/TR/xml-exc-c14n.
[UNICODE]
The Unicode Standard, Version 3, The Unicode Consortium, Addison-Wesley, 2000. ISBN 0-201-61633-5, tel que mis à jour de temps en temps lors de la publication de nouvelles versions. (Cf. http://www.unicode.org/unicode/standard/versions/ pour la dernière version et d'autres renseignements sur les versions du standardet la base de données de caractères Unicode).
[NFC]
Unicode Normalization Forms, Unicode Standard Annex #15, Mark Davis, Martin Dürst. (Cf. http://www.unicode.org/unicode/reports/tr15/ pour la dernière version).

Références informatives

[CHARMOD]
Modèle de caractères pour le Web 1.0, M. Dürst, F. Yergeau, R. Ishida, M. Wolf, A. Freytag, T Texin, rédacteurs, World Wide Web Consortium Working Draft, work in progress, 20 février 2002. Cette version est à http://www.w3.org/TR/2002/WD-charmod-20020220. La dernière version est à http://www.w3.org/TR/charmod.
[RDF-SEMANTICS]
Sémantique RDF, Hayes P. (rédacteur), recommandation du W3C, 10 février 2004. Cette version est à http://www.w3.org/TR/2004/REC-rdf-mt-20040210/. La dernière version est à http://www.w3.org/TR/rdf-mt/.
[RDF-PRIMER]
Initiation à RDF, F. Manola, E. Miller, rédacteurs, recommandation du W3C, 10 février 2004. Cette version est à http://www.w3.org/TR/2004/REC-rdf-primer-20040210/. La dernière version est à http://www.w3.org/TR/rdf-primer/.
[RDF-VOCABULARY]
Langage de description de vocabulaire RDF 1.0 : RDF Schema, Brickley D., Guha R.V. (rédacteurs), recommandation du W3C, 10 février 2004. Cette version et à http://www.w3.org/TR/2004/REC-rdf-schema-20040210/. La dernière version est à http://www.w3.org/TR/rdf-schema/.
[STRIPEDRDF]
RDF — Comprendre la syntaxe RDF/XML entrelacée, D. Brickley, W3C, 2001. Ce document est à http://www.w3.org/2001/10/stripes/.
[SVG]
Spécification des graphiques vectoriels redimensionnables (SVG) 1.0, J. Ferraiolo (rédacteur), 4 septembre 2001, recommandation du W3C. Cette version est à http://www.w3.org/TR/2001/REC-SVG-20010904. La dernière version est à http://www.w3.org/TR/SVG.
[SVG11]
Spécification des graphiques vectoriels redimensionnables (SVG) 1.1, J. Ferraiolo, J. FUJISAWA, D. Jackson (rédacteurs), 14 janvier 2003, recommandation du W3C. Cette version est à http://www.w3.org/TR/2003/REC-SVG11-20030114/. La dernière version est à http://www.w3.org/TR/SVG11.
[XPATH]
Langage de chemin XML (XPath) version 1.0, J. Clark and S. DeRose, rédacteurs. World Wide Web Consortium, 16 novembre 1999. Cette version est à http://www.w3.org/TR/1999/REC-xpath-19991116. La dernière version est à http://www.w3.org/TR/xpath.
[SAX2]
SAX Simple API for XML, version 2, D. Megginson, SourceForge, 5 mai 2000. Ce document est à http://sax.sourceforge.net/.
[UNPARSING]
Unparsing RDF/XML, J. J. Carroll, HP Labs Technical Report, HPL-2001-294, 2001. Ce document est disponible à http://www.hpl.hp.com/techreports/2001/HPL-2001-294.html.
[RELAXNG]
RELAX NG Specification, James Clark et MURATA Makoto, rédacteurs, OASIS Committee Specification, 3 décembre 2001. Cette version est à http://www.oasis-open.org/committees/relax-ng/spec-20011203.html. La dernière version est à http://www.oasis-open.org/committees/relax-ng/spec.html.
[RELAXNG-COMPACT]
RELAX NG Compact Syntax, James Clark, rédacteur. OASIS Committee Specification, 21 novembre 2002. Ce document est à http://www.oasis-open.org/committees/relax-ng/compact-20021121.html.
[RDF-IN-XHTML]
RDF in HTML: Approaches, Sean B. Palmer, 2002
[RFC-2731]
RFC 2731 : Codage des métadonnées Dublin Core en HTML, John Kunze, DCMI, décembre 1999.
[XML-SCHEMA1]
XML Schema tome 1 — Structures, H.S. Thompson, D. Beech, M. Maloney, N. Mendelsohn, rédacteurs, recommandation du W3C, 2 mai 2001. Cette version est à http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/. La dernière version est à http://www.w3.org/TR/xmlschema-1.
[XML-SCHEMA2]
XML Schema tome 2 — Types de données, P.V. Biron, A. Malhotra, rédacteurs, recommandation du W3C, 2 mai 2001. Cette version est à http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/. La dernière version est à http://www.w3.org/TR/xmlschema-2.

A Schémas de syntaxe (informatif)

Cette annexe contient les schémas XML de validation des formes RDF/XML. Ce ne sont que des exemples de schémas qui ne font pas partie de cette spécification.

A.1 Schéma RELAX NG Compact (informatif)

Voici un exemple de schéma en RELAX NG Compact (pour une meilleure lisibilité) pour RDF/XML. Les applications peuvent aussi utiliser la version RELAX NG XML. Ces formats sont décrits dans RELAX NG ([RELAXNG]) et RELAX NG Compact ([RELAXNG-COMPACT]).

Note : Le schéma RELAX NG Compact a été mis à jour pour tenter de correspondre à la grammaire mais il n'a pas été vérifié ni utilisé pour valider RDF/XML.

Schéma RELAX NG Compact pour RDF/XML
#
# RELAX NG Compact Schema for RDF/XML Syntax
#
# This schema is for information only and NON-NORMATIVE
#
# It is based on one originally written by James Clark in
# http://lists.w3.org/Archives/Public/www-rdf-comments/2001JulSep/0248.html
# and updated with later changes.
#

namespace local = ""
namespace rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
datatypes xsd = "http://www.w3.org/2001/XMLSchema-datatypes"


start = doc


# I cannot seem to do this in RNGC so they are expanded in-line

# coreSyntaxTerms = rdf:RDF | rdf:ID | rdf:about | rdf:parseType | rdf:resource | rdf:nodeID | rdf:datatype
# syntaxTerms = coreSyntaxTerms | rdf:Description | rdf:li
# oldTerms    = rdf:aboutEach | rdf:aboutEachPrefix | rdf:bagID
# nodeElementURIs       = * - ( coreSyntaxTerms | rdf:li | oldTerms )
# propertyElementURIs   = * - ( coreSyntaxTerms | rdf:Description | oldTerms )
# propertyAttributeURIs = * - ( coreSyntaxTerms | rdf:Description | rdf:li | oldTerms )

# Also needed to allow rdf:li on all property element productions
# since we can't capture the rdf:li rewriting to rdf_<n> in relaxng

# Need to add these explicitly
xmllang = attribute xml:lang { text }
xmlbase = attribute xml:base { text }
# and to forbid every other xml:* attribute, element

doc = 
  RDF | nodeElement

RDF =
  element rdf:RDF { 
     xmllang?, xmlbase?, nodeElementList
}

nodeElementList = 
  nodeElement*

  # Should be something like:
  #  ws* , (  nodeElement , ws* )*
  # but RELAXNG does this by default, ignoring whitespace separating tags.

nodeElement =
  element * - ( local:* | rdf:RDF | rdf:ID | rdf:about | rdf:parseType |
                rdf:resource | rdf:nodeID | rdf:datatype | rdf:li |
                rdf:aboutEach | rdf:aboutEachPrefix | rdf:bagID ) {
      (idAttr | nodeIdAttr | aboutAttr )?, xmllang?, xmlbase?, propertyAttr*, propertyEltList
  }

  # It is not possible to say "and not things
  # beginning with _ in the rdf: namespace" in RELAX NG.

ws = 
  " "

  # Not used in this RELAX NG schema; but should be any legal XML
  # whitespace defined by http://www.w3.org/TR/2000/REC-xml-20001006#NT-S


propertyEltList = 
  propertyElt*

  # Should be something like:
  #  ws* , ( propertyElt , ws* )*
  # but RELAXNG does this by default, ignoring whitespace separating tags.

propertyElt = 
  resourcePropertyElt | 
  literalPropertyElt | 
  parseTypeLiteralPropertyElt |
  parseTypeResourcePropertyElt |
  parseTypeCollectionPropertyElt |
  parseTypeOtherPropertyElt |
  emptyPropertyElt

resourcePropertyElt = 
  element * - ( local:* | rdf:RDF | rdf:ID | rdf:about | rdf:parseType |
                rdf:resource | rdf:nodeID | rdf:datatype |
                rdf:Description | rdf:aboutEach | rdf:aboutEachPrefix | rdf:bagID |
                xml:* ) {
      idAttr?, xmllang?, xmlbase?, nodeElement
  }

literalPropertyElt =
  element * - ( local:* | rdf:RDF | rdf:ID | rdf:about | rdf:parseType |
                rdf:resource | rdf:nodeID | rdf:datatype |
                rdf:Description | rdf:aboutEach | rdf:aboutEachPrefix | rdf:bagID |
                xml:* ) {
      (idAttr | datatypeAttr )?, xmllang?, xmlbase?, text 
  }

parseTypeLiteralPropertyElt = 
  element * - ( local:* | rdf:RDF | rdf:ID | rdf:about | rdf:parseType |
                rdf:resource | rdf:nodeID | rdf:datatype |
                rdf:Description | rdf:aboutEach | rdf:aboutEachPrefix | rdf:bagID |
                xml:* ) {
      idAttr?, parseLiteral, xmllang?, xmlbase?, literal 
  }

parseTypeResourcePropertyElt = 
  element * - ( local:* | rdf:RDF | rdf:ID | rdf:about | rdf:parseType |
                rdf:resource | rdf:nodeID | rdf:datatype |
                rdf:Description | rdf:aboutEach | rdf:aboutEachPrefix | rdf:bagID |
                xml:* ) {
      idAttr?, parseResource, xmllang?, xmlbase?, propertyEltList
  }

parseTypeCollectionPropertyElt = 
  element * - ( local:* | rdf:RDF | rdf:ID | rdf:about | rdf:parseType |
                rdf:resource | rdf:nodeID | rdf:datatype |
                rdf:Description | rdf:aboutEach | rdf:aboutEachPrefix | rdf:bagID |
                xml:* ) {
      idAttr?, xmllang?, xmlbase?, parseCollection, nodeElementList
  }

parseTypeOtherPropertyElt = 
  element * - ( local:* | rdf:RDF | rdf:ID | rdf:about | rdf:parseType |
                rdf:resource | rdf:nodeID | rdf:datatype |
                rdf:Description | rdf:aboutEach | rdf:aboutEachPrefix | rdf:bagID |
                xml:* ) {
      idAttr?, xmllang?, xmlbase?, parseOther, any
  }

emptyPropertyElt =
   element * - ( local:* | rdf:RDF | rdf:ID | rdf:about | rdf:parseType |
                 rdf:resource | rdf:nodeID | rdf:datatype |
                 rdf:Description | rdf:aboutEach | rdf:aboutEachPrefix | rdf:bagID |
                 xml:* ) {
       idAttr?, (resourceAttr | nodeIdAttr)?, xmllang?, xmlbase?, propertyAttr*
   }

idAttr = 
  attribute rdf:ID { 
      IDsymbol 
  }

nodeIdAttr = 
  attribute rdf:nodeID { 
      IDsymbol 
  }

aboutAttr = 
  attribute rdf:about { 
      URI-reference 
  }

propertyAttr = 
  attribute * - ( local:* | rdf:RDF | rdf:ID | rdf:about | rdf:parseType |
                  rdf:resource | rdf:nodeID | rdf:datatype | rdf:li |
                  rdf:Description | rdf:aboutEach |
        rdf:aboutEachPrefix | rdf:bagID |
                  xml:* ) {
      string
  }

resourceAttr = 
  attribute rdf:resource {
      URI-reference 
  }

datatypeAttr = 
  attribute rdf:datatype {
      URI-reference 
  }

parseLiteral = 
  attribute rdf:parseType {
      "Literal" 
  }

parseResource = 
  attribute rdf:parseType {
      "Resource"
  }

parseCollection = 
  attribute rdf:parseType {
      "Collection"
  }

parseOther = 
  attribute rdf:parseType {
      text
  }

URI-reference = 
  string

literal =
  any

IDsymbol = 
  xsd:NMTOKEN

any =
  mixed { element * { attribute * { text }*, any }* }

B Révisions depuis le projet du 10 octobre 2003 (informatif)

Changements depuis la deuxième version préliminaire du 10 octobre 2003

Ceux-ci se répartissent en changements non rédactionnels et changements rédactionnels. Les changements non rédactionnels listent également les changements rédactionnels consécutifs. Les changements rédactionnels sont ceux qui ne se traduisent par aucun changement du sens d'un document RDF ou du comportement d'une application RDF.

Annexe B.1 : Révisions non rédactionnelles

Néant.

Annexe B.2 : Révisions rédactionnelles

Traduction allemande
Corrigé le texte en allemand dans l'exemple 8 à la section 2.7 suite au commentaire de Benjamin Nowack
Pas d'attributs de propriété sur rdf:parseType="Resource"
Section 2.5 mise à jour pour réfléter la définition de syntaxe selon laquelle les attributs de propriété ne peuvent pas être utilisés avec rdf:parseType="Resource" comme signalé par le commentaire de Sabadello 2003-10-30
Codage des adresses URI
Sections 6.1.6, 6.1.8, 6.1.9 après proposition de Jeremy Carroll
sections 6.1.2, 6.1.4 : ajouté les sélecteurs URI-string-value aux éléments ou attributs
sections 7.2.11, 7.2.21 : ajouté l'utilisation d'un nouvel événement uri pour les cas rdf:type
7.2.11 (<e.URI> et <a.URI>), 7.2.15 (<e.URI>) 7.2.16 (<e.URI>) 7.2.17 (<e.URI>) 7.2.18 (<e.URI>) 7.2.19 (<e.URI> deux fois) 7.2.21 (<e.URI> twice, <a.URI> une fois) : changé de X.URI en X.URI-string-value (partout où apparaissait "<"..">" dans l'action de la grammaire sans référence URI figée dans le code (hardcoded))
section 7.2.32 : remplacé la formulation de l'action par « Une référence URI RDF »
tout changé comme souligné dans la proposition 2003-10-06 suite au commentaire de Patel-Schneider 2003-10-29

Annexe B.3 : Problèmes ne nécessitant pas de révisions du document

Néant.


RDF/XML Metadata