Initiation à RDF

2.1 Concepts de base

Imaginez que l'on veuille déclarer qu'un dénommé John Smith a créé une page web particulière. Une façon toute simple de l'énoncer dans un langage naturel tel que le français prendrait la forme d'une déclaration telle que :

http://www.example.org/index.html a un créateur (creator) dont la valeur est John Smith

Des parties de cette déclaration sont mises en exergue afin d'illustrer que, pour décrire les propriétés d'une chose, il est nécessaire de pouvoir nommer ou identifier plusieurs choses :

• la chose que la déclaration décrit (ici la page web) ;
• une propriété spécifique (ici le créateur) de la chose que la déclaration décrit ;
• la chose que la déclaration dit être la valeur de cette propriété (qui est le créateur ?) de la chose décrite par la déclaration.

Dans cette déclaration, l'adresse URL (Uniform Resource Locator) sert à identifier la chose. En outre, le mot « creator » est utilisé pour identifier la propriété, et les deux mots « John Smith » pour identifier la chose (une personne) qui est la valeur de cette propriété.

On pourrait décrire d'autres propriétés de cette page web en posant des déclarations supplémentaires en français de même forme générale, en utilisant l'adresse URL pour identifier la page et des mots (ou d'autres expressions) pour identifier les propriétés et leurs valeurs. Par exemple, on pourrait décrire la date de création de la page et la langue dans laquelle la page est écrite en utilisant les déclarations supplémentaires suivantes :

http://www.example.org/index.html a une date de création (creation-date) dont la valeur est August 16, 1999
http://www.example.org/index.html a une langue (language) dont la valeur est English

RDF repose sur l'idée que les choses décrites ont des propriétés lesquelles ont des valeurs, et que les ressources peuvent être décrites en faisant des déclarations, similaires aux précédentes, qui définissent ces propriétés et valeurs. RDF emploie une terminologie particulière pour indiquer les diverses parties des déclarations. Spécifiquement, la partie qui identifie la chose dont il est question dans la déclaration (ici la page web) est appelée le sujet (subject) ; la partie qui identifie la propriété ou la caractéristique du sujet que la déclaration définit (ici le créateur, la date de création ou la langue) est appelée le prédicat (predicate) ; la partie qui identifie la valeur de cette propriété est appelée l'objet (object). Ainsi, en prenant la déclaration en français :

http://www.example.org/index.html a un créateur (creator) dont la valeur est John Smith

les termes RDF pour les diverses parties de la déclaration sont les suivants :

• le sujet est l'adresse URL http://www.example.org/index.html
• le prédicat est le mot « creator »
• l'objet est l'expression « John Smith »

Toujours est-il, tandis que le français convient pour communiquer entre des humains (francophones), RDF concerne l'élaboration de déclarations interprétées automatiquement (machine-processable). Pour fabriquer ces types de déclarations utilisables en vue d'un traitement automatique, il faut deux choses :

• un système d'identificateurs interprétés automatiquement pour identifier le sujet, le prédicat ou l'objet dans une déclaration, sans confusion possible avec un identificateur d'aspect semblable utilisé par quelqu'un d'autre sur le Web ;
• un langage interprété automatiquement pour représenter ces déclarations et les échanger entre machines.

Heureusement, l'architecture Web existante fournit ces deux facilités (facilities) nécessaires.

Comme illustré précédemment, le Web offre déjà une forme d'identificateur : le localisateur de ressource uniforme (Uniform Resource Locator) ou adresse URL. Dans le premier exemple pour identifier la page web créée par John Smith, on utilisait une adresse URL. Une adresse URL est une chaîne de caractères qui identifie une ressource Web dans une représentation de son mécanisme d'accès primaire (essentiellement, son adresse sur le réseau). Néanmoins, il est également important de pouvoir enregistrer des informations à propos de beaucoup de choses qui, contrairement aux pages web, n'ont pas de localisation sur le réseau ou d'adresse URL.

Le Web offre une forme plus générale d'identificateur pour ces besoins, à savoir l'identificateur de ressource uniforme (Uniform Resource Identifier) ou adresse URI. Les adresses URL sont des types particuliers d'adresses URI. Toutes les adresses URI partagent comme propriété de pouvoir être créées indépendamment par des personnes ou des organisations différentes qui peuvent les utiliser pour identifier des choses. Par contre, les adresses URI ne se limitent pas à l'identification de choses qui ont une localisation dans un réseau ou utilisent d'autres mécanismes d'accès informatique. En fait, on peut créer une adresse URI pour tout ce qui a besoin d'être cité dans une déclaration, à savoir :

• les choses accessibles dans un réseau, telles qu'un document électronique, une image, un service (par exemple le « bulletin météo du jour pour Los Angeles ») ou un groupe d'autres ressources ;
• les choses non accessibles dans un réseau, telles que les être humains, les entreprises et les bouquins dans une bibliothèque ;
• les concepts abstraits sans réalité physique, tels que le concept de « créateur ».

À cause de cette généralité, RDF utilise des adresses URI comme base de son mécanisme pour identifier les sujets, les prédicats et les objets dans les déclarations. Plus précisément, RDF utilise des références URI (URI references) [URIS]. Une référence URI (URIref) est une adresse URI avec un identificateur de fragment (fragment identifier) optionnel à la fin. Par exemple, la référence URI http://www.example.org/index.html#section2 se compose de l'adresse URI http://www.example.org/index.html et (séparé par le caractère « # ») de l'identificateur de fragment section2. Les références URI RDF peuvent contenir des caractères Unicode [UNICODE] (cf. [RDF-CONCEPTS]), ce qui y permet la manifestation de beaucoup de langues. RDF définit une ressource (resource) comme quelque chose d'identifiable par une reférence URI ; ainsi les références URI permettent de pratiquement tout décrire et aussi de déclarer des relations entre ces choses. Les références URI et les identificateurs de fragment sont traités en détails dans l'annexe A, et dans [RDF-CONCEPTS].

Pour représenter les déclarations RDF en vue d'un traitement automatique, RDF utilise le langage de balisage extensible [XML]. XML a été conçu pour que chacun puisse créer son propre format de document et écrire un document dans ce format. RDF définit un langage de balisage XML spécifique, appelé RDF/XML, qui sert à représenter l'information RDF pour un échange entre machines. Un exemple de syntaxe RDF/XML est donné dans la section 1. Cet exemple (exemple 1) employait des balises telles que <contact:fullName> et <contact:personalTitle> pour délimiter les contenus textuels Eric Miller et Dr., respectivement. De telles balises permettent à des programmes écrits en ce sens d'interpréter correctement ce contenu. Le contenu et les balises XML (exceptionnellement) peuvent contenir des caractères Unicode [UNICODE], permettant d'y représenter directement l'informations en de nombreuses langues. L'annexe B fournit une documentation de base supplémentaire sur XML en général. La syntaxe RDF/XML spécifique utilisée pour RDF est décrite plus en détails à la section 3 ; sa définition normative est dans [RDF-SYNTAX].

2.2 Le modèle RDF

La section 2.1 introduisait les concepts de déclaration élémentaire RDF, l'idée d'utiliser des références URI pour identifier les choses citées dans les déclarations RDF, et la syntaxe RDF/XML comme un moyen de représenter les déclarations RDF en vue d'un traitement automatique. Dans ce contexte, cette section décrit comment RDF utilise les adresses URI pour faire des déclarations à propos de ressources, où chaque déclaration consiste en un sujet, un prédicat et un objet. En RDF, la phrase en français :

http://www.example.org/index.html a un créateur (creator) dont la valeur est John Smith

serait représentable par une déclaration RDF qui a :

• un sujet http://www.example.org/index.html
• un prédicat http://purl.org/dc/elements/1.1/creator
• et un objet http://www.example.org/staffid/85740

Notez comment les références URI sont utilisées pour identifier non seulement le sujet de la déclaration originale mais aussi le prédicat et l'objet, au lieu d'utiliser les mots « creator » et « John Smith » respectivement (nous verrons plus loin quelles peuvent être les effets d'utiliser les références URI de cette façon).

RDF modélise les déclarations comme des nœuds (nodes) et des arcs (arcs) dans un graphe. Le modèle de graphe de RDF est défini dans [RDF-CONCEPTS]. Dans cette notation, une déclaration est représentée par :

• un nœud pour le sujet ;
• un nœud pour l'objet ;
• un arc, orienté du nœud sujet vers le nœud objet, pour le prédicat.

Ainsi la déclaration RDF ci-dessus serait représentée par le graphe montré en figure 2 :

Figure 2 : Une déclaration RDF simple

Les groupes de déclarations sont représentés par des groupes correspondants de nœuds et d'arcs. Ainsi, pour refléter les déclarations en français suivantes :

http://www.example.org/index.html a une date de création (creation-date) dont la valeur est August 16, 1999
http://www.example.org/index.html a une langue (language) dont la valeur est English

dans le graphe RDF, on pourrait utiliser le graphe montré en figure 3 (en utilisant les références URI qui conviennent pour nommer les propriétés "creation-date" et "language") :

Figure 3 : Plusieurs déclarations à propos de la même ressource

La figure 3 illustre le fait que les objets dans les déclarations RDF peuvent être soit des références URI, soit des valeurs constantes — appelées des littéraux (literals) — exprimées par des chaînes de caractères, afin de représenter certains types de valeurs de propriétés. (En ce qui concerne le prédicat http://purl.org/dc/elements/1.1/language, le littéral est un code normalisé international de deux lettres pour l'anglais). Les littéraux ne peuvent pas être utilisés comme sujets ou prédicats dans les déclarations RDF. Dans le dessin des graphes RDF, les nœuds qui sont des références URI apparaissent comme des ellipses, ceux qui sont des littéraux comme des rectangles (boxes). (Les littéraux à chaîne de caractères simple utilisés dans ces exemples sont appelés des littéraux ordinaires (plain literals), pour les distinguer des littéraux typés (typed literals) qui seront introduits à la section 2.4. Les divers types de littéraux utilisables dans les déclarations RDF sont définis dans [RDF-CONCEPTS]. Les littéraux ordinaires et typés peuvent contenir des caractères Unicode [UNICODE], ce qui permet de représenter directement des informations en de nombreuses langues).

Parfois il n'est pas commode de dessiner des graphes pour en parler, et on utilise aussi une autre façon d'écrire les déclarations, les triplets (triples). Dans la notation en triplets, chaque déclaration dans le graphe s'écrit comme un triplet simple formé du sujet, du prédicat et de l'objet, dans cet ordre. Par exemple, les trois déclarations montrées en figure 3 s'écriraient ainsi dans la notation en triplets :

<http://www.example.org/index.html> <http://purl.org/dc/elements/1.1/creator> <http://www.example.org/staffid/85740> .

<http://www.example.org/index.html> <http://www.example.org/terms/creation-date> "August 16, 1999" .

<http://www.example.org/index.html> <http://purl.org/dc/elements/1.1/language> "en" .

Chaque triplet correspond à un seul arc dans le graphe, en entier avec les nœuds de départ et d'arrivée (le sujet et l'objet de la déclaration). À la différence du graphe dessiné (mais comme les déclarations originales), la notation en triplets impose d'identifier séparément un nœud dans chaque déclaration où il apparaît. Ainsi, http://www.example.org/index.html apparaît trois fois (une fois dans chaque triplet) dans la représentation en triplets du graphe mais seulement une fois dans le graphe dessiné. Quoiqu'il en soit, les triplets représentent exactement la même information que le graphe dessiné, et c'est un point capital : le modèle de graphe (graph model) des déclarations est fondamental en RDF. La notation employée pour représenter ou dépeindre le graphe est secondaire.

La notation en triplets complète impose d'écrire entièrement les références URI entre des crochets en chevron, ce qui peut donner de très longue lignes dans une page, comme l'illustre l'exemple précédent. Par commodité, l'initiation emploie une méthode pour réduire l'écriture des triplets (les autres spécifications RDF utilisent la même méthode). Cette réduction (shorthand) substitue un nom qualifié XML (ou nom de type QName), sans les chevrons, à la référence URI complète (les noms de type QName sont traités plus en détails à l'annexe B). Un nom qualifié contient le préfixe (prefix) affecté à l'adresse URI d'un espace de noms, suivi d'un caractère DEUX-POINTS et d'un nom local (local name). La référence URI complète est formée à partir du nom qualifié en ajoutant le nom local à la fin de l'adresse URI d'espace de noms affectée au préfixe. Ainsi, si le préfixe de nom qualifié foo est affecté à l'adresse URI d'espace de noms http://example.org/somewhere/, alors le nom qualifié foo:bar est la réduction de la référence URI http://example.org/somewhere/bar. Les exemples de cette initiation emploieront aussi plusieurs préfixes de nom qualifié « bien connus » (sans les définir explicitement à chaque fois) dont voici les descriptions :

préfixe rdf:, adresse URI d'espace de noms : http://www.w3.org/1999/02/22-rdf-syntax-ns#
préfixe rdfs:, adresse URI d'espace de noms : http://www.w3.org/2000/01/rdf-schema#
préfixe dc:, adresse URI d'espace de noms : http://purl.org/dc/elements/1.1/
préfixe owl:, adresse URI d'espace de noms : http://www.w3.org/2002/07/owl#
préfixe ex:, adresse URI d'espace de noms : http://www.example.org/ (ou http://www.example.com/)
préfixe xsd:, adresse URI d'espace de noms : http://www.w3.org/2001/XMLSchema#

Nous utiliserons aussi des variations flagrantes du préfixe « example » ex: au besoin dans les exemples, ainsi :

préfixe exterms:, adresse URI d'espace de noms : http://www.example.org/terms/ (pour les termes utilisés dans une organisation en exemple) ;
préfixe exstaff:, adresse URI d'espace de noms : http://www.example.org/staffid/ (pour les identificateurs du personnel d'une organisation en exemple) ;
préfixe ex2:, adresse URI d'espace de noms : http://www.domain2.example.org/ (pour une deuxième organisation en exemple), et ainsi de suite.

Avec cette nouvelle réduction, l'ensemble de triplets précédent peut s'écrire ainsi :

ex:index.html  dc:creator             exstaff:85740 .

ex:index.html  exterms:creation-date  "August 16, 1999" .

ex:index.html  dc:language            "en" .

ex:index.html  dc:creator  exstaff:85740 .

ex:index.html  dc:creator  exstaff:27354 .

ex:index.html  dc:creator  exstaff:00816 .

Ces exemples de déclarations RDF laissent poindre les avantages à utiliser des références URI comme méthode de base pour identifier les choses. Ainsi, dans la première déclaration, au lieu d'identifier le créateur de la page web par la chaîne de caractères "John Smith", on lui a affecté une référence URI, à savoir (en utilisant une référence URI fondée sur son numéro d'employé) http://www.example.org/staffid/85740. Ici l'avantage d'utiliser une référence URI est que l'identification du sujet de la déclaration peut être plus précise. C'est-à-dire que le créateur de la page n'est pas la chaîne de caractères "John Smith", ou l'une parmi les milliers de personnes nommées John Smith, mais le John Smith particulier associé à cette référence URI (la personne qui a créé la référence URI, quelle qu'elle soit, définit l'association). En outre, puisqu'il existe une référence URI pour désigner John Smith, il est une ressource à part entière et on peut enregistrer d'autres informations le concernant, simplement en ajoutant des déclarations RDF ayant pour sujet la référence URI de John. Par exemple, la figure 4 montre des déclarations supplémentaires donnant le nom et l'âge de John.

Figure 4 : Plus de renseignements à propos de John Smith

Ces exemples illustrent également le fait que RDF emploie des références URI comme prédicats dans les déclarations RDF. C'est-à-dire que RDF utilise des références URI plutôt que des chaînes de caractères (ou mots) telles que "creator" ou "name" pour identifier les propriétés. L'utilisation de références URI pour identifier les propriétés est important pour plusieurs raisons. D'abord, elle distingue les propriétés utilisées par une personne de celles différentes utilisées par une autre qui seraient éventuellement identifiées sinon par la même chaîne de caractères. Ainsi, dans l'exemple en figure 4, example.org utilise "name" dans le sens du nom entier de la personne écrit comme une chaîne de caractères littérale (par exemple, "John Smith"), mais quelqu'un d'autre peut envisager "name" dans un sens différent (par exemple, le nom d'une variable dans un bout de code). Un programme rencontrant "name" comme identificateur de propriété sur le Web (ou assemblant des données de plusieurs sources) ne distinguera pas nécessairement ces utilisations. En revanche, si example.org écrit http://www.example.org/terms/name pour sa propriété "name" et l'autre personne http://www.domain2.example.org/genealogy/terms/name pour la sienne, il apparaîtra clairement que des propriétés distinctes sont engagées (même si le programme ne peut pas déterminer automatiquement les sens différents). Et puis utiliser des références URI pour identifier les propriétés permet de les traiter elles-mêmes comme des ressources. Puisque les propriétés sont des ressources, on peut enregistrer des informations supplémentaires sur elles (par exemple, la description en français de ce que "name" veut dire pour example.org), simplement en ajoutant des déclarations RDF dont le sujet est la référence URI de la propriété.

L'utilisation de références URI comme sujets, prédicats et objets des déclarations RDF promeut le développement et l'utilisation de vocabulaires partagés sur le Web, puisque les personnes peuvent découvrir et commencer à utiliser des vocabulaires déjà utilisés par d'autres pour décrire les choses, en reflétant une compréhension commune de ces concepts. Par exemple, dans le triplet suivant :

ex:index.html   dc:creator   exstaff:85740 .

le prédicat dc:creator, lorsqu'il se résoud complètement en une référence URI, est une référence univoque vers l'attribut "creator" du jeu d'attributs de métadonnées Dublin Core (abordé plus loin à la section 6.1), un ensemble d'attributs (propriétés) largement répandu pour décrire des informations de toutes sortes. L'auteur de ce triplet est effectivement en train de dire que la relation entre la page web (identifiée par http://www.example.org/index.html ) et le créateur de la page (une personne distincte identifiée par http://www.example.org/staffid/85740) correspond exactement au concept identifié par http://purl.org/dc/elements/1.1/creator. Une autre personne familiarisée avec le vocabulaire Dublin Core, ou qui découvre ce que signifie dc:creator (disons en recherchant sa définition sur le Web) saura ce que cette relation veut dire. De plus, avec cette compréhension, quelqu'un peut écrire des programmes qui agissent conformément à cette signification lors du traitement de triplets contenant le prédicat dc:creator.

Bien sûr, tout cela dépend d'une utilisation générale croissante des références URI pour désigner les chose à la place des littéraux ; par exemple utiliser des références URI comme exstaff:85740 et dc:creator au lieu de chaînes de caractères littérales comme "John Smith" et "creator". L'emploi par RDF de références URI ne résoud quand même pas tous les problèmes d'identification puisque, par exemple, on peut toujours utiliser des références URI différentes pour désigner la même chose. Pour cette raison, c'est une bonne idée d'utiliser si possible les termes de vocabulaires existants (tels que le Dublin Core) plutôt que d'en créer de nouveaux qui pourraient téléscoper (overlap with) ceux d'un autre vocabulaire. Des vocabulaires adaptés à des domaines d'application spécifiques sont constamment développés, comme illustré par les applications décrites à la section 6. En revanche, même pour la création de synonymes, le fait que ces références URI différentes soient utilisées dans l'« espace Web » accessible à tous permet à la fois d'identifier les équivalences entre ces références différentes et de migrer vers l'utilisation de références communes.

ex:index.html  dc:creator  exstaff:85740 .

fy:joefy.iunm  ed:dsfbups  fytubgg:85740 .

Le résultat de tout ceci est que RDF offre un moyen de créer des déclarations que les applications peuvent traiter plus facilement. Comme déjà indiqué, une application ne peut pas réellement « comprendre » ces déclarations, pas plus qu'une base de données ne « comprend » les termes employee ou salary lors du traitement d'une requête telle que SELECT NAME FROM EMPLOYEE WHERE SALARY > 35000. En revanche, si l'application est bien écrite, elle peut traiter les déclarations RDF d'une façon qui laisse penser qu'elle les comprend, tout comme un système de base de données et ses applications peuvent faire œuvre utile en traitant des listes d'employés et des feuilles de paie sans comprendre les mots « employé » ni « feuille de paie ». Par exemple, un utilisateur pourrait chercher sur le Web toutes les critiques de livres et créer un classement moyen pour chaque livre, qu'il mettra en ligne ensuite. Un autre site web pourrait prendre ce classement et créer une page des « Dix meilleurs livres du classement ». Ici la disponibilité et l'utilisation d'un vocabulaire commun pour les classements, et d'un ensemble commun de références URI identifiant les livres auxquels elles s'appliquent, permettent à des personnes de bâtir une « base d'information » (information base) à propos de livres sur le Web, comprise mutuellement et de plus en plus efficace (au fur et à mesure des contributions). Le même principe peut s'appliquer aux énormes quantités d'information que les personnes créent à propos de milliers de sujets chaque jour sur le Web.

Les déclarations RDF sont similaires à beaucoup d'autres formats d'enregistrement d'information tels que:

• les entrées dans une liste simple d'enregistrements ou de catalogues décrivant les ressources dans un système de traitement de données ;
• les lignes (rows) dans une base de données relationnelle simple ;
• les assertions simples en logique formelle.

et les informations dans ces formats peuvent être traitées comme des déclarations RDF, permettant d'utiliser RDF pour intégrer les données de plusieurs sources.

2.3 Valeurs de propriété structurées et nœuds anonymes

Tout serait très simple si les seuls types d'information à enregistrer à propos des choses avaient la forme manifeste des déclarations RDF simples illustrées jusqu'ici. Toujours est-il que la plupart des données du monde réel font état de structures beaucoup plus compliquées, au moins en surface. Ainsi, dans l'exemple original, la date de création de la page web est enregistrée comme une seule propriété exterms:creation-date dont la valeur est un littéral ordinaire. Mais à supposer que la valeur de cette propriété exterms:creation-date doive enregistrer le mois, le jour et l'année comme des informations distinctes ? Ou, dans le cas des coordonnées de John Smith, supposons que l'on décrive l'adresse de John. On pourrait écrire l'adresse complète comme un littéral simple tel que dans ce triplet-ci :

exstaff:85740   exterms:address   "1501 Grant Avenue, Bedford, Massachusetts 01730" .

Mais à supposer qu'il faille enregistrer l'adresse de John comme une structure constituée de valeurs séparées pour la rue, la ville, l'état et le code postal ? Comment le ferait-on en RDF ?

Une information structurée comme celle-ci est représentée dans RDF en considérant la chose agrégée à décrire (telle l'adresse de John Smith) comme une ressource, puis en faisant des déclarations à propos de cette nouvelle ressource. Ainsi, dans le graphe RDF, pour scinder l'adresse de John Smith en ses parties constituantes, on crée un nouveau nœud afin de représenter le concept d'adresse de John Smith, avec une nouvelle référence URI pour la représenter, disons http://www.example.org/addressid/85740 (réduit en exaddressid:85740). On peut alors écrire des déclarations RDF (d'autres arcs et nœuds) ayant ce nœud pour sujet, pour représenter les informations supplémentaires produisant le graphe montré en figure 5 :

Figure 5 : Scinder l'adresse de John

ou bien les triplets :

exstaff:85740       exterms:address        exaddressid:85740 .
exaddressid:85740   exterms:street         "1501 Grant Avenue" .
exaddressid:85740   exterms:city           "Bedford" .
exaddressid:85740   exterms:state          "Massachusetts" .
exaddressid:85740   exterms:postalCode     "01730" .

Cette façon de représenter une information structurée en RDF peut induire la génération de nombreuses références URI « intermédiaires » telles que exaddressid:85740 pour représenter des concepts agrégés tels que l'adresse de John. De tels concepts n'auront peut-être jamais besoin d'être cités directement en dehors d'un graphe particulier et ainsi ne nécessiteront peut-être pas d'identificateurs « universels ». De plus, dans le dessin du graphe représentant le groupe de déclarations montré en figure 5, la référence URI affectée à l'identification de l'« adresse de John Smith » n'est pas vraiment nécessaire, puisqu'on aurait tout aussi bien pu dessiner le graphe comme dans la figure 6 :

Figure 6 : Utiliser un nœud anonyme

La figure 6, qui est un graphe RDF parfaitement juste, utilise un nœud sans référence URI pour représenter le concept d'« adresse de John Smith ». Ce nœud anonyme (blank node) joue son rôle dans le dessin sans nécessiter une référence URI, puisque le nœud apporte en soi la connectivité nécessaire entre les diverses autres parties du graphe. (Les nœuds anonymes s'appelaient des ressources anonymes dans [RDF-MS].) Toutefois, ce nœud a besoin d'une forme d'identificateur explicite pour représenter ce graphe par des triplets. Pour s'en persuader, une tentative d'écrire les triplets correspondant à ce qui apparaît dans la figure 6 produirait quelque chose comme ceci :

exstaff:85740   exterms:address         ??? .
???             exterms:street          "1501 Grant Avenue" .
???             exterms:city            "Bedford" .
???             exterms:state           "Massachusetts" .
???             exterms:postalCode      "01730" .

où « ??? » représente quelque chose indiquant la présence du nœud anonyme. Puisqu'un graphe complexe peut contenir plusieurs nœuds anonymes, il faut également un moyen de différencier ces nœuds anonymes dans une représentation en triplets du graphe. Par conséquent, les triplets utilisent des identificateurs de nœud anonyme (blank node identifiers), de la forme _:nom, pour indiquer la présence de nœuds anonymes. Ainsi, dans cet exemple, on pourrait utiliser un identificateur de nœud anonyme _:johnaddress pour désigner le nœud anonyme, auquel cas le graphe final serait :

exstaff:85740   exterms:address         _:johnaddress .
_:johnaddress   exterms:street          "1501 Grant Avenue" .
_:johnaddress   exterms:city            "Bedford" .
_:johnaddress   exterms:state           "Massachusetts" .
_:johnaddress   exterms:postalCode      "01730" .

Dans une représentation de graphe en triplets, chaque nœud anonyme distinct du graphe reçoit un identificateur de nœud anonyme différent. Contrairement aux références URI et aux littéraux, les identificateurs de nœud anonyme ne sont pas considérés comme faisant réellement partie du graphe RDF (on peut le constater en regardant le graphe dessiné à la figure 6 et en notant que le nœud anonyme n'a pas d'identificateur). Les identificateurs de nœud anonyme sont juste un moyen de représenter les nœuds anonymes dans un graphe (et de les distinguer les uns des autres) lorsque le graphe est écrit en forme de triplets. Les identificateurs de nœud anonyme n'ont également de signification que dans les triplets représentant un seul graphe (deux graphes différents avec le même nombre de nœuds anonymes pourraient indépendamment utiliser les mêmes identificateurs de nœud anonyme pour distinguer les triplets, et il serait faux de supposer que des nœuds anonymes de graphes différents avec les mêmes identificateurs de nœud anonyme soient les mêmes). Si l'on prévoit qu'un nœud dans un graphe sera référencé depuis l'extérieur du graphe, on devrait lui affecter une référence URI pour l'identifier. Enfin, parce que les identificateurs de nœud anonyme représentent des nœuds (anonymes), et non des arcs, dans la forme en triplets d'un graphe RDF, ils ne peuvent apparaître que comme sujets ou objets dans les triplets ; les identificateurs de nœud anonyme ne peuvent pas être utilisés comme prédicats dans les triplets.

Le début de cette section notait que les structures agrégées telles que l'adresse de John Smith pouvaient être représentées en considérant la chose agrégée à décrire comme une ressource séparée, puis en faisant des déclarations à propos de cette nouvelle ressource. Cet exemple illustre un aspect important de RDF : RDF ne représente directement que des relations binaires, par exemple la relation entre John Smith et le littéral représentant son adresse. Représenter la relation entre John et le groupe des composantes (components) séparées de cette adresse implique le traitement d'une relation n-aire (n-sens), ici n=5, entre John et les composantes rue, ville, état et code postal. Pour représenter directement de telles structures en RDF (par exemple en considérant l'adresse comme un groupe de composantes de rue, de ville, d'état et de code postal), cette relation à n-sens doit être décomposée en un groupe de relations binaires séparées. Les nœuds anonymes sont un moyen de le faire. Pour chaque relation n-aire, l'un des membres (participants) est choisi comme sujet de la relation (ici John) et un nœud anonyme est créé pour représenter le reste de la relation (ici l'adresse de John). Les membres restants de la relation (telle que la ville dans cet exemple) sont alors représentés comme des propriétés séparées de la nouvelle ressource représentée par le nœud anonyme.

Les nœuds anonymes fournissent aussi le moyen de faire des déclarations plus précises à propos des ressources qui n'ont peut-être pas d'adresse URI mais qui sont décrites en fonction de relations à d'autres ressources lesquelles ont des adresses URI. Ainsi, lorqu'on fait des déclarations à propos d'une personne, disons Jane Smith, il peut sembler naturel d'utiliser son adresse électronique comme adresse URI, par exemple mailto:jane@example.org. Toutefois, cette approche peut poser des problèmes. Il faudra peut-être enregistrer des informations à propos de la boîte aux lettres de Jane (par exemple, le serveur qui l'héberge) et aussi de Jane même (par exemple, son adresse physique courante), et l'utilisation d'une référence URI fondée sur son adresse électronique fait qu'il est difficile de savoir si c'est Jane ou sa boîte aux lettres qui est décrit. Le même problème se pose lorsque l'adresse URL d'une page web d'une entreprise, disons http://www.example.com/, sert d'adresse URI pour l'entreprise même. De nouveau, il faudra peut-être enregistrer des informations à propos de la page web même (par exemple, qui l'a créée et quand) et à propos de l'entreprise, et il est difficile de savoir, en utilisant http://www.example.com/ comme identificateur pour les deux, laquelle est réellement le sujet.

Le problème fondamental est qu'utiliser la boîte aux lettres de Jane comme représentant de Jane n'est pas vraiment précis : Jane et sa boîte aux lettres ne sont pas la même chose, et on devrait de fait les identifier différemment. Si la personne Jane n'a pas d'adresse URI, un nœud anonyme constitue une méthode plus précise de modéliser cette situation. Jane peut être représentée par un nœud anonyme, lequel est utilisé comme sujet d'une déclaration avec exterms:mailbox comme propriété dont la référence URI mailto:jane@example.org est la valeur. On pourrait aussi décrire le nœud anonyme avec une propriété rdf:type de valeur exterms:Person (les types sont étudiés plus en détails dans les sections suivantes), une propriété exterms:name de valeur "Jane Smith", et toute autre information descriptive qui serait utile, comme illustré dans les triplets suivants :

_:jane   exterms:mailbox   <mailto:jane@example.org> .
_:jane   rdf:type          exterms:Person .
_:jane   exterms:name      "Jane Smith" .
_:jane   exterms:empID     "23748"  .
_:jane   exterms:age       "26" .

(Notez que mailto:jane@example.org s'écrit entre des crochets en chevron dans le premier triplet. C'est parce que mailto:jane@example.org est une référence URI à part entière dans le schéma URI mailto, non une réduction avec un nom qualifié, et qu'il faut entourer les références URI par des chevrons en notation de triplets.)

Cela dit précisément qu'« il y a une ressource de type exterms:Person, dont la boîte électronique est identifiée par mailto:jane@example.org, dont le nom est Jane Smith, etc. », c'est-à-dire que le nœud anonyme peut être lu comme « il y a une ressource ». Les déclarations ayant ce nœud anonyme comme sujet fournissent ainsi des informations à propos des caractéristiques de cette ressource.

Dans la pratique, utiliser des nœuds anonymes au lieu de références URI dans ces cas ne change pas beaucoup la façon dont ce type d'information est traité. Par exemple, si on sait qu'une adresse électronique identifie exclusivement (uniquely) quelqu'un chez example.org (en particulier si l'adresse ne sera vraisemblablement pas réutilisée), on peut toujours s'appuyer sur ce fait pour associer des informations de plusieurs ressources à propos de cette personne, même si l'adresse électronique n'est pas l'adresse URI de la personne. Auquel cas, s'il se trouve sur le Web du RDF qui décrit un livre et indique comme coordonnées de l'auteur mailto:jane@example.org, on peut raisonnablement combiner cette nouvelle information à l'ensemble précédent de triplets pour conclure que le nom de l'auteur est Jane Smith. Le fait est qu'énoncer quelque chose comme « l'auteur du livre est mailto:jane@example.org » est typiquement un raccourci pour « l'auteur du livre est quelqu'un dont la boîte aux lettres est mailto:jane@example.org ». L'utilisation d'un nœud anonyme pour représenter ce « quelqu'un » est juste une manière plus précise de représenter la situation du monde réel. (Incidemment, quelques langages de schéma fondés sur RDF permettent d'indiquer que certaines propriétés sont des identificateurs uniques des ressources qu'elles décrivent. Cela est approfondi à la section 5.5.)

ex2terms:book78354   rdf:type          ex2terms:Book .
ex2terms:book78354   ex2terms:author   "Jane Smith" .

ex2terms:book78354   rdf:type          ex2terms:Book .
ex2terms:book78354   ex2terms:author   _:author78354 .
_:author78354        rdf:type          ex2terms:Person .
_:author78354        ex2terms:name     "Jane Smith" .

2.4 Littéraux typés

La section précédente décrivait comment aborder les situations où les valeurs de propriété représentées par des littéraux ordinaires devaient être décomposées en valeurs structurées pour représenter individuellement les composantes de ces littéraux. En suivant cette approche, au lieu disons d'enregistrer la date de création d'une page web comme une seule propriété exterms:creation-date, avec un seul littéral ordinaire pour valeur, on représenterait la valeur par une structure constituée du mois, du jour et de l'année, comme des morceaux d'information séparés, avec des littéraux ordinaires séparés pour représenter les valeurs correspondantes. Néanmoins, jusqu'ici, toutes les valeurs constantes utilisées comme objets dans les déclarations RDF ont été représentées par ces littéraux ordinaires (non typés), même si la destination probable de la valeur de la propriété était un nombre (par exemple, la valeur d'une propriété year ou age) ou quelque autre type de valeur plus spécialisé.

Par exemple, la figure 4 montrait un graphe RDF enregistrant des informations à propos de John Smith. Ce graphe notait la valeur de la propriété exterms:age de John Smith comme étant le littéral ordinaire "27", tel qu'illustré dans la figure 7 :

Figure 7 : Représenter l'âge de John Smith

Ici l'organisation fictive example.org veut probablement que l'on interprète "27" comme étant un nombre plutôt que la chaîne constituée du caractère "2" suivi du caractère "7" (puisque le littéral représente la valeur d'une propriété age). Toutefois, il n'y a aucune information dans le graphe de la figure 7 indiquant explicitement d'interpréter "27" comme un nombre. De même, example.org veut probablement aussi que l'on interprète "27" comme un nombre décimal, c'est-à-dire la valeur vingt-sept, plutôt que disons comme un nombre octal, c'est-à-dire la valeur vingt-trois. Une fois encore, aucune information dans le graphe de la figure 7 ne le dit explicitement. On pourrait écrire des applications spécifiques avec la compréhension que les valeurs de la propriété exterms:age sont à interpréter commes des nombres décimaux, mais cela voudrait dire qu'une interprétation exacte de ce RDF dépend d'une information qui ne serait pas fournie explicitement dans le graphe RDF et donc d'une information qui nécessairement ne serait pas disponible pour d'autres applications ayant à interpréter ce RDF.

La pratique courante dans les langages de programmation ou les systèmes de base de données est de fournir cette information supplémentaire sur la façon d'interpréter un littéral en lui associant un type de données (datatype), ici un type de données comme decimal ou integer. Une application comprenant le type de données sait alors si le littéral "10", par exemple, représente le nombre dix, le nombre deux ou la chaîne composée du caractère "1" suivi du caractère "0", selon que le type de données indiqué est integer, binary ou bien string respectivement. (On pourrait aussi utiliser des types de données plus spécialisés pour inclure l'information d'unité dont il est fait mention en fin de section 2.3, par exemple un type de données integerYears ; cette initiation ne développera toutefois pas cette idée.) En RDF, on utilise des littéraux typés pour fournir ce type d'information.

Un littéral typé RDF est formé en couplant une chaîne à une référence URI qui identifie un type de données particulier. Cela donne un seul nœud littéral dans le graphe RDF avec ce couple comme littéral. La valeur représentée par le littéral typé est celle que le type de données défini associe à la chaîne indiquée. Par exemple, en utilisant un littéral typé, on pourrait décrire l'âge de John Smith comme étant le nombre entier 27 avec ce triplet :

<http://www.example.org/staffid/85740>  <http://www.example.org/terms/age> "27"^^<http://www.w3.org/2001/XMLSchema#integer> .

ou en utilisant la simplification des noms qualifiés pour l'écriture d'adresses URI longues :

exstaff:85740  exterms:age  "27"^^xsd:integer .

ou comme le montre la figure 8 :

Figure 8 : Un littéral typé pour l'âge de John Smith

Pareillement, dans le graphe montré en figure 3 décrivant des informations à propos d'une page web, la valeur de la propriété exterms:creation-date de la page s'écrivait comme le littéral ordinaire "August 16, 1999". Par contre, en utilisant un littéral type, on pourrait décrire explicitement la date de création de la page web comme étant la date August 16, 1999 avec ce triplet-ci :

ex:index.html  exterms:creation-date  "1999-08-16"^^xsd:date .

ou comme le montre la figure 9 :

Figure 9 : Un littéral typé pour la date de création d'une page web

À la différence de langages de programmation et de systèmes de base de données typiques, RDF n'a pas de jeu de types de données natif (built-in), tel que des types de données pour les entiers, les réels, les chaînes ou les dates. À la place, les littéraux typés RDF constituent simplement le moyen d'indiquer explicitement, pour un littéral donné, quel type de données utiliser pour l'interpréter. Les types de données utilisés dans les littéraux typés sont définis hors de RDF et identifiés par leurs références URI de type de données. (Il y a une exception : RDF définit un type de données natif avec la référence URI rdf:XMLLiteral pour représenter du contenu XML comme une valeur littérale. Ce type de données est défini dans [RDF-CONCEPTS], et son utilisation est décrite à la section 4.5.) Ainsi, les exemples des figure 8 et figure 9 utilisent les types de données integer et date du schéma XML défini dans XML Schema tome 2 — Types de données [XML-SCHEMA2]. Un avantage de cette approche est qu'elle donne à RDF la flexibilité pour représenter directement des informations provenant de sources différentes sans devoir effectuer des conversions de types entre ces sources et un jeu natif de types de données RDF. (Des conversions de types seront quand même nécessaires lors de l'échange d'informations entre des systèmes avec des jeux de types de données différents, mais RDF n'imposera pas de conversions supplémentaires vers et depuis un jeu natif de types de données RDF.)

Puisque la valeur signifiée par un littéral typé donné est définie par son type de données et que, hormis rdf:XMLLiteral, RDF ne définit pas de type de données, l'interprétation réelle d'un littéral typé apparaissant dans un graphe RDF (par exemple déterminer la valeur qu'il annonce) doit être effectuée par un logiciel écrit pour traiter correctement non seulement le RDF mais ausi le type de données du littéral typé. En réalité, ce logiciel doit être écrit pour traiter un langage étendu qui inclut non seulement RDF mais aussi le type de données dans le cadre de son vocabulaire intégré (built-in vocabulary). Cela pose le problème de savoir quels types de données seront généralement disponibles dans un logiciel RDF. En général, les types de données XML Schema listés comme utilisables en RDF dans [RDF-SEMANTICS] ont un statut de « privilégié entre égaux » dans RDF. Comme déjà noté, les exemples des figure 8 et figure 9 utilisaient quelques uns de ces types de données XML Schema, et cette initiation les emploier également dans la plupart des autres exemples de littéraux typés (à un titre au moins, les types de données XML Schema ont déjà des références URI que l'on peut utiliser pour s'y rapporter, définis dans [XML-SCHEMA2]). Ces types de données XML Schema ne sont pas traités différemment des autres types de données, mais ils seront vraisemblablement les plus largement utilisés et donc les plus interopérables entre des programmes différents. Par conséquent, la plupart des programmes RDF seront probablement aussi écrits pour traiter ces types de données. Quoi qu'il en soit, un programme RDF peut tout aussi bien traiter d'autres jeux de types de données, à condition que ces types de données soient utilisables avec RDF, comme décrit précédemment.

En général, un programme RDF peut être appelé pour traiter des données RDF contenant des références à des types de données pour lesquels aucun traitement n'est prévu, auquel cas le programme ne pourra pas réaliser certaines tâches. À un titre au moins, hormis rdf:XMLLiteral, RDF ne définit pas en soi les références URI qui identifient les types de données. En conséquence, un programme RDF ne sera pas capable, sauf avoir été conçu pour reconnaître des références URI spécifiques, de déterminer si oui ou non une référence URI écrite dans un littéral typé identifie réellement un type de données. En outre, même si une référence URI identifie un type de données, RDF ne définit pas en soi la validité du couplage (pairing) de ce type de données à un littéral particulier. Cette validité ne peut être déterminée que par un programme écrit pour traiter correctement ce type de données particulier.

Par exemple, le littéral typé dans ce triplet-ci :

exstaff:85740  exterms:age  "pumpkin"^^xsd:integer .

ou le graphe montré en figure 10 :

Figure 10 : Un littéral typé invalide pour l'âge de John Smith

est du RDF valide mais c'est manifestement une erreur en ce qui concerne le type de données xsd:integer, puisque "pumpkin" n'est pas défini dans l'espace lexical de xsd:integer. Un programme RDF non conçu pour traiter le type de données xsd:integer serait incapable de reconnaître cette erreur.

Toujours est-il qu'une bonne utilisation des littéraux typés RDF fournit plus d'information sur l'interprétation voulue des valeurs littérales et améliore de fait les déclarations RDF pour l'échange d'informations entre les applications.

2.5 Récapitulatif des concepts

Pris dans son ensemble, RDF est fondamentalement simple : des diagrammes de nœuds et arcs interprétés comme des déclarations à propos de choses identifiées par des références URI. Cette section introduisait ces concepts. Comme noté précédemment, la spécification RDF normative (c'est-à-dire définitive) décrivant ces concepts est celle des Concepts et syntaxe abstraite RDF [RDF-CONCEPTS], à consulter pour plus d'information. La sémantique formelle (signification) de ces concepts est définie dans le document (normatif) Sémantique RDF [RDF-SEMANTICS].

Quoiqu'il en soit, en plus des techniques de base expliquées jusqu'ici pour décrire les choses avec des déclarations RDF, il devrait être clair que les personnes ou les organisations ont également besoin d'un moyen de décrire les vocabulaires (termes) qu'ils ont l'intention d'utiliser dans ces déclarations, en particulier des vocabulaires pour décrire :

• les types des choses (comme exterms:Person) ;
• les propriétés (comme exterms:age et exterms:creation-date), et ;
• les types des choses qui peuvent servir de sujets ou d'objets des déclarations impliquant ces propriétés (comme indiquer que la valeur d'une propriété exterms:age devrait toujours être du type xsd:integer).

Le fondement de la description de tels vocabulaires en RDF est le Langage de description de vocabulaire RDF 1.0 — RDF Schema [RDF-VOCABULARY], qui sera décrit à la section 5.

On trouvera une documentation supplémentaire sur les idées de base sous-tendant RDF et son rôle de langage général pour décrire une information Web dans [WEBDATA]. RDF s'appuie sur des idées de la représentation des connaissances (knowledge representation), l'intelligence artificielle et la gestion de données (data management), dont les graphes conceptuels, la représentation des connaissances fondée sur la logique, les trames (frames) et les bases de données relationnelles. D'autres sources possibles de documentation sur ces sujets comprennent [SOWA], [CG], [KIF], [HAYES], [LUGER] et [GRAY].

3.1 Principes de base

Les idées de base derrière la syntaxe RDF/XML sont illustrées en utilisant des exemples précédents. Prenons ainsi la phrase en français suivante :

http://www.example.org/index.html a une date de création (creation-date) dont la valeur est August 16, 1999

Le graphe RDF de cette déclaration seule, après affectation d'une référence URI pour la propriété creation-date, est montré en figure 11 :

Figure 11 : Décrire la date de création d'une page web

avec cette représentation en triplets :

ex:index.html   exterms:creation-date   "August 16, 1999" .

(Notez que nous n'utilisons pas de littéral typé pour la valeur de date dans cet exemple. La représentation des littéraux typés en RDF/XML sera décrite ensuite dans cette section.)

L'exemple 2 montre la syntaxe RDF/XML correspondant au graphe en figure 11 :

1. <?xml version="1.0"?>
2. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
3.             xmlns:exterms="http://www.example.org/terms/">

4.   <rdf:Description rdf:about="http://www.example.org/index.html">
5.       <exterms:creation-date>August 16, 1999</exterms:creation-date>
6.   </rdf:Description>

7. </rdf:RDF>

(Les numéros de ligne sont là pour aider l'explication de l'exemple.)

Cela semble surchargé (a lot of overhead). Il est plus facile de comprendre ce qui se passe en examinant, chacune à son tour, les parties de ce code XML (l'annexe B fournit une courte introduction à XML).

La ligne 1, <?xml version="1.0"?>, est la déclaration XML ; elle indique que le contenu à suivre est du XML et dans quelle version.

La ligne 2 débute un élément rdf:RDF ; il annonce que le contenu XML à suivre (commençant ici et se terminant par le </rdf:RDF> à la ligne 7) représente du RDF. À la suite du rdf:RDF sur cette même ligne, il y a une déclaration d'espace de noms XML, représentée par l'attribut xmlns de la balise ouvrante (start-tag) rdf:RDF. Cette déclaration indique que toutes les balises préfixées par rdf: dans ce contenu appartiennent à l'espace de noms identifié par la référence URI http://www.w3.org/1999/02/22-rdf-syntax-ns#. Les termes du vocabulaire RDF utilisent des références URI commençant par la chaîne http://www.w3.org/1999/02/22-rdf-syntax-ns#.

La ligne 3 indique une autre déclaration d'espace de noms XML, cette fois pour le préfixe exterms:. Elle est exprimée par un autre attribut xmlns de l'élément rdf:RDF ; elle indique d'associer la référence URI d'espace de noms http://www.example.org/terms/ au préfixe exterms:. Les références URI commençant par la chaîne http://www.example.org/terms/ sont utilisées pour les termes du vocabulaire défini par l'organisation example.org. Le caractère « > » à la fin de la ligne 3 marque la fin de la balise ouvrante rdf:RDF. Les lignes 1 à 3 regroupent des tâches routinières générales nécessaires pour indiquer qu'il s'agit d'un contenu RDF/XML et pour identifier les espaces de noms utilisés au sein du contenu RDF/XML.

Les lignes 4 à 6 donne le RDF/XML de la déclaration spécifique montrée en figure 11. Une façon claire de parler d'une déclaration RDF est de dire qu'il s'agit d'une description et qu'elle est faite à propos du sujet de la déclaration (ici à propos de http://www.example.org/index.html), et c'est la façon dont RDF/XML représente la déclaration. La balise ouvrante rdf:Description à la ligne 4 indique le début de la description d'une ressource et continue afin d'identifier la ressource à propos de laquelle la déclaration est faite (le sujet de la déclaration) en utilisant l'attribut rdf:about pour indiquer la référence URI de la ressource sujet. La ligne 5 fournit un élément de propriété (property element), dont la balise est le nom qualifié exterms:creation-date, pour représenter le prédicat et l'objet de la déclaration. Le nom qualifié exterms:creation-date est choisi, dans l'ajout du nom local creation-date à la référence URI du préfixe exterms: (http://www.example.org/terms/) pour donner la référence URI du prédicat de la déclaration, à savoir http://www.example.org/terms/creation-date. Le contenu de cet élément de propriété est l'objet de la déclaration, à savoir le littéral ordinaire "August 19, 1999" (la valeur de la propriété creation-date de la ressource sujet). L'élément de propriété est niché dans l'élément conteneur rdf:Description, indiquant que cette propriété s'applique à la ressource désignée dans l'attribut rdf:about de l'élément rdf:Description. La ligne 6 marque la fin de cet élément rdf:Description particulier.

Finalement, la ligne 7 marque la fin de l'élément rdf:RDF commencé à la ligne 2. L'utilisation d'un élément rdf:RDF pour englober du contenu RDF/XML est optionnelle dans les situations où le XML est identifiable comme étant du RDF/XML d'après le contexte. Cette question est approfondie dans [RDF-SYNTAX]. En tout cas, écrire l'élément rdf:RDF ne nuit pas et les exemples de cette initiation le fourniront en général (mais pas systématiquement).

L'exemple 2 illustre les idées de base employées par RDF/XML pour coder un graphe RDF par des éléments, des attributs, un contenu d'élément et des valeurs d'attributs XML. Les références URI des prédicats (ainsi que de quelques nœuds) sont écrits comme des noms qualifiées XML, composés d'un préfixe court annonçant une adresse URI d'espace de noms et d'un nom local annonçant un élément (ou un attribut) qualifié d'un espace de noms (namespace-qualified), comme décrit à l'annexe B. Le couple (référence URI d'espace de nom, nom local) est choisi de telle sorte que leur concaténation forme la référence URI du nœud ou du prédicat d'origine. Les références URI des nœuds sujets s'écrivent comme des valeurs d'attributs XML (les références URI des nœuds objets s'écrivent parfois aussi comme des valeurs d'attributs). Les nœuds littéraux (qui sont toujours des nœuds objets) deviennent du contenu textuel d'élément ou des valeurs d'attributs. (Beaucoup de ces options sont décrites plus loin dans l'initiation ; toutes ces options sont décrites dans [RDF-SYNTAX].)

En RDF/XML, on peut représenter un graphe RDF constitué de plusieurs déclarations par du RDF/XML similaire à celui des lignes 4 à 6 de l'exemple 2 pour séparer chaque déclaration. Ainsi, pour écrire les deux déclarations suivantes :

ex:index.html   exterms:creation-date   "August 16, 1999" .
ex:index.html   dc:language             "en" .

on pourrait utiliser le RDF/XML de l'exemple 3 :

1.  <?xml version="1.0"?>
2.  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
3.              xmlns:dc="http://purl.org/dc/elements/1.1/"
4.              xmlns:exterms="http://www.example.org/terms/">

5.    <rdf:Description rdf:about="http://www.example.org/index.html">
6.        <exterms:creation-date>August 16, 1999</exterms:creation-date>
7.    </rdf:Description>

8.    <rdf:Description rdf:about="http://www.example.org/index.html">
9.        <dc:language>en</dc:language>
10.   </rdf:Description>

11. </rdf:RDF>

L'exemple 3 est pareil à l'exemple 2, mais ajoute un deuxième élément rdf:Description (aux lignes 8 à 10) pour représenter la deuxième déclaration. (La ligne 3 montre aussi une déclaration d'espace de noms supplémentaire pour identifier celui utilisé dans cette deuxième déclaration.) De la même façon, on peut écrire un nombre arbitraire de déclarations supplémentaires en utilisant un élément rdf:Description distinct pour chaque déclaration en plus. Comme illustré dans l'exemple 3, une fois expédiée l'obligation des déclarations XML et d'espaces de noms, l'écriture en RDF/XML de chaque déclaration RDF supplémentaire est la fois directe et assez facile.

La syntaxe RDF/XML offre plusieurs réductions pour faciliter l'écriture des tâches courantes. Ainsi, la même ressource sera typiquement décrite avec plusieurs propriétés et valeurs en même temps, comme dans l'exemple 3, où la ressource ex:index.html est le sujet de plusieurs déclarations. Pour traiter de tels cas, RDF/XML permet de nicher plusieurs éléments de propriété représentant ces propriétés dans l'élément rdf:Description qui identifie la ressource sujet. Par exemple, pour représenter le groupe suivant de déclarations à propos de http://www.example.org/index.html :

ex:index.html   dc:creator              exstaff:85740 .
ex:index.html   exterms:creation-date   "August 16, 1999" .
ex:index.html   dc:language             "en" .

dont le graphe (le même qu'en figure 3) est montré en figure 12 :

Figure 12 : Plusieurs déclarations à propos de la même ressource

on pourrait écrire le RDF/XML de l'exemple 4 :

1.  <?xml version="1.0"?>
2.  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
3.              xmlns:dc="http://purl.org/dc/elements/1.1/"
4.              xmlns:exterms="http://www.example.org/terms/">

5.    <rdf:Description rdf:about="http://www.example.org/index.html">
6.         <exterms:creation-date>August 16, 1999</exterms:creation-date>
7.         <dc:language>en</dc:language>
8.         <dc:creator rdf:resource="http://www.example.org/staffid/85740"/>
9.    </rdf:Description>

10. </rdf:RDF>

Comparé aux deux exemples précédents, l'exemple 4 présente un élément de propriété dc:creator supplémentaire (à la ligne 8). En outre, les éléments de propriété des trois propriétés dont le sujet est http://www.example.org/index.html sont nichés au sein d'un seul élément rdf:Description identifiant ce sujet plutôt que d'écrire un élément rdf:Description pour chaque déclaration.

La ligne 8 introduit également une nouvelle forme d'élément de propriété. L'élément dc:language à la ligne 7 est similaire à l'élément exterms:creation-date utilisé dans l'exemple 2. Ces deux éléments représentent des propriétés dont les valeurs sont des littéraux ordinaires, et ces éléments s'écrivent en englobant le littéral dans les balises ouvrante et fermantes correspondant au nom de la propriété. Au contraire, l'élément dc:creator de la ligne 8 représente une propriété dont la valeur est une autre ressource, au lieu d'un littéral. Si la référence URI de cette ressource s'écrivait comme un littéral ordinaire entre des balises ouvrante et fermante à la façon des valeurs littérales des autres éléments, cela voudrait dire que la valeur de l'élément dc:creator est la chaîne de caractères "http://www.example.org/staffid/85740", au lieu de la ressource identifiée par ce littéral interprété comme référence URI. Pour indiquer la différence, l'élément dc:creator est écrit en utilisant ce que XML appelle une balise d'élément vide (empty-element tag), sans balise fermante séparée, et la valeur de propriété est écrite en utilisant un attribut rdf:resource au sein de cet élément vide. L'attribut rdf:resource indique que la valeur de l'élément de propriété est une autre ressource, identifiée par sa référence URI. Comme la référence URI est utilisée comme une valeur d'attribut, RDF/XML impose l'expansion de la référence URI (en tant que référence URI absolue ou relative), plutôt que sa réduction en un nom qualifié comme cela se faisait en écrivant les noms des éléments et des attributs (les références URI absolues et relatives sont traitées à l'annexe A).

Il importe de comprendre que la syntaxe RDF/XML dans l'exemple 4 est une réduction. La syntaxe RDF/XML de l'exemple 5, où chaque déclaration est écrite séparément, décrit exactement le même graphe RDF (le graphe de la figure 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:exterms="http://www.example.org/terms/">

   <rdf:Description rdf:about="http://www.example.org/index.html">
       <exterms:creation-date>August 16, 1999</exterms:creation-date>
   </rdf:Description>

   <rdf:Description rdf:about="http://www.example.org/index.html">
       <dc:language>en</dc:language>
   </rdf:Description>

   <rdf:Description rdf:about="http://www.example.org/index.html">
       <dc:creator rdf:resource="http://www.example.org/staffid/85740"/>
   </rdf:Description>

 </rdf:RDF>

Les sections suivantes décriront quelques réductions RDF/XML de plus. Le document [RDF-SYNTAX] fournit une description approfondie des réductions possibles.

RDF/XML peut également représenter des graphes qui incluent des nœuds sans référence URI, c'est-à-dire les nœuds anonymes décrits à la section 2.3. Ainsi, la figure 13 (extraite de [RDF-SYNTAX]) montre un graphe disant « le document "http://www.w3.org/TR/rdf-syntax-grammar" a un titre "RDF/XML Syntax Specification (Revised)" et a un rédacteur dont le nom est "Dave Beckett" et la page personnelle est "http://purl.org/net/dajobe/" ».

Figure 13 : Un graphe contenant un nœud anonyme

Elle illustre une idée abordée à la section 2.3 : l'utilisation d'un nœud anonyme pour représenter quelque chose qui n'a pas de référence URI mais que l'on peut décrire en fonction d'autres informations. Ici le nœud anonyme représente une personne, le rédacteur du document, qui est décrite par son nom et sa page personnelle.

RDF/XML offre plusieurs façons de représenter des graphes contenant des nœuds anonymes. Toutes sont décrites dans [RDF-SYNTAX]. L'approche illustrée ici, la plus directe, est d'affecter un identificateur de nœud anonyme à chaque nœud anonyme. L'identificateur de nœud anonyme qui sert à identifier un nœud anonyme au sein d'un document RDF/XML n'est pas connu hors du document dans lequel il est défini, à la différence d'une référence URI. En RDF/XML, un nœud anonyme est signalé par un attribut rdf:nodeID, dont la valeur est un identificateur de nœud anonyme, là où sinon apparaîtrait la référence URI d'une ressource. Spécifiquement, en RDF/XML, on peut écrire une déclaration ayant un nœud anonyme pour sujet en utilisant un élément rdf:Description avec un attribut rdf:nodeID au lieu d'un attribut rdf:about. Pareillement, on peut écrire une déclaration ayant un nœud anonyme pour objet en utilisant un élément de propriété avec un attribut rdf:nodeID au lieu d'un attribut rdf:resource. L'exemple 6 montre le RDF/XML correspondant à la figure 13 en utilisant l'attribut rdf:nodeID :

1.  <?xml version="1.0"?>
2.  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
3.              xmlns:dc="http://purl.org/dc/elements/1.1/"
4.              xmlns:exterms="http://example.org/stuff/1.0/">

5.     <rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
6.       <dc:title>RDF/XML Syntax Specification (Revised)</dc:title>
7.       <exterms:editor rdf:nodeID="abc"/>
8.     </rdf:Description>

9.     <rdf:Description rdf:nodeID="abc">
10.        <exterms:fullName>Dave Beckett</exterms:fullName>
11.        <exterms:homePage rdf:resource="http://purl.org/net/dajobe/"/>
12.    </rdf:Description>

13. </rdf:RDF>

Dans l'exemple 6, on utilise l'identificateur de nœud anonyme abc à la ligne 9 pour identifier le nœud anonyme comme sujet de plusieurs déclarations, et à la ligne 7 pour indiquer que le nœud anonyme est la valeur de la propriété exterms:editor d'une ressource. L'avantage d'utiliser un identificateur de nœud anonyme sur d'autres approches décrites dans [RDF-SYNTAX] est qu'il permet d'appeler le même nœud anonyme depuis plusieurs endroits du document RDF/XML.

Enfin, les littéraux typés décrits à la section 2.4 peuvent être utilisés comme valeurs de propriétés à la place des littéraux ordinaires employés jusqu'ici dans les exemples. En RDF/XML, on représente un littéral typé en ajoutant un attribut rdf:datatype, qui indique une référence URI de type de données, à l'élément de propriété contenant le littéral.

Par exemple, pour changer la déclaration dans l'exemple 2 afin qu'elle utilise un littéral typé au lieu d'un littéral ordinaire pour la propriété exterms:creation-date, la représentation en triplets serait :

ex:index.html   exterms:creation-date   "1999-08-16"^^xsd:date .

avec la syntaxe RDF/XML correspondante montrée dans l'exemple 7 :

1. <?xml version="1.0"?>
2. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
3.             xmlns:exterms="http://www.example.org/terms/">

4.   <rdf:Description rdf:about="http://www.example.org/index.html">
5.     <exterms:creation-date rdf:datatype=
         "http://www.w3.org/2001/XMLSchema#date">1999-08-16
       </exterms:creation-date>
6.   </rdf:Description>

7. </rdf:RDF>

À la ligne 5 de l'exemple 7, on donne un littéral typé comme valeur de l'élément de propriété exterms:creation-date en ajoutant un attribut rdf:datatype à la balise ouvrante de l'élément pour définir le type de données. La valeur de cet attribut est la référence URI du type de données, ici celle du type de données XML Schema date. Puisque c'est une valeur d'attribut, la référence URI doit s'écrire en entier au lieu d'employer la réduction de nom qualifié xsd:date utilisée dans le triplet. On écrit alors un littéral approprié pour ce type de données en contenu de l'élément, ici le littéral "1999-08-16", qui est la représentation littérale de « August 16, 1999 » dans le type de données XML Schema date.

<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]> 

1. <?xml version="1.0"?>
2. <!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>

3. <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
4.             xmlns:exterms="http://www.example.org/terms/">

5.   <rdf:Description rdf:about="http://www.example.org/index.html">
6.     <exterms:creation-date rdf:datatype="&xsd;date">1999-08-16
       </exterms:creation-date>
7.   </rdf:Description>

8. </rdf:RDF>