RE: ACTION: task force unasserted triples

>Hi Pat,
>
>I am not sure how many of your questions still stand.
>I'll try giving brief answers to all I find.
>
>Jeremy:
>>  >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'?
>
>The rules in every DAML+OIL model theory I have seen talk about a syntactic
>precondition creating a semantic cosntraint as a postcondition.

Again, I dont follow you. The rules in every model theory I know 
about work by associating semantic constraints with syntactic 
structures. Thats pretty much a general definition of model theory, 
in fact. Is that what you mean? If so, fine; but then....

>This contrasts with approaches I have seen from Pat,

?? that wouldn't make sense.

>  which starts off by a
>very simple mapping from syntax to semantics, and then talks about semantic
>constraints:
>   if such-and-such a semantic precondition  holds then such-and-such
>postcondition holds.

Oh, I think I see what you mean, you are referring to the 
simple/RDF/RDFS -entailment distinctions? .Right, the RDF MT is 
actually three MTs all in one document, strictly speaking. But each 
of those is a perfectly conventional MT. The closure rules provide a 
neat syntactic characterization of the relationships between the 
various languages, in effect unifying them into a single language. 
(Strictly speaking, they show how RDFS can be seen as a particular 
RDF ontology, and how RDF preserves the elementary logical 
interpretation of the graph syntax.) This seemed desirable since the 
RDF<->RDFS distinction is largely arbitrary in any case, but its 
asking too much to expect this kind of very simple relationship to go 
much further. It breaks down when we get to the datastructuring, for 
example.

>
>Pat's approach is also often equivalent to taking syntactic closures where
>if we see precondition pattern of triples we add postcondition triples.

Don't think of this as a different approach to the MT. The MT is the 
*semantic* conditions (sections 3 and 5 in the MT doc) ; the 
entailment and closures sections (sections 4 and 6) are more like 
helpful appendices.

>  >  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.
>
>rdfs:subPropertyOf doesn't and cannot add triples to the graph.

Well, I guess Im taking it for granted that any valid inference from 
a graph can be legally added to it at any time.  It would be hard to 
state a semantics that violated this condition.

>The closure rules in the RDF model theory add implicit triples but that's
>only a way of thinking.

No, its not just a way of thinking. The semantics specify what is 
true. Valid consequences of a true graph are necessarily true, so if 
their presence would alter any meanings then the logic is 
nonmonotonic (and should be given a different semantics, eg one based 
on minimal models.)

>The DAML+OIL model theories appear to me to talk
>about explicit triples in the graph before any such closure rules apply.
>
>>
>>  >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.
>
>I think rather than arguing about what DAML+OIL does in fact say, it is
>more profitable to note that, given a dark triple framework, it could say
>that all daml:*** triples are dark.

Well, it *could* but that wouldnt be useful. That would say that 
DAML+OIL semantics is completely independent from RDF semantics. I 
thought the best way to do layering would be to relate them as 
closely as possible, even if perfect alignment is impossible. Think 
of dark triples as a figleaf, not a burkah.

>This seems to me to be intelligible,
>and, moreover, many of the previous model theories that we have seen, such
>as the DAML+OIL model theory don't seem to mind.
>
>>
>>  >
>>  >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.
>
>(Personally I don't see the need for any dark triples).
>The two positions where
>1) daml:List is dark
>2) daml:* is dark

What I think would work just right would be to darken the 
list-constructing daml:vocabulary (List, first, rest, nil)

>I think can be contrasted by a student/employee test case:
>
>Premise
>John rdf:type Student .
>John rdf:type Employee .
>
>Conclusion
>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 .
>
>If all of daml is dark then this test case can be true based on daml model
>theory.
>If only the lists are dark then I can't see where the conclusion comes
>from.

In RDF it doesnt. In OWL it would come from an OWL semantic 
constraint of the form that if JOhn is in A and JOhn is in B then 
JOhn is in (A intersect B).

>
>>
>>  >
>>  >Potential paradoxes, like the Patel-Schneider paradox (Test Case C) are
>>  >resolved outside of DAML+OIL.
>Pat:
>>  'Outside' means what?
>
>
>In the model, because of set theoretic constraints on the model.
>But an axiomatisation of the DAML+OIL model theory

Please don't use meaningless phrases. What is an axiomatization of a 
model theory? Do you mean a restatement of the MT in a formal set 
theory metalanguage? If so...

>does not include
>comprehension rules for which sets exist.

...it better had have comprehension rules. Of course the semantic 
META theory has comprehension principles, in fact it will need to be 
something like ZF, probably, in our case. BUt we don't even need to 
go there: we aren't doing foundations-of-mathematics here, just plain 
old semantics.

>
>
>>  >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.
>
>I don't see this snag There are many documents that are consistent under
>RDF and inconsistent under OWL. This is just another one of those.

Well, as I understand it, this is fine if the document violates some 
syntacitic condition of OWL, like my branching-list example would 
violate a DAML condition. But Peter's point (I think) is that 
examples like his paradox in fact should not be considered to be 
OWL-illegal, and there is no need to make them so, since in OWL they 
would just be simple contradictions. But when OWL is also obliged to 
respect the RDF semantics, they become paradoxical, because they can 
then be derived in RDF.

>(It is
>more difficult to detect, since proving consisteny/inconsistency now
>involves elements of set theory).
>
>
>
>
>>
>>  >Thus the
>>  >model theory
>>
>>  Which model theory? OWL's model theory, or RDF's model theory of
>>  OWL-encoded-in-RDF ?
>
>OWL 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.
>>
>>  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.
>
>
>Yes - making everyhting dark fixes that.

Or just making the lists dark would do.

>
>>
>>  >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.

Right, that is the thought behind my most recent proposal.

>  >
>>  >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 (?)
>
>Hmmm, not today!

YOu wrote that before the telecon, right?

Pat
-- 
---------------------------------------------------------------------
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 Thursday, 25 April 2002 13:33:53 UTC