RE: A proposal for a way forward regarding fragments

Hi,

OK, I see what you say about the union. In fact, a similar thing holds for the intersection.

I've added two new rules to Table 5. I would still keep the rules in Table 3: these are redundant; however, they naturally follow
from the idea that the definition of OWL-R is obtained by weakening the semantic conditions of OWL Full. An implementation can,
however, safely ignore these rules.

Regards,

	Boris


> -----Original Message-----
> From: Alan Wu [mailto:alan.wu@oracle.com]
> Sent: 05 March 2008 19:45
> To: Boris Motik
> Cc: bcg@cs.man.ac.uk; hendler@cs.rpi.edu; 'Jeremy Carroll'; 'Michael Schneider'; OWL Working Group WG
> Subject: Re: A proposal for a way forward regarding fragments
> 
> Boris,
> 
> Copying WG on this.
> > I've extended the rules table as you've suggested and have added a new table with constraints for
> the schema entailments. Let me
> > know what you think. Below are the responses to other questions.
> >
> That is quick, Boris! Thank you. I will review the changes.
> >>> * If rdfs:subClassOf triples can be generated, then those N rules in
> >>> Table 3 regarding rdf:unionOf (should be owl:unionOf)
> >>>    can be simplified into one rule deducing that T(?C1,
> >>> rdfs:subClassOf,  ?C), T(?C2,  rdfs:subClassOf,  ?C) ...
> >>>    T(?Cn,  rdfs:subClassOf,  ?C)
> >>>
> >> I'm sorry, I don't really understand this comment.
> >>
> >
> >
> >> The idea is instead of N separate rules, we can have just one rule (please forgive me for
> >> introducing a new syntax).
> >> C owl:unionOf {c1, c2, ... cn}
> >> ===>  c1 rdfs:subClassOf C,   c2 rdfs:subClassOf C,  .... cn rdfs:subClassOf C.
> >>
> > I am not sure whether this would solve our problem. The reason why we need n rules is because the
> disjunction (and the same holds
> > for conjunction as well) in OWL can have an arbitrary number of disjuncts (i.e., conjuncts). This
> is why we introduced n rules: we
> > don't know in advance what the arity is going to be.
> >
> > Now I understand that this is quite impractical for implementations. There might be a way of
> dealing with this; I have to think
> > about it more though. In the worst case, implementors can simply instantiate these rules for all
> "reasonable" numbers of n.
> >
> I guess I did not make myself clear on this. If we change the rule from
> its original form (N rules that are operating on instances) to one rule
> that generates N rdfs:subClassOf  schema  triples,  then implementation
> is easy, right?
> 
> The generation of those N schema triples is just a one time deal. The
> rest of the work will be handled by the first rule in Table 4.
> >>> I don't think we need this restriction on the rules: we won't generate an invalid triple as long
> >>> as p is not a blank node or a literal. Thus, as long as the input obeys is syntactically correct,
> >>> it seems to me that none of the rules should really worry about producing syntactically correct
> >>> triples.
> >>>
> >
> >
> >> Let me use an example. It seems to me that the following is allowed syntactically in OWL-R FULL
> >> (RDFS 3.0).
> >>
> >> T(http://abc/d#1,  owl:sameAs,  "Hello")
> >>
> >> If we apply symmetricity, then we get an illegal triple, right?
> >>
> > Yes, true. However, the problem is not in the rules; rather, the problem is in the first triple:
> >
> > T(http://abc/d#1,  owl:sameAs,  "Hello")
> >
> > This triple equates resources to literals. In OWL DL this is illegal. I am not sure I understand
> exactly what the meaning of this in
> > light of OWL Full is; perhaps Jeremy can shed light on this. I do believe, though, that we should
> either (1) declare the knowledge
> > base to the in error or (2) indeed replace 1 with "Hello" in all triples. Simply ignoring the
> semantics of equality for this triple
> > would probably be not such a good idea.
> >
> I am not so sure on this one myself. (1) sounds better.
> > Regards,
> >
> > 	Boris
> >
> Thanks,
> 
> Zhe

Received on Thursday, 6 March 2008 10:15:36 UTC