La version anglaise de cette spécification est la seule version normative. Des traductions non normatives peuvent aussi être disponibles.
Droits d’auteur © 2004-2014 W3C® (MIT, ERCIM, Keio, Beihang), Tous droits réservés. Les règles du W3C sur la responsabilité, les marques déposées et les usages du document s’appliquent.
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.
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 à [email protected] (s’inscrire, archives). Tous les commentaires sont les bienvenus.
Veuillez voir le rapport d’implémentation du groupe de travail.
Cette traduction n’a pas été produite par un groupe de travail du W3C. En revanche, la version originale de ce document a été produite par un groupe opérant selon la politique de brevet du W3C du 5 février 2004. Le W3C tient une liste publique des divulgations de brevets effectuées en rapport avec les produits livrables du groupe ; cette page contient également des instructions pour divulguer un brevet. Une personne ayant connaissance d'un brevet qu'il croit contenir des revendications essentielles doit divulguer ces informations conformément à la section 6 de la politique de brevet du W3C.
Cette section n’est pas normative.
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, en particulier :
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.
Il peut y avoir trois sortes de nœuds dans un graphe RDF : des IRI, des littéraux et des nœuds vides.
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 ressources dé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.
La ressource dé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.
Des directives pour déterminer le référant d’un IRI sont données dans d’autres documents comme Architecture of the World Wide Web, Volume One (Architecture du World Wide Web, volume un) [WEBARCH] et Cool URIs for the Semantic Web (Des URI sympas pour le Web sémantique) [COOLURIS]. Voici un très bref exposé, informel et partiel :
http://www.w3.org/ns/org#
.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.
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 :
Préfixe d’espace de noms | IRI d’espace de noms | Vocabulaire RDF |
---|---|---|
rdf | http://www.w3.org/1999/02/22-rdf-syntax-ns# | Le vocabulaire prédéfini de RDF [RDF-SCHEMA] |
rdfs | http://www.w3.org/2000/01/rdf-schema# | Le vocabulaire de RDF Schema [RDF-SCHEMA] |
xsd | http://www.w3.org/2001/XMLSchema# | Les types XSD compatibles avec RDF |
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 ».
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 :
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.
Un jeu de données RDF est une collection de graphes RDF. Tous sauf un de ces graphes sont associés à un IRI ou un nœud vide. Ils sont appelés des graphes nommés et leur IRI ou nœud vide associé est appelé nom du graphe. Le graphe restant n’a pas d’IRI associé et s’appelle le graphe par défaut du jeu de données RDF.
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.
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 :
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.
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.
Une syntaxe RDF concrète peut offrir différentes manières d’encoder le même graphe RDF ou jeu de données RDF, par exemple par l’utilisation de préfixes d’espace de noms, d’IRI relatifs, d’identifiants de nœuds vides, et différents ordres de déclarations. Tandis que ces aspects peuvent avoir un effet important sur la commodité de travailler avec des documents RDF, ils n’ont aucune importance pour leur signification.
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 graphe RDF est un ensemble de triplets RDF.
Un triplet RDF contient trois composants :
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 nœuds vides et les littéraux sont appelés collectivement termes RDF.
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 vide http://example.org/
.
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.
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 :
http://example.com/
plutôt que http://example.com:80/
),http://example.com/
plutôt que http://example.com
),/./
» ou « /../
» dans le chemin d’un IRI,%3F
» plutôt que « %3f
»),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 :
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ées http://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
.
La valeur littérale associée à un littéral est :
É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 :
"1"^^xs:integer "01"^^xs:integer
dénotent la même valeur, mais ne sont pas les mêmes termes RDF littéraux car leur forme lexicale diffère.
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.
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.
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 :
http://example.com/.well-known/genid/d26a2d0e98334696f4ad70a677abc1f6
Deux graphes RDF G 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 :
Voir aussi : l’égalité d’IRI, l’égalité de littéraux en terme.
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].
Un jeu de données RDF est une collection de graphes RDF, et comprend :
Les nœuds vides peuvent être partagés entre graphes 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é.
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 :
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.
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.
Un type de données se compose d’un espace lexical, un espace de valeurs et une fonction lexique-valeur, et est dénoté par un ou plusieurs IRI.
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.
Les chaînes à balise de langue ont l’IRI de type de données http://www.w3.org/1999/02/22-rdf-syntax-ns#langString
. Aucun type de données n’est formellement défini pour cet IRI parce que la définition des types de données ne permet pas de tenir compte des balises de langue dans l’espace lexical. L’espace de valeurs associé à cet IRI de type de données est l’ensemble de toutes les paires de chaînes de caractères et de balises de langue.
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 :
true
», « false
», « 1
», « 0
»}true
», vrai>,
<« false
», faux>,
<« 1
», vrai>,
<« 0
», faux>,
}Les littéraux pouvant être définis en utilisant ce type de données sont :
Littéral | Valeur |
---|---|
<« true », xsd:boolean > |
vrai |
<« false », xsd:boolean > |
faux |
<« 1 », xsd:boolean > |
vrai |
<« 0 », xsd:boolean > |
faux |
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.
Type de données | Espace de valeur (informatif) | |
---|---|---|
Types de base | xsd:string | Chaînes de caractères (mais pas toutes les chaînes de caractères Unicode) |
xsd:boolean | Vrai, faux | |
xsd:decimal | Nombres décimaux de précision arbitraire | |
xsd:integer | Nombres entiers de taille arbitraire | |
Nombres IEEE à virgule flottante |
xsd:double | Nombres à virgule flottante sur 64 bits dont ±Inf, ±0, NaN |
xsd:float | Nombres à virgule flottante sur 32 bits dont ±Inf, ±0, NaN | |
Temps et date | xsd:date | Dates (aaaa-mm-jj) avec ou sans fuseau horaire |
xsd:time | Horaires (hh:mm:ss.sss…) avec ou sans fuseau | |
xsd:dateTime | Date et heure avec ou sans fuseau | |
xsd:dateTimeStamp | Date et heure avec un fuseau horaire obligatoire | |
Dates partielles et récurrentes |
xsd:gYear | Année du calendrier grégorien |
xsd:gMonth | Mois du calendrier grégorien | |
xsd:gDay | Jour d’un mois du calendrier grégorien | |
xsd:gYearMonth | Année et mois du calendrier grégorien | |
xsd:gMonthDay | Mois et jour du calendrier grégorien | |
xsd:duration | Durée de temps | |
xsd:yearMonthDuration | Durée de temps (mois et années seulement) | |
xsd:dayTimeDuration | Durée de temps (jours, heures, minutes, secondes seulement) | |
Nombre entier à champ limité |
xsd:byte | -128…+127 (8 bits) |
xsd:short | -32768…+32767 (16 bits) | |
xsd:int | -2147483648…+2147483647 (32 bits) | |
xsd:long | -9223372036854775808…+9223372036854775807 (64 bits) | |
xsd:unsignedByte | 0…255 (8 bits) | |
xsd:unsignedShort | 0…65535 (16 bits) | |
xsd:unsignedInt | 0…4294967295 (32 bits) | |
xsd:unsignedLong | 0…18446744073709551615 (64 bits) | |
xsd:positiveInteger | Nombres entiers > 0 | |
xsd:nonNegativeInteger | Nombres entiers ≥ 0 | |
xsd:negativeInteger | Nombres entiers < 0 | |
xsd:nonPositiveInteger | Nombres entiers ≤ 0 | |
Données binaires codées | xsd:hexBinary | Données binaires codées en hexadécimal |
xsd:base64Binary | Données binaires codées en base 64 | |
Divers types XSD | xsd:anyURI | URI ou IRI absolus ou relatifs |
xsd:language | Balises de langue selon [BCP47] | |
xsd:normalizedString | Chaînes de caractères aux espaces normalisées | |
xsd:token | Chaînes de caractères découpées par symboles | |
xsd:NMTOKEN | NMTOKEN XML | |
xsd:Name | noms XML | |
xsd:NCName | NCNames XML |
Les autres types de données prédéfinis de XML Schema ne conviennent pas pour des raisons diverses et NE DEVRAIENT PAS être utilisés.
xsd:QName
et xsd:ENTITY
ont besoin d’un contexte de document XML englobant.xsd:ID
et xsd:IDREF
sont utilisés pour des références croisées dans un document XML.xsd:NOTATION
n’est pas destiné à être utilisé directement.xsd:IDREFS
, xsd:ENTITIES
et xsd:NMTOKENS
sont des types de données dont les valeurs sont des séquences qui ne correspondent pas au modèle de type de données de RDF.rdf:HTML
Cette section n’est pas normative.
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 :
http://www.w3.org/1999/02/22-rdf-syntax-ns#HTML
.DocumentFragment
. Deux nœuds de type DocumentFragment
A et B sont considérés comme égaux si et seulement si la méthode DOM A.isEqualNode(B)
[DOM4] renvoie true
.Chaque membre de l’espace lexical est associé au résultat de l’application de l’algorithme suivant :
domnodes
la liste de nœuds DOM [DOM4] résultant de l’application de l’algorithme d’analyse de fragment HTML [HTML5] à la chaîne de caractères en entrée, sans élément de contexte.domfrag
le DocumentFragment
DOM [DOM4] dont l’attribut childNodes
est égal à domnodes
domfrag.normalize()
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.
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 :
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral
.DocumentFragment
. Deux nœuds de type DocumentFragment
A et B sont considérés comme égaux si et seulement si la méthode DOM A.isEqualNode(B)
[DOM4] renvoie true
.Chaque membre de l’espace lexical est associé au résultat de l’application de l’algorithme suivant :
domfrag
un DocumentFragment
DOM [DOM4] correspondant à la chaîne de caractères en entréedomfrag.normalize()
rdf:XMLLiteral
est la méthode de canonisation XML exclusive (avec les commentaires, et une InclusiveNamespaces PrefixList vide) [XML-EXC-C14N].
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]).
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 :
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral
se réfère au type de données rdf:XMLLiteral
;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.
Le langage d’ontologie du Web (Web Ontology Language) [OWL2-OVERVIEW] offre des aménagements pour définir formellement des types de données personnalisés qui peuvent être utilisés avec RDF. En outre, une pratique pour identifier des types de données simples de schémas XML définis par l’utilisateur est suggérée dans [SWBP-XSCH-DATATYPES]. Les mises en œuvre de RDF n’ont pas l’obligation de supporter ces aménagements.
Cette section n’est pas normative.
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 ressource dé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.
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.
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.
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].