Veuillez consulter l'errata de ce document, lequel peut contenir des corrections normatives.
Cf. également d'éventuelles traductions.
Copyright © 2004 W3C® (MIT, ERCIM, Keio), tous droits réservés. Les règles de responsabilité, de marque commerciale, d'utilisation des document et d'octroi de licences logicielles du W3C s'appliquent.
Cette sémantique du modèle théorique du langage OWL part directement des ontologies dans la syntaxe abstraite OWL DL, qui inclut la syntaxe abstraite OWL Lite, pour aboutir à un modèle théorique standard. Elle est plus simple que la sémantique décrite dans le chapitre 5, qui est une extension de vocabulaire de la sémantique RDFS.
La sémantique commence ici avec la notion de vocabulaire. Lorsqu'on traite une ontologie OWL, le vocabulaire doit inclure tous les appels d'adresses URI et littéraux dans cette ontologie, ainsi que les ontologies qu'elle importe, mais elle peut aussi bien inclure d'autres appels d'adresses URI et littéraux.
Dans ce chapitre, VOP
représentera les appels d'adresse URI des
propriétés d'ontologie OWL intégrées.
Définition : Un vocabulaire OWL V
consiste en
un ensemble de littéraux VL
et de sept ensembles d'appels d'adresses URI :
VC
, VD
, VI
, VDP
, VIP
, VAP
et VO
. Quel que soit le vocabulaire, les ensembles VC
et VD
sont disjoints,
et les ensembles VDP
, VIP
, VAP
et VOP
sont disjoints deux-à-deux.
L'ensemble VC
des noms de classes d'un vocabulaire contient les classes owl:Thing
et owl:Nothing. L'ensemble VD
des noms de types de données d'un vocabulaire
contient les appels d'adresse URI des types de données OWL intégrés
et la classe rdfs:Literal. L'ensemble VAP
des noms de propriétés d'annotation
d'un vocabulaire contient les propriétés owl:versionInfo, rdfs:label,
rdfs:comment, rdfs:seeAlso et rdfs:isDefinedBy.
L'ensemble VIP
des noms de propriétés à valeur d'individu d'un vocabulaire,
l'ensemble VDP
des noms de propriétés à valeur de donnée d'un vocabulaire,
l'ensemble VI
des noms d'individus d'un vocabulaire et
l'ensemble VO
des noms d'ontologies d'un vocabulaire ne contiennent pas obligatoirement des membres.
Une application de types de données peut contenir les types de données des autres types de données OWL intégrés. Elle peut aussi contenir d'autres types de données, mais il n'y a aucune disposition dans la syntaxe OWL pour communiquer ce que sont ces types de données.
Définition : Soit D
une application de types de données. Une
interprétation OWL abstraite par rapport à D
avec un vocabulaire VL
,
VC
, VD
, VI
, VDP
, VIP
, VAP
,
VO
est un tuple de la forme
I = <R, EC, ER, L, S, LV>
, où (P est
l'opérateur ensemble des parties d'un ensemble) :
Rdes ressources de
In'est pas vide
LVdes valeurs littérales de
Iest un sous-ensemble de
R, et il contient l'ensemble des chaînes Unicode, l'ensemble des couples de chaînes et étiquettes de langue Unicode, et les espaces de valeurs de chaque type de donnée dans
D
TLest l'ensemble des littéraux typés dans
VL
Oest non vide et disjoint de
LV
Le tuple EC
représente les appels d'adresses URI utilisés comme classes et types de données OWL.
Le tuple ER
représente les appels d'adresses URI utilisés comme propriétés OWL.
(La propriété rdf:type est ajoutée aux propriétés d'annotation pour représenter une
contre-indication, cf. ci-dessous).
Le tuple L
représente les littéraux typés. Le tuple S
représente les appels d'adresses URI utilisés
pour dénoter des individus OWL et faciliter l'expression des annotations. Remarquez qu'aucune interprétation ne pourra
satisfaire à toutes les conditions placées sur des littéraux mal formés, c'est-à-dire ceux dont la forme lexicale est invalide
pour le type de donnée, par exemple 1.5^^xsd:integer
.
Le tuple S
est étendu aux littéraux ordinaires dans VL
en les associant (essentiellement) à eux-mêmes,
c'est-à-dire S("l") = l
, où l
est un littéral ordinaire
sans étiquette de langue, et S("l"@t) = <l,t>
,
où l
est un littéral ordinaire avec une étiquette de langue.
Le tuple S
est étendu aux littéraux typés avec L
, tel que S(l) = L(l)
, où l
est un littéral typé.
Le tuple EC
est étendu aux structures syntaxiques des descriptions, des gammes de données, des individus, des valeurs
et des annotations selon le Le tableau d'extension de EC.
| Syntaxe abstraite | Interprétation (valeur de EC) |
|---|---|
| complementOf(c) | O - EC(c) |
| unionOf(c1 … cn) | EC(c1) ∪ … ∪ EC(cn) |
| intersectionOf(c1 … cn) | EC(c1) ∩ … ∩ EC(cn) |
oneOf(i1 … in),
pour ijun identificateur d'individu |
{S(i1), …, S(in)} |
| oneOf(v1 … vn), pour vj un littéral | {S(v1), …, S(vn)} |
| restriction(p x1 … xn), pour n > 1 | EC(restriction(p x1)) ∩…∩ EC(restriction(p xn)) |
| restriction(p allValuesFrom(r)) | {x ∈ O | <x,y> ∈ ER(p) implique y ∈ EC(r)} |
| restriction(p someValuesFrom(e)) | {x ∈ O | ∃ <x,y> ∈ ER(p) ∧ y ∈ EC(e)} |
restriction(p value(i)), pour iun identificateur d'individu |
{x ∈ O | <x,S(i)> ∈ ER(p)} |
restriction(p value(v)), pour vun littéral |
{x ∈ O | <x,S(v)> ∈ ER(p)} |
| restriction(p minCardinality(n)) | {x ∈ O | card({y ∈ O ∪ LV : <x,y> ∈ ER(p)}) ≥ n} |
| restriction(p maxCardinality(n)) | {x ∈ O | card({y ∈ O ∪ LV : <x,y> ∈ ER(p)}) ≤ n} |
| restriction(p cardinality(n)) | {x ∈ O | card({y ∈ O ∪ LV : <x,y> ∈ ER(p)}) = n} |
| Individual(annotation(p1 o1) … annotation(pk ok) type(c1) … type(cm) pv1 … pvn) |
EC(annotation(p1 o1)) ∩ …
EC(annotation(pk ok)) ∩ EC(c1) ∩ … ∩ EC(cm) ∩ EC(pv1) ∩ … ∩ EC(pvn) |
| Individual(i annotation(p1 o1) … annotation(pk ok) type(c1) … type(cm) pv1 … pvn) |
{S(i)} ∩ EC(annotation(p1 o1)) ∩ …
EC(annotation(pk ok)) ∩ EC(c1) ∩ … ∩ EC(cm) ∩ EC(pv1) ∩ … ∩ EC(pvn) |
| value(p Individual(…)) | {x ∈ O | ∃ y∈EC(Individual(…)) : <x,y> ∈ ER(p)} |
value(p id), pour idun identificateur d'individu |
{x ∈ O | <x,S(id)> ∈ ER(p) } |
value(p v), pour vun littéral |
{x ∈ O | <x,S(v)> ∈ ER(p) } |
annotation(p o), pour oun appel d'adresse URI |
{x ∈ R | <x,S(o)> ∈ ER(p) } |
| annotation(p Individual(…)) | {x ∈ R | ∃ y ∈ EC(Individual(…)) : <x,y> ∈ ER(p) } |
Une interprétation OWL abstraite I
satisfait aux axiomes et faits comme indiqué dans le
tableau d'interprétation des axiomes et des faits. Dans ce tableau,
les parties optionnelles des axiomes ou des faits apparaissent entre des crochets ([…])
tout comme les conditions optionnelles qui leur correspondent.
| Directive | Conditions sur les interprétations |
|---|---|
|
Class(c [Deprecated] complete annotation(p1 o1) … annotation(pk ok) descr1 … descrn) |
[ <S(c),S(owl:DeprecatedClass)> ∈ ER(rdf:type) ] S(c) ∈ EC(annotation(p1 o1)) … S(c) ∈ EC(annotation(pk ok)) EC(c) = EC(descr1) ∩ … ∩ EC(descrn) |
| Class(c [Deprecated] partial annotation(p1 o1) … annotation(pk ok) descr1 … descrn) |
[ <S(c),S(owl:DeprecatedClass)> ∈ ER(rdf:type) ] S(c) ∈ EC(annotation(p1 o1)) … S(c) ∈ EC(annotation(pk ok)) EC(c) ⊆ EC(descr1) ∩ … ∩ EC(descrn) |
| EnumeratedClass(c [Deprecated] annotation(p1 o1) … annotation(pk ok) i1 … in) |
[ <S(c),S(owl:DeprecatedClass)> ∈ ER(rdf:type) ] S(c) ∈ EC(annotation(p1 o1)) … S(c) ∈ EC(annotation(pk ok)) EC(c) = { S(i1), …, S(in) } |
| Datatype(c [Deprecated] annotation(p1 o1) … annotation(pk ok) ) |
[ <S(c),S(owl:DeprecatedClass)> ∈ ER(rdf:type) ] S(c) ∈ EC(annotation(p1 o1)) … S(c) ∈ EC(annotation(pk ok)) EC(c) ⊆ LV |
| DisjointClasses(d1 … dn) | EC(di) ∩ EC(dj) = { } for 1 ≤ i < j ≤ n |
| EquivalentClasses(d1 … dn) | EC(di) = EC(dj) for 1 ≤ i < j ≤ n |
| SubClassOf(d1 d2) | EC(d1) ⊆ EC(d2) |
|
DatatypeProperty(p [Deprecated] annotation(p1 o1) … annotation(pk ok) super(s1) … super(sn) domain(d1) … domain(dn) range(r1) … range(rn) [Functional]) |
[ <S(c),S(owl:DeprecatedProperty)> ∈ ER(rdf:type)] S(p) ∈ EC(annotation(p1 o1)) … S(p) ∈ EC(annotation(pk ok)) ER(p) ⊆ O×LV ∩ ER(s1) ∩ … ∩ ER(sn) ∩ EC(d1)×LV ∩ … ∩ EC(dn)×LV ∩ O×EC(r1) ∩ … ∩ O×EC(rn) [ER(p) est fonctionnelle] |
|
ObjectProperty(p [Deprecated] annotation(p1 o1) … annotation(pk ok) super(s1) … super(sn) domain(d1) … domain(dn) range(r1) … range(rn) [inverse(i)] [Symmetric] [Functional] [ InverseFunctional] [Transitive]) |
[ <S(c),S(owl:DeprecatedProperty)> ∈ ER(rdf:type)] S(p) ∈ EC(annotation(p1 o1)) … S(p) ∈ EC(annotation(pk ok)) ER(p) ⊆ O×O ∩ ER(s1) ∩ … ∩ ER(sn) ∩ EC(d1)×O ∩ … ∩ EC(dn)×O ∩ O×EC(r1) ∩ … ∩ O×EC(rn) [ER(p) est le symétrique de ER(i)] [ER(p) est symétrique] [ER(p) est fonctionnelle] [ER(p) est fonctionnelle symétrique] [ER(p) est transitive] |
| AnnotationProperty(p annotation(p1 o1) … annotation(pk ok)) | S(p) ∈ EC(annotation(p1 o1)) … S(p) ∈ EC(annotation(pk ok)) |
| OntologyProperty(p annotation(p1 o1) … annotation(pk ok)) | S(p) ∈ EC(annotation(p1 o1)) … S(p) ∈ EC(annotation(pk ok)) |
| EquivalentProperties(p1 … pn) | ER(pi) = ER(pj) pour 1 ≤ i < j ≤ n |
| SubPropertyOf(p1 p2) | ER(p1) ⊆ ER(p2) |
| SameIndividual(i1 … in) | S(ij) = S(ik) pour 1 ≤ j < k ≤ n |
| DifferentIndividuals(i1 … in) | S(ij) ≠ S(ik) pour 1 ≤ j < k ≤ n |
| Individual([i] annotation(p1 o1) … annotation(pk ok) type(c1) … type(cm) pv1 … pvn) |
EC(Individual([i] annotation(p1 o1) … annotation(pk ok) type(c1) … type(cm) pv1 … pvn)) n'est pas vide |
D'après le chapitre 2, une ontologie OWL peut avoir des annotations, qui ont besoin de leurs propres conditions sémantiques. Hormis cette signification locale, une annotation owl:imports peut aussi importer le contenu d'une autre ontologie dans l'ontologie courante. Le cas échéant, l'ontologie importée a pour nom l'argument de la structure owl:imports. (Ce traitement des importations est séparé de celui des problèmes liés au Web. Les noms d'ontologies OWL sont censés représenter leurs localisations sur le Web, mais cela ne fait pas partie de ce traitement formel).
Outilisé comme identificateur de classe (identificateur de type de donnée, identificateur d'individu, identificateur de propriété à valeur de donnée, identificateur de propriété à valeur d'individu, identificateur de propriété d'annotation, identificateur d'annotation, identificateur d'ontologie) appartient à
VC(
VD,
VI,
VDP,
VIP,
VAP,
VO, respectivement) ;
Oappartient à
VL;
Isatisfait à chaque directive dans
O, hormis les annotations d'ontologies ;
o ∈ R,
<o,S(owl:Ontology)> ∈ ER(rdf:type), tel que pour chaque annotation d'ontologie de la forme
Annotation(p v), <o,S(v)> ∈ ER(p)et que si
Oa pour nom
n, alors
S(n) = o, et
Isatisfait à chaque ontologie mentionnée par une directive d'annotation owl:imports de
O.
Définition : Un ensemble d'ontologies OWL abstraites,
d'axiomes et de faits est cohérent par rapport à l'application de type de donnée D
s'il existe une interprétation I
par rapport à D
qui satisfait à chaque ontologie, axiome et fait dans l'ensemble.
Définition : Un ensemble O
d'ontologies OWL abstraites, d'axiomes et de faits infère
l'existence d'une ontologie OWL abstraite ou d'un axiome ou d'un fait O'
par rapport à une
application de type de donnée D
si chaque interprétation par rapport à l'application D
satisfaisant à chaque ontologie,
axiome ou fait dans O
satisfait aussi O'
.