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.
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].
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.
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.
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 :
Le côté gauche du graphe de la figure 2 correspond aux lacis nœud/arc de prédicat suivants :
- Un nœud avec la référence URI RDF
http://www.w3.org/TR/rdf-syntax-grammar
- Un arc de prédicat étiqueté avec la référence URI RDF
http://example.org/terms/editor
- Un nœud sans référence URI RDF
- Un arc de prédicat étiqueté avec la référence URI RDF
http://example.org/terms/homePage
- 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é.
<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 :
<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) :
<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>
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) :
<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>
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 :
<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>
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 :
<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>
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 :
<?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.
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 :
<?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>
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.
<?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>
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].
<?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>
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.
<?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>
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 :
<?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>
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 :
<?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>
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.
<?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>
<?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>
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.
<?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>
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.
<?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>
<?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>
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 :
<?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>
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.
<?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>
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).
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].
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.
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.
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
où 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
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 :
- données en valeurs d'attribut XML interprétées comme des références URI relatives résolues par rapport à
l'adresse URI de base dans le champ, comme décrit à la section 5.3, pour donner des
références URI RDFabsolues ;
- transformées à partir des noms d'élément et d'attribut qualifiés d'un espace de noms XML (noms qualifiés QName) ;
- transformées à partir des valeurs d'attribut
rdf:ID.
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.
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.
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].
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.
- 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.
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.
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 :
- Cette spécification autorise toute représentation
d'un graphe RDF (cf. [RDF-CONCEPTS]) ; elle n'impose pas l'utilisation de
N-Triples ;
- Cette spécification n'impose pas l'utilisation de [XPATH] ou de [SAX2] ;
- Cette spécification n'exerce aucune contrainte sur l'ordre dans lequel un logiciel tranformant du RDF/XML en une représentation
de graphe construit la représentation du graphe ;
- Un logiciel transformant du RDF/XML en une représentation de graphe PEUT éliminer les
arcs de prédicat en double.
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.
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.
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.
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.
N'a aucun sélecteur ; marque la fin de l'élément conteneur dans la séquence.
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.
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.
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.
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.
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.
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.
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.
- L'événement d'élément original ;
- La valeur du sélecteur children transformée récursivement,
une liste ordonnée d'événements éventuellement vide ;
- Un événement d'élément de fin
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
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.
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. |
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. |
| 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.
|
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.
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.
Tous les termes de syntaxe du vocabulaire RDF à la section 5.1
utilisés en RDF/XML.
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.
Les références URI RDF
qui sont permises sur les éléments de nœud.
Les adresses URI qui sont permises sur les éléments de propriété.
Les références URI RDF
qui sont permises sur les attributs de propriété.
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 :
- Si e.URI !=
rdf:Description,
alors la déclaration suivante s'ajoute au graphe :
- S'il y a un attribut a dans
propertyAttr avec a.URI ==
rdf:type,
alors u:=uri(identifier:=resolve(a.string-value))
et le triplet suivant s'ajoute au graphe :
- Pour chaque attribut a correspondant à
propertyAttr (et non
rdf:type), la chaîne Unicode
a.string-value
DEVRAIT être dans la forme de normalisation C (Normal Form C) [NFC],
o := literal(literal-value := a.string-value, literal-language := e.language)
et la déclaration suivante s'ajoute au graphe :
- S'occuper des événements des sous-éléments propertyEltList
dans l'ordre du document.
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.
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 :
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
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 :
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.
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.
- Utiliser l pour construire un ensemble de nœuds XPath [XPATH]
node-set
(un sous-ensemble du document) ;
- 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 ;
- 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) ;
- On utilise la chaîne Unicode x comme forme lexicale de l ;
- 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 :
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.
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 :
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 :
Puis traiter la séquence obtenue en utilisant la production nodeElement.
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 :
sinon la déclaration suivante s'ajoute au graphe :
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 :
Pour chaque couple d'événements consécutifs et chevauchants (overlapping)
(n, o) dans s, la déclaration suivante s'ajoute au graphe :
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> .
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.
S'il n'y a aucun attribut ou seulement l'attribut optionnel rdf:ID i,
alors o := literal(literal-value:="", literal-language := e.language)
et la déclaration suivante s'ajoute au graphe :
puis si i est donné, la déclaration ci-dessus est réifiée avec
uri(identifier := resolve(e, concat("#", i.string-value)))
en utilisant les règles de réification à la section 7.3.
Sinon :
- Si l'attribut
rdf:resource i est présent,
alors r := uri(identifier := resolve(e, i.string-value)) ;
- Si l'attribut
rdf:nodeID i est présent,
alors r := bnodeid(identifier := i.string-value) ;
- Si ni l'un ni l'autre ne sont présents,
r := bnodeid(identifier := generated-blank-node-id())
Les tâches suivantes sont effectuées dans un ordre quelconque :
Pour tous les attributs propertyAttr a (dans un ordre quelconque) :
Ajouter la déclaration suivante au graphe :
puis si l'attribut rdf:ID i est donné, la déclaration ci-dessus est réifiée avec
uri(identifier := resolve(e, concat("#", i.string-value)))
en utilisant les règles de réification à la section 7.3.
Contrainte : constraint-id s'applique aux valeurs d'attribut rdf:ID
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 :
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> .
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.
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.
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.
<?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 :
- Dan Brickley, W3C/ILRT
- Jeremy Carroll, HP Labs, Bristol
- Graham Klyne, Nine by Nine
- Bijan Parsia, MIND Lab at University of Maryland at College Park
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.
#
# 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 }* }
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.
Néant.
- 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
Néant.
