Résumé
Voici la 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).
Table des matières
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émantique formelle
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 œuvres 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 œuvre surtout par la notion d'implication
(entailment), décrite plus loin, qui rend possible la définition de
règles d'inférence valides.
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 1.3, 1.4 et 1.5,
et à celles des interprétations RDF décrites à la section 3.1 de ce document. Tout nom d'implication
dans une extension sémantique DEVRAIT être indiqué par l'emploi d'un terme
d'implication de vocabulaire (vocabulary entailment).
Les conditions sémantiques imposées sur une extension sémantique RDF DOIVENT
définir une notion d'implication de vocabulaire qui soit valide
pour la sémantique modéliste décrite dans les parties normatives de ce document ; à l'exception suivante que, si l'extension sémantique est définie
sur un sous-ensemble syntaxiquement restreint des graphes RDF, alors les
conditions sémantiques ne doivent s'appliquer qu'à ce sous-ensemble. Les spécifications de telles extensions sémantiques restreintes
syntaxiquement DOIVENT inclure des conditions syntaxiques suffisantes
pour permettre à un logiciel de distinguer sans ambiguïté les graphes RDF
sur lesquels les conditions sémantiques étendues s'appliquent. Les applications fondées sur de telles extensions sémantiques restreintes syntaxiquement
PEUVENT traiter les graphes RDF
qui ne sont pas conformes aux restrictions syntaxiques imposées comme étant des erreurs de syntaxe.
RDF Schema [RDF-VOCABULARY], abrégé en RDFS,
dont la sémantique est définie dans la suite de ce document, est un exemple d'extension sémantique de RDF.
RDF Schema n'impose pas de restrictions syntaxiques supplémentaires.
Toute théorie sémantique s'appuie sur une syntaxe. Cette sémantique est définie comme une application (mapping)
sur la syntaxe abstraite de RDF
décrite dans le document des concepts et de la syntaxe abstraite RDF [RDF-CONCEPTS].
Ce document utilise la terminologie suivante qui y est définie :
référence URI (URI reference),
littéral (literal),
littéral ordinaire (plain literal),
littéral typé (typed literal),
littéral XML (XML literal),
valeur XML (XML value),
nœud (node),
nœud anonyme (blank node),
triplet (triple)
et graphe RDF (RDF graph).
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 nœud (nodeID) pour indiquer les nœuds anonymes dans les triplets
d'un graphe. Bien que les identificateurs de nœud tels que « _:xxx » servent à identifier
des nœuds anonymes dans la syntaxe de surface, ces expressions ne sont pas considérées comme étant le label (label)
du nœud 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 nœuds 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 nœud 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élimitants 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 nœud anonyme, une chaîne de caractères, et ainsi de suite.
La signification exacte sera indiquée par le contexte.
Un graphe RDF,
ou simplement un graphe, est un ensemble de triplets RDF.
Un sous-graphe (subgraph) d'un graphe RDF
est un sous-ensemble de triplets du graphe. Un triplet est identifié par le singleton (singleton set)
qui le contient, et donc chaque triplet d'un graphe est considéré comme étant un sous-graphe.
Un sous-graphe propre (proper subgraph) est un sous-ensemble propre des triplets dans le graphe.
Un graphe RDF fondamental (ground RDF graph)
est un graphe sans nœuds 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 nœuds anonymes vers un ensemble comprenant des littéraux,
des nœuds 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 nœuds 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 nœuds anonymes de l'original sont des noms de V.
Une instance propre d'un graphe est une instance dans laquelle un nœud anonyme a été
remplacé par un nom, ou deux nœuds anonymes dans le graphe ont été associés (mapped) au même
nœud dans l'instance.
Toute instance d'un graphe dans lequel un nœud anonyme est associé à un nouveau nœud 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 nœuds 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 nœud
(nodeID), tout en étant conforme à la convention selon laquelle les nœuds 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 nœuds anonymes en commun, alors l'union des graphes
est une fusion ; s'ils partagent des nœuds 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 nœuds anonymes. On le décrit souvent en disant que les nœuds 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 nœud, le document fusionné décrira un graphe
dans lequel certains nœuds 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 nœud (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 nœud, cf. la
Spécification de la syntaxe RDF/XML (révisée)
[RDF-SYNTAX].
RDF n'impose pas de restrictions logiques sur les domaines (domains) et les
images (ranges) des propriétés ; en particulier, une propriété peut s'appliquer à elle-même.
Lorsque des classes sont introduites en RDFS, elles-mêmes peuvent se contenir.
De telles « boucles d'appartenance » (membership loops) peuvent sembler enfreindre
l'axiome de fondation (axiom of foundation), l'un des axiomes de la théorie des ensembles normalisée
(Zermelo-Fraenkel), qui interdit de descendre indéfiniment dans les chaînes d'appartenance. En revanche, le modèle sémantique donné ici
distingue les propriétés et classes considérées comme des objets dans leurs extensions
— les ensembles de couples objet-valeur qui satisfont à la propriété ou aux choses qui sont « dans » la classe - en autorisant ainsi
l'extension d'une propriété (ou d'une classe) à contenir la propriété (ou la classe) elle-même sans enfreindre l'axiome de fondation.
En particulier, cette utilisation d'une application d'extension de classe permet aux classes de se contenir elles-mêmes. Ainsi, il est
tout à fait valable pour (l'extension d')une classe « universelle » de contenir la classe elle-même comme membre, une convention
souvent adoptée au sommet d'une hiérarchie de classement (classification hierarchy).
(Si une extension se contenait elle-même, l'axiome serait enfreint, mais ce cas n'arrive jamais.) La technique est décrite plus complètement
dans [Hayes&Menzel].
À cet égard, RDFS diffère de beaucoup de systèmes ontologiques (ontology frameworks)
conventionnels tels qu'UML, qui supposent une hiérarchie plus structurée d'individus, d'ensembles d'invidus, 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âti 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].
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 3.
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'autre 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 5, 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 1 et à la section 3 ; la sémantique complète de
RDFS à la section 1, à la section 3 et à la section 4.
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é 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 5.
Les sections suivantes définissent comment une interprétation d'un vocabulaire détermine la valeur de vérité d'un graphe RDF,
par une définition récursive de la dénotation — la « valeur » sémantique » — d'une expression RDF par rapport à celles de ses
sous-expressions immédiates. Celles-ci s'appliquent à toutes les extensions sémantiques subséquentes. RDF a deux types
de dénotation : les noms dénotent des choses dans l'univers et les ensembles de triplets dénotent
des valeurs de vérité.
La dénotation d'un graphe RDF fondamental dans I est donnée récursivement par les règles suivantes, lesquelles étendent
l'application d'interprétation I des noms vers les graphes fondamentaux. Ces règles (et leurs extensions
données ensuite) agissent en définissant la dénotation d'un bout de syntaxe RDF E par rapport aux dénotations des
constituants syntaxiques immédiats de E, en permettant donc de déterminer la dénotation de tout morceau de RDF par
une sorte de récursion syntaxique.
Dans ce tableau et tout au long de ce document, le signe d'égalité « = » indique une identité et les chevrons <x, y> servent
à indiquer un couple ordonné de x et y. La syntaxe des graphe RDF est indiquée en utilisant les conventions d'écriture de la
syntaxe N-Triples décrite dans le document des
jeux d'essais RDF [RDF-TESTS] : les chaînes littérales sont entre des
guillemets doubles « " », les étiquettes de langue sont indiquées par le signe « @ » et les triplets se terminent par un point de code « . ».
Conditions sémantiques des graphes fondamentaux.
| si 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.
Les nœuds 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 nœud 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 nœuds anonymes. Cela nécessitera des définitions puisque
la théorie n'offre jusqu'ici aucune méthode pour les nœuds anonymes. Supposons I une interprétation et A une application d'un ensemble de
nœuds 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 nœuds anonymes. Définissons blank(E) comme étant l'ensemble des nœuds anonymes dans E. On peut alors étendre
les règles précédentes pour inclure les deux nouveaux cas introduits lorsque des nœuds anonymes apparaissent dans le graphe :
Conditions sémantiques des nœuds anonymes.
| Si E est un nœud 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 nœuds anonymes, même si elle ne fournit aucune dénotation pour les nœuds anonymes eux-mêmes. Remarquez également que les
nœuds anonymes eux-mêmes sont des entités parfaitement bien définies ; ceux-ci diffèrent seulement des autres nœuds 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 nœud 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 nœud différent (nodeID) dans les deux triplets, indiquant que le graphe RDF avait deux
nœuds anonymes au lieu d'un, alors A' pourrait associer un nœud à 2 et l'autre à 1, et le graphe résultant serait vrai sous l'interprétation I.
On traite effectivement tous les nœuds anonymes comme ayant la même signification que des variables quantifiées existentielles
(existentially quantified variables) dans le graphe RDF 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 nœuds 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 nœuds anonymes dans chaque graphe comme étant
quantifiés existentiellement dans ce graphe, de sorte qu'aucun nœud 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
nœud anonyme dans l'un se rapporte à la même entité qu'un nœud anonyme dans l'autre.
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érence valide. 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 1.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 nœuds 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'affimer, 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 nœuds 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.
2.1 Interprétations de vocabulaire et implication de vocabulaire
Les interprétations simple et l'implication simple capturent la sémantique des graphes RDF lorsqu'aucune attention
n'est prêtée à la signification particulière des noms dans le graphe. Pour obtenir la signification complète d'un graphe RDF
écrit avec un vocabulaire particulier, il est en général nécessaire d'ajouter des conditions sémantiques qui attachent des significations
plus fortes à des références URI et littéraux typés particuliers dans le graphe. Les interprétations qui sont tenues
de satisfaire à des conditions sémantiques supplémentaires sur un vocabulaire particulier seront désignées génériquement comme étant des
interprétations de vocabulaire (vocabulary interpretations). Une implication de vocabulaire
signifie une implication par rapport à de telles interprétations de vocabulaire. Ces notions plus fortes d'interprétation et d'implication
sont indiquées par l'utilisation d'un préfixe d'espace de noms, et nous nous référerons donc à une rdf-implication
(rdf-entailment), une rdfs-implication (rdfs-entailment),
etc., dans la suite. Dans chaque cas, le vocabulaire dont la signification est restreinte et les conditions exactes associées
à ce vocabulaire sont rédigés en détail.
Le vocabulaire RDF rdfV est un ensemble de références URI
dans l'espace de noms rdf: :
| 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-interprétations 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 XML seront 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.
3.2. 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'interpoloation de la rdf-implication. La section 7.2 décrit les conditions exactes
de détection de l'implication RDF.
3.3. 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 œuvre de processus pour vérifier l'implication RDF formelle.
Ainsi, les mises en œuvre peuvent opter pour l'utilisation de techniques procédurales spéciales pour implanter (implement)
le vocabulaire des collections RDF.
| 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 nœud destiné à citer le premier triplet — le nœud anonyme dans le deuxième graphe — est appelé,
plutôt confusément, un triplet réifié (reified triple). (Il peut s'agir d'un nœud 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 RDF
concret, 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 nœud 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 nœud 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> .
| 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.
3.3.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 nœuds 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étation 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.
3.3.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.
RDF Schema [RDF-VOCABULARY] étend RDF afin d'inclure
un vocabulaire rdfsV avec des contraintes sémantiques plus complexes :
| Vocabulaire RDFS |
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 Classe 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).
4.2 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 œuvre plus simples d'un
ensemble complet de règles d'implication RDFS, décrit à la
section 7.3.
Bien que les conditions sémantiques sur les rdfs-interprétations incluent
la condition raisonnable intuitive selon laquelle ICEXT(I(rdfs:Literal)) doit être l'ensemble LV, il n'y a aucun moyen d'imposer
cette condition par une assertion RDF ou une règle d'inférence. Cette limitation est due au fait que RDF
ne permet pas l'apparition de littéraux en position de sujet d'un triplet, il y a donc des restrictions strictes sur ce que l'on peut
dire à propos des littéraux en RDF. De même, alors que l'on peut affirmer des propriétés comme étant de la
classe rdfs:Literal, aucune d'elles ne peut être transférée de façon valide aux littéraux eux-mêmes.
Par exemple, un triplet de la forme :
<ex:a> rdf:type rdfs:Literal .
est cohérent même si "ex:a" est une référence URI au lieu d'un littéral. Ce qu'il dit est que
I(ex:a) est une valeur littérale, c'est-à-dire que la référence URI "ex:a" dénote une
valeur littérale. Elle n'indique pas exactement quelle valeur littérale elle dénote.
Les conditions sémantiques garantissent que tout triplet contenant un objet de type littéral ordinaire implique un triplet similaire
avec un nœud 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.
4.4 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.
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 nœud 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.
