- From: Pat Hayes <phayes@ai.uwf.edu>
- Date: Wed, 24 Apr 2002 12:30:25 -0500
- To: "Jeremy Carroll" <jjc@hplb.hpl.hp.com>
- Cc: www-webont-wg@w3.org
> > > >> >> 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). ? I don't follow. What do you mean by 'not applicable'? Remember that DAML+OIL is *defined* to be an RDF language, which means that any RDF constructs that are legal in DAML+OIL have the same meaning in DAML+OIL as they have in RDF. That would apply to rdfs:subPropertyOf, I presume. When the DAML spec was written RDF didn't have an MT, but we took some care to try to make things come out so that they would line up (not forseeing all the problems, obviously). I think that the entailment in your test case A should be considered to be correct in DAML+OIL. >Essentially DAML+OIL properties are treated as syntactic keywords >independently of any other meaning. Again, I don't follow. They have a meaning in DAML+OIL, and their rendering into RDF (which is, officially, also their rendering in DAML+OIL itself) has a meaning in RDF. The central issue, for me, is finding a way to reconcile those two notions of 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). Again I don't quite follow. The DAML+OIL meanings (those which go beyond any RDFS meaning) are opaque to RDF, of course: we don't need any special treatment to achieve that, it kind of follows by definition. If I follow what you mean by 'switch off', ie the same as what I have been calling 'make dark', then (I think...) there is no need to do that for ALL the DAML+OIL properties, only the part of DAML+OIL that is used to encode its syntax into RDF, ie the daml:List vocabulary. > >Potential paradoxes, like the Patel-Schneider paradox (Test Case C) are >resolved outside of DAML+OIL. 'Outside' means what? >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. Fine, but the snag is that in RDF it *does* have an interpretation. In fact, it asserts that a certain class exists, and in the RDF MT it *does* exist. It can't possibly exist in an OWL interpretation, however. OWL imposes extra conditions that rule out those RDF interpretations; which would be fine, except that (as things stand at the present, which is why we have a problem) the layering process requires OWL to allow those interpretations that its own semantics would reject, because OWL includes RDF and the RDF says that the class exists. >Thus the >model theory Which model theory? OWL's model theory, or RDF's model theory of OWL-encoded-in-RDF ? >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. Well, yes and no. The MT is OK, but as things stand at present, DAML+OIL's spec contains a glaring contradiction, since DAML+OIL is defined to be RDF, and the DAML+OIL MT doesn't agree with the RDF MT. >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. Well, actually, it could be more like the latter. That is, it would be fine for RDF to interpret them, as long as OWL had some systematic way to ignore that aspect of the interpretation. OWL and RDF could agree to disagree. >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) Right, any of the above. Since apparently we are supposed to come up with an actual proposal, however, maybe we should discuss the pros and cons of these (?) >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. Its legal in DAML+OIL and should mean that the property is the same as oneOf but maybe restricted to a subdomain. For example you might define a version of oneOf that only worked on lists of people, that would be a subproperty. >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. I disagree. Well, Im not sure what you mean. Those entailments should be valid in DAML+OIL. > >Test Case B >=========== > >All the triples of the B-C except the first are dark. >(Syntax needs to make this clear). I think the first three should not be dark. They just say that something exists called the intersection, which RDFS and OWL can agree on. The remaining triples make sense to OWL, but their RDF interpretation is irrelevant to that OWL sense, and just gets in the way (not in quite such a pernicious form as a paradox, but still in the way.) >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. Not in DAML; but C-C is consistent in RDF, so (for example) it entails itself, in RDF. (And DAML *is* RDF....). We have to say which language we are working in whenever we use any semantic terminology like 'entails' or 'consistent', because they mean different things for different languages. Pat > > > >===================================================== > > > >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 In which language? (RDF or OWL?) > >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 -- --------------------------------------------------------------------- IHMC (850)434 8903 home 40 South Alcaniz St. (850)202 4416 office Pensacola, FL 32501 (850)202 4440 fax phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes
Received on Wednesday, 24 April 2002 13:30:27 UTC