Traducteur : Karl Dubost - <karl+misc@la-grange.net>
Toute amélioration est la bienvenue. Les graphiques n'ont pas encore été modifiés. Cette traduction a été relue et corrigée par Annie Marcheix de l'AILF.
La version française de cette traduction est :
http://www.la-grange.net/w3c/REC-rdf-syntax/
Version originale : http://www.w3.org/TR/1999/REC-rdf-syntax-19990222
Droit de copie © 1997,1998,1999 W3C (MIT, INRIA, Keio ), Tous droits réservés. Les règles de responsabilité, de marque déposée, d'utilisation du document et de license sur les logiciels du W3C s'appliquent.
Ce document a été examiné par les membres du W3C et autres groupes intéressés et a été approuvés par le directeur comme une recommandation du W3C. C'est un document stable et il peut être utilisé comme un matériel de référence ou cité comme une référence normative dans d'autres documents. Le rôle du W3C dans l'établissement de la recommandation est d'attirer l'attention sur la spécifivation et de promouvoir sa large mise en oeuvre. Elle améliore la fonctionnalité et l'interopérabilité du Web.
La liste des erreurs connues dans cette spécification est disponible à http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/errata.
Les commentaires sur cette spécification doivent être envoyés à www-rdf-comments@w3.org. L'archive des commentaires publiques est disponible à http://www.w3.org/Archives/Public/www-rdf-comments.
Le World Wide Web a été conçu à l'origine pour la compréhension humaine, et bien que tout ce qui y réside est lisible par une machine, ces données ne sont pas compréhensibles par une machine. Il est très difficile d'automatiser quoi que ce soit sur le Web, et à cause du volume d'information que le Web contient, il est impossible de gérer cela manuellement. La solution proposée ici est d'utiliser les métadonnées pour décrire les données contenues sur le Web. Les métadonnées sont des "données à propos des données" (par exemple, un catalogue de bibliothèque est une compilation de métadonnées, puisqu'il décrit les publications) ou spécifiquement dans le contexte de cette spécification "des données décrivant les ressources Webs". La distinction entre les "données" et les "métadonnées" n'est pas absolue ; c'est tout d'abord une distinction créée par une application particulière, et très souvent la même ressource sera êté de plusieurs façons simultanément.
Resource Description Framework (RDF) est une création pour le traitement des métadonnées ; il fournit l'interopérabilité entre les applications qui échangent de l'information non compréhensible par les machines sur le Web. RDF augmente la facilité de traitement automatique des ressources Web. RDF peut être utilisé dans une variété de champs d'application ; par exemple : dans la découverte de ressources pour fournir une meilleure efficacité aux moteurs de recherche, dans le catalogage pour décrire le contenu et les relations entre les contenus disponibles sur un site Web particulier, sur une page, ou sur une bibliothèque numérique, dans l'évaluation du contenu, en décrivant des ensembles de pages qui représente un simple et unique "document", pour décrire les droits sur la propriété intellectuelle des pages Web, et pour indiquer les préférences de confidentialité d'un utilisateur aussi bien que les politiques de confidentialité d'un site Web. RDF avec les signatures numériques sera la clé pour construire un "Web de confiance" pour le commerce électronique, les collaborations, et d'autres applications.
Ce document introduit un modèle pour représenter les métadonnées RDF aussi bien que la syntaxe pour encoder et transporter ces métadonnées d'une manière qui maximise l'interopérabilité indépendamment des serveurs et des clients Web. La syntaxe présentée ici utilise le langage de balisage extensible [XML] : une des buts de RDF est de rendre possible de spécifier les sémantiques des données basées sur XML d'une manière standardisée et interopérable. RDF et XML sont complémentaires : RDF est un modèle de métadonnées et et permet de résoudre de façon dérivée, des problèmes d'encodage ainsi que le transport et le stockage de fichier nécessite (comme l'internationalisation, les jeux de caractères, etc.). Pour ces problèmes, RDF repose sur le support de XML. Il est également important de comprendre que cette syntaxe XML est seulement une syntaxe possible pour RDF et que des manières alternatives de représenter le même modèle RDF de données pourraient voir le jour.
Le but général de RDF est de définir un mécanisme pour décrire les ressources sans faire d'hypothèses sur un domaine particulier d'application, d'ailleurs cela définit (a priori) les sémantiques de n'importe quel domaine d'application. La définition du mécanisme devrait être neutre par rapport au domaine, bien que le mécanisme devrait être approprié pour décrire l'information de chacun des domaines.
Cette spécification sera suivie par d'autres documents qui complèteront le cadre de travail. Pour faciliter la définition des métadonnées, RDF aura un système de classe comme dans tout environnement de programmation orienté objet et de modélisation. Une collection de classes (écrite typiquement pour un domaine ou un but spécifique) est appelée un schéma. Les classes sont organisées en hiérarchie, et offrent une extensibilité grâce à la subtilité des sous-classes. De cette façon, pour créer un schéma légèrement différent d'un autre déjà existant, il n'est pas nécessaire de "réinventer la roue" mais il faut juste fournir des modifications incrémentales au schéma de base. A travers le partage des schémas, RDF supportera la réutilisabilité des définitions de métadonnées. Grâce à l'extensibilité incrémentale de RDF, les agents traitant les métadonnées seront capables de tracer les origines des schémas avec lesquels ils ne sont pas familiers jusqu'à aux schémas connus et effectuer les actions appropriées sur les métadonnées pour lesquelles ils n'ont pas été conçus premièrement pour leur traitement. La possibilité de partage et l'extensibilité permet également aux auteurs de métadonnées d'utiliser plusieurs héritages pour "mélanger" les définitions, pour fournir plusieurs vues de leurs données, en s'appuyant sur le travail effectué par d'autres. De plus, il est possible de créer des données RDF basées sur de multiples schémas à partir de plusieurs sources (c.-à-d., de mélanger différent types de métadonnées). Les schémas pourrait être écrit eux-même en RDF ; un document d'accompagnement de cette spécification, [RDFSchema], décrit un ensemble de propriétés et de classes pour décrire les schémas RDF.
A partir de plusieurs communautés se rassemblant et s'accordant sur des principes élémentaires de représentation et de transport des métadonnées, RDF a subi l'influence de plusieurs sources différentes. Les influences principales sont venues de la communauté de standardisation du Web elle-même sous la forme des métadonnées HTML et de PICS, de la communauté des bibliothèques, de la communauté des documents structurés sous la forme de SGML et de manière plus importante XML, et également de la communauté de la représentation de la connaissance (KR - Knowledge Representation). Il existe également d'autres domaines de technologie qui ont contribué à la conception de RDF ; ceci inclue la programmation orientée objet et les langages de modélisation, ainsi que les bases de données. Comme RDF prend ses sources dans la communauté KR, les lecteurs familiers de ce champs doivent être attentifs au fait que RDF ne spécifie pas un mécanisme pour la dialectique. RDF peut être caractérisé comme un système de cadre simple. Un mécanisme de dialectique pourrait être construit au-dessus de ce système de cadre.
La fondation de RDF est un modèle pour représenter des propriétés et des valeurs de propriétés données. Le modèle RDF s'appuie sur des principes bien établis provenant des différentes communautés de représentation des données. Vous pouvez imaginer les propriétés RDF comme les attributs de ressources et en ce sens elles correspondent aux paires traditionnelles attribut-valeur. Les propriétés RDF représentent également les relations entre les ressources et un modèle RDF qui peut par conséquent ressembler à un diagramme entité-relation (ER). (Plus précisément, les schémas RDF — qui sont eux-mêmes des cas de modèles de données — sont des diagrammes ER.) Dans la terminologie de la conception orientée objet, les ressources correspondent aux objets et les propriétés correspondent aux variables.
Le modèle de donnée RDF est une façon neutre syntaxiquement parlant de représenter les expressions RDF. La réprésentation du modèle de données est utilisée pour évaluer l'équivalence des significations. Deux expressions RDF sont équivalentes si et seulement si leurs réprésentations de modèle de données sont les mêmes. Cette définition d'équivalence permet des variations syntaxiques dans leur expression sans en altérer la signification. (Voir Section 6. pour des commentaires supplémentaires sur les questions de comparaison de chaîne.)
Le modèle de donnée élémentaire consiste en trois types d'objets :
| Ressources | Toutes choses décrites par des expressions RDF sont appelées des ressources. Une ressource peut être une page Web entière : comme le document HTML "http://www.w3.org/Overview.html" par exemple. Une ressource peut être une partie d'une page Web : ex. un élément HTML ou XML spécifique à l'intérieur du document source. Une ressource peut être également une collection complète de pages : ex., un site web entier. Une ressource peut être également un objet qui n'est pas directement accessible par le Web : ex., un livre imprimé. Les ressources sont toujours nommées par des URIs avec des ancres ids optionnelles (voir [URI]). Toute chose peut avoir une URI : L'extensibilité des URIs permet l'introduction d'identificateurs pour toute entité imaginable. |
| Propriétés | Une propriété est un aspect, une caractéristique, un attribut, ou une relation spécifique utilisée pour décrire une ressource. Chaque propriété possède une signification spécifique, définit ses valeurs permises, les types de ressources qu'elle peut décrire, et les relations qu'elle entretient avec les autres propriétés. Ce document ne s'ocuppe pas de la façon dont les caractéristiques des propriétés sont exprimées ; pour obtenir cette information, voir la spécification sur le schéma RDF). |
| Déclarations | Une ressource spécifique associée à une propriété définie ainsi que la valeur de cette propriété pour cette ressource est une déclaration RDF. Ces trois parties individuelles d'une déclaration sont appelées, respectivement, le sujet, le prédicat, et l'objet. L'objet d'une déclaration (c.-à-d., la valeur de la propriété) peut être une autre ressource ou il peut être littéral ; c.-à-d., une ressource (spécifiée par une URI) ou une simple chaîne ou autre type de données primitif défini par XML. En termes RDF, un littéral pourrait avoir un contenu qui est un balisage XML mais qui n'est pas davantage évalué par le processeur RDF. Il y a des restrictions syntaxiques sur la façon dont le balisage dans les littéraux peut être exprimé ; voir Section 2.2.1. |
Les ressources sont identifiées par un identificateur de ressource. Un identificateur de ressource est une URI plus une ancre id optionnelle (voir Section 2.2.1.). Pour les besoins de cette section, les propriétés seront identifiées par un nom simple.
Considérez comme un exemple simple, la phrase :
Ora Lassila est le créateur de la ressource http://www.w3.org/Home/Lassila.
Cette phrase est composée des parties suivantes :
Sujet (Ressource) http://www.w3.org/Home/Lassila Prédicat (Propriété) Créateur Objet (littéral) "Ora Lassila"
Dans ce document, nous présenterons une déclaration RDF sous la forme de graphes étiquetés (également appelés "diagrammes arcs et noeuds"). Dans ces diagrammes, les noeuds (représentés par des ovales) représente les ressources et les arcs représentent les propriétés déclarées. Les noeuds qui représentent des chaînes littérales seront représentés par des rectangles. La phrase précédente sera donc représentée par le diagramme suivant :
Figure 1: Diagramme d'un noeud et d'un arc simple
Note : La direction de la flêche est importante. L'arc démarre toujours au sujet et pointe vers l'objet de la déclaration. Le diagramme simple, plus haut, peut être également lu "http://www.w3.org/Home/Lassila a pour créateur Ora Lassila", ou en général " <le sujet> A POUR <prédicat> <objet> ".
Maintenant, considérez le cas où nous voulons en dire un peu plus sur les caractéristiques du créateur de cette ressource. En prose, une phrase possible pourrait être :
La personne dont le nom est Ora Lassila, email <lassila@w3.org> , est le créateur de http://www.w3.org/Home/Lassila.
Le but de cette phrase est de définir la valeur de la propriété Créateur comme une entité structurée. En RDF une telle entité est représentée comme une autre ressource. La phrase au-dessus ne donne pas de nom à cette ressource ; elle est anonyme, donc dans le diagramme suivant, nous la représentons avec un ovale vide :
Figure 2: Propriété avec valeur structurée
Note : suite à la note précédente, ce diagramme pourraît être lu "http://www.w3.org/Home/Lassila a pour créateur quelquechose et quelquechose a pour nom Ora Lassila et email lassila@w3.org".
L'entité structurée de l'exemple précédent peut également être attribuée à un identificateur unique. Le choix de l'identificateur est fait par le concepteur de l'application de base de données. Pour continuer l'exemple, imaginez qu'un identificateur id employé est utilisé comme l'unique identificateur pour une ressource "personne". Les URIs qui servent comme clés uniques pour chaque employé (telles que définies par l'organisation) devrait être alors quelque chose comme http://www.w3.org/staffId/85740. Maintenant nous pouvons écrire les deux phrases :
La personne référencée par l'id employé 85740 est appelée Ora Lassila et a pour adresse email lassila@w3.org. La ressource http://www.w3.org/Home/Lassila a été créée par cette personne.
Le modèle RDF pour ces phrases sont :
Figure 3: Valeur structurée avec identificateur
Notez que ce diagramme est identique au précédent à l'exception de l'ajout de l'URI pour la ressource précédemment anonyme. Du point de vue d'une seconde application interrogeant ce modèle, il n'y a pas de distinction entre les déclarations faites dans une unique phrase et les déclarations faites dans des phrases différentes. Quelques applications auront, cependant, besoin de faire ce type de distinction, et RDF permet cela ; pour obtenir plus de détails, voir Section 4, Déclarations à propos des déclarations.
Le modèle de données RDF fournit un résumé, un cadre conceptuel pour définir et utiliser les métadonnées. Une syntaxe concrète est également nécessaire pour pouvoir créer et échanger ces métadonnées. Cette spécification de RDF utilise l'encodage du langage de balisage extensible [XML] comme syntaxe d'échange. RDF a besoin aussi de la facilité des espaces de nom XML pour associer précisément chaque propriété avec le schéma qui définit la propriété ; voir Section 2.2.3., Schémas et espaces de nom.
Les descriptions de syntaxe dans ce document utilisent la notation de forme étendue Backus-Naur (Extended Backus-Naur Form - EBNF) comme définie dans Section 6, Notation, de [XML] pour décrire les éléments de syntaxe essentielles RDF. l'EBNF est condensé ici pour la lisibilité humaine ; en particulier, le "rdf" en italique est utilisé pour représenté un préfixe d'espace de nom variable plutôt que la notation BNF plus précise "'<' NSprefix ':...'". L'exigence que les noms de propriété et de type dans les balises de fin sont strictement équivalentes au nom dans les balises de début correspondantes est impliquée par les règles XML. Toutes flexibilités syntaxiques de XML sont également implicitement incluses ; ex. règles sur les espaces, mise entre guillemets en utilisant soit les guillemets simples (') ou les guillemets doubles ("), caractère d'échappement, sensibilité à la casse, et et marquage de langue.
Cette spécification définit 2 syntaxes XML pour encoder un modèle de données RDF. La syntaxe de sérialisation exprime toutes les capacités du modèle de données d'une manière très courante. La syntaxe abrégée inclue des constructions supplémentaires qui fournissent une forme plus compacte pour représenter un sous-ensemble de modèle de données. Les interpréteurs RDF devraient implémenter aussi bien la syntaxe de sérialisation complète que la syntaxe abbrégée. Ainsi, les auteurs de metada sont libres de mélanger les deux.
Une déclaration RDF seule apparaît rarement isolée ; plus communément plusieurs propriétés d'une ressource seront données ensemble. La syntaxe RDF XML a été conçue pour régler ceci facilement en regroupant de multiples déclarations pour la même ressource en un élément Description. L'élément Description dénomme, dans un attribut about, les ressources auxquelles chacune des déclarations s'appliquent. Si la ressource n'existe pas encore (c.-à-d., ne possède pas encore un identificateur de ressource) alors un élément Description peut suppléer à l'identificateur pour la ressource en utilisant un attribut ID.
La syntaxe de sérialisation RDF élémentaire prend la forme :
[1] RDF ::= ['<rdf:RDF>'] description* ['</rdf:RDF>']
[2] description ::= '<rdf:Description' idAboutAttr? '>' propertyElt*
'</rdf:Description>'
[3] idAboutAttr ::= idAttr | aboutAttr
[4] aboutAttr ::= 'about="' URI-reference '"'
[5] idAttr ::= 'ID="' IDsymbol '"'
[6] propertyElt ::= '>' propName '>' value '</' propname '>'
| '>' propName resourceAttr '/>'
[7] propName ::= Qname
[8] value ::= description | string
[9] resourceAttr ::= 'resource="' URI-reference '"'
[10] Qname ::= [ NSprefix ':' ] name
[11] URI-reference ::= string, interprété par [URI]
[12] IDsymbol ::= (tout symbole de nom XML légitime) [13] name ::= (tout symbole de nom XML légitime)
[14] NSprefix ::= (tout préfixe d'espace-nom XML légitime)
[15] string ::= (tout texte XML, avec "<", ">", et "&" neutralisés)
L'élément RDF est un simple emballage qui marque les frontières au sein d'un document XML entre lesquelles le contenu est explicitement défini à l'intérieur d'une instance de modèle de donnée RDF. L'élément RDF est optionnel si le contenu peut être identifié comme du RDF à partir du contexte de l'application.
Description contient les éléments restants qui produisent la création des déclarations dans l'instance de modèle. L'élément Description peut être imaginé (pour les besoins de la syntaxe RDF élémentaire) comme, simplement, un lieu pour contenir l'identification de la ressource en cours de description. Typiquement, il y aura plus d'une déclaration faite pour une ressource ; Description fournit un moyen de donner une seule fois le nom de la ressource pour plusieurs déclarations.
Lorsque l'attribut about est spécifié avec Description, les déclarations dans Description se réferre à la ressource dont l'identificateur est déterminé grâce à about. La valeur de l'attribut about est interprêtée comme une référence-URI par la section 4 de [URI]. L'identificateur correspondant de la ressource est obtenu par la résolution de la référence-URI en une forme absolue comme spécifié par [URI]. Si un identificateur partiel est inclus dans la référence-URI alors l'identificateur de ressource se réferre seulement à la sous-composante de la ressource contenante qui est identifié par l'id partiel correspondant interne à cette ressource contenante (voir anchor dans [Dexter94]), sinon l'identificateur se réferre à la ressource complète spécifiée par l'URI. Un élément Description sans attribut about représente une nouvelle ressource. Une telle ressource devrait être un substitut, ou un proxy, pour d'autres ressources physiques qui ne possèdent pas d'URI identifiable. La valeur de l'attribut ID de l'élément Description, si présent, est l'ancre id de cette ressource "interne".
Si d'autres Description ou valeur de propriété ont besoin de se réferrer à une ressource interne, elles utiliseront la valeur de l'ID de cette ressource dans son propre attribut about. L'attribut ID signale la création d'une nouvelle ressource et l'attribut about se réferre à une ressource existante ; par conséquent ID aussi bien que about peuvent être spécifiés dans Description mais pas ensemble dans le même élément. Les valeurs pour chaque attribut ID ne doivent pas apparaître dans plus d'un attribut ID au sein d'un unique document.
Un Description unique peut contenir plus d'un élément propertyElt avec le même nom de propriété. Chacun des propertyElt ajoute un arc au graphe. L'interprétation de ce graphe est défini par le concepteur du schéma.
A l'intérieur d'un propertyElt, l'attribut de la ressource spécifie qu'une autre ressource est la valeur de cette propriété ; soit que l'objet de la déclaration est une autre ressource identifiée par une URI plutôt que par un littéral. L'identificateur de ressource de l'objet est obtenu en résolvant l'attribut URI-Réference de la ressource de la même manière que celle donnée au-dessus pour l'attribut about. Les chaîness doivent être du XML correctement formé ; les mécanismes habituels de mise entre guillemets et d'échappement du contenu XML peuvent être utilisés si la chaîne contient des séquences de caractères (ex. "<" et "&") qui violent les règles de formatage correcte ou qui devraient ressembler à du balisage. Voir la Section 6. pour obtenir des informations sur la syntaxe permettant de spécifier une valeur de propriété avec un contenu XML correctement formé contenant un balisage tel que le balisage ne soit pas interprêté par RDF.
Les noms des propriétés doivent être associés à un schéma. Ceci peut être réalisé en qualifiant les noms d'élément avec un préfixe de l'espace de nom pour relier sans ambiguité la définition de la propriété avec le schéma RDF correspondant ou en déclarant un espace de nom par défaut tel que défini dans [NAMESPACES].
La phrase de l'exemple de la Section 2.1.1
Ora Lassila est le créateur de la ressource http://www.w3.org/Home/Lassila.
est représentée en RDF/XML comme ceci :
<rdf:RDF> <rdf:Description about="http://www.w3.org/Home/Lassila"> <s:Créateur>Ora Lassila</s:Créateur> </rdf:Description> </rdf:RDF>
Ici le préfixe d'espace de nom 's' fait référence à un préfixe d'espace de nom spécifique choisi par l'auteur de cette expression RDF et défini dans une déclaration XML d'espace de nom comme dans :
xmlns:s="http://description.org/schema/"
Cette déclaration d'espace de nom devrait être incluse typiquement comme un attribut XML sur l'élément rdf:RDF mais peut être également incluse avec un élément Description particulier ou même par une expression individuelle propertyElt. L'URI de l'espace de nom dans la déclaration de l'espace de nom est globalement un identificateur unique pour le schéma particulier que l'auteur de cette métadonnée utilise pour définir l'utilisation de la propriété Créateur. D'autres schémas peuvent également définir une propriété appelé Créateur et les deux propriétés seront distinguées grâce à leur identificateur de schéma. Notez également qu'un schéma définit habituellement plusieurs propriétés ; une déclaration d'espace de nom unique suffira pour rendre disponible un large vocabulaire de propriétés.
Le document XML complet contenant la description au-dessus devrait être :
<?xml version="1.0"?> <rdf:rdf xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:s="http://description.org/schema/"> <rdf:description about="http://www.w3.org/Home/Lassila"> <s:créateur>Ora Lassila</s:créateur> </rdf:description> </rdf:rdf>
En utilisant la syntaxe de l'espace de nom par défaut défini dans [NAMESPACES] pour l'espace de nom RDF lui-même, ce document pourrait également être écrit de cette façon :
<?xml version="1.0"?> <rdf xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:s="http://description.org/schema/"> <description about="http://www.w3.org/Home/Lassila"> <s:créateur>Ora Lassila</s:créateur> </description> </rdf>
En outre, les déclarations de l'espace de nom peuvent être associées avec un élément individuel Description ou même un élément individuel propertyElt tel que dans :
<?xml version="1.0"?> <rdf xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <description about="http://www.w3.org/Home/Lassila"> <s:créateur xmlns:s="http://description.org/schema/">Ora Lassila</s:créateur> </description> </rdf>
Comme les déclarations XML des espaces de nom peuvent être imbriquées, l'exemple précédent peut être plus condensé sous la forme :
<?xml version="1.0"?> <rdf xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <description about="http://www.w3.org/Home/Lassila"> <créateur xmlns="http://description.org/schema/">Ora Lassila</créateur> </description> </rdf>
Les expressions très compactées telles que celles ci sont déconseillées, même quand l'encodage RDF/XML est écrit à la main ou grâce à un éditeur de texte. Bien qu'il n'y ai pas d'ambiguité, la possibilité d'erreur est plus grande que si des préfixes explicites sont utilisés avec consistance. Notez qu'un fragment RDF/XML dont le but est d'être inséré dans d'autres documents devrait déclarer tous les espaces de nom qu'il utilise, ainsi il sera totalement contenu par lui-même. Pour la lisibilité, les exemples d'introduction dans le reste de cette section omettent les déclarations d'espace de nom afin de ne pas troubler les points spécifiques qui seront illustrés.
Lorsque la syntaxe de sérialisation montre la struture d'un modèle RDF plus clairement, il est souvent tentant d'utiliser une forme XML plus compacte. La syntaxe abrégée RDF accomplit ceci. Avantage supplémentaire, la syntaxe abrégée permet aux documents respectant à certaines DTDs XML correctement structurées d'être directement interprêtés comme des modèles RDF.
Trois formes d'abréviation sont définies par la syntaxe de sérialisation élémentaire. La première est utilisable pour des propriétés qui ne sont pas répétées à l'intérieur d'un Description et où les valeurs de ces propriétés sont littérales. Dans ce cas, les propriétés peuvent être écrites comme des attributs XML de l'élément Description. L'exemple précédent devient alors :
<rdf:RDF> <rdf:Description about="http://www.w3.org/Home/Lassila" s:Créateur="Ora Lassila" /> </rdf:RDF>
Notez que l'élément Description n'a pas d'autre contenu une fois que la propriété Créateur ait été écrite sous la forme d'un attribut XML, la syntaxe de l'élément vide XML est employée pour éviter d'utiliser la balise de fin de Description.
Voici un autre exemple de l'utilisation de cette même forme d'abréviation :
<rdf:RDF> <rdf:Description about="http://www.w3.org"> <s:Editeur>World Wide Web Consortium</s:Editeur> <s:Titre>W3C Home Page</s:Titre> <s:Date>1998-10-03T02:27</s:Date> </rdf:Description> </rdf:RDF>
est équivalente pour les besoins RDF à :
<rdf:RDF> <rdf:Description about="http://www.w3.org" s:Editeur="World Wide Web Consortium" s:Titre="W3C Home Page" s:Date="1998-10-03T02:27"/> </rdf:RDF>
Notez que bien que ces 2 expressions RDF soient équivalentes, elles pourraient être traitées différemment par d'autres moteurs de traitement. En particulier, si les deux expressions sont incluses à l'intérieur d'un document HTML alors le comportement par défaut d'un navigateur non prévu pour RDF devrait être d'afficher les valeurs des propriétés dans le premier cas alors que dans le second cas, il ne devrait pas y avoir de texte affiché (ou tout au plus un espace).
La seconde forme d'abréviation RDF concerne des éléments Description imbriqués. Cette forme d'abréviation peut être employée pour des déclarations spécifiques lorsque l'objet de la déclaration est une autre ressource et les valeurs de toutes les propriétés données à l'intérieur pour cette seconde ressource sont des chaînes de caractères. Dans ce cas, une transformation semblable des noms d'élément XML en attributs XML est utilisée : les propriétés de la ressource dans l'élément Description imbriqué peuvent être écrites comme des attributs XML de l'élément propertyElt dans lequel Description était contenu.
Le deuxième exemple de phrase de la section 2.1.1
La personne référencée par l'id employé 85740 est appelée Ora Lassila et a pour adresse email lassila@w3.org. La ressource http://www.w3.org/Home/Lassila a été créée par cette personne.
est écrit en RDF/XML en utilisant la forme de sérialisation explicite de la manière suivante
<rdf:RDF> <rdf:Description about="http://www.w3.org/Home/Lassila"> <s:Créateur rdf:resource="http://www.w3.org/staffId/85740"/> </rdf:Description> <rdf:Description about="http://www.w3.org/staffId/85740"> <v:Nom>Ora Lassila</v:Nom> <v:Email>lassila@w3.org</v:Email> </rdf:Description> </rdf:RDF>
Cette forme révèle clairement à la personne la lisant que deux ressources séparées sont décrites mais il est moins clair que la seconde ressource est utilisée à l'intérieur de la première description. La même expression pourrait être écrite de la manière suivante pour rendre la relation plus évidente à une personne. Notez que pour une machine, cela ne fait aucune différence :
<rdf:RDF> <rdf:Description about="http://www.w3.org/Home/Lassila"> <s:Créateur> <rdf:Description about="http://www.w3.org/staffId/85740"> <v:Nom>Ora Lassila</v:Nom> <v:Email>lassila@w3.org</v:Email> </rdf:Description> </s:Créateur> </rdf:Description> </rdf:RDF>
En utilisant la deuxième syntaxe d'abréviation élémentaire, l'élément Description interne et ses expressions de propriété qu'il contient peuvent être écrits comme des attributs de l'élément Créateur :
<rdf:RDF> <rdf:Description about="http://www.w3.org/Home/Lassila"> <s:Créateur rdf:resource="http://www.w3.org/staffId/85740" v:Nom="Ora Lassila" v:Email="lassila@w3.org" /> </rdf:Description> </rdf:RDF>
Lorsque vous utilisez cette forme abrégée, l'attribut about de l'élément Description imbriqué devient un attribut de resource sur l'élément propertyElt, comme la ressource appelé par l'URI est dans les deux cas la valeur de la propriété Créateur. C'est le choix du rédacteur qui conditionne laquelle des trois formes précédentes sera utilisée dans la source RDF. Elles produisent toutes les mêmes modèles RDF internes.
Note : Le lecteur perspicace qui a étudié le reste de ce document verra qu'il existe des relations supplémentaires représentées par un élément Description pour préserver le rassemblement de déclarations syntaxiques spécifiques. Par conséquent les trois formes précédentes varient légèrement mais de façon peu importante pour les points abordés dans cette section. Ces différences deviennent importantes seulement lorsque des déclarations d'un ordre supérieur sont créées comme décrit dans la section 4.
La troisième abréviation élémentaire s'applique au cas commun d'un élément Description contenant une propriété type (voir Section 4.1 pour la signification de type). Dans ce cas, le type de ressource défini dans le schéma correspondant à la valeur de la propriété type peut être utilisé directement comme un nom d'élément. Par exemple, en utilisant le fragment RDF précédent, si nous voulons ajouter le fait que la ressource http://www.w3.org/staffId/85740 représente une représentation d'une Personne, nous devrions écrire ceci avec la syntaxe de sérialisation complète comme dans :
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:s="http://description.org/schema/"> <rdf:Description about="http://www.w3.org/Home/Lassila"> <s:Créateur> <rdf:Description about="http://www.w3.org/staffId/85740"> <rdf:type resource="http://description.org/schema/Person"/> <v:Nom>Ora Lassila</v:Nom> <v:Email>lassila@w3.org</v:Email> </rdf:Description> </s:Créateur> </rdf:Description> </rdf:RDF>et en utilisant la troisième forme abrégée :
<rdf:RDF> <rdf:Description about="http://www.w3.org/Home/Lassila"> <s:Créateur> <s:Personne about="http://www.w3.org/staffId/85740"> <v:Nom>Ora Lassila</v:Nom> <v:Email>lassila@w3.org</v:Email> </s:Personne> </s:Créateur> </rdf:Description> </rdf:RDF>
EBNF pour la syntaxe abrégée élémentaire remplace les productions [2] et [6] de la grammaire pour la syntaxe de sérialisation élémentaire de la manière suivante :
[2a] description ::= '<rdf:Description' idAboutAttr? propAttr* '/>'
| '<rdf:Description' idAboutAttr? propAttr* '>'
propertyElt* '</rdf:Description>'
| typedNode
[6a] propertyElt ::= '>' propName '>' value '</' propname '>'
| '>' propName resourceAttr? propAttr* '/>'
[16] propAttr ::= propName '="' string '"'
(avec les guillemets inclus échappés)
[17] typedNode ::= '>' typeName idAboutAttr? propAttr* '/>'
| '>' typeName idAboutAttr? propAttr* '>'
property* '</' typename '>'
Dans votre langue maternelle, lorsque vous écrivez une phrase, vous utilisez des mots qui sont considérés comme ayant une certaine signification. Cette signification est cruciale pour la compréhension des déclarations et, dans le cas des applications de RDF, est cruciale pour établir que le traitement correct est en cours comme attendu. Il est crucial qu'autant le rédacteur et le lecteur d'une déclaration comprennent de la même manière la signification des termes utilisés, tel que Créateur, ApprouvéPar, DroitDeCopie, etc., sinon s'ensuivra une confusion. Dans un média à large étendue comme le World Wide Web il n'est pas suffisant de s'appuyer sur la compréhension de concepts culturels partagés tels que ceux "livrés par le créateur" ; Il faut être aussi précis que possible.
La signification en RDF est exprimée par la référence à un schéma. Vous pouvez imaginer un schéma comme une sorte de dictionnaire. Un schéma définit les termes qui seront utilisés dans les déclarations RDF et leur donne des significations spécifiques. Une variété de formes de schéma peut être utilisée avec RDF, y compris une forme spécifique définie dans un document séparé [RDFSchema] qui possède quelques caractéristiques spécifiques pour aider l'automatisation des tâches utilisant RDF.
Un schéma est l'endroit où les définitions et les restrictions d'usage pour les propriétés sont documentées. Afin d'éviter la confusion entre les définitions indépendantes -- et potentiellement conflictuelles -- du même terme, RDF utilise les possibilités des espaces de nom XML. Les espaces de nom sont simplement une manière de lier l'utilisation spécifique d'un mot dans un contexte au dictionnaire (schéma) où la définition est supposée se trouver. En RDF, chaque prédicat utilisé dans une déclaration doit être identifié avec exactement un espace de nom, ou un schéma. Cependant, un élément Description peut contenir des déclarations avec des prédicats issues de plusieurs schémas. Des exemples de description RDF qui utilisent plus d'un schéma apparaît dans la Section 7.
Souvent la valeur d'une propriété est quelquechose qui possède une information contextuelle supplémentaire qui est considérée "être une partie de" cette valeur. En d'autres termes, Il est nécessaire de qualifier les valeurs de propriété. Des exemples d'une telle qualification incluent la dénomination une unité de mesure, un vocabulaire particulier limité, ou quelque autre annotation. Pour certaines utilisations, il est approprié d'utiliser la valeur de la propriété sans les qualificateurs. Par exemple, dans la déclaration "le prix de ce crayon est de 75 centimes U.S." il est souvent suffisant de dire simplement "le prix de ce crayon est de 75".
Dans le modèle RDF, une valeur de propriété qualifiée est simplement un autre représentant d'une valeur structurée. L'objet de la déclaration originale est cette valeur structurée et les qualificateurs sont des propriétés de cette ressource commune. La valeur principale qualifiée est donnée pour la valeur de la propriété value de cette ressource commune. Voir Section 7.3. Relations non binaires pour obtenir un exemple de l'utilisation d'une propriété value.
Il est fréquemment nécessaire de faire référence à une collection de ressources ; par exemple, pour dire qu'un travail a été créé par plus d'une personne, ou pour lister des étudiants dans un cours, ou les modules d'un logiciel. Les conteneurs RDF sont utilisés pour contenir de telles listes de ressources ou de littéraux.
RDF définit trois types d'objets conteneurs :
Note : Les définitions de Bag et de Sequence permettent explicitement les valeurs identiques. RDF ne définit pas un concept central de Set, qui serait un Bag sans double exemplaire, parce-que le coeur de RDF n'impose pas de mécanisme d'obligation dans l'événement de violation de ce type de contraintes. Des travaux futures sur le coeur de RDF définiront peut-être ce genre de possibilités.
Pour représenter une collection de ressources, RDF utilise une ressource supplémentaire qui identifie la collection spécifique (une instance d'une collection, dans la terminologie de modélisation objet). Cette ressource doit être déclarée comme une instance de l'un des types d'objet de conteneurs tels que définis au-dessus. La propriété de type, définie plus loin, est utilisée pour faire cette déclaration. La relation d'appartenance entre la ressource du conteneur et les ressources qui font partie de la collection est définie par un ensemble de propriétés défini expressément dans ce but. Ces propriétés d'appartenance sont simplement appelées "_1", "_2", "_3", etc. Les ressources de conteneur peuvent avoir d'autres propriétés en plus des propriétés d'appartenance et la propriété de type. Toutes autres déclarations de ce type décrivent le conteneur ; voir Section 3.3, sur les référents distributifs, pour en savoir plus sur les déclarations concernant chacun des membres.
Une utilisation habituelle des conteneurs est la valeur de propriété. Dans ce type d'utilisation, la déclaration a toujours un objet de déclaration unique quelquesoit le nombre de membres dans le conteneur ; la ressource du conteneur elle-même est l'objet de la déclaration.
Par exemple, pour représenter la phrase
Les étudiantes en cours 6.001 sont Amy, Tim, John, Mary, et Sue.
Le modèle RDF est
Figure 4: conteneur Bag simple
Les conteneurs Bag ne sont pas équivalents aux propriétés répétées du même type ; voir Section 3.5. pour une présentation des différences. Les auteurs auront besoin de décider cas par cas lequel (déclaration répétée de propriété ou Bag) est le plus approprié.
La phrase
Le code source pour X11 peut être trouvé à ftp.x.org, ftp.cs.purdue.edu, ou ftp.eu.net.
est modélisé en RDF par
Figure 5: Conteneur Alternative simple
Les conteneurs Alternative sont fréquemment utilisés en conjonction des langages de balisage. Un travail dont le titre a été traduit en plusieurs langue pourra avoir sa propriété Title pointant vers un conteneur Alternative contenant chacune des variantes de langue.
La syntaxe de conteneur RDF prend la forme :
[18] container ::= sequence | bag | alternative [19] sequence ::= '<rdf:Seq' idAttr? '>' member* '</rdf:Seq>' [20] bag ::= '<rdf:Bag' idAttr? '>' member* '</rdf:Bag>' [21] alternative ::= '<rdf:Alt' idAttr? '>' member+ '</rdf:Alt>' [22] member ::= referencedItem | inlineItem [23] referencedItem ::= '<rdf:li' resourceAttr '/>' [24] inlineItem ::= '<rdf:li>' value '</rdf:li>'
Les conteneurs peuvent être utilisés partout où un Description est permis :
[1a] RDF ::= '<rdf:RDF>' obj* '</rdf:RDF>' [8a] value ::= obj | string [25] obj ::= description | container
Notez que RDF/XML utilise li par commodité pour éviter d'avoir à numéroter explicitement chaque membre. L'élément li fixe les propriétés _1, _2, et ainsi de suite par nécessité. Le nom de l'élément li a été choisi pour des raisons mnémoniques avec le terme d'"élément de liste" du langage HTML.
Un conteneur Alt est requis pour avoir au moins un membre. Ce membre sera identifié par la propriété _1 et il est la valeur par défaut ou préferrée.
Note : La spécification du schéma RDF [RDFSCHEMA] définit également un mécanisme pour déclarer les sous-classes supplémentaires de ces types de conteneurs, dans lequel la production de cas [18] est étendue pour inclure les noms de ces sous-classes déclarées. Il y a également une syntaxe pour écrire des valeurs littérale sous la forme d'attribut ; voir la grammaire complète dans la Section 6.
Le modèle pour la phrase
Les étudiants dans le cours 6.001 sont Amy, Tim, John, Mary, et Sue.
est écrit en RDF/XML ainsi
<rdf:RDF> <rdf:Description about="http://mycollege.edu/courses/6.001"> <s:étudiants> <rdf:Bag> <rdf:li resource="http://mycollege.edu/students/Amy"/> <rdf:li resource="http://mycollege.edu/students/Tim"/> <rdf:li resource="http://mycollege.edu/students/John"/> <rdf:li resource="http://mycollege.edu/students/Mary"/> <rdf:li resource="http://mycollege.edu/students/Sue"/> </rdf:Bag> </s:étudiants> </rdf:Description> </rdf:RDF>
Dans ce cas, comme la valeur de la propriété étudiants est formulée comme un Bag, il n'y a pas de signification particulière pour l'ordre donné aux URIs de chaque étudiant.
Le modèle pour la phrase
Le code source pour X11 peut être trouvé à ftp.x.org, ftp.cs.purdue.edu, ou ftp.eu.net.
est écrit en RDF/XML comme
<rdf:RDF> <rdf:Description about="http://x.org/packages/X11"> <s:SiteDistribution> <rdf:Alt> <rdf:li resource="ftp://ftp.x.org"/> <rdf:li resource="ftp://ftp.cs.purdue.edu"/> <rdf:li resource="ftp://ftp.eu.net"/> </rdf:Alt> </s:SiteDistribution> </rdf:Description> </rdf:RDF>
Ici, chaque élément listé dans la valeur du conteneur pour SiteDistribution est une valeur acceptable sans égard aux autres éléments.
Les structures de conteneur font émerger un problème au sujet des déclarations : quand on réfère une déclaration à une collection, quelle "chose" est la déclaration décrite ? Ou autrement dit, à quel objet la déclaration en cours de référencement ? Est-ce la déclaration qui décrit le conteneur lui-même ou est-ce la déclaration qui décrit les membres du conteneur ? L'objet décrit (dans la syntaxe XML indiquée par l'attribut about) est en RDF appelé le référent.
L'exemple suivant :
<rdf:Bag ID="pages"> <rdf:li resource="http://foo.org/foo.html" /> <rdf:li resource="http://bar.org/bar.html" /> </rdf:Bag> <rdf:Description about="#pages"> <s:Créateur>Ora Lassila</s:Créateur> </rdf:Description>
exprime que "Ora Lassila" est le Créateur de Bag "pages". Cependant, cela ne dit rien à propos des pages individuellement, les membres de Bag. Le référent de Description est le conteneur (le Bag), pas ses membres. Certains préfèreront écrire une déclaration à propos de chaque objet contenu individuellement, à la place du conteneur lui-même. Afin d'exprimer que "Ora Lassila" est le créateur de chacune des pages, une sorte différente de référent est alors utilisée, un référrent qui se distribute sur les membres du conteneur. Ce référrent en RDF est exprimé en utilisant l'attribut aboutEach :
[3a] idAboutAttr ::= idAttr | aboutAttr | aboutEachAttr [26] aboutEachAttr ::= 'aboutEach="' URI-reference '"'
Si nous écrivons, dans l'exemple suivant
<rdf:Description aboutEach="#pages"> <s:Créateur>Ora Lassila</s:Créateur> </rdf:Description>
Nous obtiendrons le sens voulu. Nous appellerons le nouveau type de référent, un référent distributif. Les référents distributifs nous permettent de "partager la structure" dans une Description RDF. Par exemple, lors de l'écriture de plusieurs Descriptions qui ont toutes un nombre de parties de déclaration commune (prédicats et objets), les parties communes peuvent être partagées à travers toutes les Descriptions, permettant finalement par une économie d'espace et une facilité d'entretien des métadonnées. La valeur d'un attribut aboutEach doit être un conteneur. Utiliser un référent distributif sur un conteneur est identique que d'écrire toutes les déclarations à propos des membres séparément.
Il n'y a pas de réprésentation explicite de graphe de référent distributif définie. A la place, en terme de déclarations réalisées, les référents distributifs sont développés en déclarations individuelles à propos des membres de conteneurs individuels (les implémentations sont libres d'obtenir l'information à propos des référents distributifs - afin d'économiser des espaces, par exemple - aussi bien que des fonctions d'interrogations lorsque toutes les déclarations sont faites individuellement). Soit, par rapport aux ressources "foo" et "bar", l'exemple précédent est équivalent à
<rdf:Description about="http://foo.org/foo.html"> <s:Créateur>Ora Lassila</s:Créateur> </rdf:Description> <rdf:Description about="http://bar.org/bar.html"> <s:Créateur>Ora Lassila</s:Créateur> </rdf:Description>
Une utilisation très fréquente de métadonnées est de faire des déclarations à propos de "toutes les pages de mon site Web", ou "toutes les pages dans cette branche de mon site web". Dans de nombreux cas, il n'est pas pratique ou même désirable d'essayer de lister chacune des ressources explicitement et de l'identifier comme un membre d'un conteneur. RDF possède par conséquent un deuxième type de référent distributif. Ce deuxième type de référent distributif est une syntaxe raccourcie qui représente un exemple d'un Bag dont les membres sont par définition toutes les ressources dont les identificateurs de ressource commence avec une chaîne spécifiée :
[26a] aboutEachAttr ::= 'aboutEach="' URI-reference '"'
| 'aboutEachPrefix="' string '"'
L'attribut aboutEachPrefix déclare qu'il y a un Bag dont les membres sont toutes les ressources dont les identificateurs de ressources complètement résolues commencent avec la chaîne de caractères donnée pour la valeur de l'attribut. Les déclarations dans une Description qui possèdent l'attribut aboutEachPrefix s'appliquent individuellement à chacun des membres de ce Bag.
Par exemple, Si les deux ressources http://foo.org/doc/page1 et http://foo.org/doc/page2 existent alors nous pouvons dire que chacune d'elles a une propriété de droit de copie en écrivant
<rdf:Description aboutEachPrefix="http://foo.org/doc"> <s:DroitDeCopie>© 1998, Organisation Foo</s:DroitDeCopie> </rdf:Description>
S'il existe seulement deux ressources dont les URIs démarrent avec cette chaîne alors on peut réécrire un équivalent de la manière suivante :
<rdf:Description about="http://foo.org/doc/page1"< <s:DroitDeCopie>© 1998, Organisation Foo</s:DroitDeCopie> </rdf:Description> <rdf:Description about="http://foo.org/doc/page2"< <s:DroitDeCopie>© 1998, Organisation Foo</s:DroitDeCopie> </rdf:Description>
et
<rdf:Description aboutEach="#docpages"< <s:DroitDeCopie>© 1998, Organisation Foo</s:DroitDeCopie> </rdf:Description> <rdf:Bag ID="docpages"> <rdf:li resource="http://foo.org/doc/page1"< <rdf:li resource="http://foo.org/doc/page2"/< </rdf:Bag>
Une ressource peut posséder plusieurs déclarations avec le même prédicat (c.-à-d., utilisant la même propriété). Ce n'est pas la même chose que d'avoir une déclaration unique dont l'objet est un conteneur contenant plusieurs membres. Le choix de l'utilisation de l'un ou l'autre dans des cirscontances particulières est en partie fait par la personne qui conçoit le schéma et en partie fait par la personne qui écrit les déclarations RDF spécifiques.
Considérez l'exemple, la relation entre un écrivain et ses publications. Vous pourrez avoir la phrase
Sue a écrit "Anthologie du temps", "Réflexions zoologiques", "Reflets gravitationnels".
Soit, il y a 3 ressources, chacune a été écrite indépendamment par le même écrivain.
Figure 6: Propriété répétée
Dans cet exemple, il n'y a pas d'autres relations déclarées entre les publications que celle qu'elles qui ont été écrites par la même personne.
En revanche, la phrase
La commission de Fred, Wilma, et Dino a approuvé la résolution.
dit que les 3 membres de la commission dans son ensemble a voté d'une certaine manière ; mais cela ne dit pas nécessairement si chacun des membres de la commission a voté en faveur de l'article. Il ne serait pas exact de modéliser cette phrase avec trois déclarations séparées ApprouvéPar, une pour chacun des membres, car cela déterminerait le vote de chacun des membres. Il est plutôt préférable de modeler ceci avec une déclaration unique ApprouvéPar dont l'objet est un Bag contenant les identités des membres de la commission :
Figure 7: Utilisation de Bag pour indiquer une opinion collective
Le choix de la représentation à utiliser, Bag ou propriété répétée, est fait par la personne créant les métadonnées selon le schéma donné. Si, par exemple, dans l'exemple précédent de publications, nous souhaitions dire que l'ensemble des publications était donné alors le schéma pourra inclure une propriété appelée publications dans ce but. La valeur de la propriété publications serait alors un Bag listant tous les travaux de Sue.
En plus de créer des déclarations à propos des ressources Web, RDF peut être utilisé pour créer des déclarations à propos d'autres déclarations RDF. Nous les appellerons déclarations d'ordre supérieur. Afin de créer une déclaration à propos d'une autre déclaration, nous avons à construire un modèle pour la déclaration originale ; ce modèle est une nouvelle ressource à laquelle nous pouvons attacher des propriétés supplémentaires.
Des déclarations sont faites à propos de ressources. Un modèle d'une déclaration est la ressource dont nous avons besoin pour pourvoir faire de nouvelles déclarations (déclarations d'ordre supérieur) à propos de la déclaration modélisée.
Par exemple, considérons la phrase
Ora Lassila est le créateur de la ressource http://www.w3.org/Home/Lassila.
RDF devrait considérer cette phrase comme un fait. Si, à la place, nous écrivons la phrase
Ralph Swick dit que Ora Lassila est le créateur de la ressource http://www.w3.org/Home/Lassila.
nous n'avons rien dit à propos de la ressource http://www.w3.org/Home/Lassila ; à la place, nous avons exprimé un fait à propos d'une déclaration fait par Ralph. Afin de formuler ce fait avec RDF, nous devons modéliser la déclaration originale comme une ressource avec quatre propriétés. Ce procédé est formellement appelé réification dans la communauté de la Représentation des connaissances (KR). Un modèle de déclaration est appelé une déclaration réifiée.
Pour modéliser les déclarations, RDF définit les propriétés suivantes :
Une nouvelle ressource avec les quatres propriétés précédentes représentent la déclaration originale et peut être utilisée aussi bien comme l'objet d'autre déclarations et avoir des déclarations supplémentaires réalisées à son propos. La ressource avec ces quatres propriétés n'est pas un remplacement de la déclaration originale, c'est un modèle de la déclaration. Une déclaration et sa déclaration réifiée correspondante existe indépendemment dans un graphe RDF et peut toujours être présente sans les autres. Le graphe RDF est considéré comme contenant le fait donné dans la déclaration si et seulement si la déclaration est présente dans le graphe, quelque soit l'état de présence de la déclaration correspondante réifiée.
Pour modéliser l'exemple précédent, nous pouvons joindre une autre propriété à la déclaration réifiée (disons, "attribuéA") avec une autre valeur appropriée (dans ce cas, "Ralph Swick"). En utilisant la syntaxe RDF/XML de base, ceci peut être écrit par
<rdf:rdf xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:a="http://description.org/schema/"> <rdf:description> <rdf:subject resource="http://www.w3.org/Home/Lassila" /> <rdf:predicate resource="http://description.org/schema/Creator" /> <rdf:object>Ora Lassila</rdf:object> <rdf:type resource="http://www.w3.org/1999/02/22-rdf-syntax-ns#Statement" /> <a:attribuéa>Ralph Swick</a:attribuéa> </rdf:description> </rdf:rdf>
Figure 8 représente ceci sous la forme d'un graphe. Syntaxiquement, ceci est un peu trop prolixe ; dans la Section 4.2. nous présentons un raccourci pour créer des déclarations à propos des déclarations.
Figure 8: Représentation d'une déclaration réifiée
La réification est également nécessaire pour représenter explicitement dans le modèle le groupement de déclaration induit par les éléments Description. Le modèle RDF de graphe n'a pas besoins de construction spéciale pour les Descriptions ; alors que les Descriptions sont vraiment une collection de déclarations, un conteneur Bag est utilisé pour indiquer qu'un ensemble de déclarations vient de la même Description (syntaxique). Chaque déclaration à l'intérieur d'une Description est réifiée et chacune des déclarations réifiées est un membre du Bag représentant cette Description. Pour exemple, le fragment RDF
<rdf:RDF> <rdf:Description about="http://www.w3.org/Home/Lassila" bagID="D_001"> <s:Créateur>Ora Lassila</s:Créateur> <s:Titre>Ora's Home Page</s:Titre> </rdf:Description> </rdf:RDF>
devrait donner le graphe de la figure 9.
Figure 9: Utilisation du Bag pour représenter le groupement de déclaration
Notez le nouvel attribut bagID. Cet attribut spécifie la ressource id de la ressource conteneur :
[2b] description ::= '<rdf:Description' idAboutAttr? bagIDAttr? propAttr* '/>'
| '<rdf:Description' idAboutAttr? bagIDAttr? propAttr* '>'
propertyElt* '</rdf:Description>'
[27] bagIDAttr ::= 'bagID="' IDsymbol '"'
BagID et ID ne devrait pas être confondus. ID spécifie l'indentification d'une ressource interne dont les propriétés sont détaillés plus loin dans la Description. BagID spécifie l'indentification de la ressource du contenur dont les membres sont les déclarations réifiées à propos d'une autre ressource. Une Description peut avoir un attribut ID comme un attribut bagID.
Attacher un bagID à une Description est équivalent à inclure dans le modèle un Bag des déclarations réifiées de la Description, nous pouvons utiliser ceci comme raccourci syntaxique lors des déclarations à propos des déclarations. Par exemple, si nous voulons dire que Ralph a affirmé que Ora est le créateur de http://www.w3.org/Home/Lassila et qu'il a affirmé egalement que le titre de cette ressource est "Ora's Home Page", nous pouvons simplement ajouter à l'exemple précédent
<rdf:Description aboutEach="#D_001"> <a:attribuéA>Ralph Swick</a:attribuéA> </rdf:Description>
Notez que cet exemple de raccourci inclue des faits supplémentaires dans le modèle qui ne sont pas représentés dans la figure 8. Cette utilisation de raccourci exprime des faits à propos des déclarations de Ralph mais également des faits à propos de la page d'accueil d'Ora.
Figure 10: Représentation des déclarations à propos des déclarations
Le lecteur est invité à lire la Section 5 ("Modèle formel") de cette spécification pour un traitement plus formel des déclarations d'ordre supérieur et de la réification.
Cette spécification montre trois représentations d'un modèle de données ; comme 3-tuples (triples), comme un graphe, et en XML. Ces représentations ont des significations équivalentes. La correspondance entre les représentations utilisées dans cette spécification n'a pas été réalisée dans le but de contraindre en aucune manière la représentation interne qui serait choisie dans les implémentations.
Le modèle de données RDF est formellement défini comme suit :
Nous pouvons voir un ensemble de déclarations (membres de Déclarations) comme un graphe directement légendé : chaque ressource et chaque littéral est un sommet (vertex) ; un triplet {p, s, o} est d'un arc de s vers o, légendé par p. Ceci est illustré dans la figure 11.
Figure 11: Gabarit de graphe de déclaration simple
Ceci peut être également lu
o est la valeur de p pour s
ou (de gauche à droite)
s a une propriété p avec une value o
ou encore
le p de s est o
Par exemple, la phrase
Ora Lassila est le créateur de la ressource http://www.w3.org/Home/Lassila
devrait être représentée graphiquement ainsi :
Figure 12 : Graphe de déclaration simple
et le triplet correspondant (membre de Déclarations) devrait être
{créateur, [http://www.w3.org/Home/Lassila], "Ora Lassila"}
La notation [I] indique que la ressource est identifiée par une URI nommée I et les guillemets indique un littéral.
En utilisant les triplets, nous pouvons expliquer comment les déclarations sont réifiées (comme présenté dans la Section 4). Soit une déclaration
{créateur, [http://www.w3.org/Home/Lassila], "Ora Lassila"}
nous pouvons exprimer la réification de ceci comme une nouvelle ressource X ainsi :
{type, [X], [RDF:Statement]}
{predicate, [X], [créateur]}
{subject, [X], [http://www.w3.org/Home/Lassila]}
{object, [X], "Ora Lassila"}
Du point de vue d'un processeur RDF, des faits (c.-à-d., des déclarations) sont des triplets qui sont membres de Déclarations. Par conséquent, la déclaration originale reste un fait malgré qu'elle soit réifiée puisque la déclaration originale reste dans Déclarations. Nous avons simplement ajouté 4 triplets de plus.
La propriété appelée "type" est définie afin de fournir un typage primitif. La définition formelle de type est :
|
Ainsi, la spécification formelle de réification est :
|
La ressource r dans la définition précédente est appelée la déclaration réifiée. Lorsqu'une ressource représente une déclaration réifiée ; c.-à-d., elle possède une propriété RDF:type avec une valeur de RDF:Statement, alors cette ressource doit avoir exactement une propriété RDF:subject, une propriété RDF:object, et une propriété RDF:predicate.
Comme décrit dans la Section 3, il est fréquemment nécessaire de représenter une collection de ressources ou de littéraux ; par exemple pour affirmer qu'une propriété possède une séquence ordonnée de valeurs. RDF définit trois sortes de collections : listes ordonnées, appelées Séquences, listes non ordonnées, appelées Bags, et listes qui représentent des alternatives pour la valeur (unique) d'une propriété, appelée Alternatives.
Formellement, ces trois types de collections sont définis par :
|
Pour réprésenter une collection c, créez un triplet {RDF:type, c, t} où t est l'un des trois types de collection RDF:Seq, RDF:Bag, ou RDF:Alt. Les triplets restants {RDF:_1, c, r1}, ..., {RDF:_n, c, rn}, ... pointent vers chacun des membres rn de la collection. Pour une ressource de collection, il peut y avoir au plus un triplet dont le prédicat est n'importe quel élement donné de Ord et les éléments de Ord doivent être utilisés dans une séquence démarrant par RDF:_1. Pour les ressources qui sont des exemples du type de la collection RDF:Alt, il doit y avoir exactement un triplet dont le prédicat est RDF:_1 et qui est la valeur par défaut pour la ressource Alternatives (c.-à-d., il doit toujours y avoir une alternative).
Le BNF complet pour RDF est reproduit ici à partir des sections précédentes. L'interprétation précise de la grammaire en termes de modèle formel est également donnée. Les options syntaxiques héritées de XML ne sont pas reproduites ici. Ceci inclue toutes les contraintes de formatage correct, l'utilisation des espaces autour des attributs et le '=', ainsi que l'utilisation des guillements doubles ou bien simples autour des valeurs d'attribut. Cette section est rédigée pour les développeurs qui créent les outils qui lisent et interprètent la syntaxe RDF/XML.
Tel qu'utilisé plus bas, les mots clés "DEVRAIT", "DOIT", et "NE DOIT PAS" doivent être interprêtés tels que définis dans la RFC 2119 [RFC2119]. Cependant, par lisibilité, ces mots n'apparaissent pas en lettres majuscules dans cette spécification.
[6.1] RDF ::= ['<rdf:RDF>'] obj* ['</rdf:RDF>']
[6.2] obj ::= description | container
[6.3] description ::= '<rdf:Description' idAboutAttr? bagIdAttr? propAttr* '/>'
| '<rdf:Description' idAboutAttr? bagIdAttr? propAttr* '>'
propertyElt* '</rdf:Description>'
| typedNode
[6.4] container ::= sequence | bag | alternative
[6.5] idAboutAttr ::= idAttr | aboutAttr | aboutEachAttr
[6.6] idAttr ::= ' ID="' IDsymbol '"'
[6.7] aboutAttr ::= ' about="' URI-reference '"'
[6.8] aboutEachAttr ::= ' aboutEach="' URI-reference '"'
| ' aboutEachPrefix="' string '"'
[6.9] bagIdAttr ::= ' bagID="' IDsymbol '"'
[6.10] propAttr ::= typeAttr
| propName '="' string '"' (with embedded quotes escaped)
[6.11] typeAttr ::= ' type="' URI-reference '"'
[6.12] propertyElt ::= '>' propName idAttr? '>' value '</' propName '>'
| '>' propName idAttr? parseLiteral '>'
literal '</' propName '>'
| '>' propName idAttr? parseResource '>'
propertyElt* '</' propName '>'
| '>' propName idRefAttr? bagIdAttr? propAttr* '/>'
[6.13] typedNode ::= '>' typeName idAboutAttr? bagIdAttr? propAttr* '/>'
| '>' typeName idAboutAttr? bagIdAttr? propAttr* '>'
propertyElt* '</' typeName '>'
[6.14] propName ::= Qname
[6.15] typeName ::= Qname
[6.16] idRefAttr ::= idAttr | resourceAttr
[6.17] value ::= obj | string
[6.18] resourceAttr ::= ' resource="' URI-reference '"'
[6.19] Qname ::= [ NSprefix ':' ] name
[6.20] URI-reference ::= string, interpreted per [URI]
[6.21] IDsymbol ::= (any legal XML name symbol)
[6.22] name ::= (any legal XML name symbol)
[6.23] NSprefix ::= (any legal XML namespace prefix)
[6.24] string ::= (any XML text, with "<", ">", and "&" escaped)
[6.25] sequence ::= '<rdf:Seq' idAttr? '>' member* '</rdf:Seq>'
| '<rdf:Seq' idAttr? memberAttr* '/>'
[6.26] bag ::= '<rdf:Bag' idAttr? '>' member* '</rdf:Bag>'
| '<rdf:Bag' idAttr? memberAttr* '/>'
[6.27] alternative ::= '<rdf:Alt' idAttr? '>' member+ '</rdf:Alt>'
| '<rdf:Alt' idAttr? memberAttr? '/>'
[6.28] member ::= referencedItem | inlineItem
[6.29] referencedItem ::= '<rdf:li' resourceAttr '/>'
[6.30] inlineItem ::= '<rdf:li' '>' value </rdf:li>'
| '<rdf:li' parseLiteral '>' literal </rdf:li>'
| '<rdf:li' parseResource '>' propertyElt* </rdf:li>'
[6.31] memberAttr ::= ' rdf:_n="' string '"' (where n is an integer)
[6.32] parseLiteral ::= ' parseType="Literal"'
[6.33] parseResource ::= ' parseType="Resource"'
[6.34] literal ::= (any well-formed XML)
Le nom formel de l'espace de nom pour les propriétés et les classes définies dans cette spécification est http://www.w3.org/1999/02/22-rdf-syntax-ns#. Lorsque un processeur RDF rencontre un élément XML ou un nom d'attribut qui est déclaré être originaire d'un espace de nom dont le nom commence par la chaîne de caractères "http://www.w3.org/TR/REC-rdf-syntax" et que le processeur ne reconnaît pas les sémantiques de ce nom alors le processeur doit ignorer (c.-à-d., ne pas générer de tuples pour) l'élément XML complet, y compris son contenu, dont le nom est inconnu ou qui a un attribut dont le nom est inconnu.
Chaque propertyElt E contenu par un élément Description donne la création d'un triplet {p,r,v} où :
L'attribut parseType change l'interprétation du contenu de l'élément. L'attribut parseType devrait avoir une des valeurs 'Literal' ou 'Resource'. La valeur est sensible à la casse. La valeur 'Literal' spécifie que le contenu de l'élément doit être traité comme un litéral RDF/XML ; c.-à-d., le contenu ne doit pas être interprêté par un processeur RDF. La valeur 'Resource' spécifie que le contenu de l'élément doit être traité comme s'il était le contenu d'un élément Description. D'autres valeurs de parseType sont réservées pour des spécifications futures de RDF. Avec RDF 1.0, les autres valeurs doivent être traitées de façon identique à 'Literal'. Dans tous les cas, le contenu d'un élément ayant un attribut parseType doit être un document XML bien formé. Le contenu d'un élément ayant un attribut parseType="Resource" doit davantage correspondre à la production pour le conteneur d'un élément Description.
Le groupe de travail sur la modélisation et la syntaxe RDF reconnaît que le mécanisme parseType='Literal' est une solution minimale au besoin d'exprimer une déclaration RDF avec une valeur qui a un balisage XML. Les complexités supplémentaires de XML tel que la canonisation des espaces blancs ne sont pas encore très bien définies. Les travaux futurs du W3C devront régler de telles questions d'une manière uniforme pour toutes les applications basées sur XML. Les versions futures de RDF hériteront de ce travail et peut-être l'étendront au fur et à mesure de l'expérience tirée des applications.
URI-References sont résolus en identificateurs de ressource en premier en résolvant l'URI-reference à une forme absolue comme dans [URI] en utilisant l'URI de base du document dans lesquelles les déclarations RDF apparaissent. Si un identificateur partiel est inclus dans l'URI-reference alors l'identificateur de ressource fait réfèrence uniquement à une sous composante de la ressource contenante ; cette sous composante est identifiée par l'ancre id correspondante interne à cette ressource contenante et l'extension de la sous composante est définie par l'identificateur partiel en conjonction avec le type de contenu de la ressource contenante, sinon l'identificateur de ressource fait référence à l'élément entier spécifié par l'URI.
Note : Bien que les caractères non-ASCII dans les URIs ne soient pas permis par [URI], [XML] spécifie une convention pour éviter les incompatibilités en étendant la syntaxe URI. Les développeurs RDF sont encouragés à éviter d'autres incompatibilités et à utiliser la convention XML pour les identificateurs de système. Nommément, qu'un caractère non-ASCII dans une URI soit représenté en UTF-8 comme un byte ou plus, et alors ces bytes seront "échappés" par le mécanisme d'échappement d'URI (c.-à-d., en convertissant chaque byte par %HH, où HH est la notation hexadécimale de la valeur du byte).
L'élément Description lui-même représente un exemple d'une ressource Bag. Les membres de ce Bag sont les ressources correspondant à la réification de chacune des déclarations dans la Description. Si l'attribut bagID est spécifié, sa valeur est l'identificateur de ce Bag, à moins que le Bag soit anonyme.
Lorsque about est spécifié avec Description, les déclarations dans Description font référence à la ressource appelée dans about. Un élément Description sans un attribut about représente une ressource interne. La ressource interne a un identificateur de ressource formé en utilisant la valeur de la base de l'URI du contenu contenant les déclarations RDF plus une ancre id égale à la valeur de l'attribut ID attribute de l'élément Description, s'il existe. Quand une autre Description ou valeur de propriété fait référence à une ressource interne, elle utilisera la valeur de ID dans un attribut about. Quand l'autre Description fait référence au Bag des ressources correspondant des ressources réifiées, elle utilisera la valeur de bagID dans un attribut about. Aussi bien ID ou about peuvent être spécifiés dans Description mais pas simultanément ensemble dans le même ensemble. Les valeurs de chaque attribut ID et bagID ne doivent pas apparaître dans plus d'un tel attribut à l'intérieur d'un document ou bien la même valeur ne peut être utilisée dans un ID et un bagID à l'intérieur d'un document unique.
Lorsque aboutEach est spécifié avec Description, les déclarations dans Description font référence à chacun des membres du conteneur appelé par aboutEach. Les triplets {p,r,v} représentés par chaque propertyElt E contenu tel que décrit au-dessus sont dupliqués pour chaque r qui est un membre du conteneur.
Lorsque aboutEachPrefix est spécifié avec Description, les déclarations dans Description font référence à chacun des membres d'un conteneur Bag anonyme. Les membres de ce conteneur Bag sont toutes les ressources dont les identificateurs de la ressource de forme absolue sont la chaîne de caractères donnée par la valeur de aboutEachPrefix. L'identificateur de la ressource de forme absolue est produit en résolvant l'URI selon l'algorythme de la Section 5.2., Résoudre les références relatives en une forme absolue, dans [URI]. Les triplets {p,r,v} représentés par chaque propertyElt E contenue comme décrit précédemment, sont dupliqués pour chaque r qui est un membre du conteneur.
Seq, Bag, et Alt représentent respectivement, chacun un cas de type de ressource de conteneur Sequence, Bag, ou Alternative. Un triplet {RDF:type,c,t} est créé où c est la ressource collection et t est l'un des RDF:Seq, RDF:Bag, ou RDF:Alt. Les membres de la collection sont notés par li. Chaque élément li de E correspond à un membre de la collection et résulte en la création d'un triplet {p,c,v} où :
L'URI identifie (après résolution la ressource cible ; c.-à-d., la ressource à laquelle Description s'applique ou la ressource qui est incluse dans le conteneur. L'attribut bagID sur un élément Description et l'attribut ID sur un élément conteneur qui permet cette Description ou un conteneur référencé par d'autres Descriptions. L'ID sur un élément conteneur est le nom qui est utilisé dans un attribut resource sur un élément propriété pour réaliser la collection de la valeur de cette propriété.
A l'intérieur propertyElt (production [6.12]), L'URI utilisée dans un attribut resource s'identifie (après résolution) la ressource qui est l'objet de la déclaration (c.-à-d., la valeur de cette propriété). La valeur de l'attribut ID, si spécifié, est l'identificateur pour ressource qui représente la réification de la déclaration. Si une expression RDF (c.-à-d., contenu avec un balisage RDF/XML) est spécifiée comme une valeur de propriété, l'objet est la ressource donnée par l'attribut about de la Description contenue ou de l'ID (possiblement en cause) de la Description ou de la ressource conteneur. Strings doivent être du XML bien formé ; les mécanismes de mise en guillemet et d'échappement du contenu XML courant peuvent être utilisés si la chaîne contient des séquences de caractères (e.g., "<" and "&") qui violent les règles des documents bien formés ou qui autrement pourrait ressembler à du balisage. L'attribut parseType="Literal" spécifie que le contenu de l'élément est un littéral RDF. Tout balisage qui est une partie de ce contenu est inclus comme une partie du littéral et n'est pas interprété par RDF.
Il est recommandé que les noms de propriété soient toujours qualifiés avec un préfixe d'espace nominatif pour relier la définition de la propriété avec le schéma correspondant de façon unique.
Comme défini par XML, le répertoire de caractères d'une chaîne RDF est l'ISO/IEC 10646 [ISO10646]. Une chaîne RDF courante, que ce soit dans un document XML ou dans une autre représentation de modèle de données RDF, peut être stockée en utilisant un encodage direct en ISO/IEC 10646 ou un encodage dont il est possible de faire une correspondance à ISO/IEC 10646. La balise de langage fait partie de la valeur de la chaîne ; elle s'applique aux séquences de caractères à l'intérieur d'une chaîne RDF et ne possède pas de manifestation explicite dans le modèle de données.
Deux chaînes RDF sont considérées être identiques si leurs représentations ISO/IEC 10646 correspondent. Chaque application RDF doit spécifier laquelle des deux définitions suivantes de 'correspond' elle utilise :
Note : Le W3C I18N WG (Groupe de Travail sur l'internationalisation) travaille sur une définition à propos de l'identité des chaînes correspondantes. Cette définition sera probablement basée sur des équivalences canoniques en accord avec le standard Unicode et sur les principes de normalisation uniforme du début. Les utilisateurs de RDF ne devraient pas avoir confiance en des applications de correspodance utilisant les équivalents canoniques, mais devraient essayer de s'assurer que leurs données sont dans la forme normalisée telle que définie dans les définitions précédentes.
Cette spécification n'impose pas un mécanisme pour déterminer les équivalences entre les littéraux qui contiennent un balisage, et non plus si un tel mécanisme est existant.
L'attribut xml:lang peut être utilisé comme défini dans [XML] pour associer une langue avec la valeur de la propriété. Il n'existe pas de représentation spécifique de modèle de données pour xml:lang (c.-à-d., il n'ajoute aucun triplet au modèle de donnée) ; la langue d'un littéral est considéré par RDF comme étant une partie de ce littéral. Une application peut ignorer le balisage de langue d'une chaîne. Toutes les applications RDF doivent spécifier si le balisage de langue dans les littéraux est pris en considération ; c.-à-d., si oui ou non la langue est considérée lorsqu'il y a établissement de correspondance entre chaînes ou traitement d'un autre type.
Les attributs dont les noms commencent avec "xmlns" sont des déclarations d'espace de nom et ne représentent pas de triplets dans le modèle de données. Il n'y a pas de représentation spécifique de modèle de données pour de telles déclarations d'espace de nom.
Chaque propriété et valeur exprimées sous la forme d'attribut XML par les productions [6.3] et [6.10] est équivalente à la même propriété et valeur exprimées sous la forme d'un contenu XML correspondant à Description en accord avec la production [6.12]. Spécifiquement ; chaque attribut XML A spécifié avec une balise de début Description autre que les attributs ID, about, aboutEach, aboutEachPrefix, bagID, xml:lang, ou tout autre attribut commençant avec le caractère xmlns résulte dans la création d'un triplet {p,r,v} où :
Grammaticalement, la production [6.11] est juste un cas spécial de la production [6.10] propName. La valeur de l'attribut type est interprêtée comme une référence-URI et développée de la même manière que la valeur de l'attribut resource. L'utilisation de [6.11] est équivalente à l'utilisation rdf:type comme un nom d'élément (propriété) accompagné d'un attribut de resource.
La forme typedNode (production [6.13]) peut être utilisée pour représenter des cas de ressources de types spécifiques et également pour décrire ces ressources. Une Description exprimée dans une forme typedNode par une production [6.13] est équivalente à la même Description exprimée par la production [6.3] avec les mêmes attributs ID, bagID, et about plus une propriété de type supplémentaire dans la Description où la valeur de la propriété de type est la ressource dont l'identificateur est donné par l'URI complètement développée et résolue correspondant au typeName du typedNode. Spécifiquement, un typedNode représente un triplet {RDF:type,n,t} où n est la ressource dont l'identificateur est donné par la valeur de l'attribut about (après résolution) ou dont l'ancre id est donnée par la valeur de l'attribut ID de l'élément typedNode, et t est le développement du nom de la balise de l'espace de nom qualifié. Le reste des attributs typedNode et le contenu est pris en compte comme précédemment pour les éléments Description.
Les propriétés et les valeurs exprimées sous la forme d'un attribut XML à l'intérieur d'un élément XML vide E par les productions [6.10] et [6.12] sont équivalentes aux mêmes propriétés et valeurs exprimées comme le contenu XML d'un unique élément Description D qui devrait devenir le contenu de E. Le référent de D est la valeur de la propriété identifiée par le nom de l'élément XML de E en respect des productions [6.17], [6.2], et [6.3]. Spécifiquement, chaque balise de début propertyElt contenant des spécifications d'attribut autre que ID, resource, bagID, xml:lang, ou tout autre attribut démarrant avec les caractères xmlns résultent dans la création de triplets {p,r1,r2}, {pa1,r2,va1}, ..., {pan,r2,van} où
La valeur de l'attribut bagID, si spécifiée, est l'identificateur pour le Bag correspondant à la Description D ; sinon le Bag est anonyme.
Les exemples suivants illustrent les possibilités de RDF expliquées précédemment.
Une ressource unique peut être la valeur de plus d'une propriété ; c.-à-d. elle peut être l'objet de plus d'une déclaration et ainsi pointée par plus d'un arc. Par exemple, une unique page Web pourrait être partagée entre plusieurs documents et pourrait alors être référencée plus d'une fois dans un "plan du site", ou 2 séquences (ordonnées) différentes des même ressources peuvent être données.
Considérez le cas d'avoir à spécifier l'ensemble des travaux d'un auteur, trié une fois par date de publication et une seconde fois par ordre alphabétique du sujet :
<rdf xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <seq id="JSArticlesParDate"> <li resource="http://www.dogworld.com/Aug96.doc" /> <li resource="http://www.webnuts.net/Jan97.html" /> <li resource="http://www.carchat.com/Sept97.html" /> </seq> <seq id="JSArticleParSujet"> <li resource="http://www.carchat.com/Sept97.html" /> <li resource="http://www.dogworld.com/Aug96.doc" /> <li resource="http://www.webnuts.net/Jan97.html" /> </seq> </rdf>
Cet exemple XML utilise aussi la syntaxe de déclaration de l'espace de nom par défaut pour éliminer le préfixe d'espace de nom.
Figure 13 : Partage des valeurs entre deux séquences
Pour illustrer plus particulièrement le rassemblement, considérez l'exemple d'un document avec deux auteurs spécifiés alphabétiquement, un titre spécifié dans 2 langues différentes, et possédant deux localisations équivalentes sur le Web :
<rdf:rdf xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/metadata/dublin_core#"> <rdf:description about="http://www.foo.com/cool.html"> <dc:creator> <rdf:seq id="CréateursAlphabetParNom"> <rdf:li>Mary Andrew</rdf:li> <rdf:li>Jacky Crystal</rdf:li> </rdf:seq> </dc:creator> <dc:identifier> <rdf:bag id="SitesMirroirs"> <rdf:li rdf:resource="http://www.foo.com.au/cool.html" /> <rdf:li rdf:resource="http://www.foo.com.it/cool.html" /> </rdf:bag> </dc:identifier> <dc:title> <rdf:alt> <rdf:li xml:lang="en">The Coolest Web Page</rdf:li> <rdf:li xml:lang="it">Il Pagio di Web Fuba</rdf:li> </rdf:alt> </dc:title> </rdf:description> </rdf:rdf>
Cet exemple illustre l'utilisation des trois types de collection. L'ordre des créateurs est considéré significatif donc le conteneur Sequence est utilisé pour les traiter. Les localisations sur le Web sont équivalentes ; l'ordre n'est pas significatif, ainsi un Bag est utilisé. Le document possède seulement un unique titre et ce titre a deux variantes, donc le conteneur Alternatives est utilisé.
Note : Dans beaucoup de cas, il est impossible d'avoir une langue préférée parmi plusieurs langues alternatives ; toutes les langues sont considérées comme étant strictement équivalentes. Dans ces cas, l'auteur de la description devrait utiliser un Bag à la place d'un conteneur Alt.
Le modèle de données RDF ne supporte intrinsèquement que des relations binaires ; c.-à-d., une déclaration spécifie une relation entre deux ressources. Dans les exemples suivants, nous montrons la manière recommandée pour représenter des relations arité (arity) d'ordre supérieure en RDF en utilisant uniquement des relations binaires. La technique recommandée est d'utiliser une ressource intermédiaire avec des propriétés supplémentaires de cette ressource donnant les relations restantes. Comme exemple, considérez le sujet de l'un des articles récents de John Smith -- bibliothéconomie (library science). Nous pourrions utiliser le code décimal Dewey pour la bibliothéconomie pour classifier cet article. Les codes décimaux Dewey ne sont pas l'unique schéma de classification des sujets, donc pour identifier la relation du système de classification, nous identifions une ressource supplémentaire qui sera utilisée comme la valeur de la propriété sujet et nous annotons cette ressource avec une propriété supplémentaire qui identifiera le schéma de catégorisation qui est utilisé. Comme spécifié dans la Section 2.3., le noyau RDF inclue une propriété value pour marquer la valeur la plus importante de la relation principale. Le graphe résultant ressemblerait alors à :
Figure 14: Une relation ternaire
qui pourrait être échangée par :
<rdf xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/metadata/dublin_core#" xmlns:l="http://mycorp.com/schemas/my-schema#"> <description about="http://www.webnuts.net/Jan97.html"> <dc:subject rdf:value="020 - Library Science" l:classification="Code Décimal Dewey" /> </description> </rdf>
Note : Dans l'exemple précédent, le même espace de nom est déclaré deux fois. Ceci est souvent requis lorsque les espaces de noms par défaut sont déclarés de façon à ce que les attributs qui ne viennent pas de l'espace de nom de l'élément puissent être spécifiés, comme dans le cas précédent avec l'attribut rdf:value dans l'élément dc:Subject.
Une utilisation habituelle de cette capacité "arity" d'ordre supérieur est lorsque l'on travaille avec les unités de mesure. Le poids d'une personne n'est pas seulement un nombre comme "90", c'est également l'unité de mesure utilisée. Dans ce cas, nous devrions utiliser livres ou bien kilogrammes. Nous pourrions utiliser une relation avec un arc supplémentaire pour enregistrer le fait que John Smith est un gentleman plutôt bien charpenté :
Figure 15 : Unité de mesure en tant que relation ternaire
qui peut être échangée comme :
<rdf xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:n="http://www.nist.gov/units/"> <description about="John_Smith"> <n:weight rdf:parsetype="Resource"> <rdf:value>200</rdf:value> <n:units rdf:resource="http://www.nist.gov/units/Pounds" /> </n:weight> </description> </rdf>
fournit la ressource "Pounds" tel que définie par un schéma NIST avec l'URI http://www.nist.gov/units/Pounds.
Les métadonnées du Dublin Core ont été conçues pour faciliter la recherche des ressources électroniques d'un manière similaire à celle d'un catalogue de fiche de bibliothèque. Ces exemples représentent la description simple d'un ensemble de ressources en RDF utilisant les vocabulaires définis par l'Initiative du Dublin Core. Note : Le vocabulaire RDF du Dublin Core RDF montré ici ne doit pas être considéré comme normatif. L'Initiative du Dublin COre est la seule référence qui fait autorité en la matière.
Voici la description de la page d'accueil d'un site Web en utilisant les propriétés du Dublin Core :
<rdf:rdf xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/metadata/dublin_core#"> <rdf:description about="http://www.dlib.org"> <dc:title>D-Lib Program - Research in Digital Libraries</dc:title> <dc:description>Le programme D-Lib soutient la communauté qui possède des intérêts dans les bibliothèques électroniques et dans la publication numérique.</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>
Le second exemple est à propos d'un magazine publié.
<rdf:rdf xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/metadata/dublin_core#" xmlns:dcq="http://purl.org/metadata/dublin_core_qualifiers#"> <rdf:description 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 rdf:parsetype="Resource"> <dcq:agenttype rdf:resource="http://purl.org/metadata/dublin_core_qualifiers#Editor" /> <rdf:value>Amy Friedlander</rdf:value> </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>urn:issn:1082-9873</dc:identifier> <dc:relation rdf:parsetype="Resource"> <dcq:relationtype rdf:resource="http://purl.org/metadata/dublin_core_qualifiers#IsPartOf" /> <rdf:value resource="http://www.dlib.org" /> </dc:relation> </rdf:description> </rdf:rdf>
Le troisième exemple est un article spécifique dans le magazine référencé par l'exemple précédent.
<rdf:rdf xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/metadata/dublin_core#" xmlns:dcq="http://purl.org/metadata/dublin_core_qualifiers#"> <rdf:description 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> <dc:relation rdf:parsetype="Resource"> <dcq:relationtype rdf:resource="http://purl.org/metadata/dublin_core_qualifiers#IsPartOf" /> <rdf:value resource="http://www.dlib.org/dlib/may98/05contents.html" /> </dc:relation> </rdf:description> </rdf:rdf>
Note : Les développeurs de schéma peuvent être tentés de déclarer les valeurs de certaines propriétés pour qu'elles utilisent une syntaxe correspondant à l'abbréviation du nom qualifié de l'espace de nom XML. Nous recommandons de ne pas utiliser ces noms qualifiés à l'intérieur des valeurs de propriétés car cela peut entraîner des incompatibilités avec des mécanismes futurs de typage de données XML. De plus, ceux qui sont experts des possibilités de XML 1.0 reconnaîtront qu'un mécanisme d'abbréviation similaire existe dans les entités définies par les utilisateurs. Nous recommandons également de ne pas se reposer sur l'utilisation des entités car il y a une proposition pour définir un futur sous-ensemble de XML qui n'inclue pas les entités définies par l'utilisateur.
Lorsqu'une valeur de propriété est un littéral qui contient un balisage XML, la syntaxe suivante est utilisé pour signaler à l'analyseur syntaxique RDF de ne pas interpréter le balisage mais plutôt de le retenir comme faisant partie de la valeur. La représentation précise de la valeur résultante n'est pas spécifiée ici.
Dans l'exemple suivant, la valeur de la propriété Title est un littéral contenant du balisage MATHML.
<rdf:description xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/metadata/dublin_core#" xmlns="http://www.w3.org/TR/REC-mathml" rdf:about="http://mycorp.com/papers/NobelPaper1"> <dc:title rdf:parsetype="Literal"> Ramifications of <apply> <power /> <apply> <plus /> <ci>a</ci> <ci>b</ci> </apply> <cn>2</cn> </apply> to World Peace </dc:title> <dc:creator>David Hume</dc:creator> </rdf:description>
La Plateforme pour la Sélection des Contenus Internet (Platform for Internet Content Selection) (PICS) est une recommandation du W3C pour échanger les descriptions de contenu des pages Web et autre matériau. PICS est un prédécesseur de RDF et il est une necessité explicite de RDF qui est capable d'exprimer toutes les choses qui peuvent être exprimées dans un label PICS.
Voici un exemple de représentation d'un label PICS sous la forme RDF. Notez qu'un travail pour redéfinir PICS lui-même comme une application de RDF pourra suivre la sortie de la spécification RDF, ainsi l'exemple suivant ne devra pas être considéré comme un exemple faisant autorité d'un futur schéma PICS. Cet exemple vient directement de [PICS]. Notez que la Description de Service de Classification de PICS est exactement analogue à un schéma RDF ; les catégories décrites dans un tel fichier de description des services de classification sont équivalentes aux propriétés dans le modèle RDF.
<rdf:rdf xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:pics="http://www.w3.org/TR/xxxx/WD-PICS-labels#" xmlns:gcf="http://www.gcf.org/v2.5"> <rdf:description about="http://www.w3.org/PICS/Overview.html" bagid="L01" gcf:suds="0.5" gcf:density="0" gcf:color.hue="1" /> <rdf:description about="http://www.w3.org/PICS/Underview.html" bagid="L02" gcf:subject="2" gcf:density="1" gcf:color.hue="1" /> <rdf:description abouteach="#L01" pics:by="John Doe" pics:on="1994.11.05T08:15-0500" pics:until="1995.12.31T23:59-0000" /> <rdf:description abouteach="#L02" pics:by="Jane Doe" pics:on="1994.11.05T08:15-0500" pics:until="1995.12.31T23:59-0000" /> </rdf:rdf>
Notez que aboutEach est utilisé pour indiquer que les options du label PICS font référence aux déclarations individuelles (de classification) et non pas au conteneur dans lequel ces déclarations sont fournies.
[PICS] définit également un type appelé label générique. Un label générique PICS est un label qui s'appliquent à toutes les pages à l'intérieur de la portion spécifique d'un site Web.
Voici un exemple de comment un label PICS générique devrait être écrit en RDF, en utilisant le constructeur de collection aboutEachPrefix Cet exemple est tiré de l'exemple "Generic request" de l'Annexe B de [PICS]:
<rdf:rdf xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:pics="http://www.w3.org/TR/xxxx/WD-PICS-labels#" xmlns:ages="http://www.ages.org/our-service/v1.0/"> <rdf:description abouteachprefix="http://www.w3.org/WWW/" bagid="L03" ages:age="11" /> <rdf:description abouteach="#L03" pics:by="abaird@w3.org" /> </rdf:rdf>
La propriété age avec la valeur "11" apparaît sur chaque ressource dont l'URI démarre avec la chaîne "http://www.w3.org/WWW/". La déclaration réifiée correspondant à chacune des déclarations ("L'age de [I] est 11") a une propriété déclarant que "abaird@w3.org" était responsable pour la création de ces déclarations.
RDF, étant du XML bien formé, est adéquat pour l'inclusion directe dans un document HTML quand l'agent utilisateur suit les recommandations HTML pour la gestion des erreurs dans les documents non valides. Quand un fragment de RDF est incorporé dans un document HTML, certains navigateurs afficheront tout contenu de chaîne présent. Le contenu de chaîne présent est tout ce qui apparaît entre le ">" qui finit une balise et le "<" qui commence la prochaine balise. Généralement, de multiples caractères d'espace consécutifs y compris les caractères de fin de ligne sont interprêtés comme un unique espace.
La syntaxe abrégée RDF peut fréquemment être utilisée pour écrire les valeurs de propriétés qui sont des chaînes sous la forme d'attribut XML et laisser seulement les espaces comme un contenu présent. Par exemple, la première partie de l'exemple du Dublin Core de la Section 7.4. pourrait être écrit comme ceci :
<rdf:rdf xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/metadata/dublin_core#"> <rdf:description about="http://www.dlib.org" dc:title="D-Lib Program - Research in Digital Libraries" dc:description="The D-Lib program supports the community of people with research interests in digital libraries and electronic publishing." dc:publisher="Corporation For National Research Initiatives" dc:date="1995-01-07" /> </rdf:rdf>
Réécrire pour éviter le contenu exposé réussira dans dans la plupart des cas. Un cas courant mais moins évident sont les descriptions de conteneur. Considérez la première partie de l'exemple dans la Section 7.2.:
<rdf:rdf xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/metadata/dublin_core#"> <rdf:description about="http://www.foo.com/cool.html"> <dc:creator> <rdf:seq id="CréateursAlphabetParNom"> <rdf:li>Mary Andrew</rdf:li> <rdf:li>Jacky Crystal</rdf:li> </rdf:seq> </dc:creator> </rdf:description> </rdf:rdf>
Pour réécrire ceci sans contenu exposé, nous utilisons la forme suivante :
<rdf:rdf xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/metadata/dublin_core#"> <rdf:description about="http://www.foo.com/cool.html"> <dc:creator> <rdf:seq id="CréateursAlphabetParNom" rdf:_1="Mary Andrew" rdf:_2="Jacky Crystal" /> </dc:creator> </rdf:description> </rdf:rdf>
Notez ici que l'élément li ne peut pas être utilisé comme un attribut à cause de la règle XML interdisant les occurences multiples du même nom d'attribut à l'intérieur d'une balise. Par conséquent, nous utilisons les propriétés RDF Ord explicites ; qui développe manuellement l'élément li.
Un document HTML complet contenant des métadonnées RDF se décrivant lui-même est donné par :
<html> <head> <rdf:rdf xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/metadata/dublin_core#"> <rdf:description about=""> <dc:creator> <rdf:seq id="CreatorsAlphabeticalBySurname" rdf:_1="Mary Andrew" rdf:_2="Jacky Crystal" /> </dc:creator> </rdf:description> </rdf:rdf> </head> <body> <p>Voici un bon document.</p> </body> </html>
Le document HTML au-dessus devrait être accepté par tous les navigateurs compatibles avec HTML 3.2 et versions supérieures et devrait seulement afficher les caractères "Voici un bon document."
Cette spécification est le travail du groupe de travail W3C sur le modèle et la syntaxe RDF. Ce groupe de travail a été principalement piloté par Eric Miller du Online Computer Library Center et par Bob Schloss d'IBM. Nous remercions Eric et Bob pour leurs efforts inlassables pour maintenir le groupe dans la bonne voie et nous remercions spécialement OCLC, IBM et Nokia pour les avoir aider et soutenu dans cette initiative, ainsi que nous.
Les membres de ce groupe de travail qui ont aidé dans la conception de cette spécification, qui ont débattu les propositions, qui ont fourni une argumentation, qui ont relu les nombreux brouillons et qui ont finalement permis d'atteindre le consensus sont : Ron Daniel (DATAFUSION), Renato Iannella (DSTC), Tsuyoshi SAKATA (DVL), Murray Maloney (Grif), Bob Schloss (IBM), Naohiko URAMOTO (IBM), Bill Roberts (KnowledgeCite), Arthur van Hoff (Marimba), Charles Frankston (Microsoft), Andrew Layman (Microsoft), Chris McConnell (Microsoft), Jean Paoli (Microsoft), R.V. Guha (Netscape), Ora Lassila (Nokia), Ralph LeVan (OCLC), Eric Miller (OCLC), Charles Wicksteed (Reuters), Misha Wolf (Reuters), Wei Song (SISU), Lauren Wood (SoftQuad), Tim Bray (Textuality), Paul Resnick (University of Michigan), Tim Berners-Lee (W3C), Dan Connolly (W3C), Jim Miller (W3C, emeritus), Ralph Swick (W3C). Dan Brickley (UK Bristol) a rejoint l'activité Schéma RDF et nous a apporté beaucoup de sagesse dans les étapes finales de ce travail. Martin Dürst (W3C) a revisé plusieurs brouillons de travail et fait un grand nombre de suggestions pour l'amélioration en faveur du groupe de travail sur l'internationalisation du W3C. Janne Saarela (W3C) a rendu un service inestimable en créant une implémentation « propre » de nos brouillons de travail.
Ce document est le travail du groupe. Les éditeurs redevables du groupe de travail pour les avoir aidé à créer et parfaire cette spécification.
Les termes suivants sont utilisés dans cette spécification avec des degrés variables de signification intuitive et précise. Les définitions résumées ici ne le sont qu'à titre indicatif ; elles ne sont pas normatives. Lorsque c'est approprié, la localisation dans le document de la définition précise est donnée également.
Les descriptions peuvent être associées avec la ressource qu'ils décrivent de l'une des quatres façons suivantes :
Toutes les ressources ne supporteront pas toutes les méthodes d'association. En particulier, plusieurs sortes de ressource ne supporteront pas l'enchassement et seulement certaines sortes de ressources pourront être enveloppées.
Une description compréhensible par un humain ou une machine d'un schéma RDF peut être obtenue grâce à la négociation de contenu en utilisant l'URI du schéma. Si le schéma est compréhensible par la machine, il peut être possible pour une application d'apprendre quelquechose de la sémantique des propriétés appelées dans le schéma à la demande. La logique et la syntaxe des schémas RDF sont décrites dans un document séparé, [RDFSchema].
La technique recommandée pour les expressions RDF enchassées dans un document HTML est simplement d'insérer le RDF à l'intérieur tel que montré dans l'exemple 7.7. Ceci rendra le document résultant non conforme aux spécifications HTML jusqu'à la version HTML 4.0 mais le W3C espère que la spécification HTML evoluera pour supporter ceci. Deux problèmes pratiques émergeront lorsque cette technique est employée avec les navigateurs respectant les spécifications HTML jusqu'à HTML 4.0. Des alternatives sont disponibles pour les auteurs dans ces cas ; voir [XMLinHTML]. Il est à la convenance de l'auteur de choisir l'alternative appropriée pour chaque circonstance.
Dans le cas où aucune des alternatives précédentes ne puissent fournir les possibilités désirées par l'auteur, les expressions RDF peuvent être laissées à l'extérieur du document HTML et liée avec un élément <link> HTML. La relation recommandée pour cette utilisation est REL="meta"; e.g.
<link rel="meta" href="mydocMetadata.DC.RDF">
La sérialisation et les syntaxes abbrégées RDF utilisent XML pour leur encodage. Les éléments et les attributs XML sont sensibles à la casse, donc les noms de propriété RDF sont par conséquent également sensibles à la casse. Cette spécification ne requère aucun format spécifique pour les noms de propriété autre que d'être des noms XML légaux. Pour ses propres identificateurs, RDF a adopté la convention que tout nom de propriété utilise le "style InterCap" ; c.-à-d., la première lettre du nom de la propriété et le reste du mot sont en minuscules ; e.g. subject. Lorsque le nom de la propriété est une composition de mots ou de fragments de mots, les mots sont concaténés avec la première lettre de chaque mot (autre que celle du premier mot) capitalisée et aucune autre ponctuation supplémentaire ; e.g. subClassOf.
RDF utilise le mécanisme d'espace de nom XML pour mettre en oeuvre globalement des identificateurs uniques pour toutes les propriétés. De plus, le nom de l'espace de nom sert comme identificateur pour le schéma RDF correspondant. Le nom de l'espace de nom est résolu pour se former de façon absolue tel que spécifié par l'algorithme dans la section 5.2., Résolution des références relatives à une forme absolue, dans [URI]. Un processeur RDF peut utiliser le schéma URI pour accéder le contenu du schéma. Cette spécification n'impose pas plus d'exigences sur le contenu qui pourrait être soumis à cette URI, aussi bien qu'elle ne définit pas comment l'URI pourrait être modifiée pour obtenir des formes alternatives ou un fragment du schéma.
Quelques changements typographiques ont été faits après que la Recommandation proposée ait été publiée. Les erreurs connues dans la version précédente à la date de publication ont été corrigées. Un petit point d'éclaircissement au paragraphe final de la section 6 a été fait.
Journal des révisions :
17-février-1999: prepare for publication as W3C Recommendation.
5-janvier-1999: publish as W3C Proposed Recommendation.
16-décembre-1998: final draft intended as Proposed Recommendation.
30-octobre-1998: incorporate Last Call review comments, add parseType, improve the I18N wordings.
8-octobre-1998: final cleanup, move changes to Appendix E, publish as Last Call.
7-octobre-1998: reserve a bit of schema URI space for futureproofing, add rdf:value.
2-octobre-1998: major renaming; statements, predicates, subjects, objects.
4-septembre-1998: instanceOf -> type, revise higher-arity relations model, add node identifier.
19-août-1998: Add '_' to Ord property names.
12-août-1998: Update to newer XML namespace declaration syntax. Add content to Section 7.
20-juillet-1998: More typos fixed. Third public draft
15-juilet-1998: Incorporate comments and fix typos. Initial letter of property names changed to lowercase
15-juin-1998: Major rewrite and reorganization
16-février-1998: Editorial cleanup, prep for second public distribution
6-février-1998: Editorial cleanup, add and revise some examples
11-janvier-1998: Renaming and collapsing of several elements
14-novembre-1997: Further refinement, especially regarding assertions
3-novembre-1997: Edits in preparation for second public distribution
2-octobre-1997: First public draft
1-octobre-1997: Edits in preparation for first public distribution
1-août-1997: First draft to Working Group
Dernière mise à jour : $Date: 1999/02/24 14:45:07 $
