Re: CYCLES IN CLASS/PROPERTY HIERARCHIES

Vassilis Christophides wrote:
> 
> Dear Wolfram
> 
> Thanks for your detailed comments. It help us a lot to understand the
> subtleties between the the current RDF MT and the previous RDF
> semantics. However, I would like to point out some of my objections.
> 
> >If this treatment of range/domain is really useful, is a different
> >(but already closed) issue.
> 
> First of all, I am wondering to what extend we can firmly close
> semantics issues of RDF, without giving a sufficient justification of
> the adopted choices w.r.t. the modeling requirements of Semantic Web
> applications, and, the processing requirements of RDF systems (query
> languages, inference engines, etc.).  I will try mention few examples.


Dear Vassilis,

thanks for your last, very intersting email. As I am not involved with
RDF Core WG and as I also think, that seeing ranges/domains as
constraints and not as another way to add types is pretty reasonable
(even in the light of possible non-monotonicity), I'am not the right one
to comment on your objections (though, let me say that we were used to
the interpretation of ranges/domains that you suggest in your first
example, and that we will miss this possibility too).

However, let me add some clarifications to the 3rd point of your email
below because it is closely related to the previous emails. While I
share most of your remarks on the other examples, the example there does
not seem to be completely precise. I nevertheless think, that now, with
a draft of the MT available, it is a good time to discuss what should be
in the MT in the end, because it is my feeling that it will be the MT
that defines what the core of RDF really is/will be, and the draft MT
already allows to give discussions the necessary precision (for example,
returning to the constraint interpretation would simply require to
remove the closure rules 5 and 6, this would, however, have some impact
on s-entailment/schema lemma etc.).


> 
> 3) Consider finally the following schema:
> 
>    C1 p1 C2
>    C3 p2 C4
>    C3 < C1, p2 < p1 and C2 < C4
> 
>   From the following RDF MT interpretation rules:
> 
>   1) <x,y> is in IEXT(I(rdfs:subClassOf)) iff ICEXT(x) is a subset of ICEXT(y)
>   2) <x,y> is in IEXT(rdfs:subPropertyOf)) iff IEXT(x) is a subset of IEXT(y)
>   3) If <x,y> is in IEXT(I(rdf:range)) and <u,v> is in IEXT(x) then v is in ICEXT(y)
>   4) If <x,y> is in IEXT(I(rdf:domain)) and <u,v> is in IEXT(x) then u is in ICEXT(y)
> 
>   we have:
> 
>   i)   I(p2) is a subset of I(p1); (from 2)
>   ii)  I(domain(p2)) is in I(C3);  (from 4)
>   iii) I(range(p2)) is in I(C4);   (from 3)
>   iv)  I(domain(p1)) is in I(C1);  (from 4)
>    v)  I(range(p1)) is in I(C2);   (from 3)
>   vi)  I(C3) is a subset of I(C1); (from 2)
>   vii) I(C2) is a subset of I(C4); (from 2)
> 
>   I am wondering how i), iii), and vii) are all together valid?
>   I believe that equality of I(C4) and I(C2) should be considered here.


Let us assume that we have a graph E that contains the triples from your
example (p1 domain C1,...,p2 subProperty p1 etc.). Now we produce a
graph C that is the schema-closure of E. (The schema lemma claims that
we can forget about s-Entailment now, but let us but this aside for a
moment). Assume that we have an interpretation I that satisfies C.

We also need a projection for sake of simplicity: For a set of pair S,
let P2 be the projection of the second pair members, that is P2(S) = { y
| <x,y> in S}.

Now, it follows for I from the interpretation rules:

(A)  P2(IEXT(I(p2)))  subset   P2(IEXT(I(p1)))   subset   ICEXT(I(C2))
	  [subProperty]               [range]
    (compare your (i) and (v) from above)

(B) P2(IEXT(I(p2)))  subset   ICEXT(I(C4))
               [from range]
    (iii above)

(C) ICEXT(I(C2))     subset   ICEXT(I(C4))
                [subclass]
    (vii above)   

As you see, it does not follow that the class extensions of the
interpretations of C2 and C4 should be equal -- it follows from (A) and
(B) that all elements of the projection of the second argument of the
extension of the interpretation of p2 must be in both class extensions
(that is, ICEXT(I(C4) and ICEXT(I(C2)) share some elements if
IEXT(I(p2)) is not empty). Now (C) gives us the additional information,
that all elements of ICEXT(I(C2)) are in fact also elements of
ICEXT(I(C4)) (but ICEXT(I(C4)) can be bigger, see below, which is not
really counterintuitive, see below).


>   However, the RDF MS entailment rules produce different extensions for
>   I(C4) and I(C2):
> 
>   x p2 y => x rdf:type C3
>             x rdf:type C1
>             y rdf:type C4

It also produces [x p1 y] and, therefore, also [y rdf:type C2]. However,
to make ICEXT(I(C4)) larger then ICEXT(I(C2)), you could simply say: [z
rdf:type C4], which would, however, not give you a problem with respect
to the interpretation rules.

> 
>   z p1 w => z rdf:type C1
>             w rdf:type C2
>             w rdf:type C4
> 
>   How consistent looks all the above?

Looks good to me. In the end, the question is whether the schema lemma
is true (I perceive the schema lemma as saying that if you have an RDF
graph where RDFS vocabulary is used and you compute the schema closure
and look for interpretations that satisfy the RDF constraints, then you
can forget about the RDFS constraints (interpretation rules, as has been
said above)). As I see it, you tried to construct an example where the
schemma-lemma would be violated, but, I think, there is no such example. 


Best regards
	Wolfram

Received on Saturday, 27 October 2001 17:02:29 UTC