RE: ACTION: task force unasserted triples

> >
> >>  2. How do "unasserted triples" solve this problem?
> >


I found myself (possibly) understanding this.
Here is my attempt to articulate this. (BTW, I disagree with
this position, but will state as clearly as I can).

---------------------

Looking at the model theoretic semantics for Daml+Oil [1]
we see a list of mappings of syntactic structures into semantic 
constraints.

The special DAML+OIL semantics of properties such as
samePropertyAs, sameClassAs etc. only applies over the syntactic
structures, and the use of rdfs:subPropertyOf etc is not applicable.
(Test Case A).

Essentially DAML+OIL properties are treated as syntactic keywords
independently of any other meaning.

Since the RDF meaning also gets in the way (e.g. the Student/Employee
examples Test Case B) it makes sense to switch off the RDF meaning
for all of the DAML+OIL properties, and essentially treat them as
opaque to the RDF layer. (They are like reserved words in a programming
language, which cannot be understood as variable names or function names
even where there is no other syntactic ambiguity).

Potential paradoxes, like the Patel-Schneider paradox (Test Case C) are 
resolved outside of DAML+OIL. Here, a description in DAML+OIL is given of 
an 
ill-conceived class. Since the class is self-inconsistent, any DAML+OIL
document with such a description in it has no interpretation. Thus the
model theory allows the (assumed) consistency of axiomatic set theory
to be inherited to reject as inconsistent any paradoxical descriptions.

So the DAML+OIL model theoretic semantics, understood as in 
opposition to the RDF semantics, and potentially not applying the 
general rule
   mapping the syntactic triple <?R,?O1,?O2> 
   to <x,y> in IR(?R), 
when the predicate ?R is in the daml namespace, is a well-worked and
well-understood example of a resolution of the problems. For this
to work it is required that either RDF does not interpret the
predicates in the daml namespace, or such an interpretation is
ignored. Dark triples is a suggestion for the former.

A large number of syntactic devices could be used for identifying
dark triples including:
- using separate RDF graphs, for example as separate documents
  or separate rdf:RDF elements.
  These could be annotated with an attribute on the rdf:RDF element.
- using different namespace prefixes for dark triples, which
  are declared as dark either
  - explicitly with some new rdf attribute somewhere
  - implicitly using a spelling convention e.g. 
    namespace prefixes starting in _ are dark.
- using an attribure on the propertyElt production 
  to indicate darkness.
- having an extension to rdf schema so that uri-refs
  can be declared as dark properties (i.e. 
  syntactically an rdf property but not semantically
  an rdfs:Property)

I hope this helps.

Jeremy

============================================================

Discussion of test cases in the DAML+OIL model theoretics
semantics + dark triples approach.

Test Case A
===========
Maybe taking a subproperty of daml:oneOf is
simply illegal. 

If it is legal then it only entails the
property relationship daml:oneOf holding 
whenever foo holds. It does not
entail either a dark-triple with predicate 
daml:oneOf or any of the special semantics 
of daml:oneOf.

Thus A-P does not entail A-M.
Nor does A-P entail A-C.

Test Case B
===========

All the triples of the B-C except the first are dark.
(Syntax needs to make this clear).

The only constraints that need to be satisfied are
the class membership constraints.
The syntactic mapping given for daml:intersectionOf
satisfies these constraints, and the entailment
follows.



Test Case C
===========

Take any daml interpretation into any model.
Since the model is a set, normal set theoretic
reasoning applies. Assume that C-C is true under
that interpretation falsity follows, and it is
the case that C-C is not true under that 
interpretation.
So no consistent graph entails C-C.



=====================================================



Test Case A.
============
The following entailment does not hold:

A-P:

foo rdfs:subPropertyOf daml:oneOf .
_:eg foo _:list .
_:list daml:rest daml:nil .
_:list daml:first _:singleton .
_:list rdf:type daml:List .

entails

A-C:
foo daml:sameInstanceAs _:singleton .


and thus:

A-P also does not entail:

A-M:
_:eg  daml:oneOf _:list .
_:list daml:rest daml:nil .
_:list daml:first _:singleton .
_:list rdf:type daml:List .



Test Case B
===========
(employee student)
B-P:

John rdf:type Student .
John rdf:type Employee .

entails

B-C:
John rdf:type _:i .
_:i rdf:type daml:Class .
_:i daml:intersectionOf _:l .
_:l rdf:type daml:List .
_:l daml:first Student .
_:l daml:rest _:t .
_:t rdf:type daml:List .
_:t daml:first Employee .
_:t daml:rest daml:nil .


Test Case C
===========
(Patel-Schneider paradox)
C-P:
empty

does not entail
C-C:
> _:1 rdf:type owl:Restriction .
> _:1 owl:onProperty rdf:type .
> _:1 owl:maxCardinalityQ "0" .
> _:1 owl:hasClassQ _:2 .
> _:2 owl:oneOf _:3 .
> _:3 owl:first _:1 .
> _:3 owl:rest owl:nil .
> _:1 rdf:type _: 1 .


See [2]


REFERENCES

[1]
http://www.w3.org/TR/2001/NOTE-daml+oil-model-20011218

[2]
http://lists.w3.org/Archives/Public/www-webont-wg/2002Jan/0099.html

Received on Wednesday, 24 April 2002 08:08:42 UTC