RE: ACTION: task force unasserted triples

> -----Original Message-----
> From: www-webont-wg-request@w3.org
> [mailto:www-webont-wg-request@w3.org]On Behalf Of Pat Hayes
> Sent: 25 April 2002 18:34
> To: Jeremy Carroll
> Cc: www-webont-wg@w3.org
> Subject: 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.

There's a fairly large chunk here where I was trying to explain my
understanding of Peter's position - that all the owl triples are dark, the
RDF rules for them are ignored, and applying owl to itself is not
meaningful to owl.

If I have understood Pat's dark list proposal, the following may help
explain my comments about rdfs:subPropertyOf.

If we say

foo rdfs:subPropertyOf owl:first .
a foo b .

in RDF, and we are treating owl:first as dark, something gives doesn't it.
Under RDFS we have

a owl:first b .

Under OWL we don't. Isn't that one of the aspects of owl:first being dark?

My understanding of Peter's position is that that holds for all the owl:***
properties.
(I also understand all to have flexible rather than rigid positions, I
don't want to box Peter in here).

[ big snip ]

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

I was discussing daml with the guy who did the Jena partial implementation,
as far as he was concerned the DAML+OIL model theory meant that you look in
the original graph, if the given subgraph is there, then the rule is
applicable, otherwise not. It seems a perfectly reasonable reading to me -
not one I share.


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

Yes, you are taking it for granted. I like that rule, but note that I think
some others do not take it for granted.

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

And that's why, if you see the DAML+OIL model theory rules as applying to
the original graph (without its consequences), you need to have dark
triples, so that the rules (and the RDFS rules) do not apply to the OWL
bits of the graph, potentially creating consequences that would be
non-monotonic.

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

I am a naturist!
(fib)


Pat:
> What I think would work just right would be to darken the
> list-constructing daml:vocabulary (List, first, rest, nil)
Jeremy:
> >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.
Pat:
> 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).

Ahhh, that's what I thought too.
Violent agreement.

So by simple rearrangment we have

John is in (B intersect A).

Since the reverse entailment also holds, then all of Peters
Employee/Student cases from January get addressed (we need quite a bit of
machinery for all of them).

Now, the only difference between Pat's dark lists approach and my no dark
triples approach seems to be the status of the various lists.

In Pat's approach, from John is in A and John is in B we are allowed to
conclude that there exists in the model a class (A intersect B) but any
conclusion about the existence of the list [A B] is not permitted.

In my approach, both the class and the list are seen as artifacts that are
in the model and we find there exists in the model both the class (A
intersect B) and the list [A B].

In both approaches both the class (A intersect B) and the class (B
intersect A) exist. There equality is assured elsewhere by some of the
constraints.

In Pat's approach the lists do not exist in the model but get represented
by sets in the OWL interpretation only.

In my approach both the lists [A B] and [B A] exist.



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

I am sorry, I clearly didn't use the right language.
I will not try and indicate how darkening all of owl solves the
Patel-Scheider paradox, suffice to say I think it does. Peter can give a
fuller account if he wants.


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

I wonder if the following analogy might help you understand my preference
of not having anything dark.

<digression>

Analogy, Connected Components of Unlabelled Directed Graph
==========================================================

Suppose we have an unlabelled directed graph over 5 nodes.
e.g.

Edges = { <a,b>, <b,c>, <c,d>, <d,e> }

Let's suppose we see the ordering <a,b,c,d,e> in this graph as artifactual
and really wish to only see the connected components (in this case there is
only one).

One way, the dark triple way, is to say the graph is irrelevant except for
the sets of its connected components. In effect, we work out the answer we
want, the set { a,b,c,d,e }, and then delete all the edges.

Another way, the light triple way, is to add edges to take the transitive
and symmetric closure of the graph. This way we end up with the complete
directed graph over the five nodes, which also is a perfectly fine encoding
of the set { a, b, c, d, e }; layered with a different philosophy over the
original graph.

The adding edgs way when faced with a different graph e.g.

Edges2 = { <a,b>, <b,c>, <d,e> }

has the advantage of specifying how we find the answer (the connected
components). We add edges: <a,c> by transitivity, and then
<c,a>,<b,a>,<e,d>,<c,b> by symmetry.

This gives us:

{ <a,b>, <a,c> <b,c>, <b,a>, <c,a>, <c,b>, <d,e>, <e,d> }

which encodes the answer { { a, b, c }, { d, e } } and has lost (without
deletion) the spurious orderings.

</digression>

[..snip..]

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

too right.

Jeremy

Received on Friday, 26 April 2002 06:29:37 UTC