Sémantique RDF

| Patrick Hayes (IHMC) (rédacteur) | Brian McBride (Hewlett Packard Labs) |

Spécification de la sémantique précise et des systèmes de règles d'inférence complets correspondants du cadre de description de ressource (RDF) et de RDF Schema (RDFS).
Commentez

- Titre : Sémantique RDF

- Auteurs : Patrick Hayes (IHMC) (rédacteur), Brian McBride (Hewlett Packard Labs)

- Parution : 1 juin 2011

- Mise à jour : 22 juin 2011

- Public visé :

- Licence : Copyright ® 2011-2013 Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. Notes

- II. Statut de ce document

- III. Introduction

- III-A. Spécification d'une sémantique formelle : portée et limitations

- III-B. Syntaxe des graphes

- III-C. Définitions des graphes

- IV. Interprétations

- IV-A. Note technique (informatif)

- IV-B. Références URI, ressources et littéraux

- IV-C. Interprétations

- IV-D. Dénotations des graphes fondamentaux

- IV-E. Noeuds anonymes comme variables existentielles

- V. Implication simple entre graphes RDF

- V-A. Interprétations de vocabulaire et implication de vocabulaire

- VI. Interpréter le vocabulaire RDF

- VI-A. Interprétations RDF

- VI-B. Implication RDF

- VI-C. Réification, conteneurs, collections et rdf:value

- VI-C-1. Réification

- VI-C-2. Conteneurs RDF

- VI-C-3. Collections RDF

- VI-C-4. rdf:value

- VII. Interpréter le vocabulaire RDFS

- VII-A. Interprétations RDFS

- VII-B. Conditions sémantiques extensionnelles (informatif)

- VII-C. Note à propos de rdfs:Literal

- VII-D. Implication RDFS

- VIII. Interpréter les types de données

- VIII-A. Interprétations avec types de données

- VIII-B. D-implication

- IX. Monotonicité des extensions sémantiques

- X. Règles d'implication (informatif)

- X-A. Règles d'implication simple

- X-B. Règles d'implication RDF

- X-C. Règles d'implication RDFS

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

- X-D. Règle d'implication de type de données

- XI. Annexe A. Démonstrations des lemmes (informatif)

- XII. Annexe B. Glossaire (informatif)

- XIII. Annexe C. Remerciements

- XIII-A. Références

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

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

- XIV. Annexe D. Journal des changements (informatif)

- XV. Remerciements

I - Notes

Cette version : http://www.w3.org/TR/2004/REC-rdf-mt-20040210/.

Dernière version : http://www.w3.org/TR/rdf-mt/.

Version précédente : http://www.w3.org/TR/2003/PR-rdf-mt-20031215/.

Veuillez consulter la page des errata de ce document, laquelle peut contenir des corrections normatives.

Cf. également d'éventuelles traductions.

Copyright © 2004 W3C ™ (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

II - Statut de ce document

Ce document a été examiné par les membres du W3C et des tiers intéressés et il a été approuvé par le Directeur comme recommandation du W3C. Le rôle du W3C en produisant la recommandation est d'attirer l'attention sur la spécification et d'en promouvoir le large déploiement. Cela participe à la fonctionnalité et à l'interopérabilité du Web.

Ce document fait partie d'un ensemple de six (initiation, concepts, syntaxe, sémantique, vocabulaire et jeux d'essais), destinés à remplacer conjointement les spécifications RDF originales, à savoir modèle et syntaxe RDF (recommandation de 1999) et schéma RDF (recommandation candidate de 2000). Il a été développé par le groupe de travail RDF Core sous l'égide de l'activité Semantic Web du W3C (déclaration d'activité, charte du groupe) pour une publication le 10 février 2004.

Les changements effectués sur ce document depuis le projet de recommandation proposée sont détaillés dans le journal des changements.

Le public est invité à envoyer ses commentaires sur la liste de diffusion www-rdf-comments@w3.org (archives) et à discuter des questions générales de la technologie liée sur www-rdf-interest@w3.org (archives).

Une liste de mises en œuvre est disponible.

Le W3C tient une liste des divulgations de brevets en rapport à ce travail.

Cette section décrit le statut de ce document au moment de sa publication. D'autres documents peuvent venir le remplacer. On trouvera une liste des publications courantes du W3C et la dernière révision de ce rapport technique dans l'index des rapports techniques du W3C.

III - Introduction

III-A - Spécification d'une sémantique formelle : portée et limitations

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

III-B - Syntaxe des graphes

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.

III-C - Définitions des graphes

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].

IV - Interprétations

IV-A - Note technique (informatif)

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 Lbase [LBASE].

IV-B - Références URI, ressources et littéraux

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.

IV-C - Interprétations

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 :

Une interprétation simple I d'un vocabulaire V est définie par :
1. un ensemble IR non vide de ressources, appelé le domaine ou l'univers de I.
2. un ensemble IP, appelé l'ensemble des propriétés de I.
3. une application IEXT de IP vers l'ensemble des parties (powerset) de IR x IR, c'est-à-dire l'ensemble des ensembles de couples <x, y> avec x et y dans IR.
4. une application IS des références URI dans V vers (IR union IP).
5. une application IL des littéraux typés dans V vers IR.
6. un sous-ensemble distinctif LV de IR, appelé l'ensemble des valeurs littérales, qui contient tous les littéraux ordinaires dans V

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é.

IV-D - Dénotations des graphes fondamentaux

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 E est un littéral ordinaire "aaa" dans V, alors I(E) = aaa

si E est un littéral ordinaire "aaa"@ttt dans V, alors I(E) = <aaa, ttt>

si E est un littéral typé dans V, alors I(E) = IL(E)

si E est une référence URI dans V, alors I(E) = IS(E)

si E est un triplet fondamental s p o., alors I(E) = true si :
s, p et o sont dans V, I(p) est dans IP et <I(s), I(o)> est dans IEXT(I(p))
sinon I(E) = false.

si E est un graphe RDF fondamental, alors I(E) = false si I(E') = false pour un triplet E' dans E, sinon I(E) = true.

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.

IV-E - Noeuds anonymes comme variables existentielles

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.

Si E est un noeud anonyme et A(E) est défini, alors [I+A](E) = A(E)

Si E est un graphe RDF, alors I(E) = true si [I+A'](E) = true pour une application A' de blank(E) vers IR ; sinon I(E) = false.

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.

V - Implication simple entre graphes RDF

En suivant la terminologie conventionnelle, I satisfait E si I(E) = true, et un ensemble S de graphes RDF implique(simplement) un graphe E, si chaque interprétation qui satisfait chaque membre de S satisfait aussi E. Ces notions seront adaptées à d'autres classes d'interprétations dans les dernières sections, mais tout au long de cette section-ci, une « implication » (entailment) aura le sens d'implication simple.

L'implication est l'idée principale qui relie la sémantique modéliste (model-theoretic semantics) aux applications du monde réel. Comme noté précédemment, faire une assertion (assertion) équivaut à proclamer que le monde est une interprétation qui affecte la valeur de vérité vrai à l'assertion. Si A implique B, alors toute interprétation qui fait que A est vrai fait aussi que B est vrai, et donc qu'une assertion de A contient déjà la même « signification » qu'une assertion de B ; on pourrait dire que la signification de B est en quelques sorte contenue dans, ou subsumée par, celle de A. Si A et B s'impliquent mutuellement, alors tous deux signifient la même chose, dans la mesure où supposer l'un ou l'autre proclame la même chose à propos du monde. L'intérêt de cette observation apparaît plus clairement lorsque A et B sont des expressions différentes, puisque la relation d'implication est alors exactement le permis sémantique approprié pour justifier une application inférant ou générant l'un à partir de l'autre. Au travers des notions de satisfaction, d'implication et de validité, la sémantique formelle donne la définition rigoureuse d'une notion de « signification » qui peut être liée directement à des méthodes calculables pour déterminer si la signification est conservée ou non par une transformation sur une représentation de la connaissance.

Tout processus qui construit un graphe E à partir d'un autre graphe S (ou de plusieurs) est dit valide (simplement) si S implique E dans chaque cas, sinon il est invalide. Notez qu'un processus invalide ne veut pas dire que la conclusion soit fausse, et qu'un processus valide n'est pas une garantie de vérité. Toujours est-il que la validité représente la meilleure garantie qu'un langage assertionnel peut offrir : si on lui donne des entrées vraies, il n'en tirera jamais une conclusion fausse.

Cette section donne quelques résultats élémentaires à propos de l'implication simple et de l'inférencevalide. On peut reconnaître une implication simple par des comparaisons syntaxiques relativement simples. Les deux formes élémentaires d'inférence valide simplement en RDF sont, en termes logiques, l'inférence de (P et Q) vers P, et l'inférence de foo(baz) vers (exists (?x) foo(?x)).

Ces résultats ne s'appliquent qu'à l'implication simple, pas aux notions d'implication étendues introduites dans les dernières sections. Les démonstrations (proofs), toutes allant de soi, sont données à l'annexe A, qui décrit aussi d'autres propriétés de l'implication susceptibles d'intérêt.

Lemme de graphe vide (empty graph lemma). L'ensemble des triplets vide est impliqué par tout graphe et n'implique aucun graphe sauf lui-même. [Démonstration]

Lemme de sous-graphe (subgraph lemma). Un graphe implique tous ses sous-graphes. [Démonstration]

Lemme d'instance (instance lemma). Un graphe est impliqué par n'importe laquelle de ses instances. [Démonstration]

La relation entre la fusion et l'implication est simple et évidente selon les définitions suivantes :

Lemme de fusion (merging lemma). La fusion d'un ensemble S de graphes RDF est impliquée par S et implique chaque membre de S. [Démonstration]

Cela signifie qu'un ensemble de graphes peut être traité comme équivalent à sa fusion, c'est-à-dire un seul graphe, en ce qui concerne la théorie des modèles. Cela peut être utilisé pour simplifier un peu la terminologie : ainsi on peut paraphraser la définition de S implique E ci-dessus en disant que S implique E lorsque chaque interprétation qui satisfait S satisfait également E.

Que l'union simple d'un ensemble de graphes soit impliquée par l'ensemble, ce n'est en général pas le cas comme le montre l'exemple donné en section 4.5.

Le résultat principal d'une inférence RDF simple est le :

Lemme d'interpolation (interpolation lemma). S implique un graphe E si et seulement si un sous-graphe de S est une instance de E. [Démonstration]

Le lemme d'interpolation caractérise complètement l'implication RDF simple en termes syntaxiques. Pour dire si un ensemble de graphes RDF en implique un autre, cherchez s'il existe un instance du graphe impliqué qui soit un sous-ensemble de l'ensemble de graphes original. Il n'est bien sûr pas nécessaire de construire réellement la fusion. En partant du graphe E conséquent(consequent), une technique efficace serait de traiter les noeuds anonymes comme des variables dans un processus d'appariement de sous-graphes (subgraph-matching), en les liant à des noms « correspondant » dans le graphe (ou les graphes) antécédent(antecedent) dans S, c'est-à-dire ceux qui peuvent impliquer le graphe conséquent. Le lemme d'interpolation montre que ce processus est valide, et il est complet également si l'algorithme d'appariement de graphes l'est. L'existence* d'algorithmes d'appariement de graphes complets montre aussi que l'implication RDF est décidable, c'est-à-dire qu'il existe un algorithme de terminaison (terminating algorithm) qui déterminera, pour tout ensemble S fini et tout graphe E, si S implique E ou non.

Un tel processus de liaison par variable (variable-binding process) ne serait approprié qu'appliqué à la conclusion d'une implication proposée. Cela correspond à utiliser le document comme un but ou une interrogation, contrairement à l'affirmer, c'est-à-dire à le proclamer vrai. Si le document RDF est affirmé, il serait alors invalide de lier des nouvelles valeurs à l'un de ses noeuds anonymes, puisque le graphe résultant ne serait pas impliqué par l'assertion.

Le lemme d'interpolation a pour conséquence immédiate un critère de non-implication :

Lemme d'anonymat (anonymity lemma). Supposons E un graphe mince et E' une instance propre de E. Alors E n'implique pas E'. [Démonstration]

Notez encore que cela ne s'applique qu'à l'implication simple, non aux relations des implications de vocabulaire définies dans le reste du document.

Plusieurs propriétés élémentaires de l'implication découlent directement des définitions et résultats précédents, elles sont présentés ici pour exhaustivité :

Lemme de monotonicité (monotonicity lemma). Soit S un sous-graphe de S' et S implique E. Alors S' implique E. [Démonstration]

La propriété selon laquelle des expressions finies sont toujours dérivables d'un ensemble fini d'antécédents est appelée la compacité (compactness). Les théories sémantiques qui utilisent des notions non compactes de l'implication n'ont pas de systèmes d'inférence calculable correspondants.

Lemme de compacité (compactness lemma). Si S implique E et E est un graphe fini, un sous-ensemble fini S' de S implique E. [Démonstration]

V-A - Interprétations de vocabulaire et implication de vocabulaire

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.

VI - Interpréter le vocabulaire RDF

VI-A - Interprétations RDF

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

Vocabulaire RDF

rdf:type rdf:Property rdf:XMLLiteral rdf:nil rdf:List rdf:Statement rdf:subject rdf:predicate rdf:object rdf:first rdf:rest rdf:Seq rdf:Bag rdf:Alt rdf:_1 rdf:_2 ...rdf:value

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 :

x est dans IP si et seulement si <x, I(rdf:Property)> est dans IEXT(I(rdf:type))

Si "xxx"^^rdf:XMLLiteral est dans V et xxx est une chaîne littérale XML bien typée, alors :
IL("xxx"^^rdf:XMLLiteral) est la valeur XML de xxx ;
IL("xxx"^^rdf:XMLLiteral) est dans LV ;
IEXT(I(rdf:type)) contient <IL("xxx"^^rdf:XMLLiteral), I(rdf:XMLLiteral)>

Si "xxx"^^rdf:XMLLiteral est dans V et xxx est une chaîne littérale XML mal typée, alors :
IL("xxx"^^rdf:XMLLiteral) n'est pas dans LV ;
IEXT(I(rdf:type)) ne contient pas <IL("xxx"^^rdf:XMLLiteral), I(rdf:XMLLiteral)>.

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.

VI-B - Implication RDF

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.

VI-C - Réification, conteneurs, collections et rdf:value

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

Vocabulaire de réification RDF :

rdf:Statement rdf:subject rdf:predicate rdf:object

Les extensions sémantiques peuvent limiter leur interprétation, et donc un triplet de la forme :

aaa rdf:type rdf:Statement .

Est uniquement vrai dans I lorsque I(aaa) est un atome(token) d'un triplet RDF dans un document RDF, et les trois propriétés, lorsqu'elles sont appliquées à un tel triplet dénoté, ont les mêmes valeurs que les composants respectifs de ce triplet.

On peut l'illustrer en examinant les deux graphes RDF suivants, le premier constitué d'un seul triplet :

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

Et :

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

Le deuxième graphe est appelé une réification(reification) du triplet dans le premier graphe, et le noeud destiné à citer le premier triplet - le noeud anonyme dans le deuxième graphe - est appelé, plutôt confusément, un triplet réifié (reified triple). (Il peut s'agir d'un noeud anonyme ou d'une référence URI.) Dans l'interprétation attendue du vocabulaire de réification, le deuxième graphe deviendrait vrai dans une interprétation I en interprétant le triplet réifié comme rapporté à un atome du triplet du premier graphe dans un document RDFconcret, en considérant que cet atome est de la syntaxe RDF valide, puis en utilisant I pour interpréter le triplet syntaxique instancié par l'atome, afin que les sujet, prédicat et objet de ce triplet soient interprétés de la même manière dans la réification que dans le triplet décrit par la réification. On l'énoncerait formellement comme suit : <x, y> est dans IEXT(I(rdf:subject)) uniquement lorsque x est un atome d'un triplet RDF de la forme :

aaa bbb ccc .

Et y est dans I(aaa) ; idem pour le prédicat et l'objet. Remarquez que la valeur de la propriété rdf:subject n'est pas la référence URI du sujet même mais son interprétation, et donc cette condition suppose un processus d'interprétation en deux étapes : on doit interpréter le noeud réifié - le sujet des triplets dans la réification - pour se référer à un autre triplet, puis traiter ce triplet comme une syntaxe RDF et réadministrer l'application d'interprétation pour arriver au référent de son sujet. Cela exige des atomes du triplet qu'ils existent comme des entités de première classe dans l'univers IR d'une interprétation. En somme, la signification de la réification est qu'il existe un document contenant un atome de triplet qui signifie tout ce que le premier graphe signifie. Notez que cette manière de comprendre le vocabulaire de réification n'interprète pas la réification comme une forme de citation. Plutôt que la réification décrit la relation entre un atome d'un triplet et les ressources auxquelles ce triplet se rapporte. On peut lire la réification comme disant « ce bout de RDF traite de ces choses » au lieu de « ce bout de RDF a cette forme ».

L'extension sémantique décrite ici impose au triplet réifié que décrit cette réification - I(_:xxx) dans l'exemple ci-dessus - d'être un atome (ou une instance) particulier d'un triplet dans un document RDF (réel ou notionnel), plutôt qu'un triplet « abstrait » considéré comme une forme grammaticale. Plusieurs entités de ce genre pourraient avoir les mêmes propriétés de sujet, de prédicat et d'objet. Bien que l'on décrive un graphe comme un ensemble de triplets, plusieurs atomes de ce genre avec la même structure de triplet pourraient apparaître dans des documents différents. Ainsi proclamer que le noeud anonyme dans le deuxième graphe ci-dessus ne se rapporte pas au triplet dans le premier graphe mais à un autre triplet avec la même structure a un sens. Cette interprétation particulière de la réification a été choisie sur la base de cas d'utilisation où des propriétés telles que des dates de composition ou des informations de provenance ont été appliquées au triplet réifié, qui n'ont de sens que lorsqu'elles sont considérées comme se rapportant à une instance ou atome particuliers d'un triplet.

Bien que les applications RDF puissent utiliser une réification pour désigner des atomes de triplet dans des documents RDF, le lien entre le document et sa réification doit être maintenu par un moyen extérieur à la syntaxe du graphe RDF. (Dans la syntaxe RDF/XML décrite dans la Spécification de la syntaxe RDF/XML (révisée) [RDF-SYNTAX], on peut utiliser l'attribut rdf:ID dans la description d'un triplet pour créer une réification de ce triplet dans laquelle le triplet réifié est une adresse URI construite à partir de l'adresse URI de base du document XML et de la valeur de rdf:ID comme un fragment.) Puisque l'assertion de la réification d'un triplet n'affirme pas implicitement le triplet même, cela signifie qu'il n'y a aucune relation d'implication qui tienne entre un triplet et une réification de celui-ci. Ainsi le vocabulaire de réification n'a pas de contraintes sémantiques effectives sur elle, hormis celles qui s'appliquent à une rdf-interprétation.

Une réification d'un triplet n'implique pas le triplet et n'est pas impliquée par celui-ci. (La réification dit simplement que l'atome de triplet existe et de quoi il traite, pas qu'il est vrai. La deuxième non-implication est une conséquence du fait qu'affirmer un triplet n'exprime pas automatiquement que tous les atomes de triplet existent dans l'univers décrit par le triplet. Par exemple, le triplet pourrait faire partie d'une ontologie décrivant des animaux, lequel triplet serait satisfait par une interprétation où l'univers ne contiendrait que des animaux et où une réification du triplet serait donc fausse.)

Puisque la relation entre les triplets et les réifications des triplets dans un graphe (ou des graphes) RDF doit être injective (one-to-one), l'affirmation d'une propriété à propos d'une entité décrite par une réification n'a pas besoin d'impliquer que la même propriété tient pour une autre entité de ce genre, même si elle a les mêmes composants. Par exemple :

_: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> .

N'implique pas :

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

VI-C-2 - Conteneurs RDF

Vocabulaire des conteneurs RDF :

rdf:Seq rdf:Bag rdf:Alt rdf:_1 rdf:_2 ...

RDF fournit des vocabulaires pour décrire trois classes de conteneurs. Les conteneurs ont un type et leurs membres sont énumérables en utilisant un ensemble fixe de propriétés d'appartenance de conteneur (container membership properties). Ces propriétés sont indexées par des entiers pour pouvoir distinguer les membres les uns des autres mais on ne devrait pas considérer ces indices comme définissant un ordre (ordering) du conteneur en question ; certains conteneurs ne sont pas ordonnés.

Le vocabulaire RDFS, décrit ci-dessous, ajoute une propriété d'appartenance générique qui agit indépendamment de la position, et des classes contenant tous les conteneurs et toutes les propriétés d'appartenance.

On devrait comprendre ce vocabulaire RDF comme décrivant des conteneurs plutôt que comme un vocabulaire pour les construire, tel qu'en offrirait typiquement un langage de programmation. De ce point de vue, les conteneurs réels sont des entités dans l'univers sémantique, et les graphes RDF utilisant le vocabulaire fournissent simplement des informations très élémentaires à propos de ces entités, permettant à un graphe RDF de caractériser le type de conteneur et de donner une information partielle à propos des membres du conteneur. Puisque le vocabulaire des conteneurs RDF est si limité, beaucoup de suppositions « naturelles » concernant les conteneurs RDF ne sont pas sanctionnées formellement par la théorie des modèles RDF. Cela ne veut pas dire que ces suppositions sont fausses mais seulement que RDF n'implique pas formellement qu'elles doivent être vraies.

Il n'y a pas de conditions sémantiques spéciales sur le vocabulaire des conteneurs : la seule « structure » que RDF suppose ses conteneurs avoir est ce qui peut être inféré de l'utilisation de ce vocabulaire et des conditions sémantiques RDF générales. Cela revient en général à connaître le type du conteneur et avoir une énumération partielle des éléments du conteneur. Le mode d'utilisation attendu est que les choses de type rdf:Bag sont considérées comme étant non ordonnées et autorisant des copies (duplicates) ; les choses de type rdf:Seq sont considérées comme étant ordonnées ; et les choses de type rdf:Alt sont considérées comme représentant une collection d'options (alternatives), avec éventuellement une préférence d'ordre. L'ordre attendu des éléments dans un conteneur ordonné est indiqué par l'ordre numérique des propriétés d'appartenance de conteneur, lesquelles sont supposées avoir une valeur unique (single-valued). Quoiqu'il en soit, ces interprétations informelles ne se reflètent pas dans des implications RDF formelles.

RDF ne reconnaît pas d'implications qui naîtraient de l'énumération des éléments d'un conteneur rdf:Bag dans un ordre différent. Par exemple :

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

N'implique pas :

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

Remarquez que si cette conclusion était valide, alors le résultat de la conjoindre au graphe original serait également une implication valide, qui affirmerait que les deux éléments se trouvaient aux deux positions. C'est une conséquence du fait que RDF est un langage purement assertionnel.

Il n'y a aucune supposition selon laquelle une propriété d'un conteneur s'applique à l'un des éléments du conteneur, ou vice versa.

Il n'y a pas d'obligation formelle à ce que les trois classes de conteneurs soient disjointes, on peut ainsi affirmer qu'une chose est à la fois un rdf:Bag et un rdf:Seq. Il n'y a aucune supposition selon laquelle les conteneurs ne présentent pas de trous (gap-free), ainsi :

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

N'implique pas :

_:xxx rdf:_2 _:yyy .

En RDF, il n'y a aucun moyen de « clore » un conteneur, c'est-à-dire d'affirmer que celui-ci ne contient qu'un nombre fixe de membres. C'est une conséquence du fait qu'il est toujours cohérent d'ajouter un triplet à un graphe affirmant une propriété d'appartenance de conteneur quelconque. Et enfin, il n'y a aucune supposition native selon laquelle un conteneur RDF a seulement un nombre fini de membres.

VI-C-3 - Collections RDF

Vocabulaire des collections RDF

rdf:List rdf:first rdf:rest rdf:nil

RDF fournit un vocabulaire pour décrire des collections, c'est-à-dire des « structures de liste », en fonction de liens de tête et de queue (head-tail links). Les collections diffèrent des conteneurs en cela qu'elles autorisent une structure de ramification (branching structure) et qu'elles ont un terminateur explicite, permettant aux applications de déterminer l'ensemble exact des éléments dans la collection.

Comme pour les conteneurs, aucune condition sémantique spéciale n'est imposée sur ce vocabulaire hormis pour rdf:nil qui est de type rdf:List. On l'utilise typiquement dans le contexte d'un conteneur décrit en utilisant des noeuds anonymes pour connecter une séquence « bien formée » d'éléments, chacun décrit par deux triplets de la forme :

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

Où l'élément final est indiqué par l'utilisation de rdf:nil comme valeur de la propriété rdf:rest. En convention familière, on peut assimiler rdf:nil à la collection vide. Tout graphe de ce genre équivaut à une affirmation de l'existence de la collection, et puisqu'on peut déterminer les membres de la collection par une inspection, souvent cela suffit aux applications pour déterminer quelle est la signification. Toutefois, notez que la sémantique ne demande pas aux collections d'exister hormis celles mentionnées explicitement dans un graphe (et la collection vide). Par exemple, l'existence d'une collection contenant deux éléments ne garantit pas automatiquement que la collection similaire des éléments permutés existe aussi :

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

N'implique pas :

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

RDF n'impose également aucune condition de « bonne formation » (well-formedness) sur l'utilisation de ce vocabulaire, et il est donc possible d'écrire des graphes RDF qui affirment l'existence d'objets très étranges comme des listes avec des fins à bifurcation (forked tails) ou des fins non de liste (non-list tails), ou des listes à plusieurs débuts (multiple heads lists) :

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

Il est également possible d'écrire un ensemble de triplets qui manquent à définir (underspecify) une collection en omettant d'indiquer sa valeur de propriété rdf:rest.

Les extensions sémantiques peuvent placer des restrictions syntaxiques supplémentaires de bonne formation sur l'utilisation de ce vocabulaire afin d'écarter de tels graphes. Elles peuvent exclure les interprétations du vocabulaire des collections qui enfreignent la convention selon laquelle le sujet d'une collection « liée » d'éléments de deux triplets de la forme décrite ci-dessus, terminée par un élément qui finit par rdf:nil, dénote une séquence totalement ordonnée dont les membres sont les dénotations des valeurs rdf:first des éléments, dans l'ordre obtenu en retraçant les propriétés rdf:rest depuis le sujet jusqu'à rdf:nil. Cela permet d'avoir des séquences qui contiennent d'autres séquences.

Notez que les conditions sémantiques RDFS, décrites ci-après, imposent que tout sujet de la propriété rdf:first, et tout sujet ou objet de la propriété rdf:rest, soient de type rdf:List.

VI-C-4 - rdf:value

L'utilisation prévue de la propriété rdf:value est expliquée intuitivement dans le document d'Initiation à RDF [RDF-PRIMER]. Elle sert typiquement à identifier une valeur « primaire » ou « principale » d'une propriété qui a plusieurs valeurs ou qui a pour valeur une entité complexe avec plusieurs facettes ou propriétés propres.

La gamme des utilisations possibles de rdf:value étant si étendue, il est difficile de donner une description qui couvre toutes les significations attendues ou tous les cas d'utilisation. Nous prévenons donc les utilisateurs de ce que la signification de rdf:value peut varier d'une application à l'autre. En pratique, la signification attendue découle souvent clairement du contexte mais elle peut se perdre lorsque les graphes sont fusionnés ou lorsque les conclusions sont inférées.

VII - Interpréter le vocabulaire RDFS

VII-A - Interprétations RDFS

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

rdfs:domain rdfs:range rdfs:Resource rdfs:Literal rdfs:Datatype rdfs:Class rdfs:subClassOf rdfs:subPropertyOf rdfs:member rdfs:Container rdfs:ContainerMembershipProperty rdfs:comment rdfs:seeAlso rdfs:isDefinedBy rdfs:label

(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 :

x est dans ICEXT(y) si et seulement si <x, y> est dans IEXT(I(rdf:type))
IC = ICEXT(I(rdfs:Class))
IR = ICEXT(I(rdfs:Resource))
LV = ICEXT(I(rdfs:Literal))

Si <x, y> est dans IEXT(I(rdfs:domain)) et <u, v> est dans IEXT(x), alors u est dans ICEXT(y)

Si <x, y> est dans IEXT(I(rdfs:range)) et <u, v> est dans IEXT(x), alors v est dans ICEXT(y)

IEXT(I(rdfs:subPropertyOf)) est transitif et réflexif sur IP

Si <x, y> est dans IEXT(I(rdfs:subPropertyOf)), alors x et y sont dans IP et IEXT(x) est un sous-ensemble de IEXT(y)

Si x est dans IC, alors <x, I(rdfs:Resource)> est dans IEXT(I(rdfs:subClassOf))

Si <x, y> est dans IEXT(I(rdfs:subClassOf)), alors x et y sont dans IC et ICEXT(x) est un sous-ensemble de ICEXT(y)

IEXT(I(rdfs:subClassOf)) est transitif et réflexif sur IC

Si x est dans ICEXT(I(rdfs:ContainerMembershipProperty)), alors <x, I(rdfs:member)> est dans IEXT(I(rdfs:subPropertyOf))

Si x est dans ICEXT(I(rdfs:Datatype)), alors <x, I(rdfs:Literal)> est dans IEXT(I(rdfs:subClassOf))

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).

VII-B - Conditions sémantiques extensionnelles (informatif)

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.

<x, y> est dans IEXT(I(rdfs:subClassOf)) si et seulement si x et y sont dans IC et ICEXT(x) est un sous-ensemble de ICEXT(y)

<x, y> est dans IEXT(I(rdfs:subPropertyOf)) si et seulement si x et y sont dans IP et IEXT(x) est un sous-ensemble de IEXT(y)

<x, y> est dans IEXT(I(rdfs:range)) si et seulement si (si <u, v> est dans IEXT(x) alors v est dans ICEXT(y))

<x, y> est dans IEXT(I(rdfs:domain)) si et seulement si (si <u, v> est dans IEXT(x) alors u est dans ICEXT(y))

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.

VII-C - Note à propos de rdfs:Literal

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.

VII-D - Implication RDFS

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.

VIII - Interpréter les types de données

VIII-A - Interprétations avec types de données

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.

Types de données XSD

xsd:string, xsd:boolean, xsd:decimal, xsd:float, xsd:double, xsd:dateTime, xsd:time, xsd:date, xsd:gYearMonth, xsd:gYear, xsd:gMonthDay, xsd:gDay, xsd:gMonth, xsd:hexBinary, xsd:base64Binary, xsd:anyURI, xsd:normalizedString, xsd:token, xsd:language, xsd:NMTOKEN, xsd:Name, xsd:NCName, xsd:integer, xsd:nonPositiveInteger, xsd:negativeInteger, xsd:long, xsd:int, xsd:short, xsd:byte, xsd:nonNegativeInteger, xsd:unsignedLong, xsd:unsignedInt, xsd:unsignedShort, xsd:unsignedByte, xsd:positiveInteger

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 :

si <aaa, x> est dans D, alors I(aaa) = x

si <aaa, x> est dans D, alors ICEXT(x) est l'espace de valeurs de x et est un sous-ensemble de LV

si <aaa, x> est dans D, alors pour tout littéral typé "sss"^^ddd dans V avec I(ddd) = x,
si sss est dans l'espace lexical de x, alors IL("sss"^^ddd) = L2V(x)(sss), sinon IL("sss"^^ddd) n'est pas dans LV

si <aaa, x> est dans D, alors I(aaa) est dans ICEXT(I(rdfs:Datatype))

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.

VIII-B - D-implication

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.

IX - Monotonicité des extensions sémantiques

Étant donné un ensemble de graphes RDF, il existe plusieurs façons d'y « ajouter » de l'information. On peut ajouter des triplets à l'un des graphes ; on peut étendre l'ensemble des graphes par des graphes supplémentaires ; ou on peut interpréter le vocabulaire du graphe par rapport à une notion plus forte d'implication de vocabulaire, c'est-à-dire un ensemble élargi de conditions sémantiques imposées aux interprétations. Tout cela peut être considéré comme un ajout d'information et faire que plus d'implications tiennent (hold) qu'avant la modification. Tous ces ajouts sont monotones(monotonic), dans le sens où les implications tenues avant l'ajout d'information tiennent après. Ceci peut se résumer en un seul lemme :

Lemme de monotonicité général (general monotonicity lemma).

Supposons S et S' des ensembles de graphes RDF, chaque membre de S étant un sous-ensemble d'un membre de S'. Supposons Y une extension sémantique de X, telle que S X-implique E, S et E satisfaisant à toutes les restrictions syntaxiques de Y. Alors S' Y-implique E.

En particulier, si D' est une application de type de données, D un sous-ensemble de D', et si S D-implique E, alors S D'-implique E aussi.

X - Règles d'implication (informatif)

Les tableaux suivants, qui listent des formes d'inférence (inference patterns) capturant quelques-unes des diverses formes d'implication de vocabulaire, pourraient servir de guide à la conception de logiciels pour vérifier les graphes RDF d'une implication RDF et RDFS. Les mises en oeuvre peuvent se fonder sur une application préalable (applying forwards) des règles, ou sur un traitement de la conclusion comme une forme à reconnaître dans le conséquent d'une implication proposée et une recherche arrière (searching backwards) d'une correspondance appropriée avec d'autres conclusions de règle ou avec l'antécédent proposé. D'autres stratégies sont possibles.

Les règles sont toutes établies selon la forme « ajouter un triplet à un graphe lorsque celui-ci contient des triplets conformes à une forme », et sont toutes valides dans le sens suivant : un graphe implique (au sens approprié listé) un graphe plus grand obtenu en appliquant les règles au graphe original. Remarquez que l'application d'une telle règle à un graphe équivaut à former une union simple avec la conclusion, plutôt qu'une fusion, en préservant donc les noeuds anonymes qui seraient déjà dans le graphe.

Toutes ces règles emploient les conventions suivantes : les variables aaa, bbb, etc. représentent une référence URI, c'est-à-dire tout prédicat possible d'un triplet ; uuu, vvv, etc. représentent une référence URI ou un identificateur de noeud anonyme, c'est-à-dire tout sujet possible d'un triplet ; xxx, yyy, etc. une référence URI, un identificateur de noeud anonyme ou un littéral, c'est-à-dire tout sujet ou objet possibles d'un triplet ; lll un littéral ; et _:nnn, etc. des identificateurs de noeud anonyme.

X-A - Règles d'implication simple

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 :

Nom de la règle

Si E contient

alors ajouter

se1

uuu aaa xxx .

uuu aaa _:nnn .
où _:nnn identifie un noeud anonyme alloué à xxx par la règle se1 ou se2.

se2

uuu aaa xxx .

_:nnn aaa xxx .
où _:nnn identifie un noeud anonyme alloué à uuu par la règle se1 ou se2.

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 :

Nom de la règle

Si E contient

alors ajouter

lg

uuu aaa lll .

uuu aaa _:nnn .
où _:nnn identifie un noeud anonyme alloué au littéral lll par cette règle.

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 :

Nom de la règle

Si E contient

alors ajouter

gl

uuu aaa _:nnn .
où _:nnn identifie un noeud anonyme alloué au littéral lll par la règle lg.

uuu aaa lll .

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.

X-B - Règles d'implication RDF

Règles d'implication RDF :

Nom de la règle

if E contains

alors ajouter

rdf1

uuu aaa yyy .

aaa rdf:type rdf:Property .

rdf2

uuu aaa lll .
où lll est un littéral XML bien typé.

_:nnn rdf:type rdf:XMLLiteral .
où _:nnn identifie un noeud anonyme alloué à lll par la règle lg.

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.

X-C - Règles d'implication RDFS

Règles d'implication RDFS :

Nom de la règle

Si E contient

alors ajouter

rdfs1

uuu aaa lll.où lll est un littéral ordinaire (avec ou sans étiquette de langue).

_:nnn rdf:type rdfs:Literal .où _:nnn identifie un noeud anonyme alloué à lll par la règle lg.

rdfs2

aaa rdfs:domain xxx .uuu aaa yyy .

uuu rdf:type xxx .

rdfs3

aaa rdfs:range xxx .uuu aaa vvv .

vvv rdf:type xxx .

rdfs4a

uuu aaa xxx .

uuu rdf:type rdfs:Resource .

rdfs4b

uuu aaa vvv .

vvv rdf:type rdfs:Resource .

rdfs5

uuu rdfs:subPropertyOf vvv .vvv rdfs:subPropertyOf xxx .

uuu rdfs:subPropertyOf xxx .

rdfs6

uuu rdf:type rdf:Property .

uuu rdfs:subPropertyOf uuu .

rdfs7

aaa rdfs:subPropertyOf bbb .uuu aaa yyy .

uuu bbb yyy .

rdfs8

uuu rdf:type rdfs:Class .

uuu rdfs:subClassOf rdfs:Resource .

rdfs9

uuu rdfs:subClassOf xxx .vvv rdf:type uuu .

vvv rdf:type xxx .

rdfs10

uuu rdf:type rdfs:Class .

uuu rdfs:subClassOf uuu .

rdfs11

uuu rdfs:subClassOf vvv .vvv rdfs:subClassOf xxx .

uuu rdfs:subClassOf xxx .

rdfs12

uuu rdf:type rdfs:ContainerMembershipProperty .

uuu rdfs:subPropertyOf rdfs:member .

rdfs13

uuu rdf:type rdfs:Datatype .

uuu rdfs:subClassOf rdfs:Literal .

É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

Les conditions sémantiques extensionnelles plus fortes décrites à la section 4.2 sanctionnent plus encore les implications non couvertes par les règles RDFS. Le tableau suivant liste quelques formes d'implication (entailment patterns) qui sont valides dans cette sémantique plus forte. Ce n'est pas un ensemble complet de règles pour les conditions sémantiques extensionnelles. Notez qu'aucune de ces règles n'est rdfs-valide ; elles ne concernent que les extensions sémantiques qui appliquent les conditions sémantiques extensionnelles renforcées décrites à la section 4.2. Ces règles ont d'autres conséquences, par exemple que rdfs:Resource est un domaine et une image de chaque propriété.

Les règles ext5 à ext9 suivent une forme commune ; elles reflètent le fait que les conditions extensionnelles renforcées exigent que les domaines (et les images pour les propriétés transitives) des propriétés dans les vocabulaires rdfV et rdfsV soient aussi grands que possible, donc toute tentative de les restreindre sera renversée par les conditions sémantiques. Des règles similaires s'appliquent aux super-propriétés de rdfs:range et rdfs:domain. Probablement aucun de ces cas ne se produira en pratique.

Des inférences supplémentaires qui seraient valides sous les versions extensionnelles des conditions sémantiques RDFS :

ext1

uuu rdfs:domain vvv .
vvv rdfs:subClassOf zzz .

uuu rdfs:domain zzz .

ext2

uuu rdfs:range vvv .
vvv rdfs:subClassOf zzz .

uuu rdfs:range zzz .

ext3

uuu rdfs:domain vvv .
www rdfs:subPropertyOf uuu .

www rdfs:domain vvv .

ext4

uuu rdfs:range vvv .
www rdfs:subPropertyOf uuu .

www rdfs:range vvv .

ext5

rdf:type rdfs:subPropertyOf www .
www rdfs:domain vvv .

rdfs:Resource rdfs:subClassOf vvv .

ext6

rdfs:subClassOf rdfs:subPropertyOf www .
www rdfs:domain vvv .

rdfs:Class rdfs:subClassOf vvv .

ext7

rdfs:subPropertyOf rdfs:subPropertyOf www .
www rdfs:domain vvv .

rdf:Property rdfs:subClassOf vvv .

ext8

rdfs:subClassOf rdfs:subPropertyOf www .
www rdfs:range vvv .

rdfs:Class rdfs:subClassOf vvv .

ext9

rdfs:subPropertyOf rdfs:subPropertyOf www .
www rdfs:range vvv .

rdf:Property rdfs:subClassOf vvv .

X-D - Règle d'implication de type de données

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 :

rdfD1

ddd rdf:type rdfs:Datatype .
uuu aaa "sss"^^ddd .

_:nnn rdf:type ddd .
Où _:nnn identifie un noeud anonyme alloué à "sss"^^ddd par la règle lg.

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 :

rdfD2

ddd rdf:type rdfs:Datatype .
uuu aaa "sss"^^ddd .

uuu aaa "ttt"^^ddd .

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 :

rdfD3

ddd rdf:type rdfs:Datatype .
eee rdf:type rdfs:Datatype .
uuu aaa "sss"^^ddd .

uuu aaa "ttt"^^eee .

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.

xsd 1a

uuu aaa "sss" .

uuu aaa "sss"^^xsd:string .

xsd 1b

uuu aaa "sss"^^xsd:string .

uuu aaa "sss" .

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.

XI - Annexe A. Démonstrations des lemmes (informatif)

« L'un des mérites d'une démonstration est que celle-ci instille un certain doute quant au résultat démontré » - Bertrand Russell

Lemme de graphe vide. L'ensemble de triplets vide est impliqué par tout graphe et n'implique aucun graphe sauf lui-même.

Démonstration. Soit N l'ensemble de triplets vide. Les conditions sémantiques sur les graphes imposent que N soit vrai dans I, pour tout I ; la première partie découle donc de la définition de l'implication. Supposons que G soit un graphe non vide et s p o . un triplet dans G, alors une interprétation I tel que IEXT(I(p)) = { } ne satisfait pas G mais satisfait N ; donc N n'implique pas G - c.q.f.d. (ce qu'il fallait démontrer).

Cela signifie que la plupart des résultats subséquents sont évidents pour les graphes vides, ce à quoi on s'attendrait.

Lemme de sous-graphe. Un graphe implique tous ses sous-graphes.

Démonstration. Évidente, d'après les définitions du sous-graphe et de l'implication. Si le graphe est vrai dans I, alors pour un A, tous ses triplets sont vrais dans I+A, donc chaque sous-ensemble de triplets est vrai dans I - c.q.f.d.

Lemme de fusion. La fusion d'un ensemble de graphes RDF S est impliquée par S et implique chaque membre de S.

Démonstration. Évidente, d'après les définitions de l'implication et de la fusion. Tous les membres de S sont vrais si et seulement si tous les triplets dans la fusion de S sont vrais - c.q.f.d.

Cela signifie, comme noté dans le texte, qu'un ensemble de graphes peut être traité comme un seul graphe lorsqu'il s'agit de satisfaction et d'implication. Cette convention sera adopté dans le reste de l'annexe, où la référence à une interprétation d'un ensemble de graphes, d'un ensemble de graphes impliquant un graphe, et ainsi de suite, devrait être comprise dans chaque cas comme désignant la fusion de l'ensemble des graphes, et les références à un « graphe » dans la suite peut s'interpréter comme désignant des graphes ou des ensembles de graphes.

Lemme d'instance. Un graphe est impliqué par toutes ses instances.

Démonstration. Supposons que I satisfasse E', et que E' soit une instance de E. Alors pour une application A sur les noeuds anonymes de E', I+A satisfait chaque triplet dans E'. Pour chaque noeud anonyme b dans E, définissons B(b) = I+A(c), où c est le noeud anonyme ou le nom qui remplace b dans E', ou c = b si rien ne l'a remplacé. Alors I+B(E) = I+A(E') = true, donc I satisfait E. Mais I était arbitraire ; donc E' implique E - c.q.f.d.

La skolémisation est une transformation syntaxique utilisée de manière routinière dans les systèmes d'inférence automatiques, dans lesquels les variables existentielles sont remplacées par des fonctions « nouvelles » - des noms de fonction non utilisés ailleurs - appliquées aux variables universelles englobantes. En RDF, la skolémisation équivaut à remplacer chaque noeud anonyme par un « nouveau » nom, c'est-à-dire une référence URI qui est garantie ne pas apparaître ailleurs. En effet, la skolémisation donne des noms « arbitraires » aux entités anonymes dont l'existence était affirmée par l'utilisation de noeuds anonymes : le caractère arbitraire des noms assure que rien ne peut être inféré qui ne découlerait pas de la simple assertion d'existence représentée par le noeud anonyme. (L'utilisation d'un littéral ne le ferait pas ; les littéraux ne sont jamais « nouveaux » dans le sens requis).

Pour être précis, une skolémisation de E (par rapport à V) est une instance fondamentale de E par rapport à V avec une application d'instance injective (1:1 instance mapping) qui relie chaque noeud anonyme dans G à une référence URI qui n'apparaît pas dans G (le vocabulaire de Skolem (Skolem vocabulary) doit donc être disjoint du vocabulaire de E).

Bien qu'elle ne soit pas en soi une opération valide, la skolémisation n'ajoute pas de contenu nouveau à une expression, dans le sens où une expression skolémisée a les mêmes implications que l'expression originale fournie, sous réserve que celles-ci ne contiennent pas de noms du vocabulaire de skolémisation :

Lemme de skolémisation. Supposons sk(E) une skolémisation de E par rapport à V. Alors sk(E) implique E ; et si sk(E) implique F et que le vocabulaire de F est disjoint de V, alors E implique F.

Démonstration. sk(E) implique E par le lemme d'instance.

Supposons maintenant que sk(E) implique F, où F ne partage aucun vocabulaire avec V ; et supposons I une interprétation satisfaisant E. Alors pour une application A depuis les noeuds anonymes de E, I+A satisfait E. Définissons une interprétation I' du vocabulaire de sk(E) telle que : IR' = IR, IEXT' = IEXT, I'(x) = I(x) pour x dans le vocabulaire de E, et I'(x) = [I+A](y) pour x dans V, où y est le noeud anonyme dans E qui est remplacé par x dans sk(E). Clairement, I' satisfait sk(E), donc I' satisfait F. Mais I'(F) = [I+A](F), puisque le vocabulaire de F est disjoint de celui de V ; donc I satisfait F. Mais I était arbitraire ; donc E implique F - c.q.f.d.

Intuitivement, ce lemme montre que l'affirmation d'une skolémisation exprime un contenu similaire à l'affirmation du graphe original, a beaucoup d'égards. Quoiqu'il en soit, un graphe ne devrait pas être considéré comme étant équivalent à sa skolémisation, puisque ces noms « arbitraires » auraient le même statut que les autres références URI une fois publiés. Également, la skolémisation ne serait pas une opération appropriée pour application à autre chose que l'antécédent d'une implication. Néanmoins, dans beaucoup de cas pour démontrer des résultats à propos d'une implication, nous devons seulement considérer les graphes fondamentaux : pour E fourni ne contenant aucun vocabulaire de Skolem, S implique E si et seulement si S' implique E.

La démonstration des lemmes suivants emploie une façon de construire une interprétation d'un graphe utilisant les éléments lexicaux dans le graphe même. (C'était l'idée de Herbrand ; ici nous la modifions légèrement pour traiter les littéraux de manière appropriée.) Soit un graphe G non vide, l'interprétation de Herbrand (simple) de G, notée Herb(G), est l'interprétation définie comme suit :

LVHerb(G) = l'ensemble de tous les littéraux ordinaires dans G ;IRHerb(G) = l'ensemble de tous les noms et noeuds anonymes qui apparaissent en position de sujet ou d'objet dans un triplet dans G ;IPHerb(G) = l'ensemble des références URI qui apparaisent en position de propriété d'un triplet dans G ;IEXTHerb(G) = {<s, o>: G contient un triplet s p o . }ISHerb(G) et ILHerb(G) sont toutes deux des applications identiques (identity mappings) sur les parties appropriées du vocabulaire de G.

Clairement Herb(G)+B, où B est l'application identique sur les noeuds anonymes dans G, satisfait chaque triplet dans G, par construction, donc Herb(G) satisfait G.

Les interprétations de Herbrand traitent les références URI et les littéraux typés (et les noeuds anonymes) comme des littéraux ordinaires, c'est-à-dire comme dénotant leurs propres formes syntaxiques. Bien sûr, l'auteur du RDF ne le prévoyait peut-être pas comme ça, mais la construction montre que tout graphe peut être interprété de cette façon. Cela établit donc que tout graphe RDF a une interprétation simple satisfaisante, c'est-à-dire qu'il ne peut pas y avoir d'incohérence simple en RDF.

Remarquez que l'univers de l'interprétation de Herbrand de G contient les noeuds anonymes de G ; ceux-ci « représentent » les entités dont ils affirment en effet l'existence. Puisque les noeuds anonymes doivent s'interpréter pour dénoter eux-mêmes afin de satisfaire le graphe, l'interprétation de Herbrand d'une skolémisation d'un graphe est isomorphique avec l'interprétation de Herbrand du graphe avec l'application de noeud anonyme (blank node mapping) : Herb(sk(G)) = Herb(G)+B (en utilisant une notation familière abusive où l'on traite un noeud anonyme dans une interprétation de Herbrand comme un nom de Skolem).

Lemme d'interpolation. S implique E si et seulement si un sous-graphe de S est une instance de E.

Démonstration. Le « si » découle des lemmes de sous-graphe et d'instance.

Le « seulement si » utilise la construction de Herbrand. Supposons que S implique simplement E. Herb(S) satisfait S, donc Herb(S) satisfait E, c'est-à-dire que pour une application A des noeuds anonymes de E vers IRHerb(S), [Herb(S)+A] satisfait chaque triplet s p o .
dans E, donc S doit contenir le triplet
[Herb(E)+A](s) p [Herb(E)+A](o).
qui est l'instance du triplet précédent sous l'application d'instance A. Donc l'ensemble de tous ces triplets est un sous-graphe de S qui est une instance de E - c.q.f.d.

Les conséquences suivantes découlent directement du lemme d'interpolation :

Lemme d'anonymat. Supposons que E soit un graphe mince et E' une instance propre de E. Alors E n'implique pas E'.

Démonstration. Supposons que E implique E', alors un sous-graphe de E est une instance de E' et donc une instance propre de E ; donc E n'est pas mince, contrairement à l'hypothèse. Donc E n'implique pas E' - c.q.f.d.

Lemme de compacité. Si S implique E, et E est un graphe fini, alors un sous-ensemble S' fini de S implique E.

Démonstration. D'après le lemme d'interpolation, un sous-graphe S' de S est une instance de E ; donc S' est fini et S' implique E - c.q.f.d.

Quoique la compacité soit évidente pour une implication simple, elle le devient progressivement moins dans des extensions sémantiques plus élaborées.

Lemme de monotonicité. Supposons que S soit un sous-graphe de S', et que S implique E. Alors S' implique E. (Cas particulier du  lemme de monotonicité général) - c.q.f.d.

Lemme de monotonicité général. Supposons que S et S' soient des ensembles de graphes RDF, chaque membre de S étant un sous-ensemble d'un membre de S'. Supposons que Y indique une extension sémantique de X, S X-implique E, et S et E satisfont toutes les restrictions de Y. Alors S' Y-implique E.

Démonstration. Celle-ci découle simplement en retraçant les définitions. Supposons que I soit une Y-interprétation de S' ; alors puisque Y est une extension sémantique de X, I est une X-interprétation ; et d'après les lemmes de sous-graphe et de fusion, I satisfait S ; donc I satisfait E - c.q.f.d.

Les deux démonstrations suivantes obéissent à un modèle commun qui généralise celui observé dans la démonstration du lemme d'interpolation, en utilisant une modification de la construction de Herbrand appliquée à une « clôture » (closure) obtenue en appliquant les règles exhaustivement. Les démonstrations opèrent en montrant que l'interprétation résultante est à la fois appropriée au vocabulaire et agit aussi tout comme l'interprétation de Herbrand. L'essentiel de la complexité des démonstrations tient au besoin d'adapter la construction de Herbrand afin de tenir correctement compte des valeurs littérales. Les interprétations de Herbrand ignorent le typage des littéraux et traitent tous les littéraux typés comme des valeurs non littérales ; c'est sans importance pour une implication simple qui traite les littéraux typés comme dénotant simplement des noms ; mais il faudra faire plus attention en ce qui concerne les rdf-interprétations et les rdfs-interprétations.

Les deux démonstrations utilisent une idée de base qui nécessite une notation plutôt malcommode mais facile à comprendre pour l'essentiel. L'interprétation de Herbrand simple traite tous les éléments de vocabulaire comme dénotant eux-mêmes et construit l'interprétation à partir de ces éléments syntaxiques. Les conditions sémantiques sur les rdf-interprétations et les rdfs-interprétations ne le permettent pas dans tous les cas : les littéraux XML notamment sont obligés de dénoter d'autres types d'entité. Nous faisons donc la distinction entre les valeurs sémantiques « réelles » et leurs « substituts » (surrogates) syntaxiques dans ces cas, en définissant une application sur de l'univers de l'interprétation vers le vocabulaire du graphe (plus les noeuds anonymes), laquelle est aussi proche que possible d'une application identique mais qui, lorsqu'elle est est appliquée à ces valeurs littérales spéciales, identifie le noeud anonyme particulier qui sert de témoin pour cette valeur dans le graphe. Dans le cas de RDFS, l'application de substitution (surrogate mapping) est étendue à toutes les valeurs littérales, puisque le noeud anonyme alloué au littéral peut apparaître en position de sujet, et donc enregistrer une information à propos de la valeur littérale qui doit être appliquée en retour à cette valeur dans l'interprétation.

Lemme d'implication RDF. 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. Pour démontrer le « si », on doit seulement vérifier que les règles sont rdf-valides, ce qui est laissé en exercice au lecteur ; et si S ou E sont vides, alors la conclusion est évidente ; supposez donc que les deux ne sont pas vides.

Pour établir le « seulement si », la démonstration avance en construisant une rdf-interprétation de Herbrand (rdf Herbrand interpretation) RH de S qui joue le même rôle pour les rdf-interprétations que l'interprétation de Herbrand simple pour les interprétations simples. La construction suit la construction de Herbrand aussi loin que possible, mais interprète les littéraux XML bien formés de façon à satisfaire aux conditions sémantiques RDF, guidée par les triplets dans la clôture RDF (RDF closure) C, définie comme étant le graphe résultant du processus suivant :

- ajouter à S tous les triplets axiomatiques RDF ;

- appliquer la règle lg à tout triplet contenant un littéral XML bien typé jusqu'à ce que le graphe ne soit plus modifié par la règle ;

- appliquer la règle rdf2 jusqu'à ce que le graphe ne change plus ;

- appliquer la règle rdf1 jusqu'à ce que le graphe ne change plus.

Notez que C contient précisément un seul nouveau noeud anonyme _:nnn alloué à chaque littéral dans S par la règle lg, et que le sous-graphe des triplets dans S contenant un littéral XML bien typé est reproduit exactement dans C avec ce noeud anonyme remplaçant le littéral et avec le triplet supplémentaire
_:nnn rdf:type rdf:XMLLiteral .
introduit par la règle rdf2. Notez aussi que la démonstration impose seulement d'utiliser la règle lg sur les littéraux XML bien typés, de sorte qu'elle établit en réalité un résultat légèrement plus serré.

Les noeuds anonymes introduits par la règle lg représentent des substituts pour les littéraux XML bien formés en position de sujet dans un triplet. (Dans la démonstration du prochain lemme, on l'étendra à tous les littéraux). Pour construire une interprétation RDF, on doit remplacer les littéraux XML et leurs substituts par des valeurs littérales appropriées dans le domaine de l'interprétation, mais la démonstration impose que chaque valeur littérale XML soit associée exclusivement (uniquely) à un élément lexical qui la dénote. Cela exige de la finesse dans la construction suivante.

Si lll est un littéral XML bien formé, soit xml (lll) la valeur XML de lll ; et pour chaque valeur XML x d'un littéral XML bien formé dans C, soit sur(x) le noeud anonyme alloué à ce littéral XML par la règle lg ; et étendons sur pour être l'application identique sur les références URI, les noeuds anonymes et tous les autres littéraux dans C.

On définit alors RH par :

LVRH = tous les littéraux ordinaires dans C plus {xml(x): x un littéral XML bien typé dans S}
IRRH = LVRH plus l'ensemble des références URI, des noeuds anonymes et des autres littéraux typés apparaissant dans C
IPRH = {x: C contient le triplet: x rdf:type rdf:Property .}
Si x est dans IPRH alors IEXTRH(x) = {<s, o>: C contient le triplet sur(s) x sur(o) .}
ISRH est l'application identique sur les références URI dans S
Si x est un littéral XML bien formé dans S, alors ILRH(x) = xml(x), sinon ILRH(x) = x

Définissons une application B sur les noeuds anonymes dans C telle que : B(x) = xml(lll) si x est alloué à un littéral XML bien formé lll, sinon B(x) = x, alors clairement [RH+B] satisfait C et donc S ; donc RH satisfait S.

Puisque C contient tous les triplets axiomatiques RDF obligatoires, RH les satisfait.

On voit aisément que J satisfait les deux premières conditions sémantiques RDF, par construction ; car les triplets introduits par la règle rdf2 imposent que IEXTRH(rdf:type) contient <xml(lll), rdf:XMLLiteral > pour chaque littéral XML bien typé lll.

La troisième condition sémantique RDF est la seule condition sémantique négative qui ne puisse pas être satisfaite simplement par construction, mais elle est facilement satisfaite. Les littéraux XML mal typés dénotent eux-mêmes dans RH et sont donc exclus de LVRH par construction. Le couple <lll, rdf:XMLLiteral> ne peut pas apparaître dans IEXTRH(rdf:type) parce qu'un littéral ne peut pas apparaître en position de sujet ; ainsi la condition est satisfaite, et donc RH est une rdf-interprétation.

Puisque S rdf-implique E, RH satisfait E : donc pour une application A des noeuds anonymes de E vers IRRH, [RH+A] satisfait chaque triplet s p o . dans E, c'est-à-dire IEXTRH(p) contient <[RH+A](s), [RH+A](o)>, c'est-à-dire que C contient un triplet sur([RH+A](s)) p sur([RH+A](o)) . mais c'est une instance du premier triplet sous l'application d'instanciation x ? sur(A(x)) ; donc un sous-graphe de C est une instance de E ; donc C implique simplement E - c.q.f.d.

Ce lemme montre également que tout graphe a une rdf-interprétation satisfaisante, et la démonstration illustre comment la construire à partir d'une interprétation de Herbrand de la clôture, en interprétant de manière appropriée les littéraux XML bien formés et en autorisant l'existence possible de propriétés qui n'ont pas d'extension. Notez que si E est fini, alors le sous-graphe dérivé de C l'est également.

La démonstration du lemme d'implication RDFS est similaire en structure et utilise des définitions très proches, mais elle est évidemment plus longue et nécessite une construction plus élaborée pour s'assurer que les extensions de classe de rdfs:Literal et rdfs:Resource contiennent toutes les valeurs littérales.

Lemme d'implication RDFS. 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 est un conflit XML.

Démonstration. À nouveau, pour démontrer le « si », il suffit de démontrer que les règles d'implication RDFS sont rdfs-valides, ce qui est laissé en exercice ; et encore une fois les cas vides sont évidents.

La démonstration du « seulement si » est similaire à celle utilisée dans le lemme précédent, et nous utiliserons des constructions et une terminologie similaires, hormis la clôture RDFS D qui est définie comme étant le graphe résultant du processus suivant :

ajouter à S tous les triplets axiomatiques RDF et RDFS ; appliquer la règle lg à tout triplet contenant un littéral jusqu'à ce le graphe ne soit plus modifié par la règle ; appliquer les règles rdf2 et rdfs1 jusqu'à ce que le graphe ne change plus ; appliquer les règles rdf1, gl et les règles d'implication RDFS restantes jusqu'à ce que le graphe ne change plus.

À la différence du lemme précédent, cette démonstration impose que la règle lg s'applique à tous les littéraux, même les littéraux XML mal typés, et elle impose d'utiliser la règle gl symétrique. La règle gl ne doit être employée qu'après une application des règles rdfs6 ou rdfs10, puisque ce sont les seules à pouvoir déplacer un noeud anonyme d'une position de sujet à une position d'objet. Notez que D contient précisément un nouveau noeud anonyme _:nnn alloué à chaque littéral dans S par la règle lg, et que le sous-graphe des triplets dans S contenant un littéral est reproduit exactement dans D avec ce noeud anonyme remplaçant le littéral et avec le triplet supplémentaire _:nnn rdf:type rdfs:Literal . introduit par la règle rdfs1, et éventuellement aussi _:nnn rdf:type rdf:XMLLiteral . introduit par la règle rdf2, au besoin. Cela signifie que, à compter de ce point dans la construction, les littéraux peuvent effectivement être ignorés, puisque toutes les règles suivantes applicables aux triplets contenant un littéral s'appliqueront tout aussi bien aux triplets similaires où le littéral est remplacé par son noeud anonyme alloué. Le reste de la démonstration utilise ce fait en imposant aux valeurs littérales dans l'interprétation de satisfaire uniquement les conditions sémantiques imposées sur les noeuds anonymes alloués au littéral correspondant et en ignorant les triplets dans le graphe qui contiennent des littéraux. L'utilisation de la règle gl assure que D contient tout triplet ayant un littéral si et seulement si D contient le triplet similaire avec le littéral remplacé par son noeud anonyme alloué.

Comme dans la démonstration précédente, si lll est un littéral XML bien formé, soit xml(lll) la valeur XML de lll ; l'application de substitution sur est alors étendue comme suit. D'abord, le domaine de sur est l'ensemble contenant seulement les références URI, les littéraux et les noeuds anonymes apparaissant dans D et toutes les valeurs XML des littéraux XML bien formés dans D. (C'est l'univers de la rdfs-interprétation de Herbrand, définie ci-dessous.) Si maintenant lll est un littéral XML bien formé dans D, soit sur (xml(lll)) le noeud anonyme alloué à lll par la règle lg ; pour tout autre littéral lll dans D, soit sur (lll) le noeud anonyme alloué à lll par la règle lg, et pour toutes les références URI et tous les noeuds anonymes dans D, soit sur (x) = x. Notez que l'image de sur ne contient que les références URI et les noeuds anonymes qui apparaissent dans D.

On construit alors la rdfs-interprétation de Herbrand (rdfs-Herbrand interpretation) SH de S de la même façon que pour le lemme précédent.

LVSH = {x: D contient le triplet: sur(x) rdf:type rdfs:Literal .}
IRSH = LVSH plus l'ensemble des références URI, des noeuds anonymes et des littéraux autres que les littéraux XML bien formés apparaissant dans D
IPSH = {x: D contient le triplet: sur(x) rdf:type rdf:Property .}
Si x est dans IPRH, alors IEXTRH(x) = {<s, o>: D contient le triplet sur(s) x sur(o) .}
ISSH est l'application identique sur les références URI dans S
Si x est un littéral XML bien formé dans S, alors ILSH(x) = xml(x), sinon ILSH(x) = x

Définissons B(x) comme suit : si x est un noeud anonyme alloué à un littéral XML bien formé lll dans D, alors B(x) = xml(lll) ; s'il est alloué à tout autre littéral lll dans D, alors B(x) = lll ; sinon B(x) = x ; alors clairement [SH+B] satisfait D donc S, et donc SH satisfait S.

Comme dans le lemme précédent, SH satisfait à tous les triplets axiomatiques RDF et RDFS, et aux deux conditions sémantiques RDF par construction.

SH satisfait la troisième condition sémantique RDF juste pour le cas où D ne contient pas de conflit XML. Notez que la présence de substituts de littéraux XML mal typés invalide l'argument utilisé dans le lemme précédent stipulant que cette condition est aisément satisfaite. Donc supposez que D ne contient pas de conflit XML.

Comme noté dans le texte, nous pouvons considérer la première condition sémantique comme définissant ICEXT et IC : nous le ferons sans autre commentaire et décrirons toutes les conditions en fonction de IEXT. Pour démontrer que SH satisfait aux conditions sémantiques RDFS restantes, nous discutons au cas par cas, en utilisant la minimalité (minimality) de l'interprétation de Herbrand et la complétude (completeness) de la clôture.

Toutes ces conditions peuvent être représentées par une séquence correspondante d'applications de règles. On peut illustrer la forme générale de l'argument avec le cas de la deuxième condition sémantique RDFS. Supposons <x, y> dans IEXTSH(rdfs:domain) et <u, v> dans IEXTSH(x) ; alors D doit contenir les triplets :

sur(x) rdfs:domain sur(y) .sur(u) x sur(v).

donc x doit être une référence URI, donc sur(x) = x ; et selon la règle rdfs2, D doit aussi contenir le triplet :

sur(u) rdf:type sur(y).

donc IEXTSH(rdf:type) contient <u, v> ; donc la condition est satisfaite.

Les autres cas se traitent de manière similaire, en traduisant la condition sémantique en une dérivation en utilisant les règles et les triplets axiomatiques. Les formes d'argument sont résumées dans le tableau suivant. Certaines conditions sémantiques se divisent en plusieurs sous-conditions, et certaines recèlent aussi des sous cas particuliers.

Condition sémantique RDFS

Dérivation

Si x dans IR, alors
<x, rdfs:Resource> dans IEXT(rdf:type)

Référence URI ou noeud anonyme en sujet :
x a b
x rdf:type rdfs:Resource

rdfs4a

Littéral :
_:x rdf:type rdfs:Literal
rdfs:type rdfs:range rdfs:Class
rdfs:Literal rdf:type rdfs:Class
rdfs:Literal rdfs:subClassOf rdfs:Resource
_:x rdf:type rdfs:Resource

cf. ci-dessous
axiomatiquerdfs3
rdfs8
rdfs9

Référence URI ou noeud anonyme en objet :
a b x
x rdf:type rdfs:Resource

rdfs4b

Référence URI en prédicat :
a x b
x rdf:type rdf:Property
rdf:type rdfs:domain rdfs:Resource
x rdf:type rdfs:Resource

rdf1
axiomatique
rdfs2

x dans LV si et seulement si
<x, rdfs:Literal> dans IEXT(rdf:type)

Littéral XML bien typé lll :
a b lll
_:x rdf:type rdf:XMLLiteral
rdf:XMLLiteral rdfs:subClassOf rdfs:Literal
_:x rdf:type rdfs:Literal

lg, rdf2, sur(xml(lll)) = _:x
axiomatique
rdfs9

Autre littéral lll :
a b lll
_:x rdf:type rdfs:Literal

lg, rdfs1, sur(lll) = _:x

Si
<x, y> dans IEXT(rdfs:domain) et <u, v> dans IEXT(x)
alors
<u, y> dans IEXT(rdf:type)

x rdfs:domain y .
u x v .
u rdf:type y .

rdfs2

Si
<x, y> dans IEXT(rdfs:range) et <u, v> dans IEXT(x)
alors
<v, y> dans IEXT(rdf:type)

x rdfs:range y .
u x v .
v rdf:type y .

rdfs3

Si
<x, rdf:Property> dans IEXT(rdf:type)
alors
<x, x> dans IEXT(rdfs:subPropertyOf)

x rdf:type rdf:Property
x rdfs:subPropertyOf x

rdfs6

Si
<x, rdf:Property> dans IEXT(rdf:type)
<y, rdf:Property> dans IEXT(rdf:type)
<z, rdf:Property> dans IEXT(rdf:type)
<x, y> dans IEXT(rdfs:subPropertyOf)
<y, z> dans IEXT(rdfs:subPropertyOf)
alors
<x, z> dans IEXT(rdfs:subPropertyOf)

x rdfs:subPropertyOf y
y rdfs:subPropertyOf z
x subPropertyOf z

rdfs5

Si
<x, y> dans IEXT(rdfs:subPropertyOf)
<u, v> dans IEXT(x)
alors
<x, rdf:Property> dans IEXT(rdf:type)
<y, rdf:Property> dans IEXT(rdf:type)
<u, v> dans IEXT(y)

x rdfs:subPropertyOf y
u x v
rdfs:subPropertyOf rdfs:domain rdf:Property
x type rdf:Property
rdfs:subPropertyOf rdfs:domain rdf:Property
y rdf:type rdf:Property
u y v

triplet axiomatique
rdfs2
triplet axiomatique
rdfs3
rdfs7

Si
<x, rdfs:Class> dans IEXT(rdf:type)
alors
<x, rdfs:Resource> dans IEXT(rdfs:subClassOf)

x rdf:type rdfs:Class
x rdfs:subClassOf rdfs:Resource

rdfs8

Si
<x, y> dans IEXT(rdfs:subClassOf)
<u, x> dans IEXT(rdf:type)
alors
<x, rdfs:Class> dans IEXT(rdf:type)
<y, rdfs:Class> dans IEXT(rdf:type)
<u, y> dans IEXT(rdf:type)

x rdfs:subClassOf y
u rdf:type x
rdfs:subClassOf rdfs:domain rdfs:Class
x rdf:type rdfs:Class
rdfs:subClassOf rdfs:range rdfs:Class
y rdf:type rdfs:Class
u rdf:type y

triplet axiomatique
rdfs2
triplet axiomatique
rdfs3
rdfs9

Si
<x, rdfs:Class> dans IEXT(rdf:type)
alors
<x, x> dans IEXT(rdfs:subClassOf)

x rdf:type rdfs:Class
x rdfs:subClassOf x

rdfs10

Si
<x, rdfs:Class> dans IEXT(rdf:type)
<y, rdfs:Class> dans IEXT(rdf:type)
<z, rdfs:Class> dans IEXT(rdf:type)
<x, y> dans IEXT(rdfs:subClassOf)
<y, z> dans IEXT(rdfs:subClassOf)
alors
<x, z> dans IEXT(rdfs:subClassOf)

x rdfs:subClassOf y
y rdfs:subClassOf z
x rdfs:subClassOf z

rdfs11

Si
<x, rdfs:ContainerMembershipProperty> dans IEXT(rdf:type)
alors
<x, rdfs:member> dans IEXT(rdfs:subPropertyOf)

x rdf:type rdfs:ContainerMembershipProperty
x rdfs:subPropertyOf rdfs:member

rdfs12

Si
<x, rdfs:Datatype> dans IEXT(rdf:type)
alors
<x, rdfs:Literal> dans IEXT(rdfs:subClassOf)

x rdf:type rdfs:Datatype
x rdfs:subClassOf rdfs:Literal

rdfs13

donc SH est une rdfs-interprétation.

Puisque S rdfs-implique E, SH satisfait E : donc pour une application A des noeuds anonymes de E vers IRSH, [SH+A] satisfait chaque triplet :

s p o .

dans E, c'est-à-dire IEXTSH(p) contient <[SH+A](s), [SH+A](o)>, c'est-à-dire que D contient un triplet :

sur([SH+A](s)) p sur([SH+A](o)) .

qui est une instance du premier triplet sous l'application d'instanciation x ? sur(A(x)), sauf si o est un littéral. Si o est un littéral, alors sur([SH+A](o) est le noeud anonyme alloué à o, et donc D contient également le triplet :

sur([SH+A](s)) p o .

qui est une instance du premier triplet sous l'application d'instanciation x ? sur(A(x)). Donc un sous-graphe de D est une instance de E sous l'application d'instanciation x ? sur(A(x)) ; donc D implique simplement E.

Ainsi soit D contient un conflit XML, soit D implique simplement E, donc D satisfait aux conditions du lemme - c.q.f.d.

Notez que si E est fini, ou si D contient un conflit XML, alors un sous-graphe fini de D satisfait également aux conditions du lemme.

XII - Annexe B. Glossaire (informatif)

Antécédent (antecedent) n.

Dans une inférence, l'expression ou les expressions à partir desquelles la conclusion est dérivée. Dans une relation d'implication, l'impliquant (entailer). Également une supposition (assumption).

Assertion (assertion) (n.)

(i) Toute expression proclamée être vraie.

(ii) L'acte de proclamer quelque chose comme étant vraie.

Atome (token) n.

Une inscription physique particulière d'un symbole ou d'une expression dans un document. Habituellement mis en contraste avec type, la forme grammaticale abstraite d'une expression.

Bien formé (well-formed) adj., d'une expression

Syntaxiquement légal.

Classe (class) n.

Un concept, une catégorie ou une classification générale. Quelque chose servant principalement à classer ou catégoriser d'autres choses. Formellement, en RDF, une ressource de type rdfs:Class à laquelle est associé un ensemble de ressources dont toutes ont la classe pour valeur de la propriété rdf:type. Les classes sont souvent appelées des « prédicats » dans la littérature de la logique formelle.

(RDF distingue une classe d'un ensemble, quoique les deux soient souvent identifiés. Distinguer les classes des ensembles laisse à RDF plus de liberté pour construire des hiérarchies de classes, comme expliqué précédemment).

Complet (complete) adj., d'un système d'inférence

(1) Capacité à détecter toutes les implications entre deux expressions.

(2) Capacité à tirer toutes les inférences valides. Cf. inférence. Également utilisé avec un qualificatif (qualifier) : capacité à détecter des implications ou de tirer toutes les inférences valides dans une certaine forme limitée ou espèce (par exemple, entre des expressions dans une certaine forme normale, ou vérifiant certaines conditions syntaxiques).

(Ces définitions ne sont pas exactement équivalentes, puisque la première nécessite que le système ait accès au conséquent de l'implication, et peuvent être incapables de tirer des inférences « évidentes » telles que (p et p) de p. Typiquement, des systèmes d'inférence mécaniques peuvent être efficaces dans le premier sens mais pas forcément dans le deuxième).

Conséquent (consequent) n.

Dans une inférence, l'expression construite à partir de l'antécédent. Dans une relation d'implication, l'impliqué (entailee). Également une conclusion.

Cohérent (consistent) adj., d'une expression

Avoir une interprétation satisfaisante ; non intrinsèquement (internally) contradictoire. (Également employé pour un système d'inférence comme synonyme de correct).

Correct (correct) adj., d'un système d'inférence

Dans l'incapacité de tirer des inférences invalides, ou dans l'incapacité de faire des proclamations d'implication fausses. Cf. inférence.

Décidable (decideable) adj., d'un système d'inférence

Capacité à déterminer, pour un couple d'expressions, dans un temps fini avec des ressources finies, si la première implique ou non la deuxième. (Également, adj., d'une logique) Avoir un système d'inférence décidable qui est complet et correct pour la sémantique de la logique.

(Les logiques n'ont pas toutes des systèmes d'inférence qui sont à la fois complets et décidables, et des systèmes d'inférence décidables peuvent avoir une complexité de calcul arbitrairement élevée. Les relations entre la syntaxe logique, la sémantique et la complexité d'un système d'inférence continuent d'être le sujet de recherches considérables).

Équivalent (equivalent) prep., avec à

Vrai sous les mêmes conditions exactement ; en faisant des proclamations identiques à propos du monde, lorsqu'affirmé. Implique et est impliqué par.

Extensionnel (extensional) adj., d'une logique

Une théorie d'ensembles ou une logique de classes, dans laquelle les classes sont considérées comme étant des ensembles, les propriétés comme étant des ensembles de couples <objet, valeur>, et ainsi de suite. Une théorie qui n'admet aucune distinction entre des entités avec la même extension. Cf. intensionnel.

Formel (formal) adj.

Écrit dans un langage suffisamment précis pour permettre d'établir des conclusions en utilisant des techniques mathématiques conventionnelles.

Impliquer (to entail) v., implication(entailment) n.

Une relation sémantique entre des expressions qui tient à chaque fois que la vérité de la première garantit celle de la deuxième. De manière équivalente, à chaque fois qu'il est logiquement impossible à la première d'être vraie et à la deuxième d'être fausse. De manière équivalente, lorsqu'une interprétation qui satisfait la première satisfait également la deuxième. (Également utilisé entre un ensemble d'expressions et une expression).

Incohérent (inconsistent) adj.

Faux sous toutes les interprétations ; impossible à satisfaire. Incohérence (inconsitency) n. : une expression ou un graphe incohérents.

(Implication et incohérence sont étroitement liées, dans la mesure où A implique B juste lorsque l'expression (A et non-B) est incohérente, cf. la deuxième définition de l'implication. C'est la base de beaucoup de systèmes d'inférence mécaniques.

Bien que les définitions de la cohérence et de l'incohérence soient des doubles exacts, elles sont dissemblables pour le calcul. Il est souvent plus difficile de détecter la cohérence dans tous les cas que l'incohérence dans tous les cas).

Indexical (indexical) adj., d'une expression

Avoir une signification qui se réfère implicitement au contexte d'utilisation. Des exemples en français comprennent des mots tels que « ici », « maintenant », « ceci ».

Inférence (inference) n.

Un acte ou un processus consistant à construire de nouvelles expressions à partir d'expressions existantes, ou le résultat d'un tel acte ou d'un tel processus. Les inférences correspondant à des implications sont décrites comme étant correctes ou valides. Règle d'inférence (inference rule) : une description formelle d'un type d'inférence ; système d'inférence (inference system) : un système organisé de règles d'inférence ; également un logiciel qui génère des inférences ou vérifie la validité des inférences.

Intensionnel (intensional) adj., d'une logique

Non extensionnel. Une logique qui admet des entités distinctes avec la même extension.

(Les mérites et les démérites de l'intentionnalité ont été largement débattus dans la littérature de la logique philosophique. Les théories de la sémantique extensionnelle sont plus simples, et la sémantique conventionnelle de la logique formelle suppose habituellement une vision extensionnelle, mais l'analyse conceptuelle du langage ordinaire suggère souvent que la pensée intensionnelle est plus naturelle. Les exemples souvent cités sont qu'une logique extensionnelle est obligée de traiter toutes les extensions « vides » comme étant identiques, elle doit donc identifier « carré rond » à « père Noël » (N.d.T. santa clause), et elle est incapable de distinguer des concepts qui ont « accidentellement » les mêmes instances, tels que des êtres humains et des hominidés bipèdes glabres. La sémantique décrite dans ce document est essentiellement intensionnelle).

Interprétation de (interpretation of) n.

Une description formelle minimale des aspects d'un monde juste suffisante pour établir la véracité ou la fausseté d'une expression d'une logique.

(Certains textes de logique font une distinction entre une structure d'interprétation (interpretation structure), qui est un « monde possible » considéré comme quelque chose d'indépendant d'un vocabulaire particulier, et une application d'interprétation (interpretation mapping) d'un vocabulaire vers une structure. La sémantique RDF emprunte la voie plus simple de les fondre en un seul concept).

Logique (logic) n.

Un langage formel qui exprime des propositions.

Métaphysique (metaphysical) adj.

Qui a trait à la nature véritable des choses dans un sens absolu ou fondamental.

Monde (world) n.

(avec l'article le) (i) Le monde réel.

(avec l'article un) (ii) Une manière d'arranger le monde réel.

(iii) Une interprétation

(iv) Un monde possible.

(Le statut métaphysique des « monde possibles » est très controversé. Heureusement, il n'est pas nécessaire de croire en l'existence d'univers parallèles pour utiliser le concept dans ses deuxième et troisième sens, qui suffisent pour les besoins de la sémantique).

Monotone (monotonic) adj., d'une logique ou d'un système d'inférence

Satisfaisant la condition telle que si S implique E alors (S + T) implique E, c'est-à-dire qu'ajouter de l'information aux antécédents ne peut invalider une implication valide.

(Toutes les logiques fondées sur une théorie des modèles conventionnelles et une notion standard de l'implication sont monotones. Une logique monotone a pour propriété que les implications restent valides hors du contexte dans lequel elles ont été générées. C'est la raison pour laquelle RDF est conçu pour être monotone).

Non monotone (nonmonotonic) adj., d'une logique ou d'un système d'inférence

Non monotone. Les formalismes non monotones ont été proposés et utilisés en intelligence artificielle et dans diverses applications. Des exemples d'inférences non monotones comprennent le raisonnement par défaut (default reasoning), où l'on suppose une vérité générale « normale » sauf à être contredite par une information particulière (normalement les oiseaux volent, mais pas les pingouins) ; la négation par l'échec (negation-as-failure), communément supposée dans les systèmes de programmation logique, où l'on conclut de l'échec à démontrer une proposition que celle-ci est fausse ; et les suppositions de monde fermé implicite (implicit closed-world assumptions), souvent posées dans les applications de base de données, où l'on conclut de l'absence d'information à propos d'une entité dans un corpus que l'information est fausse (par exemple que si une personne n'est pas répertoriée dans une base de données des employés, c'est qu'elle n'est pas un employé).

(Le rapport entre les inférences monotones et non monotones est souvent subtil. Par exemple, si on rend explicite une supposition de monde fermé, par exemple, en affirmant explicitement que le corpus est complet et en fournissant une information de provenance explicite dans la conclusion, alors le raisonnement de monde fermé est monotone ; c'est le caractère implicite qui rend le raisonnement non monotone. On peut dire de conclusions non monotones qu'elles sont valides seulement dans un certain type de « contexte », et susceptibles d'être incorrectes ou trompeuses hors de ce contexte. Rendre le contexte explicite dans le raisonnement et visible dans la conclusion est une façon de les associer à un environnement monotone).

Ontologique (ontological) adj., philosophique

Qui a trait aux types de choses qui existent réellement. (Appliqué) Qui a trait aux détails d'une description formelle d'un thème ou d'un domaine.

Proposition (proposition) n.

Quelque chose qui a une valeur de vérité (truth-value) ; une déclaration ou une expression qui est vraie ou fausse.

(Les analyses philosophiques du langage distinguent traditionnellement les propositions des expressions qui servent à les énoncer, mais la théorie des modèles n'oblige pas cette distinction).

Réifier (reify) v. , réification(reification) n.

Catégoriser comme objet ; décrire comme entité. Souvent utilisé pour décrire une convention par laquelle une expression syntaxique est traitée comme un objet sémantique et décrite elle-même à l'aide d'une autre syntaxe. En RDF, un triplet réifié est une description d'un atome de triplet (triple-token) utilisant d'autres triplets RDF.

Ressource (resource) n. (selon RDF)

(i) Une entité ; toute chose dans l'univers.

(ii) En tant que nom de classe (Resource) : la classe de toute chose ; la catégorie la plus inclusive possible.

Satisfaire (satisfy) v.t., satisfaction(satisfaction) n. , satisfaisant (satisfying) adj., d'une interprétation

Vérifier. La relation sémantique de base entre une interprétation et une expression. X satisfait Y signifie que si le monde est conforme aux conditions décrites par X, alors Y doit être vrai.

Sémantique (semantic) adj. , sémantique(semantics) n.

Qui a trait à la spécification de la signification. Souvent mis en constraste avec syntaxique pour souligner la distinction entre les expressions et ce ce qu'elles dénotent.

Skolémisation(Skolemization) n.

Une transformation syntaxique dans laquelle les noeuds anonymes sont remplacés par des « nouveaux » noms.

(Quoique non strictement valide, la skolémisation conserve la signification essentielle d'une expression et est souvent utilisée dans les systèmes d'inférence mécaniques. La forme logique complète est plus complexe. Elle est nommée d'après le logicien A. T. Skolem)

Ssi conj. (iff)

Abréviation conventionnelle pour « si et seulement si » (if and only if). Utilisé pour exprimer des conditions nécessaires et suffisantes.

Théorie des modèles (model theory) n.

Une théorie sémantique formelle qui relie les expressions aux interprétations.

(Le nom « théorie des modèles » provient de l'usage, traditionnel en sémantique logique, selon lequel une interprétation satisfaisante est appelée un « modèle ». Toutefois, on trouve souvent cet emploi vague car c'est presque exactement le contraire de la signification impliquée par des expressions telles que « modélisation de calcul » (computational modelling), on l'a donc évité dans ce document).

Univers (universe) n., également univers du discours

Le classement universel ou l'ensemble de toutes les choses qu'une interprétation considère exister. En RDF/S, il est identique à l'ensemble des ressources.

Utiliser (use) v.

Mis en constraste avec mentionner ; utiliser un bout de syntaxe pour dénoter ou désigner autre chose. La façon normale d'utiliser la langue.

(« Dans une phrase, à chaque fois que nous voulons dire quelques chose à propos d'une certaine chose, nous devons y employer non la chose elle-même mais son nom ou sa dénomination » - Alfred Tarski)

Valide (valid) adj., d'une inférence ou d'un processus d'inférence

Correspondant à une implication, c'est-à-dire que la conclusion de l'inférence est impliquée par l'antécédent de l'inférence. Également correct.

XIII - Annexe C. Remerciements

Ce document reflète l'effort conjoint des membres du groupe de travail RDF Core. Des contributions notables ont été apportées par Jeremy Carroll, Dan Connolly, Jan Grant, R. V. Guha, Graham Klyne, Ora Lassilla, Brian McBride, Sergey Melnick, Jos deRoo et Patrick Stickler.

L'idée fondamentale d'utiliser une application d'extension explicite pour permettre l'auto-application sans enfreindre l'axiome de fondation a été suggérée par Christopher Menzel.

Peter Patel-Schneider et Herman ter Horst ont découvert plusieurs problèmes majeurs dans les versions précédentes et suggéré plusieurs améliorations techniques importantes.

Les travaux de Patrick Hayes sur ce document ont été soutenus en partie par l'agence DARPA sous le contrat #2507-225-22.

XIII-A - Références

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

[RDF-CONCEPTS]
Cadre de description de ressource (RDF) - Concepts et syntaxe abstraite, Graham Klyne et Jeremy J. Carroll, rédacteurs, recommandation du W3C, 10 février 2004, http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/. Dernière version disponible à http://www.w3.org/TR/rdf-concepts/.

[RDF-SYNTAX]
Spécification de la syntaxe RDF/XML (révisée), Dave Beckett, rédacteur, recommandation du W3C, 10 février 2004, http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/. Dernière version disponible à http://www.w3.org/TR/rdf-syntax-grammar/.

[RDF-TESTS]
Jeux d'essais RDF, Jan Grant et Dave Beckett, rédacteurs, recommandation du W3C, 10 février 2004, http://www.w3.org/TR/2004/REC-rdf-testcases-20040210/ Dernière version disponible à http://www.w3.org/TR/rdf-testcases/.

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

[RFC 2119]
RFC 2119 - Mots-clés à utiliser dans les RFC pour indiquer les niveaux d'exigence, S. Bradner, IETF. Mars 1997. Ce document est à http://www.ietf.org/rfc/rfc2119.txt.

[RFC 2396]
RFC 2396 - Identificateurs de ressource uniformes (URI) - Syntaxe générique, Berners-Lee, T., Fielding et Masinter, L., août 1998

[XSD]
XML Schema tome 2 - Types de données, Biron, P. V., Malhotra, A. (rédacteurs), recommandation du W3C, 2 mai 2001.

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

[OWL]
Référence du langage d'ontologie web OWL, Mike Dean et Guus Schreiber, rédacteurs, recommandation du W3C, 10 février 2004, http://www.w3.org/TR/2004/REC-owl-ref-20040210/. Dernière version disponible à http://www.w3.org/TR/owl-ref/.

[Conen&Klapsing]
A Logical Interpretation of RDF, Conen, W., Klapsing, R. Transmis au groupe d'intérêt RDF, août 2000.

[DAML]
Reference Description of the DAML+OIL (March 2001) ontology markup language, Frank van Harmelen, Peter F. Patel-Schneider, Ian Horrocks (rédacteurs).

[Hayes&Menzel]
A Semantics for the Knowledge Interchange Format, Hayes, P., Menzel, C., compte-rendu de l'atelier Workshop on the IEEE Standard Upper Ontology, août 2001.

[KIF]
Knowledge Interchange Format, Michael R. Genesereth et. al., 1998 (draft American National Standard).

[Marchiori&Saarela]
Query + Metadata + Logic = Metalog, Marchiori, M., Saarela, J. 1998.

[LBASE]
Lbase: Semantics for Languages of the Semantic Web, Guha, R. V., Hayes, P., note du W3C, 10 octobre 2003.

[McGuinness&al]
DAML+OIL:An Ontology Language for the Semantic Web, McGuinness, D. L., Fikes, R., Hendler J. et Stein, L.A., IEEE Intelligent Systems, Vol. 17, No. 5, septembre/octobre 2002.

[RDF-PRIMER]
Introduction à RDF, Frank Manola et Eric Miller, rédacteurs, recommandation du W3C, 10 février 2004, http://www.w3.org/TR/2004/REC-rdf-primer-20040210/. Dernière version disponible à http://www.w3.org/TR/rdf-primer/.

[RDF-VOCABULARY]
Langage de description de vocabulaire RDF 1.0 : RDF Schema, Dan Brickley et R. V. Guha, rédacteurs, recommandation du W3C, 10 février 2004, http://www.w3.org/TR/2004/REC-rdf-schema-20040210/. Dernière version disponible à http://www.w3.org/TR/rdf-schema/.

XIV - Annexe D. Journal des changements (informatif)

Changements depuis la recommandation proposée du 15 décembre 2003.

Une erreur dans la formulation du lemme d'implication RDFS en annexe A a été corrigé. Quelques coquilles dans le glossaire et le texte principal ont été corrigées.

Après examen des commentaires de ter Horst, la définition de la D-interprétation a été modifiée pour s'appliquer à un vocabulaire étendu comprenant les noms des types de données.

Les entrées anciennes dans le journal des changements ont été supprimées. On peut les trouver dans la version précédente.

XV - Remerciements

Merci à Julien Plu pour la mise en page.