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

RE: OWL 2 RL unification proposal: My comments

From: Boris Motik <boris.motik@comlab.ox.ac.uk>
Date: Wed, 3 Sep 2008 17:39:28 +0100
To: "'Michael Schneider'" <schneid@fzi.de>, "'Ian Horrocks'" <ian.horrocks@comlab.ox.ac.uk>, <public-owl-wg@w3.org>
Message-ID: <003501c90de3$a2134940$cb11a8c0@wolf>

Hello,

> -----Original Message-----
> From: Michael Schneider [mailto:schneid@fzi.de]
> Sent: 03 September 2008 14:36
> To: Ian Horrocks; Boris Motik; public-owl-wg@w3.org
> Subject: OWL 2 RL unification proposal: My comments
> 
> Hi!
> 
> Just before the poll on ISSUE-131, I managed to read the proposal for a
> unified OWL 2 RL language in
> 
>   <http://www.w3.org/2007/OWL/wiki/Profiles#OWL_2_RL>
> 
> Just a few comments.
> 
> * 4.2.1 (Entities)
> 
> Just for my own curiosity: Why are certain datatypes such as
> xsd:negativeInteger or xsd:nonPositiveInteger disallowed, while e.g.
> xsd:nonNegativeInteger is supported (same section)?
> 

All profiles, OWL RL included, have a "single model property"; that is, each ontology can be translated into a Horn theory.
Datatypes introduce slight problems, though. In particular, a problem is with finite datatypes; for example, if you use xsd:boolean
somewhere, you implicitly get a disjunction "true" || "false".

Note that you can obtain finite data ranges in many ways, one of which is to intersect two infinite datatypes. For example, the
intersection of owl:realPlus and owl:real is finite (because it contains exactly the four special values). Thus, if we allowed for
both owl:realPlus and owl:real, by using one in the LHS and the other in the RHS you could obtain finite data ranges, which would be
bad.

The set of datatypes in all profiles has thus been selected such that

- all supported datatypes are infinite, and

- the intersection of the arbitrary set of supported datatypes is infinite as well.

Thus you ensure that, regardless how people actually use these datatypes, you always obtain infinite intersections, so you have the
"single model property".

> * 4.3. (Reasoning using Rules)
> 
>   """
>   The implications are given as
>   universally quantified first-order implications
>   """
> 
> Duplicate use of the term "implications". Should perhaps be
> 
>   The /rules/ are given as ...
> 

Thanks -- I've changed the document.

> * After Table 8:
> 
>   """
>   An OWL 2 RL/RDF implementation can
>   add these triples and entailment rules as necessary
>   """
> 
> Probably better is the use of RFC 2119 terminology:
> 
>   An OWL 2 RL/RDF implementation /MAY/ ...
> 
> * A non-editorial point, and a bit more controversial, I guess (related to
> ISSUE-116): Having a second sentence of this "MAY" form about additional
> axiomatic triples for the OWL vocabulary being used in the rules would make
> me happy. :)
> 
> It's pretty clear that, if the RDFS axiomatic triples don't hurt, then
> additional OWL axiomatic triples wouldn't hurt, either. And the Full
> semantics provides guidance, how these additional axiomatic triples would
> look like in each case. So no need to list all these triples explicitly in
> the profiles document. Just a pointer to the Full semantics, in particular
> tables 4.3 and 4.4, should be sufficient. People, who are really interested
> in those axiomatic triples would need to take the burden on them to
> translate the entries there into the triples (actually: ground rules without
> an antecedent), but that's not hard to achieve.
> 
> For example, the entry for owl:equivalentClass in table 4.4 is
> 
>   URI U = "owl:equivalentClass"
>   IS(U) in IP
>   IEXT(IS(U)) subset IC x IC
> 
> which can be translated into the following axiomatic triples
> 
>   owl:equivalentClass rdf:type rdf:Property
>   owl:equivalentClass rdfs:domain rdfs:Class  	// or owl:Class
>   owl:equivalentClass rdfs:range rdfs:Class
> 
> 

I've extended the existing sentence to refer to the axiomatic triples for the OWL vocabulary as well. Please let me know if you have
further comments about this.

Regards,

	Boris

> Cheers,
> Michael
> 
> --
> Dipl.-Inform. Michael Schneider
> FZI Forschungszentrum Informatik Karlsruhe
> Abtl. Information Process Engineering (IPE)
> Tel  : +49-721-9654-726
> Fax  : +49-721-9654-727
> Email: Michael.Schneider@fzi.de
> Web  : http://www.fzi.de/ipe/eng/mitarbeiter.php?id=555
> 
> FZI Forschungszentrum Informatik an der Universität Karlsruhe
> Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
> Tel.: +49-721-9654-0, Fax: +49-721-9654-959
> Stiftung des bürgerlichen Rechts
> Az: 14-0563.1 Regierungspräsidium Karlsruhe
> Vorstand: Rüdiger Dillmann, Michael Flor, Jivka Ovtcharova, Rudi Studer
> Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
Received on Wednesday, 3 September 2008 16:41:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 3 September 2008 16:41:11 GMT