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>

Bien qu'il existe d'autres formes réduites pour écrire du RDF/XML, les facilités illustrées jusqu'ici fournissent une méthode simple mais générale pour exprimer des graphes en RDF/XML. Avec ces facilités, un graphe RDF s'écrit en RDF/XML comme ceci :

• Tous les nœuds anonymes reçoivent des identificateurs de nœud anonyme ;
• Chaque nœud est listé, à son tour, comme le sujet d'un élément rdf:Description non niché, en utilisant un attribut rdf:about si le nœud a une référence URI ou un attribut rdf:nodeID si le nœud est anonyme.
  Pour chaque triplet ayant ce nœud pour sujet, un élément de propriété approprié est créé avec l'un ou l'autre contenu littéral (éventuellement vide), un attribut rdf:resource indiquant l'objet du triplet (si le nœud objet a une référence URI) ou un attribut rdf:nodeID indiquant l'objet du triplet (si le nœud objet est anonyme).

Comparée aux approches plus réduites décrites dans [RDF-SYNTAX], cette approche simple offre la représentation la plus directe de la structure réelle du graphe, et elle est particulièrement recommandée pour les applications dont la sortie RDF/XML doit être utilisée pour un autre traitement RDF.

3.2 Abréger et organiser les références URI RDF

Jusqu'à présent, dans les exemples, on supposait que les ressources décrites avaient déjà reçu des références URI. Ainsi, les premiers exemples fournissaient des informations descriptives à propos de la page web d'example.org, dont la référence URI était http://www.example.org/index.html. En RDF/XML, cette ressource était identifiée en utilisant un attribut rdf:about citant sa référence URI en entier. Bien que RDF ne définisse pas ni ne contrôle comment les références URI sont affectées aux ressources, il est parfois souhaitable de pouvoir affecter les références URI à des ressources appartenant à un groupe organisé de ressources. Par exemple, supposons qu'un fabricant de matériel sportif, example.com, veuille fournir un catalogue de ses produits fondé sur RDF, tels que des tentes, des chaussures de randonnée, et ainsi de suite, sous forme d'un document RDF/XML, identifié par (et trouvé à) http://www.example.com/2002/04/products. Dans cette ressource, chaque produit a une description RDF séparée. Ce catalogue avec l'une de ces descriptions, l'entrée de catalogue d'un modèle de tente dit « Overnighter », pourrait s'écrire en RDF/XML comme montré dans l'exemple 9 :

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.com/terms/">

5.     <rdf:Description rdf:ID="item10245">
6.          <exterms:model rdf:datatype="&xsd;string">Overnighter</exterms:model>
7.          <exterms:sleeps rdf:datatype="&xsd;integer">2</exterms:sleeps>
8.          <exterms:weight rdf:datatype="&xsd;decimal">2.4</exterms:weight>
9.          <exterms:packedSize rdf:datatype="&xsd;integer">784</exterms:packedSize>
10.    </rdf:Description>

  ...autres descriptions de produits...

11.  </rdf:RDF>

L'exemple 9 est similaire aux exemples précédents en ce sens qu'il représente les propriétés (le modèle, la capacité de couchage, le poids) de la ressource (la tente) qui est décrite. (Les informations xml, DOCTYPE, RDF et d'espace de noms environnantes sont comprises dans les lignes 1 à 4, et dans la ligne 11, mais il ne faudra les fournir qu'une seule fois pour tout le catalogue, et ne pas les répéter pour chaque entrée du catalogue. Bien que les types de données associés aux diverses valeurs de propriété soient donnés explicitement, notez que les unités associées à certaines de ces valeurs de propriété ne le sont pas, même s'il faudrait que cette information soit disponible pour interpréter correctement les valeurs. La représentation des unités et des informations similaires pouvant être associées aux valeurs de propriété est traitée à la section 4.4. Dans cet exemple, la valeur de exterms:sleeps est le nombre de couchages dans la tente, la valeur de exterms:weight est donnée en kilogrammes et la valeur de exterms:packedSize est donnée en centimètres carrés, la surface occupée par la tente sur un sac à dos.)

Une différence importante par rapport aux exemples précédents est que, à la ligne 5, l'élément rdf:Description a un attribut rdf:ID au lieu d'un attribut rdf:about. L'utilisation de rdf:ID définit un identificateur de fragment (fragment identifier), donné par la valeur de l'attribut rdf:ID (ici item10245, vraisemblablement le numéro de catalogue affecté par example.com), comme une réduction de la référence URI complète de la ressource décrite. L'identificateur de fragment item10245 s'interprètera relativement à une adresse URI de base (base URI), ici l'adresse URI du document catalogue conteneur. La référence URI complète de la tente est formée avec l'adresse URI de base (du catalogue) à la fin de laquelle on ajoute le caractère dièse « # » (qui annonce un identificateur de fragment à suivre) puis item10245, pour donner la référence URI absolue http://www.example.com/2002/04/products#item10245.

L'attribut rdf:ID ressemble quelque peu à l'attribut ID de XML et HTML, en cela qu'il définit un nom unique par rapport à l'adresse URI de base courante (dans cet exemple, celle du catalogue). Ici l'attribut rdf:ID affecte un nom (item10245) à ce modèle particulier de tente. N'importe quel autre élément RDF/XML dans ce catalogue pourrait désigner la tente en utilisant soit la référence URI absolue http://www.example.com/2002/04/products#item10245, soit la référence URI relative #item10245. Cette dernière serait comprise comme étant une référence URI définie par rapport à l'adresse URI du catalogue. En utilisant une réduction similaire, on aurait également pu donner la référence URI de la tente en indiquant rdf:about="#item10245" dans l'entrée de catalogue (c'est-à-dire indiquer directement la référence URI relative) à la place de rdf:ID="item10245". Comme mécanisme de réduction, les deux formes sont essentiellement synonymes : la référence URI complète formée par RDF/XML est la même dans les deux cas, et c'est http://www.example.com/2002/04/products#item10245. Par contre, utiliser rdf:ID fournit une vérification supplémentaire lors de l'affectation d'un ensemble de noms distincts, puisqu'une valeur donnée de l'attribut rdf:ID ne peut apparaître qu'une seule fois vis-à-vis de la même adresse URI de base (le document catalogue dans cet exemple). En employant l'une ou l'autre forme, example.com donne la référence URI de la tente dans un processus à deux étapes ; d'abord affecter la référence URI du catalogue entier puis utiliser une référence URI relative dans la description de la tente dans le catalogue pour indiquer la référence URI affectée à ce modèle particulier de tente. De plus, on peut considérer l'utilisation d'une référence URI relative comme étant la réduction d'une référence URI affectée à la tente indépendamment du RDF, ou comme étant l'affectation de la référence URI de la tente au sein du catalogue.

Du RDF localisé hors du catalogue pourrait citer cette tente en utilisant la référence URI complète, c'est-à-dire en accolant la référence URI relative de la tente #item10245 à l'adresse URI de base du catalogue, pour former la référence URI absolue http://www.example.com/2002/04/products#item10245. Par exemple, un site web de sports de plein air exampleRatings.com pourrait utiliser du RDF pour fournir un classement de diverses tentes. Une note (de cinq étoiles) donnée à la tente décrite dans l'exemple 9 serait alors représentée sur le site web de exampleRatings.com comme montré dans l'exemple 10 :

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:sportex="http://www.exampleRatings.com/terms/">

5.    <rdf:Description rdf:about="http://www.example.com/2002/04/products#item10245">
6.         <sportex:ratingBy rdf:datatype="&xsd;string">Richard Roe</sportex:ratingBy>
7.         <sportex:numberStars rdf:datatype="&xsd;integer">5</sportex:numberStars>
8.    </rdf:Description>
9.  </rdf:RDF>

Dans l'exemple 10, la ligne 5 montre un élément rdf:Description avec un attribut rdf:about dont la valeur est la référence URI complète de la tente. L'utilisation de cette référence URI permet d'identifier précisément la tente citée dans le classement.

Ces exemples illustrent plusieurs points. D'abord, même si RDF ne définit pas ni ne contrôle comment les références URI sont affectées aux ressources (ici les diverses tentes et les autres articles du catalogue), l'effet d'affecter des références URI aux ressources dans RDF est obtenu en combinant un processus (externe à RDF), qui identifie un seul document (ici le catalogue) comme source des descriptions de ces ressources, à l'utilisation de références URI relatives dans les descriptions de ces ressources au sein de ce document. Ainsi, example.com pourrait utiliser ce catalogue comme la source centrale où ses produits sont décrits, sous-entendu que si une référence d'article n'est pas une entrée de ce catalogue, c'est que le produit est inconnu chez example.com. (Notez que RDF ne présume de l'existence d'aucune relation particulière entre deux ressources juste parce que leurs références URI ont la même base ou sont similaires par ailleurs. Cette relation peut être connue chez example.com, mais elle n'est pas définie directement par RDF.)

Ces exemples illustrent également un principe architectural fondamental du Web selon lequel « quiconque devrait pouvoir ajouter librement de l'information à propos d'une ressource existante, en utilisant le vocabulaire de son choix » [BERNERS-LEE98]. Ils montrent encore que le RDF décrivant une ressource particulière n'a pas besoin de se trouver tout entier à un seul endroit ; plutôt qu'il peut être éparpillé à travers le Web. C'est non seulement vrai pour les situations telles que celle-ci, où une seule organisation classe ou commente une ressource définie par une autre, mais aussi pour les situations où le définissant original (original definer) d'une ressource (ou n'importe qui d'autre) souhaite augmenter la description de cette ressource en fournissant d'autres informations à son sujet. Cela peut se faire en modifiant le document RDF dans lequel la ressource a été décrite au départ, pour y ajouter les propriétés et valeurs nécessaires qui décrivent l'information supplémentaire. Ou alors, comme le montre cet exemple, en créant un document séparé pour fournir les propriétés et valeurs supplémentaires dans des éléments rdf:Description qui se rapportent à la ressource originale par sa référence URI en utilisant l'attribut rdf:about.

Le paragraphe précédent expliquait que les références URI relatives telles que #item10245 sont interprétées par rapport à une adresse URI de base. Par défaut, cette adresse URI de base est celle de la ressource où la référence URI relative est utilisée. Ainsi, supposons qu'example.org, en plus du catalogue trouvé à http://www.example.com/2002/04/products, veuille en fournir une copie sur un site miroir à http://mirror.example.com/2002/04/products. Cela pourrait créer un problème, puisque si on accédait au catalogue depuis le site miroir, la référence URI de la tente en exemple serait générée d'après l'adresse URI du document conteneur, formant http://mirror.example.com/2002/04/products#item10245 au lieu de http://www.example.com/2002/04/products#item10245, et désignerait de fait une ressource différente de celle attendue. Ou supposons qu'example.org veuille affecter une référence URI de base à son ensemble de références URI de produit sans publier un seul document source dont l'emplacement définit la base.

Pour traiter ces cas, RDF/XML utilise XML Base [XML-BASE], qui permet à un document XML de définir une adresse URI de base différente de l'adresse URI du document en question. L'exemple 11 montre comment décrire le catalogue à l'aide de XML Base :

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.com/terms/"
5.               xml:base="http://www.example.com/2002/04/products">

6.     <rdf:Description rdf:ID="item10245">
7.          <exterms:model rdf:datatype="&xsd;string">Overnighter</exterms:model>
8.          <exterms:sleeps rdf:datatype="&xsd;integer">2</exterms:sleeps>
9.          <exterms:weight rdf:datatype="&xsd;decimal">2.4</exterms:weight>
10.         <exterms:packedSize rdf:datatype="&xsd;integer">784</exterms:packedSize>
11.    </rdf:Description>

  ...autres descriptions de produits...

12.  </rdf:RDF>

Dans l'exemple 11, la déclaration xml:base à la ligne 5 indique que l'adresse URI de base pour le contenu de l'élément rdf:RDF (jusqu'à l'apparition d'un autre attribut xml:base) est http://www.example.com/2002/04/products, et toutes les références URI relatives citées dans ce contenu seront interprétées par rapport à cette base, quelle que soit l'adresse URI du document conteneur. Par conséquent, la référence URI relative de la tente, #item10245, sera interprétée comme étant la même référence URI absolue, http://www.example.com/2002/04/products#item10245, peu importe l'adresse URI réelle du document catalogue ou que la référence URI de base n'identifie en réalité pas de document particulier du tout.

Jusqu'ici, les exemples faisaient appel à une seule description de produit du catalogue d'example.com, à savoir un modèle particulier de tente. Toujours est-il qu'example.com proposera sans doute plusieurs modèles de tentes, ainsi que plusieurs instances d'autres catégories de produits, telles que des sacs à dos, des chaussures de randonnée, et ainsi de suite. Cette idée de classer les choses en types ou en catégories différents est similaire au concept de langage de programmation d'objets avec des types ou des classes différents. RDF applique ce concept en fournissant une propriété prédéfinie : rdf:type. Lorsqu'une ressource RDF est décrite avec une propriété rdf:type, la valeur de cette propriété est considérée comme étant une ressource représentant une catégorie ou classe de choses, et le sujet de cette propriété est considéré comme étant une instance de cette catégorie ou classe. En utilisant rdf:type, l'exemple 12 montre comment example.com pourrait indiquer que la description de produit est celle d'une tente :

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.com/terms/"
5.               xml:base="http://www.example.com/2002/04/products">

6.     <rdf:Description rdf:ID="item10245">
7.          <rdf:type rdf:resource="http://www.example.com/terms/Tent"/>
8.          <exterms:model rdf:datatype="&xsd;string">Overnighter</exterms:model>
9.          <exterms:sleeps rdf:datatype="&xsd;integer">2</exterms:sleeps>
10.         <exterms:weight rdf:datatype="&xsd;decimal">2.4</exterms:weight>
11.         <exterms:packedSize rdf:datatype="&xsd;integer">784</exterms:packedSize>
12.    </rdf:Description>

  ...autres descriptions de produits...

13.  </rdf:RDF>

Dans l'exemple 12, la propriété rdf:type à la ligne 7 indique que la ressource décrite est une instance de la classe identifiée par la référence URI http://www.example.com/terms/Tent. Cela suppose qu'example.com a défini ses classes dans le cadre du même vocabulaire utilisé pour décrire ses autres termes (tels que la propriété exterms:weight), afin d'utiliser la référence URI absolue de la classe pour la désigner. Si example.com avait décrit ces classes dans le cadre du catalogue de produits même, on aurait pu utiliser la référence URI relative #Tent pour la désigner.

En soi, RDF n'offre pas de facilités pour définir des classes de choses spécifiques d'une application, telles que Tent dans cet exemple, ou leur propriétés, telles que exterms:weight. De telles classes seraient plutôt décrites dans un schéma RDF, à l'aide du langage RDF Schema abordé à la section 5. On peut aussi définir d'autres facilités de ce type pour décrire des classes, tells que les langages DAML+OIL et OWL décrits à la section 5.5.

En RDF, les ressources ont très couramment des propriétés rdf:type qui décrivent les ressources comme étant des instances de types ou classes spécifiques. De telles ressources sont dites des nœuds typés (typed nodes) dans le graphe, ou des éléments de nœud typé (typed node elements) dans le RDF/XML. RDF/XML fournit une réduction spéciale pour décrire ces nœuds typés. Dans cette réduction, la propriété rdf:type et sa valeur sont supprimées, et l'élément rdf:Description du nœud est remplacé par un élément dont le nom est le nom qualifié corrspondant à la valeur de la propriété rdf:type supprimée (une référence URI qui nomme une classe). En utilisant cette réduction, la tente de chez example.com dans l'exemple 12 pourrait également être décrite comme dans l'exemple 13 :

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.com/terms/"
5.               xml:base="http://www.example.com/2002/04/products">

6.     <exterms:Tent rdf:ID="item10245">
7.          <exterms:model rdf:datatype="&xsd;string">Overnighter</exterms:model>
8.          <exterms:sleeps rdf:datatype="&xsd;integer">2</exterms:sleeps>
9.          <exterms:weight rdf:datatype="&xsd;decimal">2.4</exterms:weight>
10.         <exterms:packedSize rdf:datatype="&xsd;integer">784</exterms:packedSize>
11.    </exterms:Tent>

  ...autres descriptions de produits...

12.  </rdf:RDF>

L'exemple 12 et l'exemple 13 illustrent tous deux le fait que les déclarations RDF peuvent s'écrire en RDF/XML d'une façon qui ressemble étroitement à des descriptions qui auraient pu être écrites directement en XML (non-RDF). C'est un aspect important vu l'utilisation croissante de XML dans toutes sortes d'applications, puisque cela suggère que l'on pourrait utiliser RDF dans ces applications sans nécessiter de changements majeurs sur la façon dont les informations y sont structurées.

3.3 Récapitulatif de RDF/XML

Les exemples ci-dessus illustrent quelques idées fondamentales derrière la syntaxe RDF/XML. Ces exemples fournissent suffisamment d'éclairage pour commencer à écrire du RDF/XML utile. Une explication plus approfondie des principes sous-jacents de la modélisation des déclarations RDF en XML, connu sous le nom d'entrelacement (striping)), avec une présentation des autres réductions RDF/XML disponibles et d'autres détails et exemples à propos de l'écriture de RDF en XML, est donnée dans la Spécification de la syntaxe RDF/XML (normative) [RDF-SYNTAX].

4.1 Conteneurs RDF

On a souvent besoin de décrire des groupes de choses, par exemple pour dire qu'un livre a plusieurs auteurs, ou pour lister les étudiants d'un cours ou les modules logiciels dans un paquetage (package). RDF fournit plusieurs types et propriétés prédéfinis (natifs) qui peuvent servir à décrire de tels groupes.

Au premier chef, RDF fournit un vocabulaire de conteneur (container vocabulary) consistant en trois types prédéfinis (associés à quelques propriétés prédéfinies). Un conteneur (container) est une ressource qui contient des choses. Les choses contenues s'appellent des membres (members). Les membres d'un conteneur peuvent être des ressources (y compris des nœuds anonymes) ou des littéraux. RDF définit trois types de conteneurs :

• rdf:Bag
• rdf:Seq
• rdf:Alt

Un sac (bag), ou Bag, une ressource ayant le type rdf:Bag, représente un groupe de ressources ou de littéraux, comprenant éventuellement des membres en double, où l'ordre des membres n'a aucune importance. Par exemple, on utiliserait un sac pour décrire un groupe de numéros de pièces de rechanges dans lequel l'ordre d'entrée ou de traitement des numéros n'importe pas.

Une séquence (sequence), ou Seq, une ressource ayant le type rdf:Seq, représente un groupe de ressources ou de littéraux, comprenant éventuellement des membres en double, où l'ordre des membres est significatif. Par exemple, on utiliserait une séquence pour décrire un groupe qui doit rester en ordre alphabétique.

Un choix (alternative), ou Alt, une ressource ayant le type rdf:Alt, représente un groupe de ressources ou de littéraux qui sont des options (alternatives), typiquement pour une seule valeur d'une propriété. Par exemple, on utiliserait un choix pour décrire une liste de traductions en plusieurs langues du titre d'un livre, ou pour décrire une liste de sites Internet de remplacement où trouver une ressource. Une application utilisant une propriété dont la valeur est un conteneur Alt devrait savoir qu'elle peut choisir n'importe quel membre du groupe au besoin.

Pour décrire une ressource comme étant de l'un de ces types de conteneurs, on lui donne une propriété rdf:type dont la valeur est l'une des ressources prédéfinies rdf:Bag, rdf:Seq ou rdf:Alt (selon le besoin). La ressource conteneur (qui peut être soit un nœud anonyme, soit une ressource avec une référence URI) annonce le groupe comme un tout. Les membres du conteneur peuvent être décrits en définissant une propriété d'appartenance à un conteneur (container membership property) pour chaque membre, avec la ressource conteneur pour sujet et le membre pour objet. Ces propriétés d'appartenance à un conteneur qui ont des noms de la forme rdf:_n, où n est un entier décimal supérieur à zéro, sans zéro en chef, par exemple rdf:_1, rdf:_2, rdf:_3, et ainsi de suite, sont utilisées spécifiquement pour décrire les membres des conteneurs. Les ressources conteneurs peuvent aussi avoir d'autres propriétés qui décrivent le conteneur, en plus des propriétés d'appartenance à un conteneur et rdf:type.

Bien que ces types de conteneurs soient décrits à l'aide de types et propriétés RDF prédéfinis, il importe de comprendre que les significations spéciales associées à ces conteneurs, par exemple que les membres d'un conteneur Alt sont des options, ne sont que des significations intentionnelles (intended). Ces types de conteneur spécifiques et leurs définitions sont fournis dans le but d'établir une convention partagée entre ceux qui ont besoin de décrire des groupes de choses. RDF ne fait que fournir les types et propriétés utilisables pour construire les graphes RDF qui décrivent chaque type de conteneur. RDF n'a pas plus de compréhension intrinsèque de ce qu'est une ressource de type rdf:Bag qu'il n'a d'une ressource de type ex:Tent (cf. la section 3.2). Dans chaque cas, les applications doivent être écrites pour se comporter conformément à la signification particulière impliquée par chaque type. Ce point sera développé dans les exemples à suivre.

Un conteneur sert typiquement à indiquer que la valeur d'une propriété est un groupe de choses. Ainsi, pour représenter l'énoncé «Les étudiants du cours 6.001 comprennent Amy, Mohamed, Johann, Maria et Phuong », on décrirait le cours en lui donnant une propriété s:students (d'après un vocabulaire approprié) dont la valeur est un conteneur de type rdf:Bag (représentant le groupe d'étudiants). Puis, en utilisant les propriétés d'appartenance au conteneur, on identifierait individuellement les étudiants comme membres de ce groupe, comme dans le graphe RDF montré en figure 14 :

Figure 14 : Une description de conteneur Bag simple

Puisque la valeur de la propriété s:students dans cet exemple est décrite comme étant un sac, l'ordre donné aux références URI des étudiants ne revêt aucune signification, même si les noms des propriétés d'appartenance dans le graphe contiennent des entiers. Les applications qui créent et traitent des graphes avec des conteneurs rdf:Bag doivent ignorer tout ordre (apparent) dans les noms des propriétés d'appartenance.

RDF/XML fournit une syntaxe et des réductions spéciales pour faciliter la description de tels conteneurs. Ainsi, l'exemple 14 décrit le graphe montré en figure 14 :

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:s="http://example.org/students/vocab#">

   <rdf:Description rdf:about="http://example.org/courses/6.001">
      <s:students>
         <rdf:Bag>
            <rdf:li rdf:resource="http://example.org/students/Amy"/>
            <rdf:li rdf:resource="http://example.org/students/Mohamed"/>
            <rdf:li rdf:resource="http://example.org/students/Johann"/>
            <rdf:li rdf:resource="http://example.org/students/Maria"/>
            <rdf:li rdf:resource="http://example.org/students/Phuong"/>
         </rdf:Bag>
      </s:students>
   </rdf:Description>
</rdf:RDF>

L'exemple 14 montre que RDF/XML offre l'élément rdf:li comme élément de confort (convenience element) afin d'éviter la numérotation explicite de chaque propriété d'appartenance. Les propriétés numérotées rdf:_1, rdf:_2, et ainsi de suite, sont générées à partir des éléments rdf:li en formant le graphe correspondant. Le nom de l'élément rdf:li a été choisi en mnémotechnique avec le terme « list item » (N.d.T. élément de liste) de HTML. Notez également l'utilisation de l'élément <rdf:Bag> niché au sein de l'élément de propriété <s:students>. L'élément <rdf:Bag> constitue un autre exemple du type de réduction utilisé dans l'exemple 13, qui remplace un élément rdf:Description et un élément rdf:type par un seul élément lors de la description d'une instance d'un type (ici une instance de rdf:Bag). Puisqu'aucune référence URI n'est définie, le sac est un nœud anonyme. Sa présence nichée au sein de l'élément de propriété <s:students> est une manière réduite d'indiquer que le nœud anonyme est la valeur de cette propriété. Ces réductions sont décrites en détails dans [RDF-SYNTAX].

La structure de graphe d'un conteneur rdf:Seq et le RDF/XML correspondant sont similaires à ceux d'un conteneur rdf:Bag (la seule différence se trouvant dans le type rdf:Seq). À nouveau, bien qu'un conteneur rdf:Seq soit prévu pour décrire une séquence, les applications qui créent et traitent les graphes doivent interpréter correctemment la séquence des noms de propriétés numérotées (integer-valued property).

Afin d'illustrer le conteneur Alt, on pourrait exprimer la proposition « On peut trouver le code source de X11 à ftp.example.org, ftp1.example.org ou ftp2.example.org » dans le graphe RDF montré en figure 15 :

Figure 15 : Une description de conteneur Alt simple

L'exemple 15 montre comment on pourrait écrire le graphe de la figure 15 en RDF/XML :

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:s="http://example.org/packages/vocab#">

   <rdf:Description rdf:about="http://example.org/packages/X11">
      <s:DistributionSite>
         <rdf:Alt>
            <rdf:li rdf:resource="ftp://ftp.example.org"/>
            <rdf:li rdf:resource="ftp://ftp1.example.org"/>
            <rdf:li rdf:resource="ftp://ftp2.example.org"/>
         </rdf:Alt>
      </s:DistributionSite>
   </rdf:Description>
</rdf:RDF>

Un conteneur Alt est destiné à recueillir au moins un membre, identifié par la propriété rdf:_1. Ce membre est censé être la valeur par défaut ou préférée. Hormis le membre identifié comme étant rdf:_1, l'ordre des autres membres n'a pas d'importance.

Le code RDF dans la figure 15 tel qu'il est écrit déclare simplement que la valeur de la propriété de site s:DistributionSite est la ressource du conteneur Alt même. Toute signification supplémentaire déterminée à la lecture de ce graphe, par exemple que l'un des membres du conteneur Alt doive être considéré comme la valeur de la propriété de site s:DistributionSite ou que ftp://ftp.example.org est la valeur par défaut ou préférée, doit être intégrée dans la compréhension de la signification attendue du conteneur Alt d'une application ou dans la signification définie de la propriété particulière (ici s:DistributionSite), laquelle doit également être comprise par l'application.

Les conteneurs Alt sont fréquemment employés en conjonction avec l'étiquetage des langues. (RDF/XML autorise l'emploi de l'attribut xml:lang défini dans [XML] pour indiquer que le contenu de l'élément est dans une langue donnée. L'utilisation de xml:lang est décrite dans [RDF-SYNTAX], et illustrée ici plus loin à la section 6.2.) Ainsi un document dont le titre est traduit en plusieurs langues aurait sa propriété title qui pointe vers un conteneur Alt regroupant des littéraux représentant les titres exprimés dans chacune des langues.

La distinction entre la signification attendue d'un sac et celle d'un choix peut être affinée en considérant l'auteur du livre intitulé « Huckleberry Finn ». Le livre a un seul auteur exactement mais celui-ci a deux noms (Mark Twain et Samuel Clemens). L'un ou l'autre nom suffit à désigner l'auteur. Utiliser un choix pour les noms de l'auteur représente donc la relation plus précisément qu'un sac (qui suggèrerait l'existence de deux auteurs différents).

Les utilisateurs sont libres de choisir leurs propres méthodes pour décrire des groupes de ressources au lieu d'employer le vocabulaire de conteneurs RDF. Ces conteneurs RDF sont simplement offerts comme des définitions communes qui, si elles étaient généralisées, pourraient faciliter l'interopérabilité des données impliquant des groupes de ressources.

Parfois il existe des alternatives claires à utiliser ces types de conteneurs RDF. Ainsi, une relation entre une ressource particulière et un groupe d'autres ressources pourrait être indiquée en faisant de la première ressource le sujet de plusieurs déclarations utilisant la même propriété. Ce n'est pas pareil en ce qui concerne la structure d'avoir la ressource en sujet d'une seule déclaration dont l'objet est un conteneur de plusieurs membres. Dans certains cas, ces deux structure peuvent signifier la même chose et dans d'autres cas non. Le choix de la structure à utiliser dans une situation donnée devrait intervenir avec cette distinction à l'esprit.

Prenons comme exemple la relation entre un écrivain et ses œuvres, comme dans la phrase suivante :

Sue a écrit « Anthology of Time », « Zoological Reasoning » et « Gravitational Reflections ».

Dans ce cas, il y a trois ressources, chacune écrite indépendamment par le même auteur. On pourrait l'exprimer en répétant les propriétés :

exstaff:Sue   exterms:publication   ex:AnthologyOfTime .
exstaff:Sue   exterms:publication   ex:ZoologicalReasoning .
exstaff:Sue   exterms:publication   ex:GravitationalReflections .

Ici il n'y a pas d'autre relation déclarée entre les publications que celle d'avoir été écrites par la même personne. Chaque déclaration est un fait indépendant, et la répétition des propriétés pourrait être un choix raisonnable. Toutefois, on pourrait tout aussi raisonnablement représenter cette relation comme une déclaration à propos du groupe de ressources écrites par Sue :

exstaff:Sue   exterms:publication   _:z .
_:z           rdf:type              rdf:Bag .
_:z           rdf:_1                ex:AnthologyOfTime .
_:z           rdf:_2                ex:ZoologicalReasoning .
_:z           rdf:_3                ex:GravitationalReflections .

D'un autre côté, la phrase :

La résolution a été approuvée par le Comité des règles dont les membres sont Fred, Wilma et Dino.

dit que le comité dans son ensemble a approuvé la résolution ; cela ne veut pas forcément dire que chaque membre du comité a voté individuellement en faveur de la résolution. Auquel cas, il serait potentiellement mensonger de modéliser cette proposition en trois déclarations exterms:approvedBy séparées, une par membre, comme montré ci-dessous :

ex:resolution   exterms:approvedBy   ex:Fred .
ex:resolution   exterms:approvedBy   ex:Wilma .
ex:resolution   exterms:approvedBy   ex:Dino .

puisque ces déclarations font état de l'approbation individuelle de la résolution par chaque membre.

Dans ce cas, il vaudrait mieux modéliser la phrase comme une seule déclaration exterms:approvedBy dont le sujet est la résolution et dont l'objet est le comité même. On décrirait alors la ressource comité comme un Bag dont les membres sont les membres du comité, comme dans les triplets suivants :

ex:resolution       exterms:approvedBy   ex:rulesCommittee .
ex:rulesCommittee   rdf:type             rdf:Bag .
ex:rulesCommittee   rdf:_1               ex:Fred .
ex:rulesCommittee   rdf:_2               ex:Wilma .
ex:rulesCommittee   rdf:_3               ex:Dino .

Lorsqu'on utilise des conteneurs RDF, il est important de comprendre que les déclarations ne construisent pas de conteneurs, comme dans une structure de données d'un langage de programmation. Les déclarations décrivent plutôt des conteneurs (des groupes de choses) qui existent vraisemblablement. Ainsi, dans l'exemple du Comité des règles ci-dessus, le Comité des règles est un groupe non ordonné de personnes, qu'on le décrive en RDF de cette façon ou non. Dire que la ressource ex:rulesCommittee est du type rdf:Bag n'est pas dire que le Comité des règles est une structure de données, ni construire une structure de données particulière pour contenir les membres du groupe (le Comité des règles pourrait être décrit comme un sac sans décrire de membres du tout). C'est plutôt décrire le Comité des règles comme ayant des caractéristiques correspondant à celles associées à un conteneur Bag, à savoir qu'il a des membres et que l'ordre de leurs descriptions n'est pas significatif. De même, utiliser les propriétés d'appartenance au conteneur décrit simplement une ressource conteneur ayant certaines choses comme membres. Cela ne veut pas forcément dire que les choses décrites comme membres sont les seuls membres qui existent. Par exemple, les triplets donnés ci-dessus pour décrire le Comité des règles disent seulement que Fred, Wilma et Dino sont des membres du comité, non que ce sont les seuls.

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:s="http://example.org/packages/vocab#"> 
 
 <rdf:Description rdf:about="http://example.org/packages/X11">
    <s:DistributionSite>
       <rdf:Alt>
          <rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Bag"/> 
          <rdf:_2 rdf:resource="ftp://ftp.example.org"/>
          <rdf:_2 rdf:resource="ftp://ftp1.example.org"/>
          <rdf:_5 rdf:resource="ftp://ftp2.example.org"/>
      </rdf:Alt>
    </s:DistributionSite>
 </rdf:Description>
</rdf:RDF>

4.2 Collections RDF

Une limitation des conteneurs décrits à la section 4.1 est qu'il n'y a aucun moyen de les clore, c'est-à-dire de dire que « ce sont tous les membres de ce conteneur ». Comme noté à la section 4.1, un conteneur dit seulement que certaines ressources identifiées sont membres ; il ne dit pas qu'il n'en existe pas d'autres. De même, si un graphe peut décrire quelques membres, il n'y a aucun moyen d'exclure la possibilité d'un autre graphe ailleurs qui décrive des membres en plus. RDF permet de décrire des groupes contenant seulement les membres indiqués, sous la forme de collections RDF. Une collection RDF est un groupe de choses représenté par une structure de liste dans le graphe RDF. Cette structure de liste se construit en utilisant un vocabulaire de collection (collection vocabulary) constitué du type prédéfini rdf:List, des propriétés prédéfinies rdf:first et rdf:rest, et de la ressource prédéfinie rdf:nil.

Comme illustration, la phrase « Les étudiants du cours 6.001 comprennent Amy, Mohamed et Johann » pourrait être représentée par le graphe montré en figure 16 :

Figure 16 : Une collection RDF (structure de liste)

Dans ce graphe, chaque membre de la collection, tel que s:Amy, est l'objet d'une propriété rdf:first dont le sujet est une ressource (ici un nœud anonyme) qui représente une liste. Cette ressource liste est liée au reste de la liste par une propriété rdf:rest. La fin de la liste est indiquée par la propriété rdf:rest ayant pour objet la ressource rdf:nil (la ressource rdf:nil représente la liste vide et elle est définie comme étant de type rdf:List). Cette structure est familière à ceux qui pratiquent le langage de programmation Lisp. Comme dans Lisp, les propriétés rdf:first et rdf:rest permettent aux applications de traverser la structure. Chacun des nœuds anonymes formant cette structure de liste est implicitement de type rdf:List (c'est-à-dire que chacun de ces nœuds a implicitement une propriété rdf:type dont la valeur est le type prédéfini rdf:List), bien que cela n'apparaisse pas explicitement dans le graphe. Le langage RDF Schema [RDF-VOCABULARY] définit les propriétés rdf:first et rdf:rest comme ayant des sujets de type rdf:List, et on peut donc en général inférer l'information selon laquelle ces nœuds sont des listes, au lieu de rédiger tout le temps les triplets rdf:type correspondants.

RDF/XML fournit une notation spéciale pour faciliter la description des collections utilisant des graphes de cette forme. En RDF/XML, on peut décrire une collection avec un élément de propriété qui a l'attribut rdf:parseType="Collection" et qui contient un groupe d'éléments nichés représentant les membres de la collection. RDF/XML fournit l'attribut rdf:parseType qui indique d'interpréter le contenu d'un élément d'une manière spéciale. Dans ce cas, l'attribut rdf:parseType="Collection" indique d'utiliser les éléments englobés pour créer la structure de liste correspondante dans le graphe RDF (les autres valeurs de l'attribut rdf:parseType seront décrite dans les sections à suivre de l'initiation).

Pour illustrer comment fonctionne rdf:parseType="Collection", le RDF/XML de l'exemple 17 donnerait le graphe RDF montré en figure 16 :

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:s="http://example.org/students/vocab#">

   <rdf:Description rdf:about="http://example.org/courses/6.001">
      <s:students rdf:parseType="Collection">
            <rdf:Description rdf:about="http://example.org/students/Amy"/>
            <rdf:Description rdf:about="http://example.org/students/Mohamed"/>
            <rdf:Description rdf:about="http://example.org/students/Johann"/>
      </s:students>
   </rdf:Description>
</rdf:RDF>

<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:s="http://example.org/students/vocab#"> 

<rdf:Description rdf:about="http://example.org/courses/6.001"> 
   <s:students rdf:nodeID="sch1"/>
</rdf:Description>
 
<rdf:Description rdf:nodeID="sch1"> 
   <rdf:first rdf:resource="http://example.org/students/Amy"/>
   <rdf:rest rdf:nodeID="sch2"/> 
</rdf:Description>
 
<rdf:Description rdf:nodeID="sch2"> 
   <rdf:first rdf:resource="http://example.org/students/Mohamed"/>
   <rdf:rest rdf:nodeID="sch3"/> 
</rdf:Description>
 
<rdf:Description rdf:nodeID="sch3"> 
   <rdf:first rdf:resource="http://example.org/students/Johann"/>
   <rdf:rest rdf:resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#nil"/> 
</rdf:Description>
</rdf:RDF>

4.3 Réification RDF

Les applications RDF doivent parfois décrire d'autres déclarations RDF en utilisant RDF, par exemple, pour enregistrer des informations à propos de savoir quand les déclarations ont été faites, qui les a faites, ou autre informations similaires (ce que l'on désigne aussi par informations de « provenance »). Ainsi, l'exemple 9 à la section 3.2 décrivait une tente particulière, mise en vente par example.com, par la référence URI exproducts:item10245. L'un des triplets de cette description pour le poids de la tente était celui-ci :

exproducts:item10245   exterms:weight   "2.4"^^xsd:decimal .

et il pouvait être utile pour example.com d'enregistrer qui fournissait cette information particulière.

RDF fournit un vocabulaire natif destiné à décrire les déclarations RDF. Une description de déclaration utilisant ce vocabulaire est dite une réification de la déclaration. Le vocabulaire de réification RDF comprend le type rdf:Statement et les propriétés rdf:subject, rdf:predicate et rdf:object. Néanmoins, bien que RDF propose ce vocabulaire de réification, on doit l'utiliser avec précaution, parce qu'il est facile de croire que le vocabulaire définit des choses qui en réalité ne sont pas définies. Ce point sera abordé plus loin dans cette section.

En utilisant le vocabulaire de réification, une réification de la déclaration à propos du poids de la tente serait donnée en affectant une référence URI à la déclaration telle que exproducts:triple12345 (on peut donc écrire des déclarations qui la décrivent) puis en décrivant la déclaration avec les déclarations suivantes :

exproducts:triple12345   rdf:type        rdf:Statement .
exproducts:triple12345   rdf:subject     exproducts:item10245 .
exproducts:triple12345   rdf:predicate   exterms:weight . 
exproducts:triple12345   rdf:object      "2.4"^^xsd:decimal .

Ces déclarations disent que la ressource identifiée par la référence URI exproducts:triple12345 est une déclaration RDF, que le sujet de la déclaration se rapporte à la ressource identifiée par exproducts:item10245, que le prédicat de la déclaration se rapporte à la ressource identifiée par exterms:weight et que l'objet de la déclaration se rapporte à la valeur décimale identifiée par le littéral typé "2.4"^^xsd:decimal. En supposant que la déclaration originale soit réellement identifiée par exproducts:triple12345, il devrait être clair, comparant la déclaration originale à la réification, que la réification décrit vraiment la déclaration. L'utilisation conventionnelle du vocabulaire de réification RDF implique toujours de décrire une déclaration dans ce modèle en utilisant quatre déclarations ; ces quatres déclarations sont parfois appelées pour cette raison le « quatuor de réification » (reification quad).

En utilisant une réification selon cette convention, example.com pourrait enregistrer le fait que John Smith est l'auteur de la déclaration originale à propos du poids de la tente en affectant d'abord une référence URI (telle que exproducts:triple12345 comme précédemment) à la déclaration originale, puis en décrivant cette déclaration avec la réification juste établie, enfin en ajoutant une autre déclaration selon laquelle exproducts:triple12345 a été écrite par John Smith (en utilisant une référence URI pour identifier le John Smith en question). La déclaration finale serait :

exproducts:triple12345   rdf:type        rdf:Statement .
exproducts:triple12345   rdf:subject     exproducts:item10245 . 
exproducts:triple12345   rdf:predicate   exterms:weight . 
exproducts:triple12345   rdf:object      "2.4"^^xsd:decimal .
exproducts:triple12345   dc:creator      exstaff:85740 . 

La déclaration originale, avec la réification et l'attribution de la déclaration à John Smith, forme le graphe montré en figure 17 :

Figure 17 : Une déclaration, sa réification et son attribution

Ce graphe s'écrirait en RDF/XML comme montré dans l'exemple 19 :

Exemple 19 : Syntaxe RDF/XML de l'exemple de réification

<?xml version="1.0"?>
<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>
<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.com/terms/"
            xml:base="http://www.example.com/2002/04/products">

  <rdf:Description rdf:ID="item10245">
     <exterms:weight rdf:datatype="&xsd;decimal">2.4</exterms:weight>
  </rdf:Description>

  <rdf:Statement rdf:about="#triple12345">
     <rdf:subject rdf:resource="http://www.example.com/2002/04/products#item10245"/>
     <rdf:predicate rdf:resource="http://www.example.com/terms/weight"/>
     <rdf:object rdf:datatype="&xsd;decimal">2.4</rdf:object>

     <dc:creator rdf:resource="http://www.example.com/staffid/85740"/>
  </rdf:Statement>

</rdf:RDF>

La section 3.2 introduisait l'utilisation, en RDF/XML, de l'attribut rdf:ID dans un élément rdf:Description afin de réduire la référence URI du sujet d'une déclaration. On peut aussi utiliser rdf:ID dans un élément de propriété pour produire automatiquement une réification du triplet que l'élément de propriété génère. L'exemple 20 montre comment on s'en servirait pour produire le même graphe que dans l'exemple 19 :

Exemple 20 : Générer des réifications avec rdf:ID

<?xml version="1.0"?>
<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>
<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.com/terms/"
            xml:base="http://www.example.com/2002/04/products">

  <rdf:Description rdf:ID="item10245">
     <exterms:weight rdf:ID="triple12345" rdf:datatype="&xsd;decimal">2.4
     </exterms:weight>
  </rdf:Description>

  <rdf:Description rdf:about="#triple12345">
     <dc:creator rdf:resource="http://www.example.com/staffid/85740"/>
  </rdf:Description>

</rdf:RDF>

Dans ce cas, définir l'attribut rdf:ID="triple12345" dans l'élément exterms:weight donne le triplet original décrivant le poids de la tente :

exproducts:item10245   exterms:weight   "2.4"^^xsd:decimal .

plus les triplets de réification :

exproducts:triple12345   rdf:type        rdf:Statement .
exproducts:triple12345   rdf:subject     exproducts:item10245 .
exproducts:triple12345   rdf:predicate   exterms:weight . 
exproducts:triple12345   rdf:object      "2.4"^^xsd:decimal .

Le sujet de ces triplets de réification est une référence URI formée en concaténant l'adresse URI de base du document (donnée dans la déclaration xml:base), le caractères "#" (pour indiquer un identificateur de fragment à suivre) et la valeur de l'attribut rdf:ID ; à savoir, que les triplets ont le même sujet exproducts:triple12345 que dans les exemples précédents.

Notez que faire valoir (asserting) la réification n'est pas la même chose que faire valoir la déclaration originale, et que l'un n'implique pas l'autre. C'est-à-dire que, lorsqu'on dit que John a dit quelque chose à propos du poids d'une tente, on ne fait pas soi-même une déclaration à propos du poids de la tente, on fait une déclaration à propos de quelque chose que John a dite. Inversement, lorsqu'on décrit le poids d'une tente, on ne fait pas également une déclaration à propos d'une déclaration qu'on a faite (dans la mesure où l'on n'a peut-être pas l'intention de parler de choses appelées « déclarations »).

Le texte précédent mentionnait délibérément à plusieurs reprises « l'utilisation conventionnelle de la réification ». Comme indiqué plus tôt, on doit utiliser le vocabulaire de réification RDF avec précaution car il est facile de croire que le vocabulaire définit des choses qui ne sont pas définies en réalité. Quoique des applications utilisent la réification avec succès, elles le font en suivant des conventions et en faisant des suppositions, en plus de la signification réelle que RDF définit pour le vocabulaire de réification et des facilités concrètes que RDF fournit pour l'appliquer.

À un titre au moins, il est important de noter que dans l'utilisation conventionnelle de la réification, le sujet des triplets de réification est censé identifier une instance particulière d'un triplet dans un document RDF, plutôt qu'un triplet arbitraire ayant les mêmes sujet, prédicat et objet. On utilise cette convention particulière parce que la réification est prévue pour l'expression de propriétés telles que les dates d'information de composition et de source, comme dans les exemples déjà donnés, et ces propriétés doivent s'appliquer à des instances spécifiques des triplets. Plusieurs triplets pourraient avoir les mêmes sujet, prédicat et objet, et même si un graphe est défini comme étant un ensemble de triplets, plusieurs instances avec la même structure de triplets pourraient se trouver dans des documents différents. Par conséquent, pour soutenir complètement cette convention, il faut un moyen d'associer le sujet des triplets de réification à un triplet individuel dans un document. Toutefois, RDF n'offre aucun moyen de le faire.

Ainsi, dans les exemples ci-dessus, il n'y a pas d'information explicite dans les triplets ou le RDF/XML qui indique réellement que la déclaration originale décrivant le poids de la tente est la ressource exproducts:triple12345, c'est-à-dire la ressource qui est le sujet des quatre déclarations de réification et de la déclaration selon laquelle John l'a créée. On peut le voir en examinant le graphe dessiné montré en figure 17. La déclaration originale fait certainement partie de ce graphe, mais en ce qui concerne l'information dans le graphe, exproducts:triple12345 est une ressource séparée, plutôt que d'identifier cette partie du graphe. Le langage RDF ne fournit aucune méthode native d'indiquer la façon dont une référence URI comme exproducts:triple12345 est associée à une déclaration ou un graphe particuliers, pas plus qu'il ne fournit une méthode native d'indiquer comment une référence URI comme exproducts:item10245 est associée à une tente réelle. L'association de références URI spécifiques à des ressources spécifiques (ici des déclarations) doit être réalisée à l'aide de mécanismes extérieurs à RDF.

L'utilisation de rdf:ID comme montré dans l'exemple 20 génère automatiquement la réification et fournit un moyen commode d'indiquer la référence URI à utiliser comme sujet des déclarations dans la réification. En outre, elle fournit un « crochet » partiel reliant les triplets dans la réification au morceau de syntaxe RDF/XML qui a provoqué leur création, puisque la valeur triple12345 de l'attribut rdf:ID est utilisée pour générer la référence URI du sujet des triplets de réification. En revanche, cette relation se fait encore une fois hors de RDF, puisque que rien dans les triplets résultants n'indique que le triplet original avait la référence URI exproducts:triple12345 (RDF ne présume aucune relation entre une référence URI et le RDF/XML dans lequel celle-ci aurait pu être utilisée ou en quoi elle aurait put être réduite).

L'absence d'une méthode native pour affecter les références URI aux déclarations ne signifie pas que l'on ne peut pas exprimer une information de « provenance » de ce type en RDF, juste que l'on ne peut pas le faire en utilisant seulement la sémantique (meaning) que RDFattribue au vocabulaire de réification. Par exemple, si un document RDF (disons une page web) a une adresse URI, on pourrait faire des déclarations à propos de la ressource identifiée par cette adresse URI et une application, avec une compréhension propre à l'application de la façon qu'il faudrait interpréter ces déclarations, pourrait agir comme si ces déclarations « se distribuait » sur (s'appliquait équitablement à) toutes les déclarations dans le document. Également, s'il existe un mécanisme (hors de RDF) pour affecter des adresses URI individuellement aux déclarations RDF, alors on peut certainement faire des déclarations à propos de ces déclarations individuelles, en utilisant leurs adresses URI pour les identifier. Par contre, dans ces cas, il ne serait pas strictement nécessaire non plus d'utiliser le vocabulaire de réification de la façon conventionnelle.

Pour s'en rendre compte, supposons que la déclaration originale :

exproducts:item10245   exterms:weight   "2.4"^^xsd:decimal .

ait une référence URI de exproducts:triple12345 ; on pourrait attribuer la déclaration à John Smith simplement par la déclaration :

exproducts:triple12345   dc:creator   exstaff:85740 .

sans utilisation du vocabulaire de réification (quoique la description de exproducts:triple12345 comme ayant le type (rdf:type) rdf:Statement puisse aussi être utile).

De plus, le vocabulaire de réification pourrait être utilisé directement conformément à la convention décrite auparavant, parallèlement à une compréhension liée à l'application de la façon d'associer des triplets spécifiques à leurs réifications. Toutefois, d'autres applications recevant ce RDF ne partageront peut-être pas cette compréhension d'une application particulière et n'interpréteront pas nécessairement les graphes de façon appropriée.

Il est également important de noter que l'interprétation de la réification décrite ici n'est pas la même que la « citation » (quotation), trouvée dans certains langages. La réification décrit plutôt la relation entre une instance particulière d'un triplet et les ressources auxquelles le triplet se rapporte. La réification peut intuitivement se lire comme disant « ce triplet RDF traite de ces choses » plutôt que (comme dans la citation) « ce triplet RDF a cette forme ». Ainsi, dans l'exemple de réification utilisé dans cette section, le triplet :

exproducts:triple12345   rdf:subject   exproducts:item10245 .

décrivant le sujet (rdf:subject) de la déclaration original dit que le sujet de la déclaration est la ressource (la tente) identifiée par la référence URI exproducts:item10245. Il ne dit pas que le sujet de la déclaration est la référence URI même (c'est-à-dire une chaîne commençant par certains caractères), comme une citation le ferait.

4.4 Plus sur les valeurs structurées : rdf:value

La section 2.3 notait que le modèle RDF ne gère intrinsèquement que des relations binaires ; c'est-à-dire qu'une déclaration définit une relation entre deux ressources. Par exemple, le triplet :

exstaff:85740   exterms:manager   exstaff:62345 .

déclare que la relation exterms:manager s'exerce entre deux employés (l'un dirige vraisemblablement l'autre).

Toutefois, il est nécessaire dans certains cas de représenter une information impliquant des relations d'arité (arity) supérieure (des relations entre plus de deux ressources) en RDF. La section 2.3 en donnait un exemple, où le problème était de représenter la relation entre John Smith et son adresse, et l'adresse de John était une valeur structurée de sa rue, sa ville, son état et son code postal. L'écrire comme relation montre que cette adresse est une relation 5-aire de la forme :

address(exstaff:85740, "1501 Grant Avenue", "Bedford", "Massachusetts", "01730")

La section 2.3 notait que ce type d'information structurée pouvait être représenté en RDF en considérant la chose agrégée à décrire (ici le groupe de composantes représentant l'adresse de John) comme une ressource séparée et en faisant des déclarations séparées à propos de cette nouvelle ressource, comme dans les triplets suivants :

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

(où _:johnaddress est l'identificateur de nœud anonyme du nœud anonyme représentant l'adresse de John.)

C'est une façon générale de représenter toute relation n-aire (n-ary) en RDF : sélectionnez l'un des participants (ici John) pour servir de sujet de la relation originale (ici address), puis définissez une ressource intermédiaire pour représenter le reste de la relation (en lui affectant ou non une adresse URI), donnez enfin à cette nouvelle ressource des propriétés représentant les composants restants de la relation.

Dans le cas de l'adresse de John, aucune des composantes individuelles de la valeur structurée n'était envisageable comme valeur « principale » de la propriété exterms:address ; toutes les composantes contribuent équitablement à la valeur. Néanmoins, dans certains cas, on considère souvent l'une des composantes de la valeur structurée comme étant la valeur principale, les autres composantes de la relation fournissant un contexte supplémentaire ou d'autres informations qualifiant la valeur principale. Ainsi, dans l'exemple 9 de la section 3.2, le poids d'une tente particulière était donné par la valeur décimale 2.4 en utilisant un littéral typé, à savoir :

exproduct:item10245   exterms:weight   "2.4"^^xsd:decimal .

En fait, une description plus complète du poids aurait été 2.4 kilogrammes au lieu de la seule valeur décimale 2.4. Pour le déclarer, la valeur de la propriété exterms:weight devait avoir deux composantes, le littéral typé pour la valeur décimale et une indication de l'unité de mesure (kilogramme). Dans cette situation, on pouvait considérer la valeur décimale comme étant la valeur « principale » de la propriété exterms:weight, parce que fréquemment la valeur aurait simplement été enregistrée comme le littéral typé (comme dans le triplet ci-dessus), en comptant sur une compréhension du contexte pour suppléer l'information d'unité non déclarée.

Dans le modèle RDF, une valeur de propriété qualifiée de ce type peut tout simplement être considéré comme un autre type de valeur structurée. Pour le représenter, on pourrait utiliser une ressource séparée pour représenter la valeur structurée comme un tout (ici le poids) et servir d'objet de la déclaration originale. Cette ressource pourrait alors recevoir des propriétés représentant les composantes individuelles de la valeur structurée. Auquel cas, il devrait y avoir une propriété pour le littéral typé représentant la valeur décimale et une propriété pour l'unité. RDF fournit une propriété prédéfinie rdf:value pour décrire la valeur principale (le cas échéant) d'une valeur structurée. Donc ici on pourrait donner le littéral typé en valeur de la propriété rdf:value et la ressource exunits:kilograms en valeur d'une propriété exterms:units (à supposer que la ressource exunits:kilograms soit définie dans le vocabulaire d'example.org). Les triplets résultants seraient :

exproduct:item10245   exterms:weight   _:weight10245 .
_:weight10245         rdf:value        "2.4"^^xsd:decimal .
_:weight10245         exterms:units    exunits:kilograms .

que l'on peut exprimer par le RDF/XML montré dans l'exemple 21 :

<?xml version="1.0"?>
<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
            xmlns:exterms="http://www.example.org/terms/">

  <rdf:Description rdf:about="http://www.example.com/2002/04/products#item10245">
     <exterms:weight rdf:parseType="Resource">
       <rdf:value rdf:datatype="&xsd;decimal">2.4</rdf:value>
       <exterms:units rdf:resource="http://www.example.org/units/kilograms"/>
     </exterms:weight>
  </rdf:Description>

</rdf:RDF>

L'exemple 21 illustre également une deuxième utilisation de l'attribut rdf:parseType introduit à la section 4.2, dans ce cas rdf:parseType="Resource". On utilise un attribut rdf:parseType="Resource" pour indiquer d'interpréter le contenu d'un élément comme étant la description d'une nouvelle ressource (nœud anonyme), en fait sans devoir écrire d'élément rdf:Description niché. Dans ce cas, l'attribut rdf:parseType="Resource" utilisé dans l'élément de propriété exterms:weight indique de créer un nœud anonyme comme valeur de la propriété exterms:weight, les éléments englobés (rdf:value et exterms:units) décrivant les propriétés de ce nœud anonyme. D'autres détails à propos de rdf:parseType="Resource" sont donnés dans [RDF-SYNTAX].

La même approche peut être empruntée pour représenter des quantités avec des unités de mesure, ou bien des valeurs tirées de schémas de classification ou de systèmes de notation différents, en utilisant la propriété rdf:value pour donner la valeur principale et des propriétés supplémentaires pour identifier le schéma de classification ou d'autres informations qui complètent la description de la valeur.

Il n'y a pas obligation d'utiliser rdf:value dans ce but (par exemple, on aurait pu utiliser un nom de propriété défini par l'utilisateur, tel que exterms:amount, à la place de rdf:value dans l'exemple 21), et RDF ne prête aucune signification spéciale à rdf:value. La propriété rdf:value est simplement fournie comme un commodité à utiliser dans ces situation courantes.

Quoiqu'il en soit, même si une bonne partie des données existantes dans les bases de données et sur le Web (et dans les derniers exemples de l'initiation) prennent la forme de valeurs de propriété simples, telles que des poids, des coûts, etc., un principe important est que ces valeurs simples sont souvent insuffisantes pour décrire adéquatement de telles valeurs. Dans un environnement global tel que le Web, il n'est pas prudent, en général, de supposer que quelqu'un lisant une valeur de propriété comprendra l'unité utilisée (ou une autre information dépendant du contexte qui serait impliquée). Par exemple, un site américain peut donner une valeur de poids en livres et un étranger lisant cette donnée pourrait penser que les poids sont donnés en kilogrammes. L'interprétation correcte des données dans l'environnement Web peut imposer l'enregistrement explicite d'informations supplémentaires (telles que les unités). On peut y arriver de plusieurs façons, comme utiliser rdf:value, construire les unités dans les noms de propriétés (par exemple exterms:weightInKg), définir des types de données spécialisés qui incluent l'information d'unité (par exemple extypes:kilograms) ou ajouter des propriétés définies par l'utilisateur pour donner cette information (par exemple exterms:unitOfWeight), que ce soit dans les descriptions des éléments individuels, dans les descriptions d'ensembles de données (par exemple, toutes les données d'un catalogue ou sur un site) ou dans les schémas (cf. la section 5).

5.1 Décrire des classes

Une étape de base dans tout processus de description est d'identifier les divers types de choses à décrire. RDF Schema désigne ces « types de choses » comme étant des classes. Une classe en RDF Schema correspond au concept générique d'un type ou d'une catégorie, quelque chose comme la notion d'une classe dans les langages de programmation orientée objet. Les classes RDF peuvent servir à représenter pratiquement n'importe quelle catégorie de choses, telles que des pages web, des personnes, des types de documents, des bases de données ou des concepts abstraits. Les classes sont décrites à l'aide des ressources RDF Schema rdfs:Class et rdfs:Resource, et des propriétés rdf:type et rdfs:subClassOf.

Par exemple, supposons qu'une organisation example.org veuille utiliser RDF pour fournir des informations à propos de différents types de véhicules à moteur. En RDF Schema, example.org aurait d'abord besoin d'une classe pour représenter la catégorie des choses qui sont des véhicules à moteur. Les ressources appartenant à une classe sont dites ses instances. Dans ces cas, example.org destine les instances de cette classe à être des ressources qui sont des véhicules à moteur.

En RDF Schema, une classe est une ressource avec une propriété rdf:type dont la valeur est la ressource rdfs:Class. La classe des véhicules à moteur serait donc décrite en affectant à la classe une référence URI, disons ex:MotorVehicle (où ex: représente la référence URI http://www.example.org/schemas/vehicles, utilisée comme préfixe des références URI du vocabulaire de example.org), et en décrivant cette ressource avec une propriété rdf:type dont la valeur est la ressource rdfs:Class. C'est-à-dire qu'example.org écrirait la déclaration RDF suivante :

ex:MotorVehicle   rdf:type   rdfs:Class .

Comme noté à la section 3.2, la propriété rdf:type sert à indiquer que la ressource est une instance d'une classe. Ayant décrit ex:MotorVehicle comme étant une classe, on décrirait alors la ressource exthings:companyCar comme étant un véhicule à moteur par cette déclaration RDF :

exthings:companyCar   rdf:type   ex:MotorVehicle .

(Cette déclaration obéit à une convention courante selon laquelle la première lettre des noms de classes s'écrit en majuscule et celle des noms de propriétés et d'instances en minuscule. Toutefois, cette convention n'est pas obligatoire en RDF Schema. La déclaration suppose également qu'example.org a décidé de définir des vocabulaires séparés pour les classes de choses et les instances de choses.)

La ressource rdfs:Class même a un type (rdf:type) de rdfs:Class. Une ressource peut être une instance de plusieurs classes.

Après la classe ex:MotorVehicle, example.org voudra peut-être décrire d'autres classes représentant divers types spécialisés de véhicules à moteur, par exemple des véhicules à passagers, des fourgons (vans), des fourgonnettes, etc. Ces classes peuvent être décrites de la même façon que la classe ex:MotorVehicle, en affectant une référence URI à chaque nouvelle classe et en écrivant des déclarations RDF décrivant ces ressource comme étant des classes, ainsi :

ex:Van     rdf:type   rdfs:Class .
ex:Truck   rdf:type   rdfs:Class .

et ainsi de suite. Toutefois, ces déclarations en elles-mêmes ne décrivent que des classes individuelles. L'organisation example.org voudra peut-être indiquer leur relation spéciale à la classe ex:MotorVehicle, c'est-à-dire qu'il s'agit de types spécialisés de véhicules à moteur.

Ce type de relation de spécialisation entre deux classes est décrit en utilisant la propriété prédéfinie rdfs:subClassOf pour relier les deux classes. Par exemple, pour déclarer que ex:Van est un type spécialisé de ex:MotorVehicle, example.org écrirait la déclaration RDF suivante :

ex:Van   rdfs:subClassOf   ex:MotorVehicle .

La signification de cette relation rdfs:subClassOf est que toute instance de la classe ex:Van est également une instance de la classe ex:MotorVehicle. Donc si la ressource exthings:companyVan est une instance de ex:Van, alors, d'après la relation rdfs:subClassOf déclarée, un logiciel RDF comprenant le vocabulaire RDF Schema peut inférer l'information supplémentaire selon laquelle exthings:companyVan est aussi une instance de ex:MotorVehicle.

Cet exemple de exthings:companyVan illustre le point précédent à propos de RDF Schema définissant un langage étendu. RDF ne définit pas en soi la signification spéciale des termes du vocabulaire RDF Schema tels que rdfs:subClassOf. Donc, si un schéma RDF définit cette relation rdfs:subClassOf entre ex:Van et ex:MotorVehicle, un logiciel non écrit pour comprendre les termes RDF Schema la reconnaîtrait comme étant un triplet, ayant pour prédicat rdfs:subClassOf, mais il serait incapable de comprendre la signification spéciale de rdfs:subClassOf et d'en tirer l'implication (entailment) supplémentaire que exthings:companyVan est également une instance de ex:MotorVehicle.

La propriété rdfs:subClassOf est transitive. Ainsi, pour les déclarations RDF données, cela signifie :

ex:Van       rdfs:subClassOf   ex:MotorVehicle .
ex:MiniVan   rdfs:subClassOf   ex:Van .

RDF Schema définit ex:MiniVan comme étant également une sous-classe de ex:MotorVehicle. Par conséquent, RDF Schema définit les ressources qui sont des instances de la classe ex:MiniVan comme étant aussi des instances de la classe ex:MotorVehicle (ainsi que des instances de la classe ex:Van). Une classe peut être une sous-classe de plusieurs classes (par exemple ex:MiniVan peut être une sous-classe à la fois de ex:Van et de ex:PassengerVehicle). RDF Schema définit toutes les classes comme étant des sous-classes de la classe rdfs:Resource (puisque les instances appartenant à toutes les classes sont des ressources).

La figure 18 la hiérarchie complète des classes traitées dans ces exemples.

Figure 18 : Une hiérarchie des classes de véhicules

(Pour la lisibilité, les propriétés rdf:type reliant chacune des classes à rdfs:Class sont omises dans la figure 18. En fait, RDF Schema définit les sujets et les objets des déclarations utilisant la propriété rdfs:subClassOf comme étant des ressources de type rdfs:Class, et cette information pouvait être inférée. Quoiqu'il en soit, lors de l'écriture concrète des schémas, une bonne pratique est de fournir explicitement cette information.)

On pouvait également décrire ce schéma par les triplets suivants :

ex:MotorVehicle       rdf:type          rdfs:Class .
ex:PassengerVehicle   rdf:type          rdfs:Class .
ex:Van                rdf:type          rdfs:Class .
ex:Truck              rdf:type          rdfs:Class .
ex:MiniVan            rdf:type          rdfs:Class .

ex:PassengerVehicle   rdfs:subClassOf   ex:MotorVehicle .
ex:Van                rdfs:subClassOf   ex:MotorVehicle .
ex:Truck              rdfs:subClassOf   ex:MotorVehicle .

ex:MiniVan            rdfs:subClassOf   ex:Van .
ex:MiniVan            rdfs:subClassOf   ex:PassengerVehicle .

L'exemple 23 montre comment écrire ce schéma en RDF/XML.

<?xml version="1.0"?>
<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>
<rdf:RDF   
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"  
  xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
  xml:base="http://example.org/schemas/vehicles">

<rdf:Description rdf:ID="MotorVehicle">
  <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
</rdf:Description>

<rdf:Description rdf:ID="PassengerVehicle">
  <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdf:Description>

<rdf:Description rdf:ID="Truck">
  <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdf:Description>

<rdf:Description rdf:ID="Van">
  <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdf:Description>

<rdf:Description rdf:ID="MiniVan">
  <rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
  <rdfs:subClassOf rdf:resource="#Van"/>
  <rdfs:subClassOf rdf:resource="#PassengerVehicle"/>
</rdf:Description>

</rdf:RDF>

<?xml version="1.0"?>
<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>
<rdf:RDF   
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"  
  xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
  xml:base="http://example.org/schemas/vehicles">

<rdfs:Class rdf:ID="MotorVehicle"/>

<rdfs:Class rdf:ID="PassengerVehicle">
  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdfs:Class>

<rdfs:Class rdf:ID="Truck">
  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdfs:Class>

<rdfs:Class rdf:ID="Van">
  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdfs:Class>

<rdfs:Class rdf:ID="MiniVan">
  <rdfs:subClassOf rdf:resource="#Van"/>
  <rdfs:subClassOf rdf:resource="#PassengerVehicle"/>
</rdfs:Class>

</rdf:RDF>

La syntaxe RDF/XML de l'exemple 23 et de l'exemple 24 introduit des noms, tels que MotorVehicle, pour les ressources (classes) qu'elle décrit en utilisant l'attribut rdf:ID, à effet d'« affecter » des références URI relatives au document de schéma, comme décrit à la section 3.2. L'attribut rdf:ID est utile ici parce qu'il réduit les références URI et fournit en même temps une vérification supplémentaire selon laquelle la valeur de l'attribut rdf:ID est unique par rapport à l'adresse URI de base courante (habituellement l'adresse URI du document). Cela permet de repérer les valeurs rdf:ID répétées lors de la définition des noms de classes et de propriétés dans les schémas RDF. Les références URI relatives fondées sur ces noms sont alors utilisables dans d'autres définitions de classes au sein du même schéma (par exemple, comme l'est #MotorVehicle dans la description des autres classes). La référence URI complète de cette classe, en supposant que le schéma lui-même était la ressource http://example.org/schemas/vehicles, serait http://example.org/schemas/vehicles#MotorVehicle (montré en figure 18). Comme noté à la section 3.2, afin d'assurer la pérennité des références à ces classes du schéma même si le schéma était déplacé ou copié (ou simplement pour affecter une référence URI de base aux classes du schéma sans présumer qu'elles sont publiées en un seul endroit), les descriptions de classes pourrait également inclure une déclaration explicite xml:base="http://example.org/schemas/vehicles". L'emploi d'une déclaration xml:base explicite est considérée comme une bonne pratique, et il y en a une dans les deux exemples.

Pour appeler ces classes dans des données d'instance RDF (par exemple des données décrivant des véhicules individuels de ces classes) trouvées ailleurs, example.org devra peut-être identifier les classes soit en écrivant des références URI absolues, en utilisant des références URI relatives avec une déclaration xml:base appropriée, soit en utilisant des noms qualifiés avec une déclaration d'espace de noms appropriée qui permette l'expansion des noms qualifiés vers les références URI exactes. Par exemple, on pourrait décrire la ressource exthings:companyCar comme une instance de la classe ex:MotorVehicle décrite dans le schéma de l'exemple 24 par le RDF/XML montré dans l'exemple 25 :

<?xml version="1.0"?>
<rdf:RDF   
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"  
  xmlns:ex="http://example.org/schemas/vehicles#"
  xml:base="http://example.org/things">

   <ex:MotorVehicle rdf:ID="companyCar"/>

</rdf:RDF>

5.2 Décrire des propriétés

Outre des classes spécifiques de choses, les communautés d'utilisateurs doivent aussi pouvoir décrire des propriétés spécifiques qui caractérisent ces classes de choses (telles que rearSeatLegRoom pour décrire un véhicule à passagers). En RDF Schema, les propriétés sont décrites en utilisant la classe RDF rdf:Property, et les propriétés RDF Schema rdfs:domain, rdfs:range et rdfs:subPropertyOf.

Toutes les propriétés dans RDF sont décrites comme des instances de la classe rdf:Property. Ainsi une nouvelle propriété, telle que exterms:weightInKg, est décrite en affectant une référence URI à la propriété et en décrivant cette ressource avec une propriété rdf:type dont la valeur est la ressource rdf:Property, par exemple en écrivant la déclaration RDF suivante :

exterms:weightInKg   rdf:type   rdf:Property .

RDF Schema fournit aussi un vocabulaire pour décrire la façon d'utiliser ensemble les propriétés et les classes dans les données RDF. Les informations de ce type les plus importantes sont fournies par les propriétés RDF Schema rdfs:range et rdfs:domain utilisées pour décrire plus avant les propriétés spécifiques d'une application.

La propriété rdfs:range sert à indiquer que les valeurs d'une propriété particulières sont des instances d'une classe désignée. Par exemple, si l'entreprise example.org voulait indiquer que la propriété ex:author avaient des valeurs qui sont des instances de la classe ex:Person, elle écrirait les déclarations RDF suivantes :

ex:Person   rdf:type     rdfs:Class .
ex:author   rdf:type     rdf:Property .
ex:author   rdfs:range   ex:Person .

Ces déclarations indiquent que ex:Person est une classe, que ex:author est une propriété et que les déclarations RDF utilisant la propriété ex:author ont pour objets des instances de ex:Person.

Une propriété, disons ex:hasMother, peut avoir zéro, une ou plusieurs propriétés d'image (range property). Si ex:hasMother n'a pas de propriété d'image, c'est que rien n'est dit à propos des valeurs de la propriété ex:hasMother. Si ex:hasMother a une propriété d'image, disons une indiquant ex:Person comme image, cela dit que les valeurs de la propriété ex:hasMother sont des instances de la classe ex:Person. Si ex:hasMother a plusieurs propriétés d'image, disons une indiquant ex:Person pour image et une autre définissant ex:Female pour image, cela dit que les valeurs de la propriété ex:hasMother sont des ressources qui sont des instances de l'ensemble des classes définies comme images, c'est-à-dire que toute valeur ex:hasMother est à la fois une instance ex:Female et une instance ex:Person.

ex:hasMother   rdfs:range   ex:Female .
ex:hasMother   rdfs:range   ex:Person .

exstaff:frank   ex:hasMother   exstaff:frances .

La propriété rdfs:range peut aussi servir à indiquer que la valeur d'une propriété est donnée par un littéral typé, comme expliqué à la section 2.4. Par exemple, si l'organisation example.org voulait indiquer que la propriété ex:age avait des valeurs du type de données XML Schema xsd:integer, elle écrirait les déclarations RDF suivantes :

ex:age   rdf:type     rdf:Property .
ex:age   rdfs:range   xsd:integer .

Le type de données xsd:integer est identifié par sa référence URI (la référence URI complète étant http://www.w3.org/2001/XMLSchema#integer). Cette référence URI peut être utilisée sans déclarer explicitement dans le schéma qu'elle identifie un type de données. Toutefois, il est souvent utile de déclarer explicitement qu'une référence URI donnée identifie un type de données. On peut le faire en utilisant la classe RDF Schema rdfs:Datatype. Pour déclarer que xsd:integer est un type de données, example.org pourrait écrire la déclaration RDF suivante :

xsd:integer   rdf:type   rdfs:Datatype .

Cette déclaration dit que xsd:integer est la référence URI d'un type de données (qui est censé conforme aux exigences des types de données RDF décrites dans [RDF-CONCEPTS]). Une telle déclaration ne constitue pas une définition de type de données, par exemple au sens où example.org définit un nouveau type de données. Il n'y a aucune méthode pour définir des types de données en RDF Schema. Comme noté à la section 2.4, les types de données sont définis hors de RDF (et de RDF Schema), et ils sont appelés dans les déclarations RDF par leurs références URI. Cette déclaration sert simplement à documenter l'existence du type de données et indiquer explicitement son utilisation dans ce schéma.

La propriété rdfs:domain sert à indiquer qu'une propriété particulière s'applique à une classe désignée. Par exemple, si l'organisaiton example.org voulait indiquer que la propriété ex:author s'applique aux instances de la classe ex:Book, elle écrirait les déclarations RDF suivantes :

ex:Book     rdf:type      rdfs:Class .
ex:author   rdf:type      rdf:Property .
ex:author   rdfs:domain   ex:Book .

Ces déclarations indiquent que ex:Book est une classe, que ex:author est une propriété, et que les déclarations RDF utilisant la propriété ex:author ont des instances de ex:Book pour sujets.

Une propriété donnée, disons exterms:weight, peut avoir zéro, une ou plusieurs propriétés de domaine (domain property). Si exterms:weight n'a aucune propriété de domaine, c'est que rien n'est dit à propos des ressources avec lesquelles on peut utiliser des propriétés exterms:weight (toute ressource pourrait avoir une propriété exterms:weight). Si exterms:weight a une propriété de domaine, disons une définissant ex:Book comme domaine, cela dit que la propriété exterms:weight s'applique aux instances de la classe ex:Book. Si exterms:weight a plusieurs propriété de domaine, disons une définissant ex:Book pour domaine et une autre définissant ex:MotorVehicle pour domaine, cela dit que toute ressource qui a une propriété exterms:weight est une instance de l'ensemble des classes définies comme domaines, c'est-à-dire que toute ressource qui a une propriété exterms:weight est à la fois une instance ex:Book et une instance ex:MotorVehicle (ce qui illustre la nécessité d'être prudent dans la définition des domaines et des images).

exterms:weight   rdfs:domain   ex:Book .
exterms:weight   rdfs:domain   ex:MotorVehicle .

exthings:companyCar   exterms:weight   "2500"^^xsd:integer .

L'utilisation de ces descriptions d'image et de domaine peuvent être illustrées en étendant le schéma de véhicule, en ajoutant les deux propriétés ex:registeredTo et ex:rearSeatLegRoom, une nouvelle classe ex:Person et en décrivant explicitement le type de données xsd:integer. La propriété ex:registeredTo s'applique à tout ex:MotorVehicle et sa valeur est une instance de ex:Person. Pour les besoins de cet exemple, la propriété ex:rearSeatLegRoom ne s'applique qu'aux instances de la classe ex:PassengerVehicle. La valeur est un entier xsd:integer qui donne le nombre de centimètres de l'emplacement pour les jambes du siège arrière (rear seat legroom). Ces descriptions sont montrées en exemple 26 :

<rdf:Property rdf:ID="registeredTo">
  <rdfs:domain rdf:resource="#MotorVehicle"/>
  <rdfs:range rdf:resource="#Person"/>
</rdf:Property>

<rdf:Property rdf:ID="rearSeatLegRoom">
  <rdfs:domain rdf:resource="#PassengerVehicle"/> 
  <rdfs:range rdf:resource="&xsd;integer"/>
</rdf:Property>

<rdfs:Class rdf:ID="Person"/>

<rdfs:Datatype rdf:about="&xsd;integer"/>

Notez que l'on n'utilise pas d'élément <rdf:RDF> dans l'exemple 26, parce que ce RDF/XML est censé s'ajouter au schéma de véhicule décrit en exemple 24. Cette même supposition permet également d'utiliser des références URI relatives comme #MotorVehicle pour appeler d'autres classes de ce schéma.

RDF Schema permet de spécialiser les propriétés ainsi que les classes. Cette relation de spécialisation entre deux propriétés est décrite en utilisant la propriété prédéfinie rdfs:subPropertyOf. Par exemple, si ex:primaryDriver et ex:driver sont toutes deux des propriétés, example.org pourrait décrire ces propriétés et le fait que ex:primaryDriver est une spéicialisation de ex:driver en écrivant les déclarations RDF suivantes :

ex:driver          rdf:type             rdf:Property .
ex:primaryDriver   rdf:type             rdf:Property .
ex:primaryDriver   rdfs:subPropertyOf   ex:driver .

La signification de cette relation rdfs:subPropertyOf est que si une instance exstaff:fred est un conducteur principal (ex:primaryDriver) de l'instance ex:companyVan, alors RDF Schema définit exstaff:fred comme étant également un conducteur (ex:driver) de ex:companyVan. La syntaxe RDF/XML décrivant ces propriétés (en supposant encore une fois qu'elle s'ajoute au schéma de véhicule décrit en exemple 24) est montrée en exemple 27.

<rdf:Property rdf:ID="driver">
  <rdfs:domain rdf:resource="#MotorVehicle"/>
</rdf:Property>

<rdf:Property rdf:ID="primaryDriver">
  <rdfs:subPropertyOf rdf:resource="#driver"/>
</rdf:Property>

Une propriété peut être une sous-propriété de zéro, une ou plusieurs propriétés. Toutes les propriétés RDF Schema rdfs:range et rdfs:domain qui s'appliquent à une propriété RDF s'appliquent aussi à ses sous-propriétés. Ainsi, dans l'exemple précédent, RDF Schema définit ex:primaryDriver comme ayant aussi un rdfs:domain de ex:MotorVehicle, du fait de sa relation de sous-propriété à ex:driver.

L'exemple 28 montre le RDF/XML du schéma de véhicule complet, contenant toutes les descriptions données jusqu'ici :

<?xml version="1.0"?>
<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>
<rdf:RDF   
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"  
  xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
  xml:base="http://example.org/schemas/vehicles">

<rdfs:Class rdf:ID="MotorVehicle"/>

<rdfs:Class rdf:ID="PassengerVehicle">
  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdfs:Class>

<rdfs:Class rdf:ID="Truck">
  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdfs:Class>

<rdfs:Class rdf:ID="Van">
  <rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdfs:Class>

<rdfs:Class rdf:ID="MiniVan">
  <rdfs:subClassOf rdf:resource="#Van"/>
  <rdfs:subClassOf rdf:resource="#PassengerVehicle"/>
</rdfs:Class>

<rdfs:Class rdf:ID="Person"/>

<rdfs:Datatype rdf:about="&xsd;integer"/>

<rdf:Property rdf:ID="registeredTo">
  <rdfs:domain rdf:resource="#MotorVehicle"/>
  <rdfs:range rdf:resource="#Person"/>
</rdf:Property>

<rdf:Property rdf:ID="rearSeatLegRoom">
  <rdfs:domain rdf:resource="#PassengerVehicle"/> 
  <rdfs:range rdf:resource="&xsd;integer"/>
</rdf:Property>

<rdf:Property rdf:ID="driver">
  <rdfs:domain rdf:resource="#MotorVehicle"/>
</rdf:Property>

<rdf:Property rdf:ID="primaryDriver">
  <rdfs:subPropertyOf rdf:resource="#driver"/>
</rdf:Property>

</rdf:RDF>

Ayant montré comment décrire des classes et des propriétés utilisant RDF Schema, nous pouvons maintenant illustrer des instances utilisant ces classes et propriétés. Ainsi, l'exemple 29 décrit une instance de la classe ex:PassengerVehicle décrite en exemple 28, avec des valeurs hypothétiques pour ses propriétés.

<?xml version="1.0"?>
<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
            xmlns:ex="http://example.org/schemas/vehicles#"
            xml:base="http://example.org/things">

  <ex:PassengerVehicle rdf:ID="johnSmithsCar">
       <ex:registeredTo rdf:resource="http://www.example.org/staffid/85740"/>
       <ex:rearSeatLegRoom 
           rdf:datatype="&xsd;integer">127</ex:rearSeatLegRoom>
       <ex:primaryDriver rdf:resource="http://www.example.org/staffid/85740"/>
  </ex:PassengerVehicle>
</rdf:RDF>

Notez que l'on peut utiliser une propriété ex:registeredTo pour décrire cette instance de ex:PassengerVehicle, parce que ex:PassengerVehicle est une sous-classe de ex:MotorVehicle. Notez aussi que l'on utilise un littéral typé en valeur de la propriété ex:rearSetLegRoom dans cette instance plutôt qu'un littéral ordinaire (c'est-à-dire plutôt que de déclarer la valeur par <ex:rearSeatLegRoom>127</ex:rearSeatLegRoom>). Comme le schéma décrit l'image de cette propriété comme étant de type xsd:integer, la valeur de la propriété devrait être un littéral typé de ce type de données pour correspondre à la description d'image (car la déclaration d'image n'« affecte » pas automatiquement un type de données à un littéral ordinaire, et on doit donc fournir explicitement un littéral typé du type de données approprié). D'autres informations auraient également put être fournies, soit dans le schéma, soit dans des données d'instance supplémentaires, pour indiquer explicitement l'unité de la propriété ex:rearSetLegRoom (centimètres), comme expliqué en section 4.4.

5.3 Interpréter les déclarations RDF Schema

Comme noté précédemment, le système de types RDF Schema est semblable à certains égards aux systèmes de types de langages de programmation orientée objet comme Java. Par contre, RDF diffère de la plupart des systèmes de types de langage de programmation sur plusieurs points importants.

Une différence importante est qu'au lieu de décrire une classe comme ayant un ensemble de propriétés spécifiques, un schéma RDF décrit les propriétés comme s'appliquant à des classes spécifiques de ressources, en utilisant les propriétés domain et range. Par exemple, un langage de programmation orientée objet typique définirait une classe Book avec un attribut appelé author ayant des valeurs de type Person. Un schéma RDF correspondant décrirait une classe ex:Book et, dans une description séparée, une propriété ex:author ayant un domaine de ex:Book et une image de ex:Person.

La différence entre ces approches peut sembler n'être que syntaxique mais en fait elle est importante. Dans la description de classe du langage de programmation, l'attribut author fait partie de la description de la classe Book et s'applique seulement aux instance de la classe Book. Une autre classe (disons softwareModule) pourrait aussi avoir un attribut appelé author, mais il serait considéré comme un attribut différent. En d'autres termes, la portée (scope) d'une description d'attribut dans la plupart des langages de programmation se limite à la classe ou au type où l'attribut est défini. En RDF, au contraire, les descriptions de propriétés sont par défaut indépendantes des définitions de classes et ont par défaut une portée globale (quoiqu'on puisse en option les déclarer ne s'appliquer qu'à certaines classes par des définitions de domaines).

En conséquence, un schéma RDF pourrait décrire une propriété exterms:weight sans qu'un domaine ne soit défini. Cette propriété pourrait alors servir à décrire des instances de toute classe qui aurait besoin d'un poids. Un avantage de l'approche fondée sur les propriétés de RDF est qu'il devient plus facile d'étendre l'utilisation des définitions de propriétés à des situations qui n'auraient pas été envisagées dans la description originale. En même temps, c'est un  «avantage » à faire valoir avec précaution, pour s'assurer de ne pas employer à mauvais escient les propriétés dans des situations inappropriées.

Une autre conséquence de la portée globale des descriptions de propriétés RDF est qu'il n'est pas possible dans un schéma RDF de définir une propriété spécifique comme ayant localement des images différentes en fonction de la classe de la ressource à laquelle elle s'applique. Par exemple, en définissant la propriété ex:hasParent, il aurait été souhaitable de pouvoir dire que si la propriété servait à décrire une ressource de la classe ex:Human, alors l'image de la propriété est aussi une ressource de la classe ex:Human, tandis que si elle servait à décrire une ressource de la classe ex:Tiger, alors l'image est aussi une ressource de la classe ex:Tiger. Ce genre de définition est impossible en RDF Schema. Au contraire, toute image définie pour une propriété RDF s'applique à toutes les utilisations de la propriété, et on devrait donc définir les images avec précautions. En revanche, bien que de telles images localement différentes ne puissent pas être définies en RDF Schema, elles peuvent l'être dans certains des langages de schéma enrichis abordés à la section 5.5.

Une autre différence importante est que les descriptions RDF Schema ne sont pas nécessairement normatives (prescriptive) comme le sont typiquement les déclarations de types des langages de programmation. Par exemple, si un langage de programmation déclare une classe Book avec un attribut author ayant des valeurs de type Person, on l'interprète habituellement comme un groupe de contraintes. Le langage n'autorisera pas la création d'une instance de Book sans attribut author, et il n'autorisera pas d'instance de Book avec un attribut qui n'aura pas pour valeur un type Person. De plus, author est le seul attribut défini pour la classe Book, le langage n'autorisera pas d'instance de Book avec un autre attribut.

Au contraire, RDF Schema fournit les informations de schéma comme des descriptions supplémentaires des ressources, mais ne prescrit pas comment une application devrait utiliser ces descriptions. Par exemple, supposons qu'un schéma RDF déclare qu'une propriété ex:author a une image (rdfs:range) de classe ex:Person. C'est simplement une déclaration RDF selon laquelle les déclarations RDF contenant des propriétés ex:author ont pour objets des instances de ex:Person.

Cette information fournie par le schéma pourrait être utilisée de façons différentes. Une application pourrait interpréter cette déclaration comme définissant une partie d'un modèle pour les données RDF qu'elle crée et l'utiliser pour s'assurer que toute propriété ex:author a une valeur de la classe indiquée (ex:Person). C'est-à-dire que cette application interprète la description du schéma comme une contrainte de la même façon que le ferait un langage de programmation. Au contraire, une autre application pourrait interpréter cette déclaration comme fournissant une information supplémentaire à propos des données qu'elle reçoit, une information qui n'était peut-être pas fournie explicitement dans les données originales. Par exemple, cette deuxième application pourrait recevoir des données RDF incluant une propriété ex:author dont la valeur est une ressource d'une classe non définie, et utiliser cette déclaration fournie par le schéma pour conclure que la ressource doit être une instance de la classe ex:Person. Une troisième application pourrait recevoir des données RDF incluant une propriété ex:author dont la valeur est une ressource de la classe ex:Corporation, et utiliser cette information du schéma comme fondement d'une alerte selon laquelle « il peut y avoir une incohérence ici mais d'un autre côté peut-être pas ». Quelque part ailleurs, il peut y avoir une déclaration qui résolve l'incohérence apparente (par exemple une déclaration selon laquelle « une entreprise (Corporation) est une personne (Person) morale »).

En outre, selon la manière dont l'application interprète les descriptions de propriétés, une description d'une instance serait considérée comme étant légale soit sans certaines propriétés définies par le schéma (par exemple, il pourrait y avoir une instance de ex:Book sans propriété ex:author, même si la propriété ex:author est décrite comme ayant un domaine de ex:Book), soit avec des propriétés supplémentaires (il pourrait y avoir une instance de ex:Book avec une propriété ex:technicaleditor, même si le schéma décrivant la classe ex:Book ne décrit pas une telle propriété).

En d'autres termes, les déclarations dans un schéma RDF sont toujours des descriptions. Elles peuvent aussi être normatives (introduire des contraintes), mais seulement si l'application qui les interprète veut les traiter ainsi. Tout ce que fait RDF Schema est de fournir un moyen d'énoncer cette information supplémentaire. Que cette information entre en conflit avec les données d'instance définies explicitement, c'est à l'application de le déterminer et d'agir en conséquence.

5.4 Autres informations de schéma

RDF Schema offre plusieurs propriétés natives, qui peuvent être utilisées pour fournir une documentation et d'autres informations à propos d'un schéma RDF ou à propos d'instances. Ainsi, la propriété rdfs:comment peut servir à fournir une description intelligible (human-readable) d'une ressource. La propriété rdfs:label peut servir a fournir une version plus intelligible du nom d'une ressource. La propriété rdfs:seeAlso peut servir à indiquer une ressource susceptible de fournir des informations supplémentaires à propos de la ressource sujet. La propriété rdfs:isDefinedBy est une sous-propriété de rdfs:seeAlso et elle peut servir à indiquer une ressource qui (dans un sens non défini par RDF, par exemple la ressource n'est peut-être pas un schéma RDF) « définisse » la ressource sujet. Veuillez consulter la spécification du langage de description de vocabulaire RDF 1.0 : RDF Schema [RDF-VOCABULARY] pour une explication approfondie de ces propriétés.

Comme pour nombre de propriétés RDF natives telles que rdf:value, les utilisations décrites pour ces propriétés RDF Schema sont seulement leurs utilisations prévues. [RDF-SEMANTICS] ne définit pas de significations spéciales pour ces propriétés et RDF Schema ne définit pas de contraintes fondées sur ces utilisations prévues. Par exemple, aucune contrainte n'est définie selon laquelle l'objet d'une propriété rdfs:seeAlso doive fournir des informations supplémentaires à propos du sujet de la déclaration dans laquelle elle apparaît.

5.5 Langages de schéma enrichis

RDF Schema fournit des capacités de base pour décrire des vocabulaires RDF mais des capacités supplémentaires sont également possibles et peuvent être utiles. Ces capacités peuvent être fournies au travers d'un développement plus avant de RDF Schema, ou dans d'autres langages fondés sur RDF. D'autres capacités de schémas enrichis dont l'utilité est avérée (mais qui ne sont pas fournies par RDF Schema) comprennent :

• les contraintes de cardinalité sur les propriétés, par exemple qu'une personne (Person) a exactement un seul père biologique ;
• l'indication qu'une propriété donnée (telle que ex:hasAncestor) est transitive, par exemple que si A a pour ancêtre (ex:hasAncestor) B, et que B a pour ancêtre C, alors A a pour ancêtre C ;
• l'indication qu'une propriété donnée est un identificateur unique (ou une clé) pour les instances d'une classe particulière ;
• l'indication que deux classes différentes (ayant des références URI différentes) représentent en fait la même classe ;
• l'indication que deux instances différentes (ayant des références URI différentes) représentent en fait le même individu ;
• l'indication de contraintes sur l'image ou la cardinalité d'une propriété qui dépendent de la classe d'une ressource à laquelle s'applique une propriété, par exemple pouvoir dire que pour une équipe de football la propriété ex:hasPlayers a 11 valeurs, alors que pour une équipe de basketball la même propriété ne devrait avoir que 5 valeurs ;
• la possibilité de décrire de nouvelles classes en fonction de combinaisons (par exemple unions et intersections) d'autres classes, ou de dire que deux classes sont disjointes (c'est-à-dire qu'aucune ressource est une instance de deux classes).

Les capacités supplémentaires mentionnées ci-dessus, en plus des autres, sont les cibles des langages d'ontologies tels que DAML+OIL [DAML+OIL] et OWL [OWL]. Ces deux langages sont fondés sur RDF et RDF Schema (et offrent déjà la totalité desdites capacités supplémentaires). Le but de tels langages est de fournir une sémantique supplémentaire pour les ressources, exploitable par machine, à savoir de faire que les représentations machines des ressources ressemblent plus étroitement à leurs contreparties souhaitées dans le monde réel. Quoique ces capacités ne soient pas forcément nécessaires pour construire des applications utiles en RDF (cf. la section 6 pour une description de plusieurs applications RDF existantes), le développement de tels langages est un thème de travail très actif dans le développement du Web sémantique.

6.1 Dublin Core Metadata Initiative

Les métadonnées sont des données à propos de données. Spécifiquement, le terme renvoie aux données utilisées pour identifier, décrire ou localiser des ressources d'information, qu'il s'agisse de ressources physiques ou électroniques. Quoique le traitement de métadonnées structurées par des ordinateurs soit relativement récent, le concept de base des métadonnées est utilisé depuis de nombreuses années pour faciliter la gestion et la manipulation de grands ensembles d'information. Les catalogues sur fiches (card catalogs) des bibliothèques sont un exemple connu de telles métadonnées.

Le Dublin Core est un jeu d'« éléments » (des propriétés) pour décrire les documents (et donc pour enregistrer des métadonnées). Le jeu d'éléments a été développé au départ lors de l'atelier sur les métadonnées de mars 1995 à Dublin, Ohio. Le Dublin Core a été modifié ensuite dans le cadre d'autres ateliers sur les métadonnées Dublin Core, et il est actuellement suivi par l'initiative Dublin Core Metadata Initiative. L'objectif du Dublin Core est d'offrir un jeu minimal d'éléments descriptifs qui facilitent la description et l'indexation automatisée d'objets en réseau de type document, de manière similaire à un catalogue de fiches d'une bibliothèque. Le jeu de métadonnées Dublin Core est destiné à être utilisé par les outils de découverte des ressources sur Internet, tels que les « robots indexeurs » employés par les moteurs de recherche populaires du Web. De plus, le Dublin Core est suffisamment simple pour être compris et utilisé par la grande variété des auteurs et des éditeurs ponctuels qui fabriquent de l'information pour Internet. Les éléments Dublin Core sont couramment utilisés pour documenter les ressources Internet (l'élément creator Dublin Core a déjà été utilisé dans les exemples précédents). Les éléments courants du Dublin Core sont définis dans le Jeu de métadonnées Dublin Core version 1.1 — Description de référence [DC], qui comprend les définitions de propriété suivantes :

• Title : un nom donné à la ressource ;
• Creator : une entité principalement responsable de la création du contenu de la ressource ;
• Subject : le thème du contenu de la ressource ;
• Description : un compte-rendu du contenu de la ressource ;
• Publisher : une entité responsable de la mise à disposition de la ressource ;
• Contributor : une entité responsable qui a contribué au contenu de la ressource ;
• Date : une date associée à un événement dans le cycle de vie de la ressource ;
• Type : la nature ou le type du contenu de la ressource ;
• Format : la manifestation physique ou numérique de la ressource ;
• Identifier : une référence univoque à la ressource dans un contexte donné ;
• Source : une référence à une ressource dont dérive la ressource présente ;
• Language : une langue du contenu intellectuel de la ressource ;
• Relation : une référence à une ressource liée ;
• Coverage : l'étendue ou la portée du contenu de la ressource ;
• Rights : un information à propos des droits détenus dans et sur la ressource.

Les informations utilisant les éléments Dublin Core peuvent être représentées dans un langage approprié (par exemple, dans les éléments HTML meta). Toujours est-il, RDF est une représentation idéale pour l'information Dublin Core. Les exemples suivants représentent la description simple d'un ensemble de ressources en RDF en utilisant le vocabulaire Dublin Core. Notez que le vocabulaire RDF du Dublin Core montré ici n'a pas de vocation officielle. La description de référence Dublin Core [DC] est la référence officielle.

Le premier exemple (exemple 30) décrit la page d'accueil d'un site web en utilisant des propriétés Dublin Core :

<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.dlib.org">
      <dc:title>D-Lib Program - Research in Digital Libraries</dc:title>
      <dc:description>The D-Lib program supports the community of people
       with research interests in digital libraries and electronic
       publishing.</dc:description>
      <dc:publisher>Corporation For National Research Initiatives</dc:publisher>
      <dc:date>1995-01-07</dc:date>
      <dc:subject>
        <rdf:Bag>
          <rdf:li>Research; statistical methods</rdf:li>
          <rdf:li>Education, research, related topics</rdf:li>
          <rdf:li>Library use Studies</rdf:li>
        </rdf:Bag>
      </dc:subject>
      <dc:type>World Wide Web Home Page</dc:type>
      <dc:format>text/html</dc:format>
      <dc:language>en</dc:language>
    </rdf:Description>
</rdf:RDF>

Notez que RDF comme Dublin Core définissent un élément (XML) appelé « Description » (quoique l'élément Dublin Core s'écrive tout en minuscules). Même si la lettre initiale était en majuscule, le mécanisme d'espace de noms XML permettrait de distinguer les deux éléments (l'un étant rdf:Description et l'autre dc:description). Également, pour satisfaire sa curiosité, l'accès à http://purl.org/dc/elements/1.1/ (l'adresse URI d'espace de noms utilisée ici pour identifier le vocabulaire Dublin Core) dans un navigateur Web (au moment de la rédaction) récupérera une déclaration RDF Schema pour [DC].

Le deuxième exemple (exemple 31) décrit un magazine publié :

<rdf:RDF
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:dcterms="http://purl.org/dc/terms/">
    <rdf:Description rdf:about="http://www.dlib.org/dlib/may98/05contents.html">
      <dc:title>DLIB Magazine - The Magazine for Digital Library Research
        - May 1998</dc:title>
      <dc:description>D-LIB magazine is a monthly compilation of
       contributed stories, commentary, and briefings.</dc:description>
      <dc:contributor>Amy Friedlander</dc:contributor>
      <dc:publisher>Corporation for National Research Initiatives</dc:publisher>
      <dc:date>1998-01-05</dc:date>
      <dc:type>electronic journal</dc:type>
      <dc:subject>
        <rdf:Bag>
          <rdf:li>library use studies</rdf:li>
          <rdf:li>magazines and newspapers</rdf:li>
        </rdf:Bag>
      </dc:subject>
      <dc:format>text/html</dc:format>
      <dc:identifier rdf:resource="urn:issn:1082-9873"/>
      <dcterms:isPartOf rdf:resource="http://www.dlib.org"/>
    </rdf:Description>
 </rdf:RDF>

L'exemple 31 utilise (à la troisième ligne en partant du bas) le qualificatif (qualifier) isPartOf, d'un vocabulary séparé, pour indiquer que ce magazine « fait partie » du site décrit précédemment.

Le troisième exemple (exemple 32) décrit un article spécifique du magazine de l'exemple 31.

<rdf:RDF
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:dcterms="http://purl.org/dc/terms/">
    <rdf:Description rdf:about="http://www.dlib.org/dlib/may98/miller/05miller.html">
      <dc:title>An Introduction to the Resource Description Framework</dc:title>
      <dc:creator>Eric J. Miller</dc:creator>
      <dc:description>The Resource Description Framework (RDF) is an
       infrastructure that enables the encoding, exchange and reuse of
       structured metadata. rdf is an application of xml that imposes needed
       structural constraints to provide unambiguous methods of expressing
       semantics. rdf additionally provides a means for publishing both
       human-readable and machine-processable vocabularies designed to
       encourage the reuse and extension of metadata semantics among
       disparate information communities. the structural constraints rdf
       imposes to support the consistent encoding and exchange of
       standardized metadata provides for the interchangeability of separate
       packages of metadata defined by different resource description
       communities. </dc:description>
      <dc:publisher>Corporation for National Research Initiatives</dc:publisher>
      <dc:subject>
        <rdf:Bag>
          <rdf:li>machine-readable catalog record formats</rdf:li>
          <rdf:li>applications of computer file organization and
           access methods</rdf:li>
        </rdf:Bag>
      </dc:subject>
      <dc:rights>Copyright © 1998 Eric Miller</dc:rights>
      <dc:type>Electronic Document</dc:type>
      <dc:format>text/html</dc:format>
      <dc:language>en</dc:language>
      <dcterms:isPartOf rdf:resource="http://www.dlib.org/dlib/may98/05contents.html"/>
    </rdf:Description>
</rdf:RDF>

L'exemple 32 utilise également le qualificatif isPartOf, cette fois pour indiquer que l'article « fait partie » du magazine décrit précédemment.

<?xml version="1.0"?>
<svg width="4in" height="3in" version="1.1"
    xmlns = 'http://www.w3.org/2000/svg'>
    <desc xmlns:myfoo="http://example.org/myfoo">
      <myfoo:title>This is a financial report</myfoo:title>
      <myfoo:descr>The global description uses markup from the
        <myfoo:emph>myfoo</myfoo:emph> namespace.</myfoo:descr>
      <myfoo:scene><myfoo:what>widget $growth</myfoo:what>
      <myfoo:contains>$three $graph-bar</myfoo:contains>
        <myfoo:when>1998 $through 2000</myfoo:when> </myfoo:scene>
   </desc>
    <metadata>
      <rdf:RDF
           xmlns:rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
           xmlns:rdfs = "http://www.w3.org/2000/01/rdf-schema#"
           xmlns:dc = "http://purl.org/dc/elements/1.1/" >
        <rdf:Description rdf:about="http://example.org/myfoo"
             dc:title="MyFoo Financial Report"
             dc:description="$three $bar $thousands $dollars $from 1998 $through 2000"
             dc:publisher="Example Organization"
             dc:date="2000-04-11"
             dc:format="image/svg+xml"
             dc:language="en" >
          <dc:creator>
            <rdf:Bag>
              <rdf:li>Irving Bird</rdf:li>
              <rdf:li>Mary Lambert</rdf:li>
            </rdf:Bag>
          </dc:creator>
        </rdf:Description>
      </rdf:RDF>
    </metadata>
</svg>

6.2 PRISM

PRISM — Publishing Requirements for Industry Standard Metadata [PRISM] est une spécification de métadonnées développée dans l'industrie de l'édition. Les éditeurs de magazines et leurs vendeurs ont formé le groupe de travail PRISM pour identifier les besoins de l'industrie en métadonnées et définir une spécification pour les satisfaire. Les éditeurs veulent utiliser le contenu existant de plusieurs façons afin d'accroître le retour sur l'investissement consenti pour le créer. Convertir des articles de magazines en HTML pour une publication sur le Web en est un exemple. Octroyer des licences à des agrégateurs comme LexisNexis en est un autre. Ce sont toutes des « utilisations premières » du contenu ; typiquement, elles entrent toutes en service au moment où le magazine est en kiosque. Les éditeurs veulent également que leurs contenus soient « persistants ». Ils pourraient servir dans les nouveaux numéros, tels que dans un article rétrospectif. Ils pourraient être utilisés par d'autres services de l'entreprise, tel que dans un livre compilé à partir des photos, des recettes, etc. du magazine. Une autre utilisation serait de le licencier à des tiers, pour une réimpression d'un banc d'essai de produits, ou pour une rétrospective produite par un éditeur différent. Cet objectif global impose une approche des métadonnées qui se concentre sur la découverte (discovery), le suivi des droits (rights tracking) et les métadonnées de bout en bout (end-to-end metadata).

Découverte — La découverte est un terme général pour la détection d'un contenu qui englobe la recherche, la navigation, la circulation du contenu et d'autres techniques. Les discussions sur la découverte portent fréquemment sur un consommateur explorant un site web public. Néanmoins, la découverte d'un contenu revêt un sens beaucoup plus large que ça. Le public peut consister en consommateurs, ou en utilisateurs internes tels que des documentalistes (researchers), des dessinateurs, des photographes éditeurs, des agents de concession de licence, etc. Pour aider la découverte, PRISM fournit des propriétés afin de décrire les thèmes, les formats, le genre, l'origine et les contextes d'une ressource. Il fournit aussi des méthodes pour catégoriser les ressources en utilisant plusieurs taxonomies de description de sujet (subject description taxonomies).

Suivi des droits — Les magazines contiennent souvent des documents sous licence de tiers. Les photos d'une agence photographique constituent le type le plus courant de documents sous licence, mais les articles, les encadrés (sidebars) et tous les autres types de contenu peuvent être couverts par des licences. Le simple fait de savoir si le contenu est concédé pour une utilisation ponctuelle, nécessite le paiement de redevances ou est la propriété exclusive de l'éditeur est une épreuve. PRISM fournit des éléments pour un suivi de base de tels droits. Un vocabulaire séparé définit dans la spécification PRISM gère la description des lieux, des dates et des industries où le contenu est ou non utilisable.

Métadonnées de bout en bout — La plupart des contenus publiés ont déjà des métadonnées créées pour eux. Malheureusement, lorsque le contenu passe d'un système à un autre, les métadonnées sont fréquemment écartées pour être recrées ensuite dans le processus de production à grands frais. PRISM vise à réduire ce problème en fournissant une indication utilisable à plusieurs stades au cours de la filière de production de contenu (content production pipeline). Une caractéristique importante de la spécification PRISM est son utilisation d'autres spécifications existantes. Plutôt que de créer quelque chose d'entièrement nouveau, le groupe a décidé d'utiliser autant que possible les spécifications existantes et de ne définir du nouveau qu'au besoin. Ainsi, la spécification PRISM utilise XML, RDF, Dublin Core ainsi que divers formats et vocabulaires ISO.

Une description PRISM peut simplement revêtir l'aspect de quelques propriétés Dublin Core avec des valeurs littérales ordinaires. L'exemple 34 décrit une photo en donnant une information de base à propos de son titre, du photographe, du format, etc.

<?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/"
         xml:lang="en-US">

 <rdf:Description rdf:about="http://travel.example.com/2000/08/Corfu.jpg">
  <dc:title>Walking on the Beach in Corfu</dc:title>
  <dc:description>Photograph taken at 6:00 am on Corfu with two models
  </dc:description>
  <dc:creator>John Peterson</dc:creator>
  <dc:contributor>Sally Smith, lighting</dc:contributor>
  <dc:format>image/jpeg</dc:format>
 </rdf:Description>
</rdf:RDF>

PRISM permet également d'augmenter le Dublin Core pour des descriptions plus détaillées. Les augmentations sont définies comme trois vocabulaires nouveaux, en général cités par les préfixes prism:, pcv: et prl:.

prism: — Ce préfixe se rapporte au vocabulaire principal PRISM, dont les termes utilisent le préfixe d'adresse URI http://prismstandard.org/namespaces/basic/1.0/. La plupart des propriétés dans ce vocabulaire sont des versions plus spécifiques de propriétés du Dublin Core. Par exemple, des propriétés plus spécifiques de dc:date sont fournies par des propriétés telles que prism:publicationTime, prism:releaseTime, prism:expirationTime, etc.

pcv: — Ce préfixe se rapporte au vocabulaire contrôlé PRISM (PRISM Controlled Vocabulary), dont les termes utilisent le préfixe d'adresse URI http://prismstandard.org/namespaces/pcv/1.0/. Actuellement, la pratique commune pour décrire le(s) sujet(s) d'un article est de fournir des mots-clés descriptifs. Malheureusement, des mots-clés simples ne font pas une grande différence pour le rendement (performance) de la récupération, du fait que des personnes différentes utiliseront des mots-clés différents [BATES96]. La bonne pratique est de coder les articles avec les termes de sujets d'un « vocabulaire contrôlé » (controlled vocabulary). Le vocabulaire devrait fournir autant de synonymes que possibles pour les termes qu'il contient. Les termes contrôlés fournissent ainsi un terrain de rencontre pour les mots-clés définis par le chercheur et l'indexeur. Le vocabulaire pcv fournit des propriétés pour définir les termes dans un vocabulaire, les relations entre les termes et les noms alternatifs des termes.

prl: — Ce préfixe se rapporte au vocabulaire du langage des droits PRISM (PRISM Rights Language), dont les termes utilisent le préfixe d'adresse URI http://prismstandard.org/namespaces/prl/1.0/. La gestion des droits numériques (Digital Rights Management) est un domaine qui vit un bouleversement considérable. Plusieurs langages de gestion des droits numériques ont été proposés mais aucun n'est clairement privilégié dans l'ensemble de l'industrie. Comme aucun choix clair n'était recommandé, le langage des droits PRISM (PRL) fut défini comme mesure temporaire. Il fournit des propriétés permettant de dire si l'on peut « utiliser » un élément ou non, en fonction de conditions temporelles, géographiques et industrielles. On pense que c'est un compromis 20/80 (80/20 trade-off) qui aidera les éditeurs à économiser de l'argent dans le suivi des droits. Il n'a pas pour vocation d'être un langage général des droits ou de permettre aux éditeurs d'appliquer automatiquement des limites aux consommations (consumer uses) du contenu.

PRISM utilise RDF à cause de ses facultés à traiter avec des descriptions de complexité variable. Actuellement, une bonne part des métadonnées utilise des valeurs de chaîne de caractères simples (littéraux ordinaires) telles que :

<dc:coverage>Greece</dc:coverage>

Avec le temps, les développeurs de PRISM prévoient des utilisations plus sophistiquées de la spécification PRISM, depuis des valeurs littérales simples vers des valeurs structurées. En réalité, on retrouve cette échelle des valeurs dans la situation actuelle. Des éditeurs utilisent déjà des vocabulaires contrôlés sophistiqués, d'autres utilisent à peine des mots-clés définis manuellement. Pour illustration, voici quelques exemples des différents types de valeurs attribuables à la propriété dc:coverage :

<dc:coverage>Greece</dc:coverage>

<dc:coverage rdf:resource="http://prismstandard.org/vocabs/ISO-3166/GR"/>

(à savoir, en utilisant soit un littéral ordinaire, soit une référence URI pour identifier le pays), et :

<dc:coverage>
  <pcv:Descriptor rdf:about="http://prismstandard.org/vocabs/ISO-3166/GR">
    <pcv:label xml:lang="en">Greece</pcv:label>
    <pcv:label xml:lang="fr">Grèce</pcv:label>
  </pcv:Descriptor>
</dc:coverage>

(en utilisant une valeur structurée pour fournir à la fois une référence URI et des noms en diverses langues).

Notez aussi qu'il existe des propriétés dont les significations sont similaires ou sont des sous-ensembles d'autres propriétés. Par exemple, on pourrait donner le sujet géographique d'une ressource avec :

<prism:subject>Greece</prism:subject>
<dc:coverage>Greece</dc:coverage>

ou :

<prism:location>Greece</prism:location>

Chacune de ces propriétés pourrait utiliser la valeur littérale simple ou une valeur structurée plus complexe. Une telle gamme de possibilités ne peut pas se décrire de façon adéquate par des définitions DTD ou même par les schémas XML plus récents. Bien que l'éventail des variations syntaxiques à traiter soit considérable, le modèle de graphe RDF a une structure simple : un ensemble de triplets. Il est beaucoup plus facile pour les programmes plus anciens de s'adapter à du contenu avec de nouvelles extensions, en traitant les métadonnées dans le domaine des triplets.

Cette section s'achève par deux derniers exemples. L'exemple 35 dit que l'image (.../Corfu.jpg) ne peut pas être utilisée (#none) dans l'industrie du tabac — code 21 dans la classification SIC (Standard Industrial Classifications).

<rdf:RDF xmlns:prism="http://prismstandard.org/namespaces/basic/1.0/"
         xmlns:prl="http://prismstandard.org/namespaces/prl/1.0/"
         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://travel.example.com/2000/08/Corfu.jpg">
  <dc:rights rdf:parseType="Resource"
         xml:base="http://prismstandard.org/vocabularies/1.0/usage.xml">
     <prl:usage rdf:resource="#none"/>
     <prl:industry rdf:resource="http://prismstandard.org/vocabs/SIC/21"/>
  </dc:rights>
 </rdf:Description>
</rdf:RDF>

L'exemple 36 dit que l'image de Corfou (Corfu) a été photographiée par l'employé 3845, plus connu sous le nom de John Peterson. Il dit aussi que la couverture géographique de la photo est la Grèce (Greece), ce qui est fait en fournissant non seulement un code issu d'un vocabulaire contrôlé mais une version en cache de l'information de ce terme dans le vocabulaire.

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:pcv="http://prismstandard.org/namespaces/pcv/1.0/"
         xmlns:dc="http://purl.org/dc/elements/1.1/"
         xml:base="http://travel.example.com/">

  <rdf:Description rdf:about="/2000/08/Corfu.jpg">
    <dc:identifier rdf:resource="/content/2357845" />
    <dc:creator>
      <pcv:Descriptor rdf:about="/emp3845">
        <pcv:label>John Peterson</pcv:label>
      </pcv:Descriptor>
    </dc:creator>
    <dc:coverage>
      <pcv:Descriptor
          rdf:about="http://prismstandard.org/vocabs/ISO-3166/GR">
        <pcv:label xml:lang="en">Greece</pcv:label>
        <pcv:label xml:lang="fr">Grece</pcv:label>
      </pcv:Descriptor>
    </dc:coverage>
  </rdf:Description>
</rdf:RDF>

6.3 XPackage

<?xml version="1.0"?>
<xpackage:description>
  <rdf:RDF>

    (la description des ressources individuelles se place ici)

  </rdf:RDF>
</xpackage:description>

<?xml version="1.0"?> 
<xpackage:description 
           xmlns:xpackage="http://xpackage.org/namespaces/2003/xpackage#"
           xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
           xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
           xmlns:dc="http://purl.org/dc/elements/1.1/"
           xmlns:mime="http://xpackage.org/namespaces/2003/mime#" 
           xmlns:x="http://xpackage.org/namespaces/2003/xml#"
           xmlns:xlink="http://www.w3.org/1999/xlink">  
    <rdf:RDF>

    <!--doc.html-->
    <rdf:Description rdf:about="urn:example:xhtmldocument-doc">
      <rdfs:comment>The XHTML document.</rdfs:comment>
      <xpackage:location xlink:href="doc.html"/>
      <mime:contentType>application/xhtml+xml</mime:contentType>
      <x:namespace rdf:resource="http://www.w3.org/1999/xhtml"/>
      <x:style rdf:resource="urn:example:xhtmldocument-stylesheet"/>
      <dc:creator>Garret Wilson</dc:creator>
      <xpackage:manifest rdf:parseType="Collection">
         <rdf:Description rdf:about="urn:example:xhtmldocument-stylesheet"/>
         <rdf:Description rdf:about="urn:example:xhtmldocument-image"/>
      </xpackage:manifest>
    </rdf:Description>

    </rdf:RDF> 
</xpackage:description>

<?xml version="1.0"?> 
<xpackage:description 
           xmlns:xpackage="http://xpackage.org/namespaces/2003/xpackage#"
           xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
           xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
           xmlns:dc="http://purl.org/dc/elements/1.1/"
           xmlns:mime="http://xpackage.org/namespaces/2003/mime#" 
           xmlns:x="http://xpackage.org/namespaces/2003/xml#"
           xmlns:xlink="http://www.w3.org/1999/xlink">  
    <rdf:RDF> 

    <!--stylesheet.css-->
    <rdf:Description rdf:about="urn:example:xhtmldocument-css">
      <rdfs:comment>The document style sheet.</rdfs:comment>
      <xpackage:location xlink:href="stylesheet.css"/>
      <mime:contentType>text/css</mime:contentType>
    </rdf:Description>

    </rdf:RDF> 
</xpackage:description>

6.4 RSS 1.0 : sommaire de site RDF

On a parfois besoin chaque jour de consulter une grande variété d'informations sur le Web, telles que des emplois du temps, des listes de choses à faire, des titres de l'actualité, des résultats de recherche, des « quoi de neuf », etc. Avec l'augmentation des sources d'information et sa diversité sur le Web, il devient de plus en plus difficile de gérer ces informations et de les intégrer en un tout cohérent. RSS 1.0 (RDF Site Summary) est un vocabulaire RDF qui fournit un moyen simple mais puissant de décrire l'information pour une diffusion et une réutilisation opportune à grande échelle. RSS 1.0 est peut-être aussi l'application RDF la plus répandue sur le Web.

Pour donner un exemple simple, la page d'accueil du W3C est un point de contact principal avec le public, et sert en partie à disséminer des informations à propos des produits livrables du Consortium. La figure 19 montre un exemple de cette page à une certaine date. La colonne centrale des nouveaux articles change fréquemment. Pour gérer la dissémination opportune des informations, l'Équipe du W3C a installé un fil de nouvelles (news feed) RSS (RSS 1.0) qui permet à d'autres de réutiliser le contenu de la colonne centrale comme ils l'entendent. Les sites de syndication de nouvelles peuvent réunir les manchettes (headlines) en un résumé des dernières nouvelles du jour, d'autres peuvent afficher les manchettes sous forme de liens en service à leurs lecteurs et, de plus en plus, des personnes peuvent s'abonner à ce fil avec une application bureautique. Ces lecteurs RSS (RSS readers) de bureau permettent à leurs utilisateurs de suivre potentiellement des centaines de sites sans devoir visiter chacun avec leur navigateur.

Figure 19 : La page d'accueil du W3C

De nombreux sites partout sur le Web offrent des fils RSS 1.0. L'exemple 40 montre le fil du W3C (d'une autre date) :

<?xml version="1.0" encoding="utf-8"?>

<rdf:RDF xmlns="http://purl.org/rss/1.0/"
    xmlns:dc="http://purl.org/dc/elements/1.1/" 
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">

  <channel rdf:about="http://www.w3.org/2000/08/w3c-synd/home.rss">
    <title>The World Wide Web Consortium</title>
    <description>Leading the Web to its Full Potential...</description>
    <link>http://www.w3.org/</link>

    <dc:date>2002-10-28T08:07:21Z</dc:date>

    <items>
        <rdf:Seq>
            <rdf:li rdf:resource="http://www.w3.org/News/2002#item164"/>
            <rdf:li rdf:resource="http://www.w3.org/News/2002#item168"/>
            <rdf:li rdf:resource="http://www.w3.org/News/2002#item167"/>
        </rdf:Seq>
    </items>

  </channel>

  <item rdf:about="http://www.w3.org/News/2002#item164">
    <title>User Agent Accessibility Guidelines Become a W3C 
       Proposed Recommendation</title>
    <description>17 October 2002: W3C is pleased to announce the 
       advancement of User Agent Accessibility Guidelines 1.0 to 
       Proposed Recommendation. Comments are welcome through 14 November. 
       Written for developers of user agents, the guidelines lower 
       barriers to Web accessibility for people with disabilities 
       (visual, hearing, physical, cognitive, and neurological). 
       The companion Techniques Working Draft is updated. Read about 
       the Web Accessibility Initiative. (News archive)</description>
    <link>http://www.w3.org/News/2002#item164</link>
    <dc:date>2002-10-17</dc:date>
  </item>

  <item rdf:about="http://www.w3.org/News/2002#item168">
    <title>Working Draft of Authoring Challenges for Device 
       Independence Published</title>
    <description>25 October 2002: The Device Independence 
       Working Group has released the first public Working Draft of 
       Authoring Challenges for Device Independence. The draft describes 
       the considerations that Web authors face in supporting access to 
       their sites from a variety of different devices. It is written 
       for authors, language developers, device experts and developers 
       of Web applications and authoring systems. Read about the Device 
       Independence Activity (News archive)</description>
    <link>http://www.w3.org/News/2002#item168</link>
    <dc:date>2002-10-25</dc:date>
  </item>

  <item rdf:about="http://www.w3.org/News/2002#item167">
    <title>CSS3 Last Call Working Drafts Published</title>
    <description>24 October 2002: The CSS Working Group has 
       released two Last Call Working Drafts and welcomes comments 
       on them through 27 November. CSS3 module: text is a set of 
       text formatting properties and addresses international contexts. 
       CSS3 module: Ruby is properties for ruby, a short run of text 
       alongside base text typically used in East Asia. CSS3 module: 
       The box model for the layout of textual documents in visual 
       media is also updated. Cascading Style Sheets (CSS) is a 
       language used to render structured documents like HTML and 
       XML on screen, on paper, and in speech. Visit the CSS home 
       page. (News archive)</description>
    <link>http://www.w3.org/News/2002#item167</link>
    <dc:date>2002-10-24</dc:date>
  </item>

</rdf:RDF>

Comme le montre l'exemple 40, le format est conçu pour du contenu qui peut être conditionné en sections aisément perceptibles. Qu'il s'agisse de sites de nouvelles, de journaux Web, de résultats sportifs, de cours de la bourse et autres, tous sont des scénarios pour RSS 1.0.

Le fil RSS peut être demandé par toute application capable de « parler » le HTTP. Quoiqu'il en soit, les applications RSS 1.0 se divisent depuis peu en trois catégories différentes :

• Les agrégateurs en ligne — Des sites tels que Meerkat et NewsIsFree, montrés côte-à-côte en figure 20 (chacun reproduisant (mirroring) la colonne des actualités du W3C). Ceux-ci rassemblent des fils de milliers de sources, distinguent chaque élément (<item>) et les réunissent à nouveau en un seul groupe élargi. Le groupe entier devient alors explorable. Ainsi, on peut alors chercher, par exemple, les dernières nouvelles à propos de « Java » dans des milliers de sites éventuellement, sans devoir tous les explorer ;
• Les lecteurs de bureau — Des utilitaires tels que Amphetadesk et NetNewsWire Lite permettent à leurs utilisateurs de s'abonner à des centaines de fils depuis leur bureau. Les lecteurs rafraîchissent habituellement chaque fil toutes les heures, permettant aux utilisateurs de rester informés ;
• Les scripts — Le but original de RSS était de permettre aux webmestres d'inclure le contenu d'un autre site au leur. RSS 1.0 est toujours utilisé de ce cette façon et de nombreux sites (par exemple Slashdot) incorporent des fils RSS à leur page d'accueil.

Figure 20 : MeerKat et NewsIsFree

RSS 1.0 est extensible par conception. En important des vocabulaires RDF supplémentaires (ou modules comme on les appelle dans la communauté du développement RSS), le créateur RSS 1.0 peut fournir une grande quantité de métadonnées et d'instructions de manipulation au destinataire du fichier. De même que les vocabulaires RDF plus généraux, n'importe qui peut écrire des modules. Il existe actuellement 3 modules officiels et 19 modules proposés reconnus sans difficulté par la communauté au sens large. Ces modules vont du module Dublin Core complet à des modules plus spécialisés axés sur RSS tels que le module Aggregation.

Il faudrait faire attention lorsqu'on parle de « RSS » dans le cadre de RDF. Il existe actuellement deux courants (strands) de spécification RSS : l'un n'utilise pas RDF (RSS 0.91, 0.92, 0.93, 0.94 et 2.0), l'autre l'utilise (RSS 0.9 et 1.0).

6.5 CIM/XML

Les centrales électriques (electric utilities) utilisent des modèles de système électrique (power system models) pour plusieurs raisons différentes. Par exemple, des simulations de systèmes électriques sont nécessaires pour la planification (planning) et l'analyse de sécurité informatique (security analysis). Des modèles de système électrique sont également utilisés en exploitation réelle, par exemple, par les systèmes de gestion d'énergie ou systèmes EMS (energy management systems) employés dans les postes de commande de l'énergie. Un modèle de système électrique opérationnel peut comprendre des milliers de classes d'information. Outre l'utilisation de ces modèles en interne, les centrales électriques ont besoin d'échanger des informations de modélisation de système (system modeling information), à la fois dans la planification et pour les besoins de l'exploitation, par exemple pour coordonner la transmission et assurer la fiabilité de l'exploitation. Toutefois, les centrales utilisent individuellement des logiciels différents pour ces besoins et par conséquent les modèles de système sont enregistrés dans des formats différents, en compliquant l'échange de ces modèles.

Afin de permettre l'échange de modèles de système électrique, les centrales devaient s'accorder sur des définitions communes des entités de système électrique et leurs relations. Pour cela, l'Electric Power Research Institute (EPRI), un consortium de recherche sur l'énergie à but non lucratif, a développé un modèle d'information commun ou modèle CIM (common information model) [CIM]. Le modèle CIM définit une sémantique commune pour les ressources de systèmes électriques, leurs attributs et leurs relations. En outre, pour permettre l'échange électronique des modèles CIM, l'industrie électrique a développé CIM/XML, un langage d'expression des modèles CIM en XML. CIM/XML est une application RDF, utilisant RDF et RDF Schema pour organiser ses structures XML. Le North American Electric Reliability Council (NERC), une organisation financée par l'industrie, fondée pour promouvoir la fiabilité de la distribution d'électricité en Amérique du nord, a adopté CIM/XML comme norme pour l'échange de modèles entre les exploitants des systèmes de transport de l'électricité (power transmission system operators). Le format CIM/XML est également examiné par l'IEC pour une normalisation internationale. On peut trouver une excellente présentation de CIM/XML dans [DWZ01]. [Nota bene : Il ne faut pas confondre ce modèle d'information commun de l'industrie électrique avec celui développé par le Distributed Management Task Force pour représenter l'information de gestion des environnements de calcul distribué (distributed software), de réseau et d'entreprise. Le modèle d'information commun DMTF possède une représentation XML mais n'utilise pas RDF pour l'instant, quoique des travaux indépendants en cours aillent en ce sens.]

Le modèle CIM peut représenter tous les objets majeurs d'une centrale électrique comme des classes d'objets et des attributs ainsi que leurs relations. Le modèle CIM utilise ces classes et attributs d'objets pour permettre l'intégration d'applications développées indépendamment entre les systèmes EMS spécifiques de fournisseurs, ou entre un système EMS et d'autres systèmes en rapport avec les divers aspects de l'exploitation d'un système électrique, tels que la gestion de la production ou de la distribution.

Le modèle CIM est défini comme un ensemble de diagrammes de classe en utilisant le langage de modélisation UML (Unified Modeling Language). La classe de base du modèle CIM est la classe PowerSystemResource, avec d'autres classes plus spécialisées telles que Substation, Switch et Breaker définies comme sous-classes. CIM/XML représente le modèle CIM comme un vocabulaire RDF Schema et utilise RDF/XML comme langage d'échange de modèles de système spécifiques. L'exemple 41 montre des définitions de classes et propriétés CIM/XML :

<rdfs:Class rdf:ID="PowerSystemResource"> 
  <rdfs:label xml:lang="en">PowerSystemResource</rdfs:label> 
  <rdfs:comment>"A power system component that can be either an
    individual element such as a switch or a set of elements 
    such as a substation. PowerSystemResources that are sets 
    could be members of other sets. For example a Switch is a 
    member of a Substation and a Substation could be a member 
    of a division of a Company"</rdfs:comment> 
</rdfs:Class>

<rdfs:Class rdf:ID="Breaker"> 
  <rdfs:label xml:lang="en">Breaker</rdfs:label> 
  <rdfs:subClassOf rdf:resource="#Switch" /> 
  <rdfs:comment>"A mechanical switching device capable of making, 
     carrying, and breaking currents under normal circuit conditions 
     and also making, carrying for a specified time, and breaking 
     currents under specified abnormal circuit conditions e.g. those 
     of short circuit. The typeName is the type of breaker, e.g., 
     oil, air blast, vacuum, SF6."</rdfs:comment> 
</rdfs:Class>

<rdf:Property rdf:ID="Breaker.ampRating"> 
   <rdfs:label xml:lang="en">ampRating</rdfs:label> 
   <rdfs:domain rdf:resource="#Breaker" /> 
   <rdfs:range rdf:resource="#CurrentFlow" /> 
   <rdfs:comment>"Fault interrupting rating in amperes"</rdfs:comment> 
</rdf:Property>

CIM/XML n'utilise qu'une partie (subset) de la syntaxe RDF/XML totale afin de simplifier l'expression des modèles. De plus, CIM/XML met en œuvre quelques extensions du vocabulaire RDF Schema. Ces extensions permettent la description des rôles symétriques (inverses roles) et des contraintes de multiplicité (cardinalité) pour indiquer combien d'instances d'une propriété donnée sont permises pour une ressource donnée (les valeurs permises pour une déclaration de multiplicité sont zéro ou un, exactement un, zéro ou plus, et un ou plus). Les propriétés dans l'exemple 42 illustrent ces extensions (qui sont identifiées par le préfixe de nom qualifié cims:) :

<rdf:Property rdf:ID="Breaker.OperatedBy"> 
   <rdfs:label xml:lang="en">OperatedBy</rdfs:label> 
   <rdfs:domain rdf:resource="#Breaker" /> 
   <rdfs:range rdf:resource="#ProtectionEquipment" /> 
   <cims:inverseRoleName rdf:resource="#ProtectionEquipment.Operates" /> 
   <cims:multiplicity rdf:resource="http://www.cim-logic.com/schema/990530#M:0..n" />
   <rdfs:comment>"Circuit breakers may be operated by 
       protection relays."</rdfs:comment>
</rdf:Property>

<rdf:Property rdf:ID="ProtectionEquipment.Operates"> 
   <rdfs:label xml:lang="en">Operates</rdfs:label> 
   <rdfs:domain rdf:resource="#ProtectionEquipment" /> 
   <rdfs:range rdf:resource="#Breaker" /> 
   <cims:inverseRoleName rdf:resource="#Breaker.OperatedBy" /> 
   <cims:multiplicity rdf:resource="http://www.cim-logic.com/schema/990530#M:0..n" />
   <rdfs:comment>"Circuit breakers may be operated by 
       protection relays."</rdfs:comment>
</rdf:Property>

L'EPRI a mené des tests d'interopérabilité réussis en utilisant CIM/XML pour échanger des modèles réels à grande échelle (engageant, en un seul test, des données décrivant plus de 2000 sous-stations) entre divers produits de vendeurs, et en validant l'interprétation correcte de ces modèles par des applications à usage général (utility applications). Bien que le modèle CIM ait été destiné au départ aux systèmes EMS, il est également étendu pour gérer la distribution d'électricité ainsi que d'autres applications.

L'Object Management Group a adopté un standard d'interface objet pour accéder aux modèles de système électrique CIM, appelée la méthode DAF (Data Access Facility) [DAF]. Comme le langage CIM/XML, la méthode DAF est fondée sur le modèle RDF et partage le même schéma CIM. Au contraire de CIM/XML qui permet d'échanger un modèle comme un document, la méthode DAF permet à une application d'accéder au modèle en tant qu'ensemble d'objets.

CIM/XML illustre le rôle utile que RDF peut jouer en permettant l'échange d'informations fondé sur XML qui s'exprime naturellement par des classes de relation d'entités ou orientées objets, des attributs et des relations (même si ces informations ne seront pas forcément accessibles par le Web). Dans ces cas, RDF fournit une structure de base pour le XML à l'appui d'identifier les objets et de les utiliser dans des relations structurées. Cette filiation est illustrée par nombre d'applications utilisant RDF/XML pour l'échange d'information, ainsi que par nombre de projets explorant les couplages (linkages) entre RDF (ou des langages d'ontologie tel OWL) et UML (et ses représentations XML). Le besoin qu'a CIM/XML d'étendre RDF Schema pour gérer les contraintes de cardinalité et les relations symétriques illustre également les types d'exigences qui ont conduit au développement de langages de schéma ou d'ontologie plus puissants fondés sur RDF tels que DAML+OIL et OWL décrits à la section 5.5. De tels langages seront peut-être appropriés pour gérer de nombreuses applications de modélisation similaires dans le futur.

Enfin, CIM/XML illustre également un fait important pour ceux cherchant d'autres exemples de « RDF sur le terrain » : parfois les langages sont décrits comme étant des langages « XML », ou les systèmes sont décrits comme utilisant « XML », et ce « XML » utilisé est en réalité du RDF/XML, c'est-à-dire qu'il s'agit d'applications RDF. Il est parfois nécessaire de fouiller très profondément dans la description du langage ou du système pour le découvrir (dans certains exemples trouvés, RDF n'est pas du tout mentionné explicitement mais les données en échantillon montre clairement qu'il s'agit de RDF/XML). De plus, dans des applications telles que CIM/XML, le RDF créé ne se trouvera pas facilement sur le Web puisqu'il est destiné à l'échange d'information entre des éléments de logiciel (software components) plutôt que pour un accès général (bien que l'on puisse imaginer des scénarios futurs dans lesquels une plus grande partie de ce type de RDF sera accessible par le Web).

6.6 Gene Ontology Consortium

Les métadonnées structurées utilisant des vocabulaires contrôlés tels que SNOMED RT (Systematized Nomenclature of Medicine Reference Terminology) et MeSH (Medical Subject Headings) jouent un rôle important en médecine, en autorisant des recherches bibliographiques plus efficaces et en aidant la diffusion et l'échange de connaissances médicales [COWAN]. Dans le même temps, le champs de la médecine évolue rapidement, et de ce fait il est nécessaire de développer des vovabulaires supplémentaires.

L'objectif du Gene Ontology (GO) Consortium [GO] est de fournir des vocabulaires contrôlés pour décrire les aspects spécifiques des produits génétiques. Les banques de données (databases) participantes annotent leurs produits génétiques (ou leurs gènes) avec des termes GO, en fournissant des références et en indiquant quel type de preuve vient à l'appui des annotations. L'emploi de termes GO communs par ces banques de données facilite les interrogations uniformes à travers toutes celles-ci. Les ontologies GO sont structurées de façon à permettre à la fois d'effectuer une attribution et une interrogation à différents degrés de granularité. Les vocabulaires GO sont dynamiques, puisque la connaissance des rôles des gènes et des protéines dans les cellules augmente et évolue.

Les trois principes d'organisation de l'ontologie génétique sont la fonction moléculaire, le processus biologique et le composant cellulaire. Un produit génétique a une ou plusieurs fonctions moléculaires et intervient dans un ou plusieurs processus biologiques ; il peut être, ou être associé à, un ou plusieurs composants cellullaires. Les définitions des termes dans chacune de ces trois ontologies sont contenues dans un seul fichier de définition (textuel). Les versions au format XML, contenant la totalité des trois fichiers d'ontologie et des définitions disponibles, sont générées chaque mois.

La fonction, le processus et le composant sont représentés par des graphes acycliques orientés (directed acyclic graphs) (DAG) ou des réseaux. Un sous-terme (child term) peut être une « instance » de son terme parent (relation isa) ou un composant de celui-ci (relation part-of). Un sous-terme peut avoir plusieurs termes parents et une classe de relation différente avec ses différents parents. Les synonymes et les références croisées vers les banques de données externes sont également représentés dans les ontologies. L'ontologie génétique utilise les fonctions RDF/XML pour représenter les relations entre les termes dans les versions XML des ontologies, à cause de sa flexibilité pour représenter ces structures de graphe et aussi de ses nombreux outils en appui (widespread tool support). Parallèlement, GO utilise actuellement des structures XML nichées non-RDF dans les descriptions de termes, et le langage employé n'est donc pas du pur RDF/XML.

L'exemple 43 montre un échantillon d'information GO issu de la documentation GO :

<?xml version="1.0" encoding="UTF-8"?> 
<!DOCTYPE go:go> 
<go:go xmlns:go="http://www.geneontology.org/xml-dtd/go.dtd#" 
       xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> 
  <go:version timestamp="Wed May 9 23:55:02 2001" /> 

  <rdf:RDF> 
     <go:term rdf:about="http://www.geneontology.org/go#GO:0003673"> 
        <go:accession>GO:0003673</go:accession> 
        <go:name>Gene_Ontology</go:name> 
        <go:definition></go:definition> 
     </go:term> 

     <go:term rdf:about="http://www.geneontology.org/go#GO:0003674"> 
        <go:accession>GO:0003674</go:accession> 
        <go:name>molecular_function</go:name> 
        <go:definition>The action characteristic of a gene product.</go:definition> 
        <go:part-of rdf:resource="http://www.geneontology.org/go#GO:0003673" /> 
        <go:dbxref> 
           <go:database_symbol>go</go:database_symbol> 
           <go:reference>curators</go:reference> 
        </go:dbxref> 
     </go:term> 

     <go:term rdf:about="http://www.geneontology.org/go#GO:0016209"> 
        <go:accession>GO:0016209</go:accession> 
        <go:name>antioxidant</go:name> 
        <go:definition></go:definition> 
        <go:isa rdf:resource="http://www.geneontology.org/go#GO:0003674" /> 
        <go:association> 
           <go:evidence evidence_code="ISS"> 
              <go:dbxref> 
                 <go:database_symbol>fb</go:database_symbol> 
                 <go:reference>fbrf0105495</go:reference> 
              </go:dbxref> 
           </go:evidence> 
           <go:gene_product> 
              <go:name>CG7217</go:name> 
              <go:dbxref> 
                 <go:database_symbol>fb</go:database_symbol> 
                 <go:reference>FBgn0038570</go:reference> 
              </go:dbxref> 
           </go:gene_product> 
        </go:association> 
        <go:association> 
           <go:evidence evidence_code="ISS"> 
              <go:dbxref> 
                 <go:database_symbol>fb</go:database_symbol> 
                 <go:reference>fbrf0105495</go:reference> 
              </go:dbxref> 
           </go:evidence> 
           <go:gene_product> 
              <go:name>Jafrac1</go:name> 
              <go:dbxref> 
                 <go:database_symbol>fb</go:database_symbol> 
                 <go:reference>FBgn0040309</go:reference> 
              </go:dbxref> 
           </go:gene_product> 
        </go:association> 
      </go:term> 
  </rdf:RDF> 
</go:go> 

L'exemple 43 illustre le fait que go:term est l'élément de base. Par endroits, l'ontologie génétique a défini ses propres termes au lieu d'utiliser RDF Schema. Par exemple, le terme GO:0016209 a l'élément <go:isa rdf:resource="http://www.geneontology.org/go#GO:0003674" />. Cette balise représente la relation « GO:0016209 isa GO:0003674 », ou en français « antioxydant (antioxidant) est une fonction moléculaire (molecular function) ». Une autre relation spécialisée est go:part-of. Par exemple, GO:0003674 a l'élément <go:part-of rdf:resource="http://www.geneontology.org/go#GO:0003673" />. Cela dit que « fonction moléculaire fait partie de l'ontologie génétique ».

Chaque annotation doit être attribuée à une source, laquelle peut être une référence bibliographique, une autre banque de données ou une analyse informatique (computational analysis). L'annotation doit indiquer quel type de preuve se trouve dans la source citée pour soutenir l'association entre le produit génétique et le terme GO. On utilise un vocabulaire contrôlé simple pour enregistrer la preuve. Les exemples comprennent :

• ISS signifie « inferred from sequence similarity [avec <database:sequence_id>] » ;
• IDA signifie « inferred from direct assay » ;
• TAS signifie « traceable author statement »

L'élément go:dbxref représente le terme dans une banque de données externe et go:association représente les associations de gène de chaque terme. go:association peut avoir à la fois go:evidence, qui contient un go:dbxref vers la preuve en appui de l'association, et un go:gene_product, qui contient le symbole du gène et go:dbxref. Ces éléments illustrent le fait que la syntaxe XML GO n'est pas du « pur » RDF/XML, puisque l'imbrication d'autres éléments dans ces éléments n'est pas conforme aux « entrelacements » d'arcs alternés nœud/prédicat décrits aux sections 2.1 et 2.2 de [RDF-SYNTAX].

L'ontologie génétique illustre plusieurs points intéressants. D'abord, elle montre qu'utiliser du XML pour l'échange d'information présente une valeur accrue en structurant ce XML avec RDF. C'est particulièrement vrai pour les données qui ont une structure de graphe ou de réseau globale plutôt que d'être des hiérarchies strictes. L'ontologie génétique GO est aussi un autre exemple de ce que les données utilisant RDF n'apparaîtront pas nécessairement en utilisation directe (bien que les fichiers soient accessibles par le Web). C'est aussi un autre exemple de données qui sont décrites, en surface, comme du XML mais qui, à mieux regarder, utilisent des fonctions RDF/XML (quoique du RDF/XML « frelaté »). Enfin, l'ontologie génétique illustre le rôle potentiel de RDF comme base pour représenter des ontologies. Ce rôle prendra de l'ampleur dès lors que des langages plus riches fondés sur RDF pour définir des ontologies, tels que les langages DAML+OIL ou OWL mentionnés en section 5.5, seront plus répandus. En fait, un projet intitulé Gene Ontology Next Generation développe actuellement une représentation des ontologies GO dans ces langages enrichis.

6.7 Décrire les capacités des appareils et les préférences des utilisateurs

Ces dernières années sont apparus un grand nombre de nouveaux appareils portables pour naviguer sur le Web. Beaucoup de ces appareils ont des capacités très divergentes dont un éventail très large de capacités d'entrée et de sortie ainsi que différents degrés de reconnaissance des langages. Les appareils portables peuvent aussi avoir des capacités de connectivité aux réseaux très différentes. Les utilisateurs de ces nouveaux appareils attendent une présentation utilisable indépendamment des capacités de l'appareil ou des caractéristiques du réseau courant. De plus, les utilisateurs souhaitent une prise en compte de leurs préférences à changement dynamique (par exemple couper ou mettre le son) lors de la présentation d'un contenu ou d'une application. Toujours est-il, l'hétérogénéité des appareils et l'absence d'une méthode normalisée permettant aux utilisateurs de communiquer leurs préférences au serveur peuvent se traduire en réalité par un contenu qui n'est pas stockable sur l'appareil, qui n'est pas affichable ou qui va à l'encontre des souhaits de l'utilisateur. En plus, le contenu final peut prendre trop longtemps à passer sur le réseau jusqu'à l'appareil client.

Une solution à ces problèmes est que le client code son contexte de livraison (delivery context), à savoir les capacités de l'appareil, les préférences de l'utilisateur, les caractéristiques du réseau, etc., afin que le serveur qui l'utilise puisse personnaliser le contenu pour l'appareil et l'utilisateur (cf. [DIPRINC] pour une définition du contexte de livraison). La spécification des profils composites de capacités/préférences (CC/PP) du W3C [CC/PP] aide à répondre à ce problème en définissant un cadre générique pour décrire un contexte de livraison.

Le cadre CC/PP définit une structure relativement simple : une hiérarchie de composants et de couples attribut/valeur à deux niveaux. On peut utiliser un composant (component) pour capturer une partie d'un contexte de livraison (par exemple les caractéristiques du réseau, les logiciels gérés par un appareil ou les caractéristiques matérielles d'un appareil). Un composant peut contenir un ou plusieurs attributs (attributes). Ainsi, un composant qui code les préférences de l'utilisateur pourra contenir un attribut pour indiquer si une sortie audio (AudioOutput) est souhaitée ou non.

CC/PP définit sa structure (la hiérarchie décrite ci-dessus) avec RDF Schema (cf. [CC/PP] pour le détail du schéma de structure). Un vocabulaire CC/PP définit des composants spécifiques et leurs attributs. Toutefois, [CC/PP] ne définit pas de tels vocabulaires. Les vocabulaires sont plutôt définis par d'autres organisations ou applications (comme décrit ci-dessous). [CC/PP] ne définit pas non plus de protocole pour le transport d'une instance d'un vocabulaire CC/PP.

Une instance d'un vocabulaire CC/PP s'appelle un profil (profile). Les attributs CC/PP sont codés comme des propriétés RDF dans un profil. L'exemple 44 montre un fragment de profil des préférences d'un utilisateur privilégiant une présentation sonore :

 <ccpp:component>
  <rdf:Description rdf:ID="UserPreferences">
   <rdf:type rdf:resource="http://www.example.org/profiles/prefs/v1_0#UserPreferences"/>
   <ex:AudioOutput>Yes</ex:AudioOutput>
   <ex:Graphics>No</ex:Graphics>
   <ex:Languages>
    <rdf:Seq>
     <rdf:li>en-cockney</rdf:li>
     <rdf:li>en</rdf:li>
    </rdf:Seq>
   </ex:Languages>
  </rdf:Description>
 </ccpp:component>

Il y a plusieurs avantages à utiliser RDF dans cette application. D'abord, un profil codé via CC/PP peut inclure des attributs définis dans des schémas créés par d'autres organisations. RDF est un choix naturel pour ces profils car aucune organisation seule ne créera vraisemblablement de super schéma pour les données de profil agrégées. Un deuxième avantage de RDF est qu'il facilite (en vertu de son modèle de données fondé sur des graphes) l'insertion d'attributs arbitraires (des propriétés RDF) dans un profil. Cela est particulièrement utile pour les profils qui incluent des données changeant fréquemment telles qu'une information de localisation.

L'Open Mobile Alliance a défini le profil d'agent utilisateur (UAProf) [UAPROF], un environnement fondé sur CC/PP qui inclut un vocabulaire pour décrire les capacités de l'appareil, les capacités de l'agent utilisateur, les caractéristiques du réseau, etc., ainsi qu'un protocole de transport des profils. UAProf définit six composantes dont HardwarePlatform, SoftwarePlatform, NetworkCharacteristics et BrowserUA. Il définit aussi plusieurs attributs pour chaque composantes bien que les attributs d'une composante ne soient pas fixes — ils peuvent être complétés ou écrasés. L'exemple 45 montre un fragment de la composante HardwarePlatform UAProf :

 <prf:component>
  <rdf:Description rdf:ID="HardwarePlatform">
   <rdf:type rdf:resource="http://www.openmobilealliance.org/profiles/UAPROF/ccppschema-20021113#HardwarePlatform"/>
   <prf:ScreenSizeChar>15x6</prf:ScreenSizeChar>
   <prf:BitsPerPixel>2</prf:BitsPerPixel>
   <prf:ColorCapable>No</prf:ColorCapable>
   <prf:BluetoothProfile>
    <rdf:Bag>
     <rdf:li>headset</rdf:li>
     <rdf:li>dialup</rdf:li>
     <rdf:li>lanaccess</rdf:li>
    </rdf:Bag>
   </prf:BluetoothProfile>
  </rdf:Description>
 </prf:component>

Le protocole UAProf gèrent les profils statiques et les profils dynamiques. On accède à un profil statique par une adresse URI. Cela présente plusieurs avantages : la requête du client au serveur ne contient qu'une adresse URI au lieu d'un document XML verbeux (diminuant ainsi le trafic hertzien) ; le client n'a pas à stocker ou créer le profil ; la charge de la mise en œuvre sur le client est relativement légère. Les profils dynamiques sont créés à la volée et n'ont donc pas d'adresse URI associée. Ils peuvent se composer d'un fragment de profil contenant une différence par rapport à un profil statique, mais ils peuvent aussi contenir des données uniques non incluses dans le profil statique du client. Une requête peut contenir un nombre quelconque de profils statiques et dynamiques. En revanche, l'ordre des profils est important car les derniers profils écrasent les premiers dans la requête. Cf. [UAPROF] pour plus de renseignements à propos du protocole UAProf et ses règles pour la résolution de plusieurs profils.

D'autres communautés (c'est-à-dire les spécifications TS 26.234 de 3GPP [3GPP] et Multimedia Messaging Service Client Transactions du WAP Forum [MMS-CTR]) ont définis des vocabulaires fondés sur CC/PP. En conséquence, un profil peut tirer avantage de la nature répartie de RDF et inclure des composants définis dans des vocabulaires variés. L'exemple 46 montre un tel profil :

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:prf="http://www.wapforum.org/profiles/UAPROF/ccppschema-20010330#"
         xmlns:mms="http://www.wapforum.org/profiles/MMS/ccppschema-20010111#"
     xmlns:pss="http://www.3gpp.org/profiles/PSS/ccppschema-YYYYMMDD#">

 <rdf:Description rdf:ID="SomeDevice">
  <prf:component>
   <rdf:Description rdf:ID="Streaming">
    <rdf:type rdf:resource="http://www.3gpp.org/profiles/PSS/ccppschema-PSS5#Streaming"/>
    <pss:AudioChannels>Stereo</pss:AudioChannels>
    <pss:VideoPreDecoderBufferSize>30720</pss:VideoPreDecoderBufferSize>
    <pss:VideoInitialPostDecoderBufferingPeriod>0</pss:VideoInitialPostDecoderBufferingPeriod>
    <pss:VideoDecodingByteRate>16000</pss:VideoDecodingByteRate>
   </rdf:Description>
  </prf:component>
 
  <prf:component>
   <rdf:Description rdf:ID="MmsCharacteristics">
    <rdf:type rdf:resource="http://www.wapforum.org/profiles/MMS/ccppschema-20010111#Streaming"/>
    <mms:MmsMaxMessageSize>2048</mms:MmsMaxMessageSize>
    <mms:MmsMaxImageResolution>80x60</mms:MmsMaxImageResolution>
    <mms:MmsVersion>2.0</mms:MmsVersion>
   </rdf:Description>
  </prf:component>

  <prf:component>
   <rdf:Description rdf:ID="PushCharacteristics">
    <rdf:type rdf:resource="http://www.openmobilealliance.org/profiles/UAPROF/ccppschema-20010330#PushCharacteristics"/>
    <prf:Push-MsgSize>1024</prf:Push-MsgSize>
    <prf:Push-MaxPushReq>5</prf:Push-MaxPushReq>
    <prf:Push-Accept>
     <rdf:Bag>
      <rdf:li>text/html</rdf:li>
      <rdf:li>text/plain</rdf:li>
      <rdf:li>image/gif</rdf:li>
     </rdf:Bag>
    </prf:Push-Accept>
   </rdf:Description>
  </prf:component>

 </rdf:Description>
</rdf:RDF>

La définition d'un contexte de livraison et les données d'un contexte continueront d'évoluer. Par conséquent, l'extensibilité inhérente de RDF, et donc la gestion des vocabulaires dynamiques, font de RDF un bon environnement pour le codage d'un contexte de livraison.

7.1 Sémantique RDF

Comme expliqué dans les sections précédentes, RDF est destiné à exprimer des déclarations à propos de ressources sous la forme d'un graphe, en utilisant des vocabulaires spécifiques (noms des ressources, propriétés, classes, etc.). RDF est également destiné à servir de fondation pour des langages plus avancés, tels que ceux mentionnés en section 5.5. Pour ces utilisations, la  «signification » d'un graphe RDF doit être définie de manière très précise.

Ce que renferme exactement la « signification » d'un graphe RDF dans un sens très général peut dépendre de plusieurs facteurs, comprenant les conventions dans une communauté d'utilisateurs pour interpréter spécifiquement les classes et propriétés RDF définies par un utilisateur, les commentaires en langage naturel ou les liens vers d'autres documents porteurs de contenu (content-bearing documents). Comme noté brièvement à la section 2.2, une grande partie de la signification circulant sous ces formes ne sera pas directement accessible lors d'un traitement automatique (machine processing), bien que cette signification puisse être utilisée par les interprètes humains de l'information RDF ou par les programmeurs écrivant des logiciels pour effectuer divers types de traitement sur cette information RDF. Quoiqu'il en soit, les déclarations RDF ont aussi une signification formelle qui détermine, avec une précision mathématique, les conclusions — ou implications (entailments) — que les machines peuvent extraire d'un graphe RDF donné. Le document Sémantique RDF [RDF-SEMANTICS] définit cette signification formelle, en utilisant une technique appelée théorie des modèles (model theory) pour définir la sémantique d'un langage formel. [RDF-SEMANTICS] définit également les extensions sémantiques du langage RDF représentées par RDF Schema et par les types de données individuels. En d'autres mots, la théorie des modèles de RDF fournit les fondements de tous les concepts RDF. Sur la base de la sémantique définie dans la théorie des modèles, il est facile de traduire un graphe RDF en une expression logique ayant essentiellement la même signification.

7.2 Jeux d'essais

Le document Jeux d'essais RDF [RDF-TESTS] complète les spécifications RDF textuelles par des jeux d'essais (exemples) correspondant aux problèmes techniques particuliers traités par le groupe de travail RDF Core. Pour aider à décrire ces exemples, le document des Jeux d'essais introduit une notation appelée N-Triples, qui constitue la base de la notation en triplets utilisée dans toute cette initiation. Les jeux d'essais sont publiés sous une forme interprétable par une machine à des adresses Web référencées par le documents des Jeux d'essais, de façon à ce que les développeurs puissent les utiliser comme base pour le test automatisé des logiciels RDF.

Les jeux d'essais se divisent en plusieurs catégories :

• Tests d'analyseur syntaxique positifs et négatifs — Ceux-ci testent si les analyseurs syntaxiques (parsers) RDF/XML produisent un graphe de sortie N-Triples correct à partir de documents d'entrée RDF/XML légaux, ou signalent correctement des erreurs si les documents d'entrée ne sont pas du RDF/XML légal.
• Tests d'implication positifs et négatifs — Ceux-ci testent si des implications (conclusions) appropriées sont tirées ou non d'ensembles de déclarations RDF indiquées.
• Tests d'implication avec type de données — Ceux-ci sont des tests d'implication positifs ou négatifs qui associent l'utilisation de types de données, et qui nécessitent donc une gestion supplémentaires des types de données spécifiques associés aux tests.
• Tests divers — Ce sont les tests qui n'entrent pas dans les autres catégories.

Les jeux d'essais ne sont pas une spécification complète de RDF et ne sont pas prioritaires sur les autres documents de spécification. Par contre, ils illustrent l'intention du groupe de travail RDF Core par rapport à la conception de RDF, et les développeurs trouveront peut-être ces jeux d'essais utiles si la formulation des spécifications apparaissait imprécise sur un point de détail.

8.1 Références normatives

[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-MIME-TYPE]

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.

[RDF-MS]

Spécification du modèle et de la syntaxe du cadre de description de ressource (RDF), Lassila O., Swick R. (rédacteurs), World Wide Web Consortium, 22 février 1999. Cette version est à http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/. La dernière version est à http://www.w3.org/TR/REC-rdf-syntax/.

[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-SYNTAX]

Spécification de la syntaxe RDF/XML, Beckett D. (rédacteur), recommandation du W3C, 10 février 2004. Cette version est à http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/. La dernière version est à http://www.w3.org/TR/rdf-syntax-grammar/.

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

[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 est à http://www.w3.org/TR/2004/REC-rdf-schema-20040210/. La dernière version est à http://www.w3.org/TR/rdf-schema/.

[UNICODE]

The Unicode Standard, Version 3, The Unicode Consortium, Addison-Wesley, 2000. ISBN 0-201-61633-5, tel que mis à jour épisodiquement à 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 standard et la base de données de caractères Unicode).

[URIS]

RFC 2396 : Identficateurs de ressource uniformes — Syntaxe générique, Berners-Lee T., Fielding R., Masinter L., IETF, août 1998, http://www.isi.edu/in-notes/rfc2396.txt.

[XML]

Langage de balisage extensible (XML) 1.0, deuxième édition, Bray T., Paoli J., Sperberg-McQueen C.M., Maler E. (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 à http://www.w3.org/TR/REC-xml.

[XML-BASE]

XML Base, Marsh J. (rédacteur), 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-NS]

Espaces de noms en XML, Bray T., Hollander D., Layman A. (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 à http://www.w3.org/TR/REC-xml-names/.

[XML-XC14N]

Canonisation XML exclusive version 1.0, Boyer J., Eastlake D.E. 3rd, Reagle J. (auteurs/rédacteurs), 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/.

8.2 Références informatives

[3GPP]

3GPP TS 26.234. 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Transparent end-to-end packet switched streaming service; Protocols and codecs V5.2.0 (2002-09). Ce document est disponible à http://www.3gpp.org/specs/specs.htm via le répertoire ftp://ftp.3gpp.org/specs/2002-09/Rel-5/26_series/.

[ADDRESS-SCHEMES]

Schémas d'adressage, Connolly D., 2001. Ce document est à http://www.w3.org/Addressing/schemes.html.

[BATES96]

Indexing and Access for Digital Libraries and the Internet: Human, Database, and Domain Factors, Bates M.J., 1996. Cedocument est à http://is.gseis.ucla.edu/research/mjbates.html.

[BERNERS-LEE98]

What the Semantic Web can represent, Berners-Lee T., 1998. Ce document est à http://www.w3.org/DesignIssues/RDFnot.html.

[CC/PP]

Profils composites de capacités/préférences (CC/PP — Structure et vocabulaires, Klyne G., Reynolds F., Woodrow C., Ohto H., Hjelm J., Butler M., Tran, L., recommandation du W3C, 15 janvier 2004. Cette version est à http://www.w3.org/TR/2004/REC-CCPP-struct-vocab-20040115/. La dernière version est à http://www.w3.org/TR/CCPP-struct-vocab/.

[CG]

Conceptual Graphs, Sowa J., ISO working document ISO/JTC1/SC32/WG2 N 000, 2 avril 2001 (travail en cours). Disponible à http://users.bestweb.net/~sowa/cg/cgstand.htm.

[CHARMOD]

Modèle de caractères pour le Web 1.0, Dürst M., Yergeau F., Ishida R., Wolf M., Freytag A., Texin T. (rédacteurs), World Wide Web Consortium, 20 février 2002 (travail en cours). Cette version est à http://www.w3.org/TR/2002/WD-charmod-20020220/. La dernière version est à http://www.w3.org/TR/charmod/.

[CIM]

Common Information Model (CIM): CIM 10 Version, EPRI, Palo Alto, CA: 2001, 1001976. Ce document est disponible à http://www.epri.com/attachments/286161_1001976(1).pdf (267pp.).

[COWAN]

Metadata, Reuters Health Information, and Cross-Media Publishing, Cowan J., 2002. Présentation à Seybold New York 2002 Enterprise Publishing Conference. Ce document est à http://seminars.seyboldreports.com/seminars/2002_new_york/presentations/014/cowan_john.ppt. Une transcription d'accompagnement se trouve à http://seminars.seyboldreports.com/2002_new_york/files/transcripts/doc/transcript_EP7.doc

[DAF]

Utility Management System (UMS) Data Access Facility, version 2.0, Object Management Group, novembre 2002. Ce document est disponible à http://www.omg.org/technology/documents/formal/UMS_Data_Access_Facility.htm.

[DAML+OIL]

DAML+OIL (March 2001) Reference Description, Connolly D., van Harmelen F., Horrocks I., McGuinness D.L., Patel-Schneider P.F., Stein L.A., World Wide Web Consortium, 18 décembre 2001. Ce document est à http://www.w3.org/TR/daml+oil-reference.

[DC]

Jeu d'éléments de métadonnées Dublin Core version 1.1 — Description de référence, 2 juin 2003. Cette version est à http://dublincore.org/documents/2003/06/02/dces/. La dernière version est à http://dublincore.org/documents/dces/.

[DIPRINC]

Principes de l'indépendance par rapport aux appareils, Gimson, R., Finkelstein, S., Maes, S., Suryanarayana, L., World Wide Web Consortium, 18 septembre 2001 (travail en cours). Cette version est à http://www.w3.org/TR/2001/WD-di-princ-20010918. La dernière version est à http://www.w3.org/TR/di-princ/.

[DWZ01]

XML for CIM Model Exchange, deVos A., Widergreen S.E., Zhu J., Proc. IEEE Conference on Power Industry Computer Systems, Sydney, Australia, 2001. Ce document est à http://www.langdale.com.au/PICA/.

[GO]

Gene Ontology: tool for the unification of biology, The Gene Ontology Consortium, Nature Genetics, Vol. 25: 25-29, May 2000. Disponible à http://www.geneontology.org/GO_nature_genetics_2000.pdf

[GRAY]

Logic, Algebra and Databases, Gray P., Ellis Horwood Ltd., 1984. ISBN 0-85312-709-3, 0-85312-803-0, 0-470-20103-7, 0-470-20259-9.

[HAYES]

In Defense of Logic, Hayes P., Proceedings from the International Joint Conference on Artificial Intelligence, 1975, San Francisco. Morgan Kaufmann Inc., 1977. Also in Computation and Intelligence: Collected Readings, Luger G. (ed), AAAI press/MIT press, 1995. ISBN 0-262-62101-0.

[KIF]

Knowledge Interchange Format, Genesereth M., draft proposed American National Standard NCITS.T2/98-004. Disponible à http://logic.stanford.edu/kif/dpans.html.

[LBASE]

LBase: Semantics for Languages of the Semantic Web, Guha R. V., Hayes P., note du W3C, 10 octobre 2003. Cette version est à http://www.w3.org/TR/2003/NOTE-lbase-20031010/. La dernière version est à http://www.w3.org/TR/lbase/.

[LUGER]

Artificial Intelligence: Structures and Strategies for Complex Problem Solving (3rd ed.), Luger G., Stubblefield W., Addison Wesley Longman, 1998. ISBN 0-805-31196-3.

[MATHML]

Langage de balisage mathématique (MathML) version 2.0, Carlisle D., Ion P., Miner R., Poppelier N. (rédacteurs) ; Ausbrooks R., Buswell S., Dalmas S., Devitt S., Diaz A., Hunter R., Smith B., Soiffer N., Sutor R., Watt S. (auteurs principaux), World Wide Web Consortium, 21 février 2001. Cette version est à http://www.w3.org/TR/2001/REC-MathML2-20010221/. La dernière version est à http://www.w3.org/TR/MathML2/.

[MMS-CTR]

Multimedia Messaging Service Client Transactions Specification, WAP-206-MMSCTR-20020115-a. Ce document est disponible à http://www.openmobilealliance.org/.

[NAMEADDRESS]

Nommage et adressage : adresses URI, adresses URL, ..., Connolly D., 2002. Ce document est à http://www.w3.org/Addressing/.

[OWL]

Référence du langage d'ontologie Web OWL, Dean M., Schreiber G (rédacteurs) ; van Harmelen F., Hendler J., Horrocks I., McGuinness D.L., Patel-Schneider P.F., Stein L.A. (auteurs), recommandation du W3C, 10 février 2004. La dernière version est à http://www.w3.org/TR/owl-ref/.

[PRISM]

PRISM: Publishing Requirements for Industry Standard Metadata, Version 1.1, 19 février 2002. La dernière version de la spécification PRISM est disponible à http://www.prismstandard.org/.

[RDFISSUE]

Suivi des problèmes RDF, McBride B., 2002. Ce document est à http://www.w3.org/2000/03/rdf-tracking/.

[RDF-S]

Spécification du schéma du cadre de description de ressource (RDF) 1.0, Brickley D., Guha, R.V. (rédacteurs), World Wide Web Consortium, 27 mars 2000. Cette version est à http://www.w3.org/TR/2000/CR-rdf-schema-20000327/.

[RSS]

RDF Site Summary (RSS) 1.0, Beged-Dov G., Brickley D., Dornfest R., Davis I., Dodds L., Eisenzopf J., Galbraith D., Guha R.V., MacLeod K., Miller E., Swartz A., van der Vlist E., 2000. Ce document est à http://purl.org/rss/1.0/spec.

[RUBY]

Annotation ruby, Sawicki M., Suignard M., Ishikawa M., Dürst M., Texin T. (rédacteurs), World Wide Web Consortium, 31 mai 2001. Cette version est à http://www.w3.org/TR/2001/REC-ruby-20010531/. La dernière version est à http://www.w3.org/TR/ruby/.

[SOWA]

Knowledge Representation: Logical, Philosophical and Computational Foundations, Sowa J., Brookes/Cole, 2000. ISBN 0-534-94965-7.

[SVG]

Spécification des graphiques vectoriels redimensionnables (SVG) 1.1, Ferraiolo J., Fujisawa J., Jackson D. (rédacteurs), World Wide Web Consortium, 14 janvier 2003. Cette version est à http://www.w3.org/TR/2003/REC-SVG11-20030114/. La dernière version est à http://www.w3.org/TR/SVG11/.

[UAPROF]

User Agent Profile, OMA-WAP-UAProf-v1_1. Ce document est disponible à http://www.openmobilealliance.org/.

[WEBDATA]

Architecture Web — Description et échange de données, Berners-Lee T., Connolly D., Swick R., World Wide Web Consortium, 7 juin 1999. Ce document est à http://www.w3.org/1999/04/WebData.

[XLINK]

Langage de liaison XML (XLink) version 1.0, DeRose S., Maler E., Orchard D. (rédacteurs), World Wide Web Consortium, 27 juin 2001. Cette version est à http://www.w3.org/TR/2001/REC-xlink-20010627/. La dernière version est à http://www.w3.org/TR/xlink/.

[XML-SCHEMA2]

XML Schema tome 2 — Types de données, Biron P., Malhotra A. (rédacteurs), World Wide Web Consortium. 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/.

[XPACKAGE]

XML Package (XPackage) 1.0, Wilson G., rédacteur de l'ébauche, 6 mars 2003. Cette version est à http://www.xpackage.org/specification/xpackage-draft-20030306.html. La dernière version est à http://www.xpackage.org/specification/.