RE: private review of Profiles, Section 4.3 (OWL 2 RL/RDF rules)

Hello Michael,

Thanks a lot for your detailed review! Please find my responses inline. Here is
the diff to the changes I made in response to your comments:

http://www.w3.org/2007/OWL/wiki/index.php?title=Profiles&diff=22290&oldid=22225

Regards,

	Boris

> -----Original Message-----
> From: public-owl-wg-request@w3.org [mailto:public-owl-wg-request@w3.org] On
> Behalf Of Michael Schneider
> Sent: 16 April 2009 21:40
> To: OWL 2
> Subject: private review of Profiles, Section 4.3 (OWL 2 RL/RDF rules)
> 
> Hi!
> 
> Here is a last minute review of the OWL 2 RL ruleset in Section 4.3 of the
> Profiles document.
> 
> Michael
> 
> * [editorial, missing explanation] Intro text, 2nd par: It's explained what
> the "propositional symbol 'false'" means in the tables. What's missing is an
> explanation of the symbol 'true', which appears several times as the premise
> of rules (e.g. in Table 5, rule "prp-ap").
> 

I agree that this was missing. However, rather than defining what true means,
I've removed true from the premises. It seems to me that people will be less
confused with this. I've also added the following sentence to the beginning of
the section:

The rules that have empty "if" parts should be understood as being always
applicable.

> * [editorial, typo(?)] Text preceding Table 4: "it defines the equality
> relation on resources owl:sameAs as being reflexive,...". Is there a
> grammatical error in this sentence ("on resources owl:sameAs")?
> 

I'm not sure whether this is strictly speaking incorrect; however, I've just
removed "on resources".

> * [editorial, possible confusion] The rule "eq-diff2" in Table 4 contains the
> triple "T(?zi owl:sameAs ?zj)" in the premise, and the third column contains
> the text_ "for each 1<=i<j<=n". There are two possible ways to understand
> this: (a) this table entry stands for several rules, and (b) it's one rule
> with several such triples on the LHS. I suppose (a) is meant, but this should
> be made clearer (originally, I thought it was (b), till I found that this rule
> would then be strange). Same for several other rules: prp-adp, cls-uni and
> cax-adc.
> 

I've added the following sentence before all the tables:

The rows of several tables specify rules that need to be instantiated for each
combination of indices given in the right-most column.

> * [technical, change request] In another mail I suggested to remove the typing
> triples of the two rules for negative property assertions, see
> <http://lists.w3.org/Archives/Public/public-owl-wg/2009Apr/0341.html>.
> 

In general, I thought that it would be best to keep all the semantics conditions
completely in sync with RDF mapping. But, as you rightly point out, this has not
been the case in OWL 1, so there is no need to stick to this principle now
either. Consequently, I've changed the rule set as you've suggested.

> * [technical, missing(?) rules] I wonder why there are no rules for
> owl:hasSelf, which mirror the two rules for owl:hasValue. Have these been
> forgotton? They would be:
> 
>   cls-hs1:
>   IF:
>       T(?x, owl:hasSelf, "true"^^xsd:boolean)
>       T(?x, owl:onProperty, ?p)
>       T(?u, rdf:type, ?x)
>   THEN:
>       T(?u, ?p, ?u)
> 
>   cls-hs2:
>   IF:
>       T(?x, owl:hasSelf, "true"^^xsd:boolean)
>       T(?x, owl:onProperty, ?p)
>       T(?u, ?p, ?u)
>   THEN:
>      T(?u, rdf:type, ?x)
> 

Self-restrictions were eliminated from the profile at the request of Zhe. I
don't feel empowered to just change this right now.

> * [technical, change request] All the cardinality restrictions in Table 6
> contain literals of the form "n"^^xsd:nonNegativeInteger. In believe this asks
> for trouble, since presumably only a small fraction of all OWL/RDF documents
> will use xsd:nonNegativeInteger for building cardinality restrictions. In
> comparison, the reverse RDF Mapping uses a function "NN_INT(n)" as a
> placeholder for all kinds of non negative integer definitions. I suggest to
> use this function in RL, too. This would be ok for the relationship to the
> RDF-Based Semantics, which isn't restricted to a single number datatype,
> either, but only talks about the /value space/ of xsd:nonNegativeInteger.
> 

I see that this might be misunderstood; however, I don't believe that we have a
problem formally speaking. We say that the rules are a bunch of universally
quantified clauses, right? Now it all depends on how you interpret the literals
in there. I believe these should be interpreted *semantically*. That is,
"0"^^xsd:nonNegativeInteger should be interpreted as the integer zero, just like
"0"^^xsd:integer. Thus, if your data contains the latter but the rule contains
the former, the rule still applies because the two values are semantically
equivalent.

I haven't changed anything to this end.

> * [technical, missing(?) rules] Where are the exact-cardinality variants of
> all the max-cardinality restrictions (including max-QCRs)? This looks like a
> significant omission to me that may lead to problems in practice.
> 

The rule set contains exactly those rules that correspond to the grammar of OWL
2 RL (the DL view of the profile). The grammar does not allow for exact
cardinality restrictions, and so there are no rules for these either.

Note also that you can't really have exact cardinality other than 0, as this
would involve existential quantification (which we don't want to have in OWL 2
RL). Thus, it is not clear to me that allowing exact cardinality 0 (in both the
DL and the RDF view of the profile) would be all that useful.

> * [editorial, incoherent format] The rule "cls-oo" in Table 6 has as its
> consequent: "T(?yi, rdf:type, ?c)", and the third column says "for each
> 1<=i<=n". Make it coherent with the other rules with more than one result
> triple (eg. cls-int2), by replacing this single template triple by "T(?y1,
> rdf:type, ?c) T(?y2, rdf:type, ?c) ... T(?yn, rdf:type, ?c)"; and drop the
> "for each ..." text in the third column (this will also avoid confusion with
> other occurrences of "for each" entries in the third column, which have a
> different meaning than this one).
> 

Fair enough!

> * [change, redundancy] In Table 9, the rule "scm-cls" has several result
> triples, including "T(?c, owl:equivalentClass, ?c)". I suggest to drop this
> equivalence triple, since it is redundant, due to the rdfs:subClassOf triple
> and rule scm-eqc2. I know, we don't claim redundancy-freeness for the ruleset,
> but IMHO this one is almost provocatively redundant. ;-) Analog for the rules
> scm-op and scm-dp.
> 

The rule set has not been designed to be minimal. This is consistent with the
desire to provide a clean specification of the semantics, as well as some
guidance to the implementors. In fact, coming up with a minimal set of rules is
an interesting problem that should be considered in more detail. I can imagine
that there are several minimal rule sets, so selecting the best one might ne
nontrivial.

Consequently, I wouldn't change anything here in order to make the semantics
consequences of these rules clear. I leave it to the implementors to eliminate
redundancy as they see fit.

> --
> Dipl.-Inform. Michael Schneider
> Research Scientist, Dept. Information Process Engineering (IPE)
> Tel  : +49-721-9654-726
> Fax  : +49-721-9654-727
> Email: michael.schneider@fzi.de
> WWW  : http://www.fzi.de/michael.schneider
> =======================================================================
> 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, RP Karlsruhe
> Vorstand: Prof. Dr.-Ing. Rüdiger Dillmann, Dipl. Wi.-Ing. Michael Flor,
> Prof. Dr. Dr. h.c. Wolffried Stucky, Prof. Dr. Rudi Studer
> Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
> =======================================================================
>

Received on Friday, 17 April 2009 10:29:59 UTC