Sémantique RDF

RDF est un langage assertionnel (assertional language) conçu pour exprimer des propositions à l'aide de vocabulaires formels précis, notamment ceux définis avec RDFS [RDF-VOCABULARY], pour accès et utilisation sur le Web, et conçu pour servir de fondation à des langages assertionnels plus avancés à but similaire. Les objectifs de conception d'ensemble mettent l'accent sur la généralité et la précision de l'expression des propositions à propos d'un sujet plutôt que sur la conformité à un modèle de traitement particulier ; cf. le document Concepts et syntaxe abstraite RDF [RDF-CONCEPTS] pour plus d'explications.

La « signification » exacte de ce qui est considéré une assertion (assertion) au sens large dans RDF ou RDFS peut dépendre de plusieurs facteurs, comprenant les conventions sociales, les commentaires en langage naturel ou les liens vers d'autres documents porteurs de contenu. Une grande partie de cette signification sera inaccessible au traitement automatique (machine processing) et n'est mentionnée ici que pour souligner le fait que la sémantiqueformelle décrite dans ce document n'a pas vocation à fournir une analyse complète de la « signification » dans ce sens large ; elle constituerait un sujet de recherche considérable. La sémantique donnée ici se limite à une notion formelle de la signification que l'on caractériserait comme étant la partie commune à tous les comptes du sens (accounts of meaning), et qui peut être capturée dans des règles d'inférence mécaniques.

Ce document utilise une technique de base appelée la théorie des modèles (model theory) pour définir la sémantique d'un langage formel. Les lecteurs non familiarisés avec la théorie des modèles consulteront avec profit le glossaire en annexe B ; tout au long du texte, les termes employés dans un sens technique sont reliés à leur définition dans le glossaire. La théorie des modèles suppose que le langage se rapporte à un « monde » et elle décrit les conditions minimales qu'un monde doit remplir pour affecter une signification appropriée à chaque expression dans le langage. Un monde particulier est appelé une interprétation, et la théorie des modèles serait donc mieux nommée « théorie des interprétations ». L'idée est de fournir un compte mathématique abstrait des propriétés qu'une telle interprétation doit avoir, en faisant aussi peu de suppositions que possible à propos de sa nature réelle ou de sa structure intrinsèque, et en retenant ainsi autant de généralité que possible. L'utilité principale d'une théorie sémantique formelle n'est pas de fournir une analyse en profondeur de la nature des choses décrites par le langage ni de suggérer un modèle de traitement particulier, mais plutôt de fournir un moyen technique pour déterminer si les processus d'inférence sont valides, c'est-à-dire si ceux-ci restent vrais. Cela laisse la plus grande liberté aux mises en oeuvre tout en conservant une notion de la signification globalement cohérente.

La théorie des modèles essaye d'être neutre d'un point de vue métaphysique et ontologique. Cette neutralité s'exprime typiquement dans le langage de la théorie des modèles tout simplement parce que c'est le langage normal des mathématiques - par exemple, cette sémantique suppose que les noms dénotent des choses dans un ensemble IR appelé l'« univers » - mais l'utilisation ici du langage de la théorie des ensembles ne doit pas faire penser que les choses dans l'univers sont de nature ensembliste (set-theoretic in nature). La théorie des modèles intéresse en général une mise en oeuvre surtout par la notion d'implication(entailment), décrite plus loin, qui rend possible la définition de règles d'inférencevalides.

Une autre façon de définir une sémantique est de donner une traduction de RDF vers une logique formelle déjà liée à une théorie des modèles, ou comme si c'était le cas. Cette approche « sémantique axiomatique » a été suggérée et utilisée antérieurement avec diverses versions alternatives du langage logique cible [Conen&Klapsing] [Marchiori&Saarela] [McGuinness&al]. Une telle traduction de RDF et RDFS est également donnée dans la spécification L_base [LBASE]. Le style de la sémantique axiomatique présente des avantages pour le traitement automatique et il est peut-être plus lisible, mais au cas où une sémantique axiomatique n'était pas conforme à la sémantique modéliste (model-theoretic semantics) décrite dans ce document, la théorie des modèles serait considérée comme normative.

Plusieurs aspects de la signification en RDF sont ignorés par cette sémantique ; en particulier, elle traite les références URI (URI references) comme des noms simples, ignorant les aspects de la signification codés dans des formes URI particulières [RFC 2396], et elle ne fournit aucune analyse des données variant dans le temps ou des changements sur les références URI. Elle ne fournit aucune analyse des utilisations indexicales des références URI, par exemple pour dire « ce document ». Quelques parties des vocabulaires RDF et RDFS n'ont reçu aucune signification formelle et dans certains cas, notamment les vocabulaires de réification et des conteneurs, il est attribué moins de signification que ce que l'on attendrait. Ces cas sont notés dans le texte et les limitations expliquées plus en détails. RDF est une logique assertive, dans laquelle chaque triplet exprime une proposition simple. Cela impose une discipline monotone(monotonic) plutôt stricte sur le langage, et celui-ci ne peut donc pas exprimer de suppositions de monde fermé (closed-world assumptions), de préférences locales par défaut et plusieurs autres constructions non monotones couramment utilisées.

Des utilisations de RDF, y compris comme base pour des langages plus expressifs tels que DAML+OIL [DAML] et OWL [OWL], peuvent imposer d'autres conditions sémantiques, en plus de celles décrites ici, et de telles conditions supplémentaires peuvent aussi être imposées aux significations des termes dans des vocabulaires RDF particuliers. Les extensions ou dialectes de RDF obtenus en imposant ces conditions sémantiques supplémentaires sont appelés des extensions sémantiques (semantic extensions) de RDF. Dans cette recommandation, les extensions sémantiques de RDF sont régies selon les mots-clés « doit », « ne doit pas », « devrait » et « peut » du [RFC 2119]. Les extensions sémantiques de RDF doivent se conformer aux conditions sémantiques des interprétations simples décrites aux sections 4.3, 4.4 et 4.5, et à celles des interprétations RDF décrites à la section 6.1 de ce document. Tout nom d'implication dans une extension sémantique devrait être indiqué par l'emploi d'un terme d'implication de vocabulaire(vocabulary entailment). Les conditions sémantiques imposées sur une extension sémantique RDF doivent définir une notion d'implication de vocabulaire qui soit valide pour la sémantique modéliste décrite dans les parties normatives de ce document ; à l'exception suivante que, si l'extension sémantique est définie sur un sous-ensemble syntaxiquement restreint des graphes RDF, alors les conditions sémantiques ne doivent s'appliquer qu'à ce sous-ensemble. Les spécifications de telles extensions sémantiques restreintes syntaxiquement doivent inclure des conditions syntaxiques suffisantes pour permettre à un logiciel de distinguer sans ambiguïté les graphes RDF sur lesquels les conditions sémantiques étendues s'appliquent. Les applications fondées sur de telles extensions sémantiques restreintes syntaxiquement peuvent traiter les graphes RDF qui ne sont pas conformes aux restrictions syntaxiques imposées comme étant des erreurs de syntaxe.

RDF Schema [RDF-VOCABULARY], abrégé en RDFS, dont la sémantique est définie dans la suite de ce document, est un exemple d'extension sémantique de RDF. RDF Schema n'impose pas de restrictions syntaxiques supplémentaires.

Toute théorie sémantique s'appuie sur une syntaxe. Cette sémantique est définie comme une application (mapping) sur la syntaxe abstraite de RDF décrite dans le document des concepts et de la syntaxe abstraite RDF [RDF-CONCEPTS]. Ce document utilise la terminologie suivante qui y est définie : référence URI (URI reference), littéral(literal), littéral ordinaire (plain literal), littéral typé (typed literal), littéral XML (XML literal), valeur XML (XML value), noeud(node), noeud anonyme (blank node), triplet(triple) et graphe RDF (RDFgraph). Tout au long du document, nous employons le terme « chaîne de caractères » (character string) ou « chaîne » (string) pour désigner une séquence de caractères Unicode, et « étiquette de langue » (language tag) au sens du RFC 3066, cf. la section 6.5 dans [RDF-CONCEPTS. Notez que les chaînes dans un graphe RDF devraient être dans la forme de normalisation C (normal form C).

Ce document utilise la syntaxe N-Triples décrite dans le document des jeux d'essais RDF [RDF-TESTS] pour décrire les graphes RDF. Cette notation emploie une convention d'identificateur de noeud (nodeID) pour indiquer les noeuds anonymes dans les triplets d'un graphe. Bien que les identificateurs de noeud tels que « _:xxx » servent à identifier des noeuds anonymes dans la syntaxe de surface, ces expressions ne sont pas considérées comme étant le label (label) du noeud de graphe qu'elles identifient ; ce ne sont pas des noms et n'apparaissent pas dans le graphe réel. En particulier, les graphes RDF décrits par deux documents N-Triples qui ne diffèrent que par le renommage de leurs identificateurs de noeuds seront compris comme étant équivalents. Cette convention de renommage devrait être comprise comme ne s'appliquant qu'à des documents entiers, puisque le renommage des identificateurs de noeud dans une partie d'un document peut aboutir à un document décrivant un graphe RDF différent.

La syntaxe N-Triples impose de donner les références URI en entier entre des chevrons. Pour la concision des exemples illustratifs, nous utilisons le schéma URI fictif « ex: ». Pour avoir une vue plus réaliste de l'apparence de la syntaxe N-Triples, le lecteur devra imaginer qu'il est remplacé par quelque chose comme « http://www.example.org/rdf/mt/artificial-example/ ». Les préfixes de nom qualifié (QName prefixs) rdf:, rdfs: et xsd: sont définis comme suit :

Adresse URI d'espace de noms du préfixe rdf:http://www.w3.org/1999/02/22-rdf-syntax-ns#

Adresse URI d'espace de noms du préfixe rdfs:http://www.w3.org/2000/01/rdf-schema#

Adresse URI d'espace de noms du préfixe xsd:http://www.w3.org/2001/XMLSchema#

Puisque la syntaxe QName n'est pas une syntaxe N-Triples légale, et pour la concision et la lisibilité, les exemples emploient la convention selon laquelle un nom qualifié s'utilise sans chevrons délimitant pour indiquer la référence URI englobée entre des chevrons ; par exemple ce triplet-ci :

<ex:a> rdf:type rdfs:Class .

Devrait se lire comme une abréviation de la syntaxe N-Triples :

<ex:a> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> <http://www.w3.org/2000/01/rdf-schema#Class> .

Pour la déclaration de conditions sémantiques générales, les caractères seuls ou les séquences de caractères sans caractère DEUX-POINTS indiquent arbitrairement un nom, un noeud anonyme, une chaîne de caractères, et ainsi de suite. La signification exacte sera indiquée par le contexte.

Un graphe RDF, ou simplement un graphe, est un ensemble de triplets RDF.

Un sous-graphe (subgraph) d'un graphe RDF est un sous-ensemble de triplets du graphe. Un triplet est identifié par le singleton (singleton set) qui le contient, et donc chaque triplet d'un graphe est considéré comme étant un sous-graphe. Un sous-graphe propre (proper subgraph) est un sous-ensemble propre des triplets dans le graphe.

Un graphe RDF fondamental (ground RDF graph) est un graphe sans noeuds anonymes.

Un nom est une référence URI ou un littéral. Ce sont les expressions qui ont besoin de recevoir une signification par une interprétation. Notez qu'un littéral typé se compose de deux noms : le sien et sa référence URI de type interne.

Un ensemble de noms est appelé un vocabulaire. Le vocabulaire d'un graphe est l'ensemble des noms apparaissant comme sujet, prédicat ou objet d'un triplet dans le graphe. Notez que les références URI qui n'apparaissent qu'au sein de littéraux typés ne sont pas tenus d'être dans le vocabulaire du graphe.

Supposons M, une application d'un ensemble de noeuds anonymes vers un ensemble comprenant des littéraux, des noeuds anonymes et des références URI ; alors tout graphe obtenu à partir d'un graphe G en remplaçant une partie ou la totalité des noeuds anonymes N dans G par M(N) est une instance de G. Notez que tout graphe est une instance de lui-même, une instance d'une instance de G est une instance de G, et si H est une instance de G alors chaque triplet dans H est une instance d'un triplet dans G.

Une instance par rapport à un vocabulaire V est une instance dans laquelle tous les noms de l'instance substitués aux noeuds anonymes de l'original sont des noms de V.

Une instance propre d'un graphe est une instance dans laquelle un noeud anonyme a été remplacé par un nom, ou deux noeuds anonymes dans le graphe ont été associés (mapped) au même noeud dans l'instance.

Toute instance d'un graphe dans lequel un noeud anonyme est associé à un nouveau noeud anonyme dans le graphe original est une instance de l'original et l'a également comme instance, et on peut itérer ce processus pour que toute application injective (1:1 mapping) entre des noeuds anonymes définisse une instance d'un graphe ayant le graphe original comme instance. Deux graphes de ce type, chacun étant une instance de l'autre mais aucun une instance propre, sont considérés comme équivalents. Nous traiterons de tels graphes équivalents comme identiques ; cela permet d'ignorer quelques problèmes soulevés par le « renommage » des identificateurs de noeud (nodeID), tout en étant conforme à la convention selon laquelle les noeuds anonymes n'ont pas de label. Les graphes équivalents sont des instances mutuelles avec une application d'instance réversible (invertible instance application).

Un graphe RDF est mince (lean) s'il n'a aucune instance qui est un sous-graphe propre du graphe. Les graphes non minces ont une redondance interne et expriment le même contenu que leurs sous-graphes minces. Par exemple, le graphe :

<ex:a> <ex:p> _:x .
_:y <ex:p> _:x .

N'est pas mince, mais :

<ex:a> <ex:p> _:x .
_:x <ex:p> _:x .

Est mince.

On définit la fusion (merge) d'un ensemble de graphes RDF comme suit. Si les graphes de l'ensemble n'ont pas de noeuds anonymes en commun, alors l'union des graphes est une fusion ; s'ils partagent des noeuds anonymes, alors c'est l'union d'un ensemble de graphes obtenu en remplaçant les graphes dans l'ensemble par des graphes équivalents ne partageant pas de noeuds anonymes. On le décrit souvent en disant que les noeuds anonymes ont été « normalisés à part » (standardized apart). On peut aisément constater que deux fusions sont équivalentes, et nous dirons la fusion, en suivant la convention des graphes équivalents. En utilisant la convention des graphes équivalents et de l'identité, tout graphe de l'ensemble original est considéré comme étant un sous-graphe de la fusion.

En général, on n'obtient pas la fusion d'un ensemble de graphes en concaténant leurs documents N-Triples correspondants et en construisant le graphe décrit par le document fusionné. Si certains de ces documents utilisent les mêmes identificateurs de noeud, le document fusionné décrira un graphe dans lequel certains noeuds anonymes auront été « accidentellement » identifiés. Pour fusionner des documents N-Triples, il est nécessaire de vérifier si le même identificateur de noeud (nodeID) est utilisé dans deux documents ou plus et de le remplacer par un identificateur distinct dans chacun d'eux avant de fusionner les documents. Des précautions similaires s'appliquent à la fusion des graphes décrits par les documents RDF/XML qui contiennent des identificateurs de noeud, cf. la Spécification de la syntaxe RDF/XML (révisée) [RDF-SYNTAX].

RDF n'impose pas de restrictions logiques sur les domaines (domains) et les images (ranges) des propriétés ; en particulier, une propriété peut s'appliquer à elle-même. Lorsque des classes sont introduites en RDFS, elles-mêmes peuvent se contenir. De telles « boucles d'appartenance » (membership loops)peuvent sembler enfreindre l'axiome de fondation (axiom of foundation), l'un des axiomes de la théorie des ensembles normalisée (Zermelo-Fraenkel), qui interdit de descendre indéfiniment dans les chaînes d'appartenance. En revanche, le modèle sémantique donné ici distingue les propriétés et classes considérées comme des objets dans leurs extensions - les ensembles de couples objet-valeur qui satisfont à la propriété ou aux choses qui sont « dans » la classe - en autorisant ainsi l'extension d'une propriété (ou d'une classe) à contenir la propriété (ou la classe) elle-même sans enfreindre l'axiome de fondation. En particulier, cette utilisation d'une application d'extension de classe permet aux classes de se contenir elles-mêmes. Ainsi, il est tout à fait valable pour (l'extension d') une classe « universelle » de contenir la classe elle-même comme membre, une convention souvent adoptée au sommet d'une hiérarchie de classement (classification hierarchy). (Si une extension se contenait elle-même, l'axiome serait enfreint, mais ce cas n'arrive jamais.) La technique est décrite plus complètement dans [Hayes&Menzel].

À cet égard, RDFS diffère de beaucoup de systèmes ontologiques (ontology frameworks) conventionnels tels qu'UML, qui supposent une hiérarchie plus structurée d'individus, d'ensembles d'individus, etc., ou qui font une distinction nette entre les données et les métadonnées. Toutefois, quoique RDFS ne suppose pas l'existence d'une telle structure, il ne l'interdit pas. RDF autorise les boucles d'appartenance, mais il ne mandate pas leur utilisation pour toutes les parties d'un vocabulaire d'utilisateur. Si on estime cette caractéristique de RDF ennuyeuse, on peut alors se restreindre à un sous-ensemble de graphes RDF qui ne contient pas de telles « boucles » d'appartenance de classe ou d'application de propriété tout en gardant l'essentiel de la puissance d'expression de RDFS pour plusieurs objectifs pratiques, et des extensions sémantiques peuvent imposer des conditions syntaxiques interdisant de telles constructions en boucle.

L'utilisation de l'application d'extension explicite permet aussi à deux propriétés d'avoir exactement les mêmes valeurs, ou à deux classes de contenir les mêmes instances, en étant toujours des entités distinctes. Cela signifie que l'on peut considérer les classes RDFS comme étant plus que de simples ensembles ; on peut les considérer comme des « classements » (classifications) ou des « concepts » qui ont une notion forte de l'identité, qui va au-delà d'une simple correspondance extensionnelle. Cette propriété de la théorie des modèles a des conséquences importantes dans des langages plus expressifs bâtis sur RDF, tels que OWL [OWL], qui sont capables d'exprimer directement une identité entre des propriétés et des classes. Cette nature « intensionnelle » (intensional) des classes et des propriétés est parfois revendiquée comme étant une propriété utile d'un langage descriptif, mais une explication complète de ce problème est hors du propos de ce document.

Remarquez que la question de savoir si oui ou non une classe se contient elle-même comme membre est très différente de celle de savoir si oui ou non elle est une sous-classe d'elle-même. Toutes les classes sont des sous-classes d'elles-mêmes.

Les lecteurs familiarisés avec la sémantique logique conventionnelle trouveront peut-être utile de voir RDF comme une version d'une logique relationnelle binaire existentielle selon laquelle les relations sont des entités de première classe dans l'univers de la quantification. Une telle logique peut être obtenue en codant l'atome relationnel R(a, b) en une syntaxe logique conventionnelle, avec une relation notionnelle à trois position Triple(a, R, b) (notional three-place relation) ; on peut reconstruire la sémantique de base décrite ici à partir de cette intuition en définissant l'extension de y comme étant l'ensemble {<x, z> : Triple(x, y, z)} et en notant que ce serait précisément la dénotation de R dans la théorie des modèles tarskienne (Tarskian model theory) conventionnelle de la forme originale R(a, b) de l'atome relationnel. Cette construction peut également se retrouver dans la sémantique de la description axiomatique L_base [LBASE].

Ce document n'adopte aucune position sur la façon dont les références URI sont composées à partir d'autres expressions, par exemple à partir d'adresses URI relatives ou de noms qualifiés (QName) ; la sémantique suppose simplement que ces problèmes lexicaux ont été résolus d'une manière globalement cohérente, et donc qu'une référence URI seule peut être interprétée comme ayant la même signification où qu'elle apparaisse. Pareillement, la sémantique n'offre aucune disposition spéciale pour le suivi des changements temporels. Elle suppose implicitement que les références URI ont la même signification à chaque fois qu'elles apparaissent. Fournir une sémantique adéquate qui serait sensible aux changements temporels est un problème de recherche qui est hors du propos de ce document.

La sémantique ne suppose aucune relation particulière entre la dénotation d'une référence URI et un document, ou une ressource Web, récupérable en utilisant cette référence URI dans un protocole de transfert HTTP, ou de toute entité considérée comme étant la source de tels documents. Cette exigence pourrait être ajoutée comme une extension sémantique, mais la sémantique formelle décrite ici ne fait aucune supposition à propos d'un quelconque lien entre les dénotations de références URI et les utilisations de ces références URI dans d'autres protocoles.

La sémantique traite tous les noms RDF comme des expressions qui dénotent. Les choses dénotées sont appelées des « ressources », selon le [RFC 2396], mais il n'est fait aucune supposition ici à propos de la nature des ressources ; ici le terme « ressource » est synonyme d'« entité », c'est-à-dire comme un terme générique pour quelque chose dans l'univers du discours.

Les différentes formes syntaxiques de noms sont traitées exactement. Les références URI sont traitées simplement comme des constantes logiques. Les littéraux ordinaires indiquent eux-mêmes, et ont donc une signification fixe. La dénotation d'un littéral typé est la valeur établie à partir de sa chaîne de caractères incluse par le type de données associé à son type inclus. RDF attribue une signification particulière aux littéraux typés avec rdf:XMLLiteral, décrits à la section 6.

L'intuition de base de la sémantique modéliste est qu'affirmer (asserting) une phrase établit une revendication à propos du monde : c'est une autre façon de dire que le monde est, en fait, arrangé selon une interprétation qui rend la phrase vraie. En d'autres termes, une affirmation revient à énoncer une contrainte sur les états possibles du monde. Remarquez que l'on ne présume pas ici qu'une affirmation contienne suffisamment d'information pour indiquer une seule et unique interprétation. Il est généralement impossible de produire suffisamment d'affirmation dans un langage pour contraindre entièrement les interprétations à un seul monde possible, et donc la seule et unique interprétation d'un graphe RDF, ça n'existe pas. En général, plus grand est le graphe RDF - plus il dit de choses à propos du monde - plus petit est l'ensemble des interprétations vraies pour une assertion du graphe - moins il y a d'états possibles du monde qui vérifient le graphe affirmé.

La définition d'une interprétation qui suit est formulée en langage mathématique, mais intuitivement il en ressort qu'une interprétation fournit juste assez d'information à propos d'un état probable du monde - un monde possible - pour établir la valeur de vérité (truth-value), vrai ou faux, d'un triplet RDF fondamental. Elle le fait en indiquant, pour chaque référence URI, de quoi celle-ci est censée être le nom ; et aussi, si celle-ci indique une propriété, quelles sont les valeurs de cette propriété pour chaque chose dans l'univers ; et si celle-ci indique un type de données, que le type de données définit une application entre des formes lexicales et des valeurs de type de données. C'est juste assez d'information pour établir la valeur de vérité de tout triplet fondamental, et donc de tout graphe RDF fondamental. (Les graphes non fondamentaux sont traités dans la section suivante.) Notez que si l'une de ces informations était omise, certains triplets bien formés pourraient rester sans valeur déterminée ; et aussi que toute autre information - telle que la nature exacte des choses dans l'univers - serait, indépendamment de son intérêt intrinsèque, sans rapport avec les valeurs de vérité réelles d'un triplet.

Toutes les interprétations seront relatives à un ensemble de noms, appelé le vocabulaire de l'interprétation ; on devrait donc, strictement, parler d'une interprétation d'un vocabulaire RDF plutôt que de RDF même. Certaines interprétations peuvent attribuer des significations spéciales aux symboles d'un vocabulaire particulier. Les interprétations qui partagent la signification spéciale d'un vocabulaire particulier seront nommées d'après ce vocabulaire, par exemple « rdf-interprétations », « rdfs-interprétations », etc. Une interprétation sans conditions supplémentaires particulières sur un vocabulaire (y compris le vocabulaire RDF même) sera dite une interprétation simple ou plus simplement une interprétation.

RDF utilise plusieurs formes de littéral. La caractéristique sémantique principale des littéraux est que leurs significations sont largement déterminées par la forme de la chaîne qu'ils contiennent. Les littéraux ordinaires, sans référence URI de type intégrée, sont toujours interprétés comme se rapportant à eux-mêmes : soit une chaîne de caractères, soit un couple composé d'une chaîne de caractères et d'une étiquette de langue ; dans l'un ou l'autre cas, la chaîne de caractères est dite la « chaîne de caractères littérale ». Dans le cas des littéraux typés, par contre, la définition complète de la signification dépend de l'accès à l'information de type de données qui est extérieure à RDF même. Une explication complète de la signification des littéraux typés est donnée à la section 8, où l'on introduit une notion spéciale de l'interprétation des types de données. Chaque interprétation définit une application IL, des littéraux typés vers leurs interprétations. Nous définirons des conditions plus fortes sur IL avec l'extension de la notion d'« interprétation » dans les sections à suivre.

Tout au long de ce document, des conditions sémantiques précises seront établies dans les tableaux qui présentent des conditions sémantiques, les tableaux contenant des assertions vraies et des règles d'inférence valides, et les tableaux listant la syntaxe, qui se distinguent par leur couleur d'arrière-plan. Ces tableaux, pris dans leur ensemble, équivalent à un résumé formel de la sémantique entière. Notez que la sémantique de RDF ne dépend pas de celle de RDFS. La sémantique complète de RDF est définie à la section 4 et à la section 6 ; la sémantique complète de RDFS à la section 4, à la section 6 et à la section 7.

Définition d'une interprétation simple :

IEXT(x), appelé l'extension de x, est un ensemble de couples qui identifient les arguments pour lesquels la propriété est vraie, c'est-à-dire une extension relationnelle binaire. Cette astuce de distinguer une relation comme étant un objet de son extension relationnelle permet à une propriété d'être présente dans sa propre extension, comme noté précédemment.

L'hypothèse selon laquelle LV est un sous-ensemble de IR revient à dire que les valeurs littérales sont interprétées comme des entités réelles qui « existent ». Cela revient à dire que les valeurs littérales sont des ressources. En revanche, cela n'implique pas que les littéraux doivent être identifiés par des références URI. Notez que LV peut contenir d'autres éléments en plus des littéraux ordinaires. Il y a une raison technique à ce que l'image de IL soit IR plutôt que de se restreindre à LV. Lorsque les interprétations tiennent compte de l'information de type de données, il est syntaxiquement possible pour un littéral typé d'être incohérent en interne, et de tels littéraux mal typés sont obligés d'indiquer une valeur non littérale, comme expliqué à la section 8.

Les sections suivantes définissent comment une interprétation d'un vocabulaire détermine la valeur de vérité d'un graphe RDF, par une définition récursive de la dénotation - la « valeur » sémantique » - d'une expression RDF par rapport à celles de ses sous-expressions immédiates. Celles-ci s'appliquent à toutes les extensions sémantiques subséquentes. RDF a deux types de dénotation : les noms dénotent des choses dans l'univers et les ensembles de triplets dénotent des valeurs de vérité.

La dénotation d'un graphe RDF fondamental dans I est donnée récursivement par les règles suivantes, lesquelles étendent l'application d'interprétation I des noms vers les graphes fondamentaux. Ces règles (et leurs extensions données ensuite) agissent en définissant la dénotation d'un bout de syntaxe RDF E par rapport aux dénotations des constituants syntaxiques immédiats de E, en permettant donc de déterminer la dénotation de tout morceau de RDF par une sorte de récursion syntaxique.

Dans ce tableau et tout au long de ce document, le signe d'égalité « = » indique une identité et les chevrons <x, y> servent à indiquer un couple ordonné de x et y. La syntaxe des graphe RDF est indiquée en utilisant les conventions d'écriture de la syntaxe N-Triples décrite dans le document des jeux d'essais RDF [RDF-TESTS] : les chaînes littérales sont entre des guillemets doubles « " », les étiquettes de langue sont indiquées par le signe « @ » et les triplets se terminent par un point de code « . ».

Conditions sémantiques des graphes fondamentaux :

Si le vocabulaire d'un graphe RDF contient des noms qui ne sont pas dans le vocabulaire d'une interprétation I - c'est-à-dire simplement si I ne donne pas de valeur sémantique à un nom utilisé dans le graphe - alors ces conditions de vérité produiront toujours la valeur false pour un triplet dans le graphe, et donc pour le graphe même. Vu autrement, cela signifie que toute assertion d'un graphe proclame implicitement que tous les noms dans le graphe se réfèrent réellement à quelque chose dans le monde. La condition finale implique qu'un graphe vide (un ensemble de triplets vide) est évidemment vrai.

Notez que la dénotation des littéraux ordinaires est toujours dans LV ; et que celles du sujet et de l'objet d'un triplet vrai doivent être dans IR ; donc toute référence URI qui apparaît dans un graphe, à la fois comme prédicat et comme sujet ou objet doit dénoter quelque chose dans l'intersection de IR et IP, dans toute interprétation satisfaisant le graphe.

Comme exemple illustratif, voici une interprétation réduite pour le vocabulaire artificiel {ex:a, ex:b, ex:c, "whatever", "whatever"^^ex:b}. Des entiers sont utilisés pour indiquer les « choses » non littérales dans l'univers. Cela n'est pas pour impliquer que les interprétations devraient être interprétées comme étant à propos d'arithmétique, mais plus pour souligner le fait que la nature exacte des choses dans l'univers n'est pas pertinente. LV peut être tout ensemble satisfaisant aux conditions sémantiques. (Dans cet exemple et les suivants, les symboles « supérieur à » et « inférieur à » sont employés de plusieurs façons : en suivant l'usage mathématique pour indiquer des couples et n-uplets (n-tuples) abstraits ; en suivant la syntaxe N-Triples pour englober les références URI, et aussi comme des flèches pour indiquer des applications).

IR = LV union{1, 2}

IP = {1}

IEXT: 1=>{<1,2>, <2,1>}

IS: ex:a=>1, ex:b=>1, ex:c=>2

IL: "whatever"^^ex:b =>2

Figure 1 : Un exemple d'interprétation. Notez qu'il ne s'agit pas d'une image d'un graphe RDF. La figure ne montre pas le nombre infini des membres de LV.

Cette interprétation rend ces triplets vrais :

<ex:a> <ex:b> <ex:c> .

<ex:c> <ex:a> <ex:a> .

<ex:c> <ex:b> <ex:a> .

<ex:a> <ex:b> "whatever"^^<ex:b> .

Par exemple, I(<ex:a> <ex:b> <ex:c> .) = true si <I(ex:a), I(ex:c)> est dans IEXT(I(<ex:b>)), c'est-à-dire si <1, 2> est dans IEXT(1), qui est {<1, 2>, <2, 1>} et contient donc <1, 2>, et donc I(<ex:a <ex:b> ex:c>) est vrai.

La vérité du quatrième triplet est une conséquence de l'interprétation plutôt idiosyncratique choisie ici pour les littéraux typés.

Dans cette interprétation, IP est un sous-ensemble de IR ; ce sera typique des interprétations sémantiques RDF, mais ce n'est pas obligé.

Elle rend ces triplets faux :

<ex:a> <ex:c> <ex:b> .

<ex:a> <ex:b> <ex:b> .

<ex:c> <ex:a> <ex:c> .

<ex:a> <ex:b> "whatever" .

Par exemple, I(<ex:a> <ex:c> <ex:b> .) = true si <I(ex:a), I(<ex:b>)>, c'est-à-dire <1, 1>, est dans IEXT(I(ex:c)) ; mais I(ex:c) = 2, qui n'est pas dans IP, donc IEXT n'est pas défini pour 2, et donc la condition échoue et I(<ex:a> <ex:c> <ex:b> .) = false.

Elle rend aussi tous les triplets contenant un littéral ordinaire faux, puisque l'extension de propriété n'a aucun couple contenant un littéral ordinaire.

En rappel : il ne s'agit que d'une seule interprétation possible de ce vocabulaire ; il y en a beaucoup d'autres (infiniment). Par exemple, si cette interprétation était modifiée en joignant l'extension de propriété à 2 au lieu de 1, aucun des triplets précédents ne serait vrai.

Cet exemple illustre le fait que toute interprétation qui associe une référence URI, apparaissant en position de prédicat d'un triplet dans un graphe, à quelque chose qui n'est pas dans IP rendra le graphe faux.

Les noeuds anonymes sont traités comme indiquant simplement l'existence d'une chose, sans utiliser le nom de cette chose, ou dire quelque chose à son propos. (Ce n'est pas pareil de supposer que le noeud anonyme indique une référence URI « inconnue » (unknown) ; ainsi cela ne suppose pas qu'il y a une référence URI qui se rapporte à la chose. L'explication de la skolémisation(skolemization) à l'annexe A est en relation avec ce point).

Une interprétation peut indiquer la valeur de vérité d'un graphe contenant des noeuds anonymes. Cela nécessitera des définitions puisque la théorie n'offre jusqu'ici aucune méthode pour les noeuds anonymes. Supposons I une interprétation et A une application d'un ensemble de noeuds anonymes vers l'univers IR de I, et définissons I+A comme étant une interprétation étendue, pareille à I sauf qu'elle utilise A pour donner l'interprétation des noeuds anonymes. Définissons blank(E) comme étant l'ensemble des noeuds anonymes dans E. On peut alors étendre les règles précédentes pour inclure les deux nouveaux cas introduits lorsque des noeuds anonymes apparaissent dans le graphe :

Conditions sémantiques des noeuds anonymes.

Remarquez que cela ne change pas la définition d'une interprétation ; elle se compose toujours des mêmes valeurs IR, IP, IEXT, IS, LV et IL. Cela étend simplement les règles de définition des dénotations sous une interprétation, et donc la même interprétation qui fournit une valeur de vérité pour des graphes fondamentaux affecte également des valeurs de vérité à des graphes avec des noeuds anonymes, même si elle ne fournit aucune dénotation pour les noeuds anonymes eux-mêmes. Remarquez également que les noeuds anonymes eux-mêmes sont des entités parfaitement bien définies ; ceux-ci diffèrent seulement des autres noeuds en cela qu'aucune interprétation ne leur affecte de dénotation, reflétant l'intuition qu'ils n'ont aucune signification « globale » (c'est-à-dire hors du graphe où ils apparaissent).

Par exemple, le graphe défini par les triplets suivants est faux dans l'interprétation montrée en figure 1 :

_:xxx <ex:a> <ex:b> .

<ex:c> <ex:b> _:xxx .

Puisque si l'application A' associe le noeud anonyme à 1, alors le premier triplet est faux dans I+A', et si elle l'associe à 2, alors le deuxième triplet est faux.

Notez que chacun de ces triplets, si on les considérait comme un seul graphe, serait vrai dans I, mais non le graphe entier ; et que si on utilisait un identificateur de noeud différent (nodeID) dans les deux triplets, indiquant que le graphe RDF avait deux noeuds anonymes au lieu d'un, alors A' pourrait associer un noeud à 2 et l'autre à 1, et le graphe résultant serait vrai sous l'interprétation I.

On traite effectivement tous les noeuds anonymes comme ayant la même signification que des variables quantifiées existentielles (existentially quantified variables) dans le grapheRDF où ils apparaissent, et qui ont une visibilité (scope) dans le graphe entier. Par rapport à la syntaxe N-Triples, cela équivaut à la convention qui placerait les quantificateurs juste en dehors, ou à la lisière externe, du document N-Triples correspondant au graphe. D'où il ressort qu'il y a une différence de signification subtile mais importante entre l'opération de former l'union de deux graphes et celle d'en former la fusion. La simple union de deux graphes correspond à la conjonction (« ET ») de tous les triplets dans les graphes, en conservant l'identité des noeuds anonymes qui apparaissent dans les deux graphes. C'est approprié lorsque les informations dans les graphes proviennent d'une seule source, ou que l'une est dérivée de l'autre au moyen d'un processus d'inférence valide, comme par exemple lors de l'application d'une règle d'inférence pour ajouter un triplet à un graphe. La fusion de deux graphes traite les noeuds anonymes dans chaque graphe comme étant quantifiés existentiellement dans ce graphe, de sorte qu'aucun noeud anonyme n'est autorisé à errer dans le champ du quantificateur qui entoure l'autre graphe. C'est approprié lorsque les graphes proviennent de sources différentes et qu'il n'y a aucune raison de supposer qu'un noeud anonyme dans l'un se rapporte à la même entité qu'un noeud anonyme dans l'autre.

Les interprétations simples et l'implication simple capturent la sémantique des graphes RDF lorsqu'aucune attention n'est prêtée à la signification particulière des noms dans le graphe. Pour obtenir la signification complète d'un graphe RDF écrit avec un vocabulaire particulier, il est en général nécessaire d'ajouter des conditions sémantiques qui attachent des significations plus fortes à des références URI et littéraux typés particuliers dans le graphe. Les interprétations qui sont tenues de satisfaire à des conditions sémantiques supplémentaires sur un vocabulaire particulier seront désignées génériquement comme étant des interprétations de vocabulaire (vocabulary interpretations). Une implication de vocabulaire signifie une implication par rapport à de telles interprétations de vocabulaire. Ces notions plus fortes d'interprétation et d'implication sont indiquées par l'utilisation d'un préfixe d'espace de noms, et nous nous référerons donc à une rdf-implication (rdf-entailment), une rdfs-implication (rdfs-entailment), etc., dans la suite. Dans chaque cas, le vocabulaire dont la signification est restreinte et les conditions exactes associées à ce vocabulaire sont rédigés en détail.

Le vocabulaire RDF rdfV est un ensemble de références URI dans l'espace de noms rdf :

Les rdf-interpretations impose des conditions sémantiques supplémentaires sur rdfV et sur les littéraux typés de type rdf:XMLLiteral, dit le type de données natif de RDF. Ce type de données est décrit complètement dans le document Concepts et syntaxe abstraite RDF [RDF-CONCEPTS]. Toute chaîne de caractères sss qui satisfait aux conditions pour être dans l'espace lexical de rdf:XMLLiteral sera appelée une chaîne littéral XML bien typée (well-typed XML literal string). La valeur correspondante sera appelée la valeur XML du littéral. Notez que les valeurs XML des littéraux XML bien typés se trouvent dans une correspondance de type 1:1 précise avec les chaînes littérales XML de ces littéraux, mais ne sont pas elles-mêmes des chaînes de caractères. Un littéral XML dont la chaîne littérale est bien typée sera appelée un littéral XML bien typé (well-typed XML literal) ; les autres littéraux XMLseront dits mal typés (ill-typed).

Une rdf-interprétation d'un vocobulaire V est une interprétation simple I de (V union rdfV) qui satisfait aux conditions supplémentaires décrites dans le tableau suivant et dans tous les triplets des tableaux subséquents. Ces triplets sont appelés les triplets axiomatiques RDF (RDF axiomatic triples).

Conditions sémantiques RDF :

On pourrait regarder la première condition comme définissant IP pour être l'ensemble des ressources dans l'univers de l'interprétation qui ont la valeur I(rdf:Property) de la propriété I(rdf:type). De tels sous-ensembles de l'univers seront centraux dans les interprétations de RDFS. Notez que cette condition impose que IP soit un sous-ensemble de IR. La troisième condition impose que les littéraux XML mal typés dénotent autre chose qu'une valeur littérale : ce sera la façon standard de traiter les littéraux typés mal formés.

Triplets axiomatiques RDF :

	rdf:type rdf:type rdf:Property .
	rdf:subject rdf:type rdf:Property .
	rdf:predicate rdf:type rdf:Property .
	rdf:object rdf:type rdf:Property .
	rdf:first rdf:type rdf:Property .
	rdf:rest rdf:type rdf:Property .
	rdf:value rdf:type rdf:Property .
	rdf:_1 rdf:type rdf:Property .
	rdf:_2 rdf:type rdf:Property .
	... 
	rdf:nil rdf:type rdf:List .

Les rdfs-interprétations décrites à la section 4 plus loin affectent des conditions sémantiques supplémentaires (des conditions d'image et de domaine) aux propriétés utilisées dans le vocabulaire RDF, et d'autres extensions sémantiques peuvent imposer plus de conditions pour restreindre encore leurs significations, mais ces conditions doivent être compatibles avec celles décrites dans cette section.

Par exemple, la rdf-interprétation suivante étend l'interprétation simple de la figure 1 au cas où V contient rdfV. Pour simplifier, nous ignorons ici les littéraux XML.

IR = LV union {1, 2, T , P}

IP = {1, T}

IEXT: 1 = >{<1, 2>, <2, 1>}, T = >{<1, P>, <T, P>}

IS: ex:a = >1, ex:b = >1, ex:c = > 2, rdf:type = >T, rdf:Property = >P, rdf:nil = >1, rdf:List = >P, rdf:Statement = >P, rdf:subject = >1, rdf:predicate = >1, rdf:object = >1, rdf:first = >1, rdf:rest = >1, rdf:Seq = >P, rdf:Bag = >P, rdf:Alt = >P, rdf:_1, rdf:_2, ... = >1

Figure 2 : Une rdf-interprétation.

Ce n'est pas la rdf-interprétation la plus petite qui étend l'exemple antérieur, puisqu'on aurait pu faire que IEXT(T) soit {<1, 2>, <T, 2>}, sans avoir P dans l'univers. En général, une entité donnée dans une interprétation peut jouer plusieurs « rôles » en même temps, tant que cela n'enfreint pas les conditions sémantiques imposées. L'interprétation ci-dessus, par exemple, identifie les propriétés avec des listes ; bien sûr, d'autres interprétations ne réaliseront peut-être pas cette identification.

Chaque rdf-interprétation est également une interprétation simple. La structure « supplémentaire  ne l'empêche pas de jouer le rôle plus simple.

S rdf-implique E lorsque chaque rdf-interprétation qui satisfait chaque membre de S satisfait aussi E. Cette formulation suit celle de la définition de l'implication simple à la section 2, mais ne se rapporte qu'aux rdf-interprétations au lieu des interprétations simples. La rdf-implication est un exemple d'implication de vocabulaire (vocabulary entailment).

On voit aisément que les lemmes de la section 2 ne s'appliquent pas tous à la rdf-implication, ainsi le triplet :

	rdf:type rdf:type rdf:Property .

Est vrai dans chaque rdf-interprétation, et est donc rdf-impliqué par le graphe vide, contredisant le lemme d'interpolation de la rdf-implication. La section 7.2 décrit les conditions exactes de détection de l'implication RDF.

Les conditions sémantiques RDF imposent des contraintes formelles importantes seulement sur la signification du vocabulaire RDF central, et les notions de rdf-implication et de rdf-interprétation s'appliquent donc au reste du vocabulaire sans autre modification. Cela inclut le vocabulaire destiné à la description des conteneurs et des collections liées, et un vocabulaire de réification qui permet à un graphe RDF de décrire ainsi que d'exposer les triplets. Dans cette section, nous examinons les significations attendues de ce vocabulaire, et notons quelques conséquences évidentes qui ne sont pas gérées par la théorie des modèles formelle. Les extensions sémantiques peuvent limiter les interprétations formelles de ces conditions afin de se conformer à ces significations attendues.

L'omission de ces conditions de la sémantique formelle est une décision de conception pour tenir compte des divergences dans l'utilisation du RDF existant et pour faciliter la mise en oeuvre de processus pour vérifier l'implication RDF formelle. Ainsi, les mises en oeuvre peuvent opter pour l'utilisation de techniques procédurales spéciales pour implanter (implement) le vocabulaire des collections RDF.

VI-C-1. Réification▲

		aaa rdf:type rdf:Statement .

		<ex:a> <ex:b> <ex:c> .

		_:xxx rdf:type rdf:Statement .
		_:xxx rdf:subject <ex:a> .
		_:xxx rdf:predicate <ex:b> .
		_:xxx rdf:object <ex:c> .

		aaa bbb ccc .

		_:xxx rdf:type rdf:Statement .
		_:xxx rdf:subject <ex:subject> .
		_:xxx rdf:predicate <ex:predicate> .
		_:xxx rdf:object <ex:object> .
		_:yyy rdf:type rdf:Statement .
		_:yyy rdf:subject <ex:subject> .
		_:yyy rdf:predicate <ex:predicate> .
		_:yyy rdf:object <ex:object> .
		_:xxx <ex:property> <ex:foo> .

		_:yyy <ex:property> <ex:foo> .

VI-C-2. Conteneurs RDF▲

		_:xxx rdf:type rdf:Bag .
		_:xxx rdf:_1 <ex:a> .
		_:xxx rdf:_2 <ex:b> .

		_:xxx rdf:_1 <ex:b> .
		_:xxx rdf:_2 <ex:a> .

		_:xxx rdf:type rdf:Seq .
		_:xxx rdf:_1 <ex:a> .
		_:xxx rdf:_3 <ex:c> .

		_:xxx rdf:_2 _:yyy .

VI-C-3. Collections RDF▲

		_:c1 rdf:first aaa .
		_:c1 rdf:rest _:c2 .

		_:c1 rdf:first <ex:aaa> .
		_:c1 rdf:rest _:c2 .
		_:c2 rdf:first <ex:bbb> .
		_:c2 rdf:rest rdf:nil .

		_:c3 rdf:first <ex:bbb> .
		_:c3 rdf:rest _:c4 .
		_:c4 rdf:first <ex:aaa> .
		_:c4 rdf:rest rdf:nil .

		_:666 rdf:first <ex:aaa> .
		_:666 rdf:first <ex:bbb> .
		_:666 rdf:rest <ex:ccc> .
		_:666 rdf:rest rdf:nil .

VI-C-4. rdf:value▲

RDF Schema [RDF-VOCABULARY] étend RDF afin d'inclure un vocabulaire rdfsV avec des contraintes sémantiques plus complexes :

(rdfs:comment, rdfs:seeAlso, rdfs:isDefinedBy et rdfs:label sont inclus ici parce que certaines contraintes afférentes à leur utilisation peuvent être déclarées avec rdfs:domain, rdfs:range et rdfs:subPropertyOf. À part ça, la sémantique formelle ne leur attribut pas de significations particulières.)

Bien que cela ne soit pas strictement nécessaire, il est commode de présenter la sémantique RDFS par rapport à une nouvelle construction sémantique, une « classe », c'est-à-dire une ressource qui représente un ensemble de choses dans l'univers qui toutes ont cette classe en valeur de leur propriété rdf:type. Les classes sont des choses définies de type rdfs:Class, et l'ensemble de toutes les classes dans une interprétation sera nommé IC. Les conditions sémantiques sont déclarées en fonction d'une application ICEXT (abréviation de Extension de C lasse dans I) de IC vers l'ensemble des sous-ensembles de IR. Les significations de ICEXT et IC dans une rdf-interprétation du vocabulaire RDFS sont entièrement définies par les deux premières conditions dans le tableau des conditions sémantiques RDFS ci-dessous. Remarquez qu'une classe peut avoir une extension de classe vide, que (comme noté précédemment) deux entités de classe différentes pourraient avoir la même extension de classe, et que l'extension de classe de rdfs:Class contient la classe rdfs:Class.

Une rdfs-interprétation de V est une rdf-interprétation I de (V union rdfV union rdfsV) qui satisfait aux conditions sémantiques suivantes et à tous les triplets, appelés les triplets axiomatiques RDFS, dans le tableau suivant.

Conditions sémantiques RDFS :

Triplets axiomatiques RDFS :

	rdf:type rdfs:domain rdfs:Resource .
	rdfs:domain rdfs:domain rdf:Property .
	rdfs:range rdfs:domain rdf:Property .
	rdfs:subPropertyOf rdfs:domain rdf:Property .
	rdfs:subClassOf rdfs:domain rdfs:Class .
	rdf:subject rdfs:domain rdf:Statement .
	rdf:predicate rdfs:domain rdf:Statement .
	rdf:object rdfs:domain rdf:Statement .
	rdfs:member rdfs:domain rdfs:Resource .
	rdf:first rdfs:domain rdf:List .
	rdf:rest rdfs:domain rdf:List .
	rdfs:seeAlso rdfs:domain rdfs:Resource .
	rdfs:isDefinedBy rdfs:domain rdfs:Resource .
	rdfs:comment rdfs:domain rdfs:Resource .
	rdfs:label rdfs:domain rdfs:Resource .
	rdf:value rdfs:domain rdfs:Resource .
	
	rdf:type rdfs:range rdfs:Class .
	rdfs:domain rdfs:range rdfs:Class .
	rdfs:range rdfs:range rdfs:Class .
	rdfs:subPropertyOf rdfs:range rdf:Property .
	rdfs:subClassOf rdfs:range rdfs:Class .
	rdf:subject rdfs:range rdfs:Resource .
	rdf:predicate rdfs:range rdfs:Resource .
	rdf:object rdfs:range rdfs:Resource .
	rdfs:member rdfs:range rdfs:Resource .
	rdf:first rdfs:range rdfs:Resource .
	rdf:rest rdfs:range rdf:List .
	rdfs:seeAlso rdfs:range rdfs:Resource .
	rdfs:isDefinedBy rdfs:range rdfs:Resource .
	rdfs:comment rdfs:range rdfs:Literal .
	rdfs:label rdfs:range rdfs:Literal .
	rdf:value rdfs:range rdfs:Resource .
	
	rdf:Alt rdfs:subClassOf rdfs:Container .
	rdf:Bag rdfs:subClassOf rdfs:Container .
	rdf:Seq rdfs:subClassOf rdfs:Container .
	rdfs:ContainerMembershipProperty rdfs:subClassOf rdf:Property .
	
	rdfs:isDefinedBy rdfs:subPropertyOf rdfs:seeAlso .
	
	rdf:XMLLiteral rdf:type rdfs:Datatype .
	rdf:XMLLiteral rdfs:subClassOf rdfs:Literal .
	rdfs:Datatype rdfs:subClassOf rdfs:Class .
	
	rdf:_1 rdf:type rdfs:ContainerMembershipProperty .
	rdf:_1 rdfs:domain rdfs:Resource .
	rdf:_1 rdfs:range rdfs:Resource .
	rdf:_2 rdf:type rdfs:ContainerMembershipProperty .
	rdf:_2 rdfs:domain rdfs:Resource .
	rdf:_2 rdfs:range rdfs:Resource .
	...

Puisque I est une rdf-interprétation, la première condition implique que IP = ICEXT(I(rdf:Property)).

Ces axiomes et conditions présentent des redondances : par exemple, tous les triplets axiomatiques RDF sauf un peuvent être dérivés des triplets axiomatiques RDFS et des conditions sémantiques sur ICEXT, rdfs:domain et rdfs:range. D'autres triplets qui doivent être vrais dans toutes les rdfs-interprétations comprennent :

Quelques triplets qui sont rdfs-valides(rdfs-valid) :

	rdfs:Resource rdf:type rdfs:Class .
	rdfs:Class rdf:type rdfs:Class .
	rdfs:Literal rdf:type rdfs:Class .
	rdf:XMLLiteral rdf:type rdfs:Class .
	rdfs:Datatype rdf:type rdfs:Class .
	rdf:Seq rdf:type rdfs:Class .
	rdf:Bag rdf:type rdfs:Class .
	rdf:Alt rdf:type rdfs:Class .
	rdfs:Container rdf:type rdfs:Class .
	rdf:List rdf:type rdfs:Class .
	rdfs:ContainerMembershipProperty rdf:type rdfs:Class .
	rdf:Property rdf:type rdfs:Class .
	rdf:Statement rdf:type rdfs:Class .
	
	rdfs:domain rdf:type rdf:Property .
	rdfs:range rdf:type rdf:Property .
	rdfs:subPropertyOf rdf:type rdf:Property .
	rdfs:subClassOf rdf:type rdf:Property .
	rdfs:member rdf:type rdf:Property .
	rdfs:seeAlso rdf:type rdf:Property .
	rdfs:isDefinedBy rdf:type rdf:Property .
	rdfs:comment rdf:type rdf:Property .
	rdfs:label rdf:type rdf:Property .

Notez que les types de données peuvent avoir des extensions de classe, c'est-à-dire qu'ils sont considérés comme étant des classes, dans RDFS. Comme illustré par la condition sémantique sur l'extension de classe de rdf:XMLLiteral, les membres d'une classe de type de données sont les valeurs du type de données. Cela est expliqué plus en détails à la section 5 ci-dessous. La classe rdfs:Literal contient toutes les valeurs littérales ; par contre, les littéraux typés dont les chaînes ne sont pas conformes aux exigences lexicales de leur type de données sont obligés d'avoir des significations qui ne sont pas dans cette classe. Les conditions sémantiques sur les rdf-interprétations impliquent que ICEXT(I(rdf:XMLLiteral)) contient toutes les valeurs XML des littéraux XML bien typés.

Les conditions sur rdf:XMLLiteral et rdfs:range prises ensemble rendent possible l'écriture d'une déclaration contradictoire dans RDFS, en affirmant qu'une valeur de propriété doit être dans la classe rdf:XMLLiteral mais en appliquant à cette propriété une valeur qui est un littéral XML mal formé, donc obligé de ne pas être dans cette classe. Par exemple :

<ex:a> <ex:p> "<notLegalXML"^^ rdf:XMLLiteral . <ex:p> rdfs:range rdf:XMLLiteral .

Ne peut pas être vrai dans une rdfs-interprétation ; cette déclaration est rdfs-incohérente(rdfs-inconsistent).

La sémantique donnée ci-dessus a été délibérément choisie pour être l'interprétation raisonnable « la plus faible » du vocabulaire RDFS. Des extensions sémantiques peuvent renforcer les conditions sémantiques d'image (range), de domaine (domain), de sous-classe (subclass) et de sous-propriété (subproperty) vers les versions « extensionnelles » suivantes :

Alternatives extensionnelles pour quelques conditions sémantiques RDFS.

Ce qui garantirait la transitivité et la réflexivité des propriétés de sous-propriété et de sous-classe, mais aurait aussi d'autres conséquences.

Ces conditions renforcées seraient satisfaites à l'évidence lorsque les propriétés sont identifiées par des extensions de propriété, les classes par des extensions de classe, et rdfs:SubClassOf compris dans le sens de sous-ensemble, et donc seraient satisfaites par une sémantique extensionnelle de RDFS. En quelque sorte, les versions extensionnelles offrent une sémantique simplifiée, mais elles nécessitent des règles d'inférence plus complexes. La sémantique « intensionnelle » (intensional) décrite dans le texte principal pourvoit aux utilisations les plus courantes des assertions de sous-classe et de sous-propriété, et permet des mises en oeuvre plus simples d'un ensemble complet de règles d'implication RDFS, décrit à la section 7.3.

Bien que les conditions sémantiques sur les rdfs-interprétations incluent la condition raisonnable intuitive selon laquelle ICEXT(I(rdfs:Literal)) doit être l'ensemble LV, il n'y a aucun moyen d'imposer cette condition par une assertion RDF ou une règle d'inférence. Cette limitation est due au fait que RDF ne permet pas l'apparition de littéraux en position de sujet d'un triplet, il y a donc des restrictions strictes sur ce que l'on peut dire à propos des littéraux en RDF. De même, alors que l'on peut affirmer des propriétés comme étant de la classe rdfs:Literal, aucune d'elles ne peut être transférée de façon valide aux littéraux eux-mêmes.

Par exemple, un triplet de la forme :

	<ex:a> rdf:type rdfs:Literal .

Est cohérent même si « ex:a » est une référence URI au lieu d'un littéral. Ce qu'il dit est que I(ex:a) est une valeur littérale, c'est-à-dire que la référence URI « ex:a » dénote une valeur littérale. Elle n'indique pas exactement quelle valeur littérale elle dénote.

Les conditions sémantiques garantissent que tout triplet contenant un objet de type littéral ordinaire implique un triplet similaire avec un noeud anonyme comme objet :

	<ex:a> <ex:b> "10" .

implique :

	<ex:a> <ex:b> _:xxx .

Cela signifie que le littéral dénote une entité, que l'on pourrait donc nommer, au moins en principe, par une référence URI.

S rdfs-implique (rdf-entails) E lorsque chaque rdfs-interprétation qui satisfait chaque membre de S satisfait aussi E. Cette formulation suit celle de la définition de l'implication simple à la section 2, mais ne se rapporte qu'aux rdfs-interprétations au lieu de toutes les interprétations simples. La rdfs-implication est un exemple d'implication de vocabulaire.

Puisque chaque rdfs-interprétation est une rdf-interprétation, si S rdfs-implique E alors S rdf-implique E ; mais la rdfs-implication est plus forte que la rdf-implication. Même le graphe vide a un grand nombre de rdfs-implications qui ne sont pas des rdf-implications. Par exemple, tous les triplets de la forme :

	xxx rdf:type rdfs:Resource .

Sont vrais dans toutes les rdfs-interprétations d'un vocabulaire contenant la référence URI xxx.

Un graphe rdfs-incohérent rdfs-implique tout graphe, selon la définition de l'implication ; toutefois, en pratique, de telles « implications évidentes » par un ensemble incohérent ne sont habituellement pas considérées comme des inférences utiles à tirer.

RDF pourvoit à l'utilisation de types de données définis extérieurement, identifiés par une référence URI particulière. Dans l'intérêt de la généralité, RDF impose des conditions minimales sur un type de données. RDF inclut également le seul type de donnée natif rdf:XMLLiteral.

Cette sémantique des types de données est minimale. Elle ne prévoit pas d'associer un type de données à une propriété qui puisse s'appliquer à toutes les valeurs de la propriété, et ne fournit aucun moyen d'affirmer explicitement qu'un noeud anonyme dénote une valeur de type de données particulière. Des extensions sémantiques et des versions futures de RDF pourront imposer des conditions de typage (datatyping) plus élaborées. Les extensions sémantiques peuvent également se référer à d'autres types d'information à propos d'un type de données, tels que des ordres de l'espace de valeurs.

Un type de données est une entité caractérisée par un ensemble de chaînes de caractères appelées des formes lexicales (lexical forms) et une application de cet ensemble vers un ensemble de valeurs. Les définitions exactes de ces ensembles et applications sont extérieures à RDF.

Formellement, un type de données d est défini par trois éléments :

• un ensemble non vide de chaînes de caractères appelé l'espace lexical (lexical space) de d ;
• un ensemble non vide appelé l'espace de valeurs (value space) de d ;
• une application de l'espace lexical de d vers l'espace de valeurs de d, appelée l'application lexique-à-valeur (lexical-to-value mapping) de d.

L'application lexique-à-valeur d'un type de données d est écrite L2V(d).

Dans la déclaration de la sémantique, nous supposons que les interprétations sont relatives à un ensemble particulier de types de données, chacun d'eux étant identifié par une référence URI.

Formellement, soit D un ensemble de couples, composés d'une référence URI et d'un type de données, tel qu'aucune référence URI n'apparaît deux fois dans l'ensemble, que l'on puisse donc considérer D comme une fonction d'un ensemble de références URI vers un ensemble de types de données : appelons-la une application de type de données (datatype map). (Les références URI particulières doivent être mentionnées explicitement afin de s'assurer que les interprétations soient conformes aux conventions de nommage imposées par l'autorité externe responsable de la définition des types de données.) Chaque application de type de données comprend <rdf:XMLLiteral, x> où x est le type de données littéral XMLnatif, dont l'espace lexical, l'espace de valeurs et l'application lexique-à-valeur sont définis dans le document Concepts et syntaxe abstraite RDF [RDF-CONCEPTS].

L'application de type de données, qui contient également l'ensemble de tous les couples de la forme <http://www.w3.org/2001/XMLSchema# sss, sss>, où sss est un type de données natif nommé sss dans XML Schema tome 2 - Types de données [XML-SCHEMA2] et listé dans le tableau suivant, est appelée ici XSD.

Ces autres types de données XML Schema natifs ne conviennent pas pour des raisons diverses, et on ne devrait pas les utiliser : le type xsd:duration n'a pas d'espace de valeurs bien défini (cela sera peut-être corrigé dans des révisions ultérieures des types de données XML Schema, auquel cas le type de données révisé serait utilisable dans le typage RDF); les types xsd:QName et xsd:ENTITY nécessitent un contexte de document XML englobant ; les types xsd:ID et xsd:IDREF servent pour des références croisées au sein d'un documentXML ; xsd:NOTATION n'est pas utilisable directement ; xsd:IDREFS, xsd:ENTITIES et xsd:NMTOKENS sont des types de données à valeur de séquence (sequence-valued datatypes) qui ne rentrent pas dans le modèle de type de données RDF.

Si D est une application de type de données, une D-interprétation d'un vocabulaire V est toute rdfs-interprétation I de V union {aaa: < aaa, x > dans D pour x } qui satisfait aux conditions supplémentaires suivantes pour chaque couple <aaa, x> dans D :

Conditions sémantiques générales des types de données :

La première condition assure que I interprète la référence URI conformément à l'application de type de données fournie. Notez que cela n'empêche pas d'autres références URI de dénoter également le type de données.

La deuxième condition assure que la référence URI du type de données, lorsqu'utilisée comme un nom de classe, se rapporte à l'espace de valeurs du type de données, et que tous les éléments d'un espace de valeurs doivent être des valeurs littérales.

La troisième condition assure que les littéraux typés dans le vocabulaire respectent l'application lexique-à-valeur du type de données. Par exemple, si I est une XSD-interprétation, alors I("15"^^xsd:decimal) doit être le nombre quinze. La condition impose également qu'un littéral mal typé, dont la chaîne littérale n'est pas dans l'espace lexicale du type de données, ne dénote pas de valeur littérale. Intuitivement, un tel nom ne dénote aucune valeur, mais pour éviter les complexités sémantiques qui surviennent avec des noms vides, la sémantique impose qu'un tel littéral typé dénote une valeur non littérale « arbitraire ». Ainsi, par exemple, si I est une XSD-interprétation, alors tout ce que l'on peut conclure à propos de I("arthur"^^xsd:decimal) c'est que cela n'est pas dans LV, c'est-à-dire pas dans ICEXT(I(rdfs:Literal)). Un littéral mal typé ne constitue pas en soi une incohérence, mais un graphe qui impliquerait qu'un littéral mal typé a le type rdf:type rdfs:Literal, ou qu'un littéral XML mal typé a le type rdf:type rdf:XMLLiteral, serait incohérent.

Notez que cette troisième condition ne s'applique qu'aux types de données dans l'image de D. Les littéraux typés dont le type n'est pas dans l'application de type de données de l'interprétation sont traités comme auparavant, c'est-à-dire comme dénotant une chose inconnue. La condition n'impose pas que la référence URI dans le littéral typé soit la même que la référence URI associée du type de données ; cela permet des extensions sémantiques qui peuvent exprimer des conditions d'identité sur les références URI pour tirer des conclusions appropriées.

La quatrième condition assure que la classe rdfs:Datatype contient les types de données utilisées dans toute D-interprétation satisfaisante. Remarquez que c'est une conditions nécessaire mais pas suffisante ; elle permet à la classe I(rdfs:Datatype) de contenir d'autres types de données.

Les conditions sémantiques des rdf-interprétations imposent l'interprétation correcte sur les littéraux typés par "rdf:XMLLiteral". Toutefois, une D-interprétation reconnaît l'existence du type de données comme entité au lieu d'être simplement une condition sémantique imposée à la syntaxe littérale typée RDF. Les extensions sémantiques qui peuvent exprimer des conditions d'identité sur des ressources pourraient donc tirer des conclusions plus fortes des D-interprétations que des rdfs-interprétations.

Si les types de données dans l'application de type de données D imposent des conditions de disjonction sur leurs espaces de valeurs, il est possible pour un graphe RDF de n'avoir aucune D-interprétation qui la satisfasse. Par exemple, XML Schema définit les espaces de valeurs de xsd:string et xsd:decimal comme étant disjoints, il est donc impossible de construire une XSD-interprétation satisfaisant le graphe suivant :

	<ex:a> <ex:b> "25"^^xsd:decimal .
	<ex:b> rdfs:range xsd:string .

On pourrait caractériser cette situation en disant que le graphe est XSD-incohérent, ou plus généralement comme étant un conflit de types de données (datatype clash). Notez qu'il est possible de construire une rdfs-interprétationsatisfaisante pour ce graphe, mais elle enfreindrait les conditons XSD, puisque l'intersection des extensions de classe de I(xsd:decimal) et I(xsd:string) ne serait pas vide.

Les conflits de types de données peuvent survenir de plusieurs autres façons. Par exemple, toute assertion selon laquelle quelque chose est à la fois dans deux classes de type de données disjointes :

	_:x rdf:type xsd:string .
	_:x rdf:type xsd:decimal .

Ou selon laquelle une propriété avec une image « impossible » a une valeur :

	<ex:p> rdfs:range xsd:string .
	<ex:p> rdfs:range xsd:decimal .
	_:x <ex:p> _:y .

Constituerait un conflit de types de données. Un conflit de types de données peut aussi se produire à cause de l'utilisation d'une forme lexicale particulière, par exemple :

	<ex:a> <ex:p> "2.5"^^xsd:decimal .
	<ex:p> rdfs:range xsd:integer .

Ou de l'utilisation d'une forme lexicale mal typée :

	<ex:a> <ex:p> "abc"^^xsd:integer .
	<ex:p> rdfs:range xsd:integer .

Les conflits de types de données sont les seules incohérences reconnues par cette théorie des modèles ; notez cependant que des conflits de types de données impliquant des littéraux XML peuvent se produire en RDFS.

Si D est un sous-ensemble de D', alors restreindre les interprétations d'un graphe à des D'-interprétations équivaut à une extension sémantique comparée à la même restriction par rapport à D. En fait, l'extension de l'application de type de données produit des assertions implicites à propos des littéraux typés en les obligeant à dénoter des entités dans l'espace de valeurs d'un type de données. Les contraintes sémantiques supplémentaires associées à l'application de type de données plus grande forceront les interprétations à rendre plus de triplets vrais, mais elles peuvent aussi révéler des conflits et infractions de types de données, de sorte qu'un graphe D-cohérent pourrait être D'-incohérent.

Disons qu'un graphe RDF reconnaisse une référence URI de type de données aaa lorsque le graphe rdfs-implique un triplet de typage (datatyping triple) de la forme :

	aaa rdf:type rdfs:Datatype .

Les conditions sémantiques des rdfs-interprétations imposent de reconnaître la référence URI de type de données natif « rdf:XMLLiteral ».

Si chaque référence URI reconnue dans un graphe est le nom d'un type de données connu, alors il existe une application de type de données naturelle DG qui associe chaque référence URI reconnue à ce type de données connu (et « rdf:XMLLiteral » à rdf:XMLLiteral). Toute rdfs-interprétation I de ce graphe a alors une DG-interprétation « naturelle » correspondante qui est pareille à I sauf que I(aaa) est le type de données approprié et que l'extension de classe de rdfs:Datatype est modifiée de façon appropriée. Les applications peuvent imposer que les graphes RDF soient interprétés par des D-interprétations où D contient une application de type de données naturelle du graphe. Cela équivaut à traiter les triplets de typage comme des « déclarations » de types de données par le graphe et à transformer la quatrième condition sémantique en une condition « si et seulement si » ('iff' condition). Notez par contre qu'un triplet de typage ne fournit pas en soi l'information nécessaire pour vérifier qu'un graphe satisfait aux autres conditions sémantiques de type de données, et qu'il n'écarte pas formellement les autres interprétations, et donc adopter cette exigence comme principe d'implication formel enfreindrait le lemme de monotonicité générale décrit à la section 6 à suivre.

S D-implique (D-entails) E lorsque chaque D-interprétation qui satisfait chaque membre de S satisfait aussi E. Cette formulation suit celle de la définition de l'implication simple à la section 2, mais ne se rapporte qu'aux D-interprétations au lieu des interprétations simples. La D-implication (D-entailment) est un exemple d'implication de vocabulaire.

Comme noté précédemment, il est possible qu'un graphe cohérent dans un vocabulaire devienne incohérent dans une extension sémantique définie sur un vocabulaire plus grand, et les D-interprétations permettent les incohérences dans un graphe RDF. La définition d'une implication de vocabulaire signifie qu'un graphe incohérent impliquera tout graphe dans l'implication du vocabulaire plus fort. Ainsi, un graphe D-incohérent D-implique tout graphe RDF. Toutefois, il ne sera en général pas approprié de considérer de telles implications « évidentes » comme des conséquences utiles, puisqu'elles ne sont peut-être pas des implications valides dans un vocabulaire plus petit.

Le lemme d'interpolation de la section 2 peut être caractérisé par les règles d'implication suivantes qui génèrent des généralisations, c'est-à-dire des graphes qui ont le graphe original comme instance. D'être un sous-ensemble ne nécessite aucune formulation implicite comme règle d'inférence sur les triplets.

Règles d'implication simple :

La terminologie « alloué à » signifie que le noeud anonyme doit avoir été créé par une application antérieure des règles indiquées sur les mêmes référence URI, noeud anonyme ou littéral, ou s'il n'y a pas de tel noeud anonyme, ce doit alors être un « nouveau » noeud qui n'apparaît pas dans le graphe. Cette condition plutôt compliquée assure que le graphe résultant, obtenu en ajoutant les nouveaux triplets à noeud anonyme (blank-node triples), a le graphe original comme instance propre et qu'un tel graphe aura un sous-graphe qui est le même que l'un pouvant être généré par ces règles. Par exemple, le graphe :

	<ex:a> <ex:p> <ex:b> .
	<ex:c> <ex:q> <ex:a> .

pourraient être développé comme suit :

• _:x <ex:p> <ex:b> . par se1 en utilisant un nouveau noeud _:x qui est alloué à ex:a ;
• <ex:c> <ex:q> _:x . par se2 en utilisant le même _:x alloué à ex:a ;
• _:x <ex:p> _:y . par se2 en utilisant un nouveau noeud _:y qui est alloué à ex:b.

Mais il serait inexact d'inférer :

• ** _:x <ex:q> <ex:a> . ** par se2 (** puisque _:x n'est pas alloué à ex:c).

Ces règles permettent la prolifération des noeuds anonymes, en produisant des graphes très alourdis (highly non-lean) ; elles sanctionnent des implications telles que :

• <ex:a> <ex:p> <ex:b> . ;
• <ex:a> <ex:p> _:x . par xse1 avec _:x alloué à ex:b ;
• <ex:a> <ex:p> _:y . par xse1 avec _:y alloué à _:x ;
• _:z <ex:p> _:y . par xse2 avec _:z alloué à ex:a ;
• _:u <ex:p> _:y . par xse2 avec _:u alloué à _:z ;
• _:u <ex:p> _:v . par xse1 avec _:v alloué à _:y .

On voit tout de suite que S est une instance de E si et seulement si l'on peut dériver E de S en appliquant ces règles dans un ordre convenable ; on peut découvrir les applications de règles nécessaires en examinant l'application d'instance (instance mapping). Ainsi, selon le lemme d'interpolation, S implique simplement E si et seulement si l'on peut dériver (un graphe contenant) E de S par l'application de ces règles. Par contre, il est clair également que l'application naïve de ces règles ne se traduirait pas par un processus de recherche efficace, puisque les règles ne se termineront pas et pourront produire arbitrairement beaucoup de dérivations redondantes de triplets équivalents.

Le problème général de déterminer une implication simple entre des graphes RDF arbitraires est décidable mais NP-complet (NP-complet). On peut le démontrer en codant le problème de détecter un sous-graphe d'un graphe orienté arbitraire comme une implication RDF, en n'utilisant que des noeuds anonymes pour représenter le graphe (observation faite par Jeremy Carroll).

Les ensembles de règles suivants pour détecter l'implication RDF et RDFS utilisent un cas particulier de la règle se1 qui ne s'applique qu'aux littéraux :

Règle de généralisation littérale :

Notez que cette règle est juste suffisante pour reproduire un sous-graphe de E constitué de triplets contenant tous un littéral donné comme un sous-graphe isomorphe dans lequel le littéral est remplacé par un noeud anonyme unique. L'importance de ceci tient au fait que les noeuds anonymes peuvent être en position de sujet dans un triplet RDF, permettant aux autres règles qui expriment des propriétés de la valeur littérale dénotée par ce littéral de tirer des conclusions.

Pour l'implication RDFS, une règle supplémentaire est nécessaire, laquelle inverse la règle lg :

Règle d'instanciation littérale :

Il est clair que la règle gl produira simplement une redondance, sauf dans les cas où le noeud anonyme alloué aura été introduit en position d'objet d'un nouveau triplet par quelque autre règle d'inférence. L'effet de ces règles est d'assurer que tout triplet contenant un littéral, et le triplet similaire contenant le noeud anonyme alloué, soient toujours dérivables l'un de l'autre, afin de pouvoir identifier un littéral et son noeud anonyme alloué dans le but d'appliquer ces règles.

Règles d'implication RDF :

Ces règles sont complètes dans le sens suivante.

Lemme d'implication RDF (RDF entailment lemma). S rdf-implique E si et seulement s'il existe un graphe dérivable de S plus les triplets axiomatiques RDF par l'application de la règle lg et des règles d'implication RDF, et qui implique simplement E. (Démonstration en Annexe A).

Notez que cela ne nécessite pas l'utilisation de la règle gl.

Règles d'implication RDFS :

Établir la complétude(completeness) de ces règles nécessite plus d'attention, puisqu'il est possible pour un graphe d'être rdfs-incohérent en vertu de contenir des assertions insatisfiables à propos de littéraux XML mal typés, par exemple :

	<ex:a> rdfs:subClassOf rdfs:Literal .
	<ex:b> rdfs:range <ex:a> .
	<ex:c> rdfs:subPropertyOf <ex:b> .
	<ex:d> <ex:c> "<"^^rdf:XMLLiteral .

Où la dénotation du littéral XML mal typé est obligée de ne pas être une valeur littérale mais elle peut être inférée dans le cadre des autres assertions. Puisqu'un tel graphe rdfs-incohérent rdfs-implique tous les graphes RDF, même sans qu'ils soient liés syntaxiquement à l'antécédent, nous devons exclure ce cas.

Les règles d'implication peuvent reconnaître un signe caractéristique d'incohérence, par la dérivation d'un triplet de la forme :

	xxx rdf:type rdfs:Literal .

Où xxx est alloué à un littéral XML mal typé par la règle lg. Appelons un tel triplet un conflit XML (XML clash). La dérivation d'un tel conflit à partir de l'exemple ci-dessus est facile :

• <ex:d> <ex:c> _:1 . (par la règle lg, avec _:1 alloué à "<"^^rdf:XMLLiteral) ;
• <ex:d> <ex:b> _:1 . (par la règle rdfs7) ;
• _:1 rdf:type <ex:a>. (par la règle rdfs3) ;
• _:1 rdf:type rdfs:Literal . (par la règle rdfs9).

Ces règles sont donc complètes dans le sens suivant :

Lemme d'implication RDFS (RDFS entailement lemma). S rdfs-implique E si et seulement s'il existe un graphe dérivable de S plus les triplets axiomatiques RDF et RDFS par l'application des règles lg, gl et des règles d'implication RDF et RDFS, et qui soit implique simplement E, soit contient un conflit XML. (Démonstration en Annexe A).

Les règles RDFS sont quelque peu redondantes. Ainsi, tous les triplets axiomatiques RDF sauf un sont dérivables des règles rdfs2 et rdfs3 et des triplets axiomatiques RDFS.

Les résultats (outputs) de ces règles en lanceront souvent d'autres. Ces règles propageront toutes les assertions rdf:type dans le graphe en amont des hiérarchies de sous-propriétés et de sous-classes, en les réaffirmant pour toutes les super-propriétés et les super-classes. La règle rdf1 générera des assertions de type pour tous les noms de propriété utilisés dans le graphe, et la règle rdfs3 avec le dernier triplet axiomatique RDFS ajouterons toutes les assertions de type de tous les noms de classe utilisés. Toute assertion de sous-propriété ou de sous-classe générera les assertions de type appropriées pour ses sujet et objet via les règles rdfs2 et rdfs3 et les assertions de domaine et d'image dans l'ensemble des triplets axiomatiques RDFS. Les règles généreront toutes les assertions de la forme :

	uuu rdf:type rdfs:Resource .

Pour chaque uuu dans V, et de la forme :

	uuu rdfs:subClassOf rdfs:Resource .

Pour chaque nom de classe uuu ; et plusieurs faits plus « universels », tels que :

	rdf:Property rdf:type rdfs:Class .

X-C-1. Règles d'implication extensionnelles▲

Pour capturer une implication de type de données (datatype entailment) en fonction d'assertions et de règles d'implication, les règles ont besoin de se référer aux informations fournies par les types de données eux-mêmes ; et pour établir les règles, il est nécessaire de supposer des conditions syntaxiques qui ne sont vérifiables qu'en consultant les sources des types de données.

Pour chaque type d'information disponible à propos d'un type de données, on peut établir des règles d'inférence pour ce type d'information, ce que l'on peut assimiler à une extension du tableau des règles d'implication RDFS. Il faudrait les comprendre comme une application aux types de données, hormis le type de données natif, des règles qui font partie des règles d'implication RDFS. Les règles établies ci-dessous supposent qu'une information est disponible à propos du type de données dénoté par une référence URI reconnue, et qu'elles utilisent cette référence URI pour se référer au type de données.

L'information de base indique, pour chaque chaîne littérale, s'il s'agit oui ou non d'une forme lexicale légale pour le type de données, c'est-à-dire l'une qui correspond à une valeur sous l'application lexique-à-valeur du type de données. Cela correspond à la règle suivante, pour chaque chaîne sss qui est une forme lexicale légale du type de données dénoté par ddd :

Supposons les deux formes lexicales sss et ttt connues comme correspondant à la même valeur sous le type de données dénoté par ddd ; alors la règle suivante s'applique :

Supposons que la forme lexicale sss du type de données dénoté par ddd et la forme lexicale ttt du type de données dénoté par eee soient connues pour correspondre à la même valeur ; alors la règle suivante s'applique :

En outre, si l'espace de valeurs du type de données dénoté par ddd est connu comme étant un sous-ensemble de celui du type de données dénoté par eee, alors il serait approprié d'affirmer que :

	ddd rdfs:subClassOf eee .

Mais il faut l'affirmer explicitement ; cela ne découle pas de la relation de sous-ensemble seule.

En supposant que l'information codée dans ces règles est correcte, appliquer celles-ci et les règles précédentes produira un graphe qui est D-impliqué par l'original.

Les règles rdfD2 et rdfD3 sont essentiellement des substitutions en vertu des équivalences entre les formes lexicales. De telles équivalences sont capables de générer infiniment beaucoup de conclusions ; par exemple, il est possible d'ajouter un nombre quelconque de zéros de tête à une forme lexicale de xsd:integer sans que celle-ci cesse d'être une forme lexicale correcte pour xsd:integer. Pour éviter de telles inférences correctes mais inutiles, il suffit de restreindre la règle rdfD2 aux cas qui remplacent une forme lexicale par la forme canonique du type de données en question, si une telle forme canonique est définie. Toutefois, pour ne pas omettre des implications valides, de telles règles de canonisation devraient s'appliquer aux conclusions ainsi qu'aux antécédents des implications proposées, et les règles correspondantes de type rdfD3 devrait refléter une connaissance des identités entre les formes canoniques du type de données distinct.

Dans des cas particuliers, d'autres informations seraient disponibles, qui pourraient s'exprimer à l'aide d'un vocabulaire RDFS particulier. Les extensions sémantiques peuvent également définir en plus de telles significations spécifiques d'un type de données.

Ces règles permettent de conclure que tout littéral typé bien formé d'un type de données reconnu dénotera quelque chose dans la classe rdfs:Literal.

	<ex:a> <ex:p> "sss"^^<ex:dtype> .
	<ex:dtype> rdf:type rdfs:Datatype .

• <ex:a> <ex:p> _:nnn . (par la règle lg).
• _:nnn rdf:type <ex:dtype> . (par la règle rdfD1).
• <ex:dtype> rdfs:subClassOf rdfs:Literal . (par la règle rdfs11).
• _:nnn rdf:type rdfs:Literal . (par la règle rdfs9).

La règle rdfD1 suffit à exposer quelques cas de conflit de type de données, par une chaîne de raisonnement de la forme suivante :

	<ex:p> rdfs:range <ex:dtype> .
	<ex:a> <ex:p> "sss"^^<ex:otherdtype> .

• <ex:a> <ex:p> _:>nnn .
• _:nnn rdf:type <ex:otherdtype> . (par la règle rdfD1).
• _:nnn rdf:type <ex:dtype> . (par la règle rdfs3).

Ces règles ne fourniront peut-être pas un ensemble complet de principes d'inférences pour la D-implication, puisqu'il peut y avoir des D-implications valides pour des types de données particuliers qui dépendent de propriétés idiosyncratiques des types de données particuliers, telles que la dimension (size) de l'espace de valeurs (par exemple, xsd:boolean n'a que deux éléments, donc tout ce qui est établi pour ces deux valeurs doit être vrai pour tous les littéraux avec ce type de données). En particulier, l'espace de valeurs et l'application lexique-à-valeur du type de données XSD xsd:string autorisent l'identification des littéraux typés avec des littéraux ordinaires sans étiquette de langue pour toutes les chaînes de caractères qui se trouvent dans l'espace lexical du type de données, puisque les deux dénotent la chaîne de caractères Unicode affichée dans le littéral ; la règle d'inférence suivante est donc valide dans toutes les XSD-interprétations. Ici "sss" indique toute chaîne RDF dans l'espace lexical de xsd:string.

Encore une fois, comme avec les règles rdfD2 et rdfD3, les applications peuvent effectuer un remplacement systématique de l'une de ces formes équivalentes par l'autre au lieu d'appliquer directement ces règles.

XIII-A-1. Références normatives▲

XIII-A-2. Références non normatives▲