Ce document est la traduction en français de la recommandation du W3C portant sur les concepts et la syntaxe abstraite de RDF 1.1 (25 février 2014).
Cette traduction peut comporter des erreurs. La seule version normative est la version originale anglaise, RDF 1.1 Concepts and Abstract Syntax qui se trouve à l’adresse http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/. Le traducteur tient à remercier Julien Plu pour sa relecture de ce document. Un glossaire donne la correspondance entre les concepts exprimés en français et les concepts originaux, et vice versa. Pour tout commentaire au sujet de la traduction elle-même (et non le contenu de la spécification) veuillez envoyer un email à Antoine Zimmermann.
Le cadre de description de ressource (Resource Description Framework ou RDF) est un cadre de représentation de l’information sur le Web.
Ce document définit une syntaxe abstraite (un modèle de données) qui sert à lier tous les langages et spécifications fondés sur RDF. La syntaxe abstraite a deux structures de données clé : les graphes RDF sont des ensembles de triplets sujet-prédicat-objet, où les éléments peuvent être des IRI, des nœuds vides, ou des littéraux typés. Ils sont utilisés pour décrire des ressources. Les jeux de données RDF sont utilisés pour organiser des collections de graphes RDF, et comprennent un graphe par défaut et zéro ou plus graphes nommés. Les concepts et syntaxe abstraite de RDF 1.1 introduisent également les concepts clés et la terminologie, et discutent du typage et de la manière dont doivent être traités les identifiants de fragments dans les IRI au sein de graphes RDF.
Statut de ce document
Cette section décrit le statut de ce document au moment de sa publication.
D’autres documents peuvent remplacer ce document. Une liste des publications actuelles du W3C et la dernière mise à jour
de ce rapport technique peut être trouvée dans l’index des rapports techniques du W3C à l’adresse
http://www.w3.org/TR/.
Ce document fait partie de la suite de documents RDF 1.1. Il s’agit de la spécification centrale de RDF 1.1 et il définit les concepts essentiels de RDF. La notion de jeu de données RDF est un nouveau concept de RDF 1.1 pour représenter des graphes multiples. Les suites de tests et les rapports d’implémentation d’un certain nombre de spécifications de RDF 1.1 qui se fondent sur ce document sont disponibles via le document des cas de tests RDF 1.1 (RDF 1.1 Test Cases) [RDF11-TESTCASES]. Il n'y a eu aucun changement sur ce document depuis sa publication en tant que recommandation proposée.
La version anglaise de ce document a été publiée par le groupe de travail RDF en tant que recommandation. Cette version traduite n’est pas normative.
Si vous souhaitez faire des commentaires au sujet de ce document, veuillez les envoyer à
public-rdf-comments@w3.org
(s’inscrire,
archives).
Tous les commentaires sont les bienvenus.
La structure de base de la syntaxe abstraite est un ensemble de triplets, chacun consistant en un sujet, un prédicat et un objet. Un ensemble de ces triplets est appelé un graphe RDF. Un graphe RDF peut être visualisé sous la forme d’un diagramme composé de nœuds et d’arcs orientés, dans lequel chaque triplet est représenté comme un lien nœud-arc-nœud.
Fig. 1Un graphe RDF avec deux nœud (Sujet et Objet) et un triplet les reliant (Prédicat)
Tout IRI ou littéral dénote quelque chose dans le monde (« l’univers de discours »). Ces choses sont appelées des ressources. N’importe quoi peut être une ressource, y compris des choses physiques, des documents, des concepts abstraits, des nombres et des chaînes de caractères ; le terme est synonyme d’« entité » tel qu’utilisé dans la spécification de la sémantique de RDF [RDF11-MT]. La ressource dénotée par un IRI est appelée son référant, et la ressource dénotée par un littéral est appelée sa valeur littérale. Les littéraux ont des types de données qui définissent l’étendue des valeurs possibles, tels que les chaînes de caractères, les nombres et les dates. Un type spécial de littéraux, les chaînes à balise de langue, dénotent du texte simple dans une langue naturelle.
L’énonciation d’un triplet RDF consiste à dire qu’une certaine relation, indiquée par le prédicat, lie les ressourcesdénotées par le sujet et l’objet. Cette déclaration correspondant à un triplet RDF s’appelle une déclaration RDF.
Le prédicat lui-même est un IRI et dénote une propriété, c’est-à-dire, une ressource que l’on peut voir comme une relation binaire.
(Les relations qui impliquent plus de deux entités ne peuvent être exprimées qu’indirectement en RDF [SWBP-N-ARYRELATIONS].)
À la différence des IRI et des littéraux, les nœuds vides n’identifient pas de ressources spécifiques. Des déclarations comportant des nœuds vides disent que quelque chose impliquée dans la relation existe, sans la nommer explicitement.
1.3 Le référant d’un IRI
La ressourcedénotée par un IRI est aussi appelée son référant. Pour certains IRI ayant une signification particulière, tels que ceux identifiant les types de données XSD, le référant est fixé par cette spécification. Pour tous les autres IRI, ce qui est exactement dénoté par un IRI donné n’est pas défini par cette spécification. D’autres spécifications peuvent fixer le référant d’un IRI, ou appliquer d’autres contraintes sur ce que peuvent être les référants de n’importe quel IRI.
Par conception, les IRI ont une portée globale. Ainsi, deux occurrences différentes d’un IRI dénotent la même ressource. Violer ce principe constitue une collision d’IRI [WEBARCH].
Par convention sociale, le propriétaire d’un IRI [WEBARCH] décide de ce qu’est le référant attendu (ou habituel) d’un IRI. Les applications et les utilisateurs n’ont pas besoin de se plier à cette dénotation attendue mais il pourrait y avoir une perte d’interopérabilité avec d’autres applications et utilisateurs s’ils ne le font pas.
Le propriétaire de l’IRI peut établir le référant voulu par le biais d’une spécification ou un autre document qui explique ce qu’il dénote. Par exemple, l’ontologie des organisations [VOCAB-ORG] spécifie les référants attendus de divers IRI commençant par http://www.w3.org/ns/org#.
Un bon moyen de communiquer le référant voulu consiste à mettre en place l’IRI de sorte qu’il déréference [WEBARCH] vers un tel document.
Un tel document peut, en fait, être un document RDF qui décrit la ressource dénotée par le biais de déclarations RDF.
La caractéristique sans doute la plus importante des IRI dans l’architecture du Web est qu’ils peuvent être déréférencés, et donc servir de points de départ pour les interactions avec un serveur distant. Cette spécification ne concernent pas ces interactions. Elle ne définit pas un modèle d’interaction. Elle ne traite les IRI que comme des identifiants uniques dans un modèle de données de graphes qui décrit des ressources. Cependant, ces interactions sont cruciales pour le concept de Web de données (Linked Data) [LINKED-DATA], qui utilise le modèle de données de RDF et ses formats de sérialisation.
1.4 Vocabulaires RDF et IRI d’espace de noms
Un vocabulaire RDF est une collection d’IRI destinés à être utilisés dans des graphes RDF. Par exemple, les IRI documentés dans [RDF-SCHEMA] sont le vocabulaire de RDF Schema. RDF Schema peut lui-même être utilisé pour définir et documenter des vocabulaires RDF supplémentaires. Certains de ces vocabulaires sont mentionnés dans le Primer [RDF-PRIMER].
Les IRI d’un vocabulaire RDF commencent souvent par une sous-chaîne commune appelée IRI d’espace de noms. Certains IRI d’espace de noms sont associés par convention avec un nom court appelé préfixe d’espace de noms. Voici quelques exemples :
Des exemples de préfixes et d’IRI d’espaces de noms
Dans certains formats de séralisation, il est courant d’abréger les IRI qui commencent par un IRI d’espace de noms en utilisant un préfixe d’espace de noms afin d’améliorer la lisibilité. Par exemple, l’IRI http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral serait abrégé en rdf:XMLLiteral. Notons cependant que ces abréviations ne sont pas des IRI valides, et ne doivent pas être utilisés dans des contextes où des IRI sont attendus. Les IRI d’espace de noms et les préfixes d’espace de noms ne font pas partie du modèle de donnée de RDF. Ils ne sont qu’une commodité syntaxique pour abréger des IRI.
Le terme « espace de noms » en lui-même n’a pas de sens bien défini dans le contexte de RDF mais est parfois utilisé pour signifier « IRI d’espace de noms » ou « vocabulaire RDF ».
1.5 RDF et changement au cours du temps
Le modèle de données RDF est atemporel : les graphes RDF sont des instantanés statiques de l’information.
Cependant, des graphes RDF peuvent exprimer de l’information sur des événements et sur les aspects temporels d’autres entités, à supposer que des termes appropriés de vocabulaires soient fournis.
Puisque les graphes RDF sont définis comme des ensembles mathématiques, ajouter ou retirer des triplets d’un graphe RDF produit un graphe RDF différent.
Nous utilisons informellement le terme source RDF pour se référer à une source ou un conteneur de graphes RDF persistant mais changeant au cours du temps. Une source RDF est une ressource dont on peut dire qu’elle a un état qui change au cours du temps. Un instantané de cet état peut être exprimé comme un graphe RDF. Par exemple, n’importe quel document sur le Web qui a une représentation RDF peut être considéré comme une source RDF. Comme toute ressource, les sources RDF peuvent être nommées avec des IRI et par conséquent être décrites dans d’autres graphes RDF.
Intuitivement parlant, les changements dans l’univers du discours peuvent être reflétés de la manière suivante :
Les littéraux, par construction, sont constants et ne changent jamais leur valeur.
Une relation qui existe entre deux ressources à un moment donné peut ne plus exister à un autre moment.
Les sources RDF peuvent changer leur état au cours du temps. C’est-à-dire, elles peuvent contenir différents graphes RDF à différents moments.
Certaines sources RDF peuvent, cependant, être des instantanés immutables d’une autre source RDF, archivant son état à un instant.
1.6 Travailler avec des multiples graphes RDF
Puisque les graphes RDF sont des ensembles de triplets, ils peuvent être combinés facilement, ce qui aide à l’utilisation de données issues de sources multiples. Néanmoins, il est parfois souhaitable de travailler avec des graphes RDF multiples tout en gardant leur contenu séparé. Les jeux de données RDF répondent à ce besoin.
Il y a de nombreuses utilisations possibles des jeux de données RDF. Notamment, ils peuvent être utilisés pour contenir des instantanés de multiples sources RDF.
1.7 Équivalence, implication et incohérences
Un triplet RDF encode une déclaration — une expression logique simple, ou une affirmation sur le monde. Un graphe RDF est la conjonction (ET logique) de ses triplets. Les détails précis de la signification des triplets et des graphes RDF sont l’objet de la spécification de la sémantique de RDF [RDF11-MT], qui introduit diverses relations entre les graphes RDF :
Implication
Un graphe RDFA implique un autre graphe RDF B si tous les arrangements possibles du monde qui rendent A vrai rendent aussi B vrai. Quand A implique B, si la véracité de A est admise ou démontrée, alors la véracité de B est établie.
Équivalence
Deux graphes RDFA et B sont équivalents s’ils prétendent la même chose sur le monde. A est équivalent à B si et seulement si AimpliqueB et B implique A.
Incohérence
Un graphe RDF est inconhérent si il contient une contradiction interne. Il n’y a pas d’arrangement possible du monde qui puisse rendre l’expression vraie.
Un régime d’implication [RDF11-MT] est une spécification qui définit les conditions précises par lesquelles ces relations existent. RDF lui-même ne reconnait que quelques cas élémentaires d’implication, d’équivalence et d’incohérence. D’autres spécifications, telles que RDF Schema [RDF-SCHEMA] et OWL 2 [OWL2-OVERVIEW], ajoutent des régimes d’implication plus puissants, comme le font certains vocabulaires spécifiques à un domaine.
Cette spécification ne contraint pas comment les implémentations utilisent les relations logiques définies par les régimes d’implication. Les implémentations peuvent ou non détecter des incohérences, et peuvent rendre toutes, certaines ou aucune implications disponibles aux utilisateurs.
1.8 Documents RDF et syntaxes
Un document RDF est un document qui encode un graphe RDF ou un jeu de données RDF dans une syntaxe RDF concrète, telle que Turtle [TURTLE], RDFa [RDFA-PRIMER], JSON-LD [JSON-LD], ou TriG [TRIG]. Les documents RDF permettent l’échange de graphes RDF et de jeux de données RDF entre des systèmes.
De même que les sections marquées comme non-normatives, toutes les directives de création, diagrammes, exemples
et notes dans cette spécification sont non-normatifs. Tout le reste dans cette spécification est
normatif.
Les mots clés DOIT, DOIVENT, NE DOIT PAS, NE DOIVENT PAS, OBLIGATOIRE, OBLIGATOIRES, DEVRAIT, DEVRAIENT, NE DEVRAIT PAS, NE DEVRAIENT PAS, RECOMMANDÉ, RECOMMANDÉE, RECOMMANDÉS, RECOMMANDÉES, PEUT, PEUVENT,
OPTIONNEL, OPTIONNELLE, OPTIONNELS et OPTIONNELLES dans cette spécification sont à interpréter comme décrits dans [RFC2119].
Cette spécification, RDF 1.1 Concepts et syntaxe abstraite, définit un modèle de données et la terminologie associée pour être utilisée dans d’autres spécifications, telles que des syntaxes RDF concrètes, des spécifications d’API, ou des langages de requêtes. Les implémentations ne peuvent pas directement se conformer à RDF 1.1 Concepts et syntaxe abstraite, mais peuvent se conformer à de telles autres spécifications qui référencent normativement les termes définis ici.
Un triplet RDF est conventionnellement écrit dans l’ordre sujet, prédicat, objet.
L’ensemble des nœud d’un graphe RDF est l’ensemble des sujets et objets des triplets dans le graphe. Il est possible que l’IRI d’un prédicat apparaissent également en tant que nœud dans le même graphe.
Les IRI, les littéraux et les nœuds vides sont distincts et distinguable. Par exemple, http://example.org/ en tant que chaîne de caractères littérale n’est pas égale à http://example.org/ en tant qu’IRI, ni à un nœud vide avec l’identifiant de nœud videhttp://example.org/.
3.2 IRI
Un IRI (Identifiant de Ressource Internationalisé ou Internationalized Resource Identifier) dans un graphe RDF est une chaîne de caractères Unicode [UNICODE] qui se conforme à la syntaxe définie dans RFC 3987 [RFC3987].
Les IRI dans la syntaxe abstraite de RDF DOIVENT être absolue, et PEUVENT contenir un identifiant de fragment.
Égalité d’IRI : Deux IRI sont égales si et seulement si ils sont équivalents selon la comparaison de chaînes simples de la section 5.1 de [RFC3987]. Aucune autre normalisation NE DOIT être effectuée quand on vérifie l’égalité d’IRI.
Note
URI et IRI : les IRI sont une généralisation des URI [RFC3986] qui permet une plus large plage de caractères Unicode. Tout URI absolu et tout URL est un IRI mais tout IRI n’est pas un URI. Quand les IRI sont utilisés dans des opérations définies seulement pour les URI, ils doivent d’abord être convertis selon la function définie dans la section 3.1 de [RFC3987]. Un exemple notable est la récupération via le protocole HTTP. La fonction implique l’encodage en UTF-8 des caractères non ASCII, l’encodage avec % des octets non autorisés dans les URI, et l’encodage Punycode des noms de domaine.
IRI relatifs : certaines syntaxes RDF concrètes autorisent les IRI relatifs comme raccourci commode qui permet la création de documents indépendamment de l’endroit où ils seront finalement publiés. Les IRI relatifs doivent être résolus par rapport à un IRI de base pour les rendre absolus. Par conséquent, le graphe RDF sérialisé dans de telles syntaxes n’est bien défini que si un IRI de base peut être établi [RFC3986].
Normalisation d’IRI : des problèmes d’interopérabilité peuvent être évités en n’émettant que des IRI normalisés selon la section 5 de [RFC3987]. Les formes non normalisées qui sont à éviter de préférence comprennent :
des lettres capitales dans les noms de schémas et les noms de domaine,
un encodage avec % de caractères lorsqu’il n’est pas obligatoire de le faire dans la syntaxe des IRI,
mentionner explicitement le port par défaut du protocole HTTP (préférer http://example.com/ plutôt que http://example.com:80/),
un chemin complètement vide dans les IRI HTTP (préférer http://example.com/ plutôt que http://example.com),
« /./ » ou « /../ » dans le chemin d’un IRI,
des lettres minuscules hexadécimales dans l’encodage avec % (préférer « %3F » plutôt que « %3f »),
encodage Punycode des noms de domaines internationalisés dans des IRI,
les IRI n’étant pas dans la forme normale C de normalisation unicode (Unicode Normalization Form C) [NFC].
3.3 Littéraux
Les littéraux sont utilisés pour des valeurs comme des chaînes de caractères, des nombres et des dates.
Un littéral dans un graphe RDF se compose de deux ou trois éléments :
une forme lexicale, étant une chaîne de caractères Unicode [UNICODE], qui DEVRAIT être en forme normal C [NFC],
un IRI de type de données, étant un IRI qui identifie un type de données qui détermine à quelle valeur littérale se réfère une forme lexicale et
si et seulement si l’IRI de type de données est http://www.w3.org/1999/02/22-rdf-syntax-ns#langString, une balise de langue non vide comme définie dans [BCP47]. La balise de langue DOIT être bien-formée selon la section 2.2.9 de [BCP47].
Un littéral est une chaîne à balise de langue si le troisième élément est présent. Les représentations lexicales des balises de langues PEUVENT être converties en lettres minuscules. L’espace de valeurs des balises de langues est toujours en minuscules.
Veuillez noter que des syntaxes concrètes PEUVENT prendre en charge les littéraux simples, constitués d’une forme lexicale seule, sans aucun IRI de type de données ni balise de langue. Les littéraux simples sont traités comme un raccourci syntaxique pour la syntaxe abstraite des littéraux avec l’IRI de type de donnéeshttp://www.w3.org/2001/XMLSchema#string. De même, la plupart des syntaxes concrètes représentent les chaînes à balise de langue sans l’IRI de type de données car il est toujours égal à http://www.w3.org/1999/02/22-rdf-syntax-ns#langString.
Sinon, le littéral est mal-typé, et aucune valeur littérale ne peut lui être associé. Un tel cas produit une incohérence mais n’est pas une erreur de syntaxe. Les implémentations DOIVENT accepter des littéraux mal-typés et former des graphes RDF à partir d’eux. Les implémentations PEUVENT produire des messages d’avertissement quand elles rencontrent des littéraux mal-typés.
Égalité de littéraux en terme : deux littéraux sont égaux en terme (sont le même littéral) si et seulement si les deux formes lexicales, les deux IRI de type de données, et les deux balises de langues (le cas échéant) sont égaux, caractère par caractère. Ainsi, deux littéraux peuvent avoir la même valeur sans être le même terme RDF. Par exemple :
Les nœuds vides sont disjoints des IRI et des littéraux. Sinon, l’ensemble des nœuds vides possibles est arbitraire. RDF ne fait référence à aucune structure interne des nœuds vides.
Note
Les identifiants de nœuds vides sont des identifiants locaux qui sont utilisés dans certaines syntaxes RDF concrètes ou des implémentations de dépôts RDF. Ils sont toujours à portée locale au fichier ou au dépôt RDF, et ne sont pas des identifiants persistant ou portables pour les nœuds vides. Les identifiants de nœuds vides ne font pas partie de la syntaxe abstraite RDF, mais sont entièrement dépendants de la syntaxe concrète ou de la mise en œuvre. Les restrictions syntaxiques sur les identifiants de nœuds vides, s’il y en a, sont par conséquent aussi dépendantes de la syntaxe RDF concrète ou de la mise en œuvre. Les implémentations qui manipulent des identifiants de nœuds vides dans des syntaxes concrètes doivent veiller à ne pas créer le même nœud vide à partir de multiples occurrences du même identifiant de nœud vide sauf dans les situations prises en charge par la syntaxe.
3.5 Remplacement des nœuds vides par des IRI
Les nœuds vides n’ont pas d’identifiants dans la syntaxe abstraite de RDF. Les identifiants de nœuds vides introduits par certaines syntaxes concrètes n’ont qu’une portée locale et sont purement des artefacts de la sérialisation.
Dans des situations où une identification plus forte est nécessaire, les sytèmes PEUVENT systématiquement remplacer certains ou tous les nœuds vides d’un graphe RDF avec des IRI. Les systèmes qui souhaitent faire cela DEVRAIENT émettre un nouvel IRI globalement unique (un IRI de Skolem) pour chaque nœud vide remplacé.
Cette transformation ne change pas sensiblement le sens d’un graphe RDF, à condition que les IRI de Skolem n’apparaissent nulle part ailleurs. Cela permet toutefois à d’autres graphes d’utiliser par la suite les IRI de Skolem, ce qui n’était pas possible lorsque le nœud était vide.
Des systèmes peuvent souhaiter émettre un IRI de Skolem de telle manière qu’ils puissent reconnaître les IRI introduits seulement pour remplacer des nœuds vides. Ceci permet au système de faire correspondre les IRI aux nœuds vides, si nécessaire.
Les systèmes qui veulent pouvoir reconnaître des IRI de Skolem hors de leur limite DEVRAIENT utiliser un IRI bien-connu [RFC5785] avec le nom enregistré genid. Il s’agit d’un IRI qui utilise le schéma HTTP ou HTTPS, ou un autre schéma utilisant les IRI bien-connus, et dont le composant chemin commence par /.well-known/genid/.
Par exemple, l’autorité responsable du domaine example.com pourrait émettre l’IRI de Skolem reconnaissable suivante :
RFC 5785 [RFC5785] ne spécifie que des URI bien-connus, pas des IRI. Pour les besoins de ce document, un IRI bien-connu est n’importe quel IRI qui se traduit par un URI bien-connu après la transformation IRI-vers-URI [RFC3987].
3.6 Comparaison de graphes
Deux graphes RDFG et G' sont isomorphes (c’est-à-dire, ils sont de formes identiques) s’il existe une bijection M entre les deux ensembles de nœuds des deux graphes, telle que :
M associe des nœuds vides à des nœuds vides.
M(lit)=lit pour tout littéral RDFlit dans les nœuds de G.
Avec cette définition, M montre comment chaque nœud dans G peut être remplacé par un autre nœud pour donner G'. L’isomorphisme de graphe est nécessaire pour définir la spécification des cas de tests RDF [RDF11-TESTCASES].
4. Jeu de données RDF
Un jeu de données RDF est une collection de graphes RDF, et comprend :
Exactement un graphe par défaut, qui est un graphe RDF. Le graphe par défaut n’a pas de nom et PEUT être vide.
Zéro ou plus graphes nommés. Chaque graphe nommé est une paire constituée d’un IRI ou d’un nœud vide (le nom du graphe), et un graphe RDF. Les noms de graphe sont uniques au sein d’un même jeu de données RDF.
Malgré l’utilisation du mot « nom » dans « graphe nommé », le nom du graphe ne dénote pas formellement le graphe. Il est seulement apparié syntaxiquement avec le graphe. RDF ne pose aucune restriction formelle sur la ressource que le nom de graphe dénote, ni sur la relation entre la ressource et le graphe. Une présentation de différentes sémantiques des jeux de données RDF peut être trouvée dans [RDF11-DATASETS].
Certaines implémentations des jeux de données RDF ne tiennent pas compte des graphes nommés vides. Les applications peuvent éviter des problèmes d’intéropérabilité en n’accordant pas d’importance à la présence ou l’absence de graphes nommés vides.
SPARQL 1.1 [SPARQL11-OVERVIEW] définit également le concept de jeu de données RDF. La définition d’un jeu de données RDF dans SPARQL 1.1 et cette spécification diffèrent légèrement car cette spécification permet d’identifier un graphe RDF en utilisant soit un IRI, soit un nœud vide. Le langage de requête SPARQL 1.1 ne permet que d’identifier un graphe RDF en utilisant un IRI. Des implémentations existantes de SPARQL pourraient ne pas autoriser l’utilisation de nœuds vides pour identifier des graphes RDF pendant quelque temps, donc leur utilisation peut poser des problèmes d’interopérabilité. La skolémisation des nœuds vides utilisés comme noms de graphes peut être utilisée pour surmonter ces problèmes d’interoperabilité.
4.1 Comparaison de jeux de données RDF
Deux jeux de données RDF (le jeu de données D1 avec le graphe par défaut DG1 et les graphes nommés NG1 et le jeu de données D2 avec le graphe par défaut DG2 et les graphes nommés NG2) sont jeu-de-données-isomorphes si et seulement si il existe une bijection M entre les nœuds, triplets et graphes dans D1 et ceux dans D2 telle que :
M associe des nœuds vides à des nœuds vides ;
M est l’identité sur les littéraux et les IRI ;
pour chaque triplets <s p o>, M(<s, p, o>) = <M(s), M(p), M(o)> ;
pour chaque graphe G = {t1, ..., tn}, M(G)={M(t1), ..., M(tn)} ;
DG2 = M(DG1) et
<n, G> est dans NG1 si et seulement si <M(n), M(G)> est dans NG2.
4.2 Négociation de contenu des jeux de données RDF
Cette section n’est pas normative.
Des ressources Web peuvent avoir de multiples représentations rendues disponibles par négociation de contenu [WEBARCH]. Une représentation peut être rendue dans un format de sérialisation RDF qui prend en charge à la fois l’expression de jeux de données RDF et de graphes RDF. Si un jeu de données RDF est rendu et que le consommateur attend un graphe RDF, il est attendu que le consommateur utilise le graphe par défaut du jeu de données RDF.
5. Types de données
Les types de données sont utilisés avec des littéraux pour représenter des valeurs comme des chaînes de caractères, des nombres et des dates. L’abstraction de type de données utilisée dans RDF est compatible avec XML Schema [XMLSCHEMA11-2]. Toute définition de type de données conforme à cette abstraction PEUT être utilisée en RDF, même si elle n’est pas définie en termes de schéma XML. RDF réutilise beaucoup des types de données prédéfinis de XML Schema, et fournit deux autres types de données prédéfinis, rdf:HTML et rdf:XMLLiteral. La liste des types de données supportés par une implémentation est déterminée par ses IRI de types de données reconnus.
L’espace lexical d’un type de données est un ensemble de chaînes de caractères Unicode [UNICODE].
La fonction lexique-valeur d’un type de données est un ensemble de paires dont le premier élément appartient à un espace lexical, et le second élément appartient à l’espace de valeurs d’un type de données. Chaque membre de l’espace lexical est associé à exactement une valeur, et est une représentation lexicale de cette valeur. Elle peut être vue comme une fonction de l’espace lexical vers l’espace de valeurs.
Par exemple, le type de données de XML Schema xsd:boolean, où chaque élément de l’espace de valeurs a deux représentations lexicales, est défini ainsi :
Les littéraux pouvant être définis en utilisant ce type de données sont :
Cette table liste les littéraux de type xsd:boolean.
Littéral
Valeur
<« true », xsd:boolean>
vrai
<« false », xsd:boolean>
faux
<« 1 », xsd:boolean>
vrai
<« 0 », xsd:boolean>
faux
5.1 Les types de données prédéfinis XML Schema
Les IRI de la forme http://www.w3.org/2001/XMLSchema#xxx, où xxx est le nom d’un type de données, dénotent le type de données prédéfinis dans XML Schema 1.1 Part 2: Datatypes [XMLSCHEMA11-2]. Les types prédéfinis de XML Schema listés dans la table suivante sont les types XSD compatibles avec RDF. Leur utilisation est RECOMMANDÉE.
Les lecteurs pourraient noter que les types de données xsd:hexBinary et xsd:base64Binary sont les seuls types de données sûrs pour transférer de l’information binaire.
Une liste des types XSD compatible avec RDF, avec une courte description
RDF peut fournir du contenu HTML comme possible valeur littérale. Cela permet d’inclure des balises dans les valeurs littérales. Un tel contenu est indiqué dans un graphe RDF en utilisant un littéral dont le type de données est rdf:HTML. Ce type de données est défini comme non-normatif parce qu’il dépend de [DOM4], une spécification qui n’a pas encore atteint le statut de recommandation du W3C.
Le type de données rdf:HTML est défini comme suit :
L’IRI dénotant ce type de données
est http://www.w3.org/1999/02/22-rdf-syntax-ns#HTML.
L’espace lexical
est l’ensemble des chaînes de caractères Unicode [UNICODE].
Toute annotation de langue (lang="…") ou espace de noms XML (xmlns) souhaités dans le contenu HTML doit être inclus explicitement dans le littéral HTML. Des URL relatifs dans les attributs tels que href n’ont pas d’URL de base bien défini et sont à éviter. Les applications RDF peuvent utiliser des relations d’équivalence supplémentaires, telles que celle qui relie une chaîne de caractères xsd:string à un littéral rdf:HTML correspondant à un seul nœud texte de la même chaîne.
5.3 Le type de données rdf:XMLLiteral
Cette section n’est pas normative.
RDF peut fournir du contenu XML comme possible valeur littérale. Un tel contenu est indiqué dans un graphe RDF en utilisant un littéral dont le type de données est rdf:XMLLiteral. Ce type de données est défini comme non-normatif parce qu’il dépend de [DOM4], une spécification qui n’a pas encore atteint le statut de recommandation du W3C.
Le type de données rdf:XMLLiteral est défini comme suit :
est l’ensemble des chaînes de caractères qui sont du contenu XML bien équilibrées, autonomes (well-balanced and self-contained) [XML10], et pour lesquels l’intégration entre une balise XML de départ arbitraire et une balise de fin donne un document conforme aux espaces de noms XML [XML-NAMES].
Toutes les déclarations d’espace de noms XML (xmlns), les annotations de langue (xml:lang) ou les déclarations d’URI de base (xml:base) souhaitées dans le contenu XML doivent être incluses explicitement dans le littéral XML. Notez que certaines syntaxes RDF concrètes peuvent définir des mécanismes pour les hériter du contexte (par exemple, @parseType="literal" en RDF/XML [RDF-SYNTAX-GRAMMAR]).
5.4 IRI de types de données
Les types de données sont identifiés par des IRI. Si D est un ensemble d’IRI utilisés pour se référer à des types de données, alors les éléments de D sont appelés IRI de types de données reconnus. Les IRI reconnus ont des référants fixés. Si un quelconque IRI de la forme http://www.w3.org/2001/XMLSchema#xxx est reconu, il DOIT se référer au type XSD compatible avec RDF nommé xsd:xxx pour chaque type XSD listé dans la section 5.1. En outre, les IRI suivants sont alloués aux types de données non-normatifs :
l’IRI http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral se réfère au type de données rdf:XMLLiteral ;
l’IRI http://www.w3.org/1999/02/22-rdf-syntax-ns#HTML se réfère au type de données rdf:HTML.
Des extensions sémantiques de RDF pourraient choisir de reconnaître d’autres IRI de type de données et imposer qu’ils se réfèrent à des types de données fixés. Se référer à la spécification de la sémantique de RDF [RDF11-MT] pour plus d’informations sur les extensions sémantiques.
Un processeur RDF n’est pas obligé de reconnaitre des IRI de types de données. Tout littéral typé avec un IRI non-reconnu est traité comme un IRI inconnu, c.-à.-d. comme se référant à une chose inconnue. Les applications PEUVENT donner un message d’avertissement si elles ne sont pas capables de déterminer le référant d’un IRI utilisé dans un littéral typé, mais NE DEVRAIENT PAS rejeter un tel RDF comme erreur de syntaxe ou de sémantique.
D’autres spécifications PEUVENT imposer des contraintes supplémentaires sur les IRI de types de données, par exemple, l’obligation de supporter certains types de données.
RDF utilise des IRI, pouvant inclure des identifiants de fragment, comme identifiants de ressource. La sémantique des identifiants de fragment est définie dans RFC 3986 [RFC3986] : ils identifient une ressource secondaire qui est habituellement une partie ou une vue définie ou décrite dans la ressource primaire, et sa sémantique précise dépend de l’ensemble de représentations qui pourrait résulter de l’action de récupération de la ressource primaire.
Cette section traite de la manipulation des identifiants de fragment dans les représentations qui encodent des graphes RDF.
Dans des représentations RDF d’une ressource primaire <foo>, la ressource secondaire identifiée par un fragment bar est la ressourcedénotée par l’IRI<foo#bar> dans le graphe RDF. Puisque les IRI dans des graphes RDF peuvent dénoter n’importe quoi, la ressource peut être quelque chose d’extérieure à la représentation, ou même extérieur au Web.
De cette manière, la représentation RDF agit comme un intermédiaire entre la ressource primaire accessible par le Web, et un certain ensemble d’entités potentiellement non-Web ou abstraite que le graphe RDF peut décrire.
Dans les cas où d’autres spécifications limitent la sémantique des identifiants de fragment dans des représentations RDF, le graphe RDF encodé devrait utiliser les identifiants de fragment en accord avec ces contraintes. Par exemple, dans un document HTML+RDFa [HTML-RDFA], le fragment chapter1 peut identifier une section de document via la sémantique des attributs @name ou @id de HTML. L’IRI<#chapter1> devrait alors dénoter cette même section dans tout triplets encodés en RDFa dans le même document. De même, les identifiants de fragment devraient être utilisés de façon cohérente avec la négociation de contenu [WEBARCH]. Par exemple, si le fragment chapter1 identifie une section de document dans une représentation HTML de la ressource primaire, alors l’IRI<#chapter1> devrait dénoter la même section dans toute les représentations RDF de la même ressource primaire.
7. Triplets, graphes et jeux de données RDF généralisés
Cette section n’est pas normative.
Il est parfois commode de réduire les exigences sur les triplets RDF. Par exemple, la complétude des règles d’implication RDFS est plus facile à montrer avec des triplets RDF généralisés.
Un triplet RDF généralisé est un triplet ayant un sujet, un prédicat et un objet qui peuvent chacun être un IRI, un nœuds vides ou un littéral. Un graphe RDF généralisé est un ensemble de triplets RDF généralisés. Un jeu de données RDF généralisé comprend un graphe RDF généralisé distingué et zéro ou plus paires associant chacune un IRI, un nœud vide ou un littéral à un graphe RDF généralisé.
Les triplets, graphes et jeux de données RDF généralisés diffèrent des triplets, graphes et jeux de données RDF uniquement en autorisant les IRI, les nœuds vides et les littéraux à apparaître à n’importe quelle position, c’est-à-dire comme sujet, prédicat, objet ou nom de graphe.
Les utisateurs des triplets, graphes ou jeux de données généralisés doivent être conscients que ces notions sont des extensions non standards de RDF et peuvent causer des problèmes d’interopérabilité. Il n’y a aucune obligation de la part des outils RDF d’accepter, de traiter, ou de produire quoi que ce soit au delà des triplets, graphes et jeux de données RDF réguliers.
8. Remerciement
Cette section n’est pas normative.
Les rédacteurs reconnaissent les précieuses contributions de Thomas Baker, Tim Berners-Lee, David Booth, Dan Brickley, Gavin Carothers, Jeremy Carroll, Pierre-Antoine Champin, Dan Connolly, John Cowan, Martin J. Dürst, Alex Hall, Steve Harris, Sandro Hawks, Pat Hayes, Ivan Herman, Peter F. Patel-Schneider, Addison Phillips, Eric Prud’hommeaux, Nathan Rixham, Andy Seaborne, Guus Schreiber, Leif Halvard Silli, Dominik Tomaszuk et Antoine Zimmermann.
Les membres du groupe de travail RDF incluaient Thomas Baker, Scott Bauer, Dan Brickley, Gavin Carothers, Pierre-Antoine Champin, Olivier Corby, Richard Cyganiak, Souripriya Das, Ian Davis, Lee Feigenbaum, Fabien Gandon, Charles Greer, Alex Hall, Steve Harris, Sandro Hawke, Pat Hayes, Ivan Herman, Nicholas Humfrey, Kingsley Idehen, Gregg Kellogg, Markus Lanthaler, Arnaud Le Hors, Peter F. Patel-Schneider, Eric Prud'hommeaux, Yves Raimond, Nathan Rixham, Guus Schreiber, Andy Seaborne, Manu Sporny, Thomas Steiner, Ted Thibodeau, Mischa Tuffield, William Waites, Jan Wielemaker, David Wood, Zhe Wu et Antoine Zimmermann.
A. Changements entre RDF 1.0 et RDF 1.1
Cette section n’est pas normative.
Un résumé détaillé des différences entre la version 1.0 et 1.1 de RDF se trouve dans What’s New in RDF 1.1 (Quoi de neuf dans RDF 1.1) [RDF11-NEW].
Anne van Kesteren; Aryeh Gregor; Ms2ger; Alex Russell; Robin Berjon. W3C DOM4. 4 February 2014. W3C Last Call Working Draft. URL : http://www.w3.org/TR/dom/
