W3C home > Mailing lists > Public > public-owl-wg@w3.org > March 2008

[Fwd: Re: A proposal for a way forward regarding fragments]

From: Alan Wu <alan.wu@oracle.com>
Date: Wed, 05 Mar 2008 12:10:48 -0500
Message-ID: <47CED418.9080805@oracle.com>
To: OWL Working Group WG <public-owl-wg@w3.org>


Forgot the copy the WG on this. Here it is.



Re: A proposal for a way forward regarding fragments
Alan Wu <alan.wu@oracle.com>
Tue, 04 Mar 2008 17:56:09 -0500
Boris Motik <boris.motik@comlab.ox.ac.uk>, bcg@cs.man.ac.uk

Boris Motik <boris.motik@comlab.ox.ac.uk>, bcg@cs.man.ac.uk
hendler@cs.rpi.edu, 'Jeremy Carroll' <jjc@hpl.hp.com>, 'Michael 
Schneider' <schneid@fzi.de>

Dear Boris and Bernardo,

Thanks very much for your hard work. In general, I am very happy to see 
those axiomatic rules on top of DLP. They do seem vendor
friendly. A few questions and comments so far,

* the transitivity of rdfs:subClassOf and rdfs:subPropertyOf is not 
reflected in the rules. Is that intentional or am I missing something?
  I understand that you took out "if" condition from the iff condition 
in Section 4.3.1. However, given
  T(?c1,  rdfs:subClassOf,  ?c2)  and   T(?c2,  rdfs:subClassOf,  ?c3), 
users would naturally expect to see
  T(?c1,  rdfs:subClassOf,  ?c3)

* Along the same line, do we want to generate rdfs:subClassOf (resp. 
rdfs:subPropertyOf) based on
  owl:equivalentClass (resp. owl:equivalentProperty)? and vice versa?

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

* Should the T(?x1, rdf:unionOf, ?c) in those N rules in Table 3 
regarding rdf:unionOf
  be  T(?c,  rdf:unionOf,  ?x1).   Ignore the typo for now.

  Same thing for T(?x1,  rdf:intersectionOf,  ?c) in Table 3.

* domain/range rules are missing. I guess we can simply import rules 
rdfs2 & rdfs3 from

  Since you took out if condition, we don't need rules ext1, ext2, ext3, 
or ext4 (from the same doc)

* For OWL-R FULL, the second rule (the one on 
owl:InverseFunctionalProperty) in Table2, can ?y be a literal?

* OWL-R FULL does allow the following, right?
  T(:GreenEagle,  rdf:type, :EndangeredSpecifies)
  T(:GreenEagle,  rdf:type, owl:Class)
  T(:GreenEagle,  rdfs:subClassOf,  :Eagle)

* OWL-R FULL, owl:sameAs rules in Table 1 can be applied to classes, 
properties, right?

* The fifth rule in Table 1, can p' be a blank node or literal? I assume 
the answer is no. So we may want to add a
   general restriction on all rules so that illegal  triples cannot be 

* An editorial suggestion. Can we name/number all those rules so that 
they can easily be referenced?

That is all for now,



Boris Motik wrote:
> Dear Zhe, Jim, Jeremy, Michael,
> The recent discussion on fragments prompted Bernardo and me to come up 
> with a new version of the fragments document [1] that
> includes a "rule fragment" (which we have called "OWL-R" pending 
> someone thinking of a better name). As you can see, the description
> of this fragment (finally!) includes a set of rules that axiomatizes 
> OWL Prime as we discussed.
> We would be very interested if you have any comments about it before 
> we circulate it to the Working Group (which we would like to do
> ASAP).
> Regards,
>     Bernardo & Boris
> [1] http://www.w3.org/2007/OWL/wiki/Fragments_Proposal
Received on Wednesday, 5 March 2008 17:13:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:42:03 UTC