- From: Jeremy Carroll <jjc@hpl.hp.com>
- Date: Fri, 20 Jun 2003 13:53:09 +0300
- To: www-webont-wg@w3.org
This is my final beer session action.
The idea is to change the mapping rules, so that for any rule which introduces
a new blank node as its main node, then the explicit type triple in that rule
is made optional. We will continue to refer to this triple as the explicit
type triple (even though it is optional).
This is a little too ambitious, (it does not work), and I suggest retaining
the restriction that unnamed ontologies must have an explicit type triple.
Moreover, I need a small tweak to the OWL Full semantics concerning the
definition of the class extenstion of owl:DataRange.
Specifically any member of IDC that has a finite size is a member of the class
extension of owl:DataRange.
Observations:
1) With the new mapping rules, the direct semantics of an RDF graph G missing
one or more explicit type triples (for blank nodes) is the same as for the
same graph augmented by the explicit type triples.
2) Under 1) the explicit type triples that must be added can be syntactically
computed from G, except, that there may be any number of
_:b rdf:type owl:Thing .
corresponding to facts of the form
individual()
3) All missing explicit type triples are RDFS consequences of G.
4) Given 2 and 3 then the correspondence theorem continues to hold, because
given 2, and using the notation [G] to indicate the graph G with all missing
explicit type triples added we have:
If G OWL-DL entails H
then
G RDFS entails [G] OWL-DL entails [H]
G RDFS entails [G] OWL-full entails [H}
G OWL-Full entails [H]
G OWL-Full entails H
The inverse is not true, but then that seems to be the case anyway. The
inverse is only not true because:
a) [G] owl-DL entails [H]
does not follow from
[G] owl-full entails [H]
b) _:b rdf:type owl:Thing . is always true in OWL Full
but
individual() is not always true in OWL DL
================
I prove 2 and 3, and then have further discussion of facts
individual()
=====
2) given a bnode b, from the mapping rules, then either there are no triples
involving b, or one of the following is true.
a)
b rdf:type owl:Ontology . is in G (*not* optional)
and this is the explicit type triple.
b)
b rdf:type blank . is in G
and explicit type is present or owl:Thing.
c)
b rdf:type classID .
classID rdf:type owl:Class . (or classID is a builtin class)
are in G
and explicit type is present or owl:Thing.
d)
b apID any .
apID rdf:type owl:AnnotationProperty . (or apID is a builtin annotation
property)
are in G
and
b rdf:type owl:Ontology .
is not in G
and explicit type is present or owl:Thing.
e)
b owl:unionOf any .
is in G
and explicit type is owl:Class
f)
b owl:intersectionOf any .
is in G
and explicit type is owl:Class
g)
b owl:complementOf any .
is in G
and explicit type is owl:Class
h)
b owl:oneOf any .
is in G
and
exists dpID such that
dpID rdf:type owl:DatatypeProperty .
is in G
(or dpID is a builtin datatypeproperty)
such that
either
h.1)
dpID range b .
is in G
or
h.2)
there is another blank node c with
c owl:onProperty dpID
in G
and either
c owl:allValuesFrom b .
or
c owl:someValuesFrom b .
in G
and explicit type is owl:DataRange
i)
b owl:oneOf any .
is in G
and
h) does not apply
and explicit type is owl:Class
j)
b owl:onProperty any .
is in G
and explicit type is owl:Restriction
k)
b rdf:first any .
is in G
and explicit type is rdf:List .
That is an exhaustive analysis of the mapping rules, except
for the new rule (in red in the current editors draft) which
maps
individual() to
b rdf:type owl:Thing .
If this is a top-level fact then this may result in no triple
in the graph, since the explicit type triple is optional.
Otherwise we have either:
l)
any apID b .
apID rdf:type owl:AnnotationProperty .
(or apID is a builtin annotationproperty)
are in G
and explicit type of b is owl:Thing
or
m)
any opID b .
opID rdf:type owl:ObjectProperty .
(or opID is a builtin individual valued property)
are in G
and explicit type of b is owl:Thing .
Since the options a) through m) are mututally exclusive except for those that
result in explicit type of owl:Thing; and moreover options a) through m) are
an exhaustive analysis of the mapping rules, we have that any missing
explicit type triple of blank nodes (other than owl:Ontology) can be deduced
by syntactic analyis of G, or they are triples of the form
b rdf:type owl:Thing .
where b does not occur elsewhere in G.
3) analysing the cases above we see:
the empty ontology OWL Full entails
b rdf:type owl:Thing
(owl:Thing rdf:type owl:Class and
owl:Class rdfs:subClassOf rdfs:Resource
and
rdfs:Resource owl:equivalentClass owl:Thing
are all trivial)
The cases
e)
b owl:unionOf any .
f)
b owl:intersectionOf any .
g)
b owl:complementOf any .
i)
b owl:oneOf any .
is in G
and
h) does not apply
and explicit type is owl:Class
j)
b owl:onProperty any .
k)
all follow by considering the rdfs:domain of the predicate of the given
triple.
Case
a)
b rdf:type owl:Ontology .
is trivial, since the explicit type triple is not optional.
Cases
b)
b rdf:type blank . is in G
c)
b rdf:type classID .
d)
b apID any .
l)
any apID b .
m)
any opID b .
all have explicit type owl:Thing, which is trivially OWL Full entailed for any
node.
Which leaves only case h).
[[
b owl:oneOf any .
is in G
and
exists dpID such that
dpID rdf:type owl:DatatypeProperty .
is in G
(or dpID is a builtin datatypeproperty)
such that
either
h.1)
dpID range b .
is in G
or
h.2)
there is another blank node c with
c owl:onProperty dpID
in G
and either
c owl:allValuesFrom b .
or
c owl:someValuesFrom b .
in G
and explicit type is owl:DataRange
]]
This case follows because by the syntax of G the triple
b owl:oneOf any .
has object which is a (possibly empty) well-formed list of data literals, and
from OWL Full semantics we have
if there exisits:
l, a sequence of x1,…,xn over LVI
then there exisits
y in IDC, <y,l> in EXTI(SI(owl:oneOf))
since this is finite, then y is also in the class extention of owl:DataRange,
by the proposed tweak to OWL Full semantics.
Finished.
++++
I've jsut discovered this msg sitting on my desktop - I think it's finished,
if not I guess someone will point it out.
Jeremy
Received on Friday, 20 June 2003 07:53:17 UTC