Re: Comments: OWL 2 RL in RIF FPWD

Michael Schneider wrote:
> Dear RIF WG!
> 
> I had a look into the "OWL 2 RL in RIF" FPWD and found a few issues. I will separate them into what I believe are technical errors, editorial errors and suggestions for enhancement. I have checked all reported issues against the latest version in the Wiki.

Thanks Michael.

While many of the original rules were mechanically generated the "list" 
and datatype rules were rather manual and modified several times to 
accomodate changes at both the RIF and OWL end. That seems to be where 
some of the errors crept in.

> * 4.3.1, translation for eq-diff3: contains the triple "?a[owl:members -> ?l]". This should be "?a[owl:distinctMembers -> ?l]" (both the first two translations refer to "owl:members" in the draft).

Fixed. It was correct in the template algorithm (the one we actually 
used for implementation).

> * 4.3.3, translation for prp-key: after "Forall" the variable "?c" is listed two times; the second occurrence should probably be removed.

Not harmful but fixed anyway.

> * 4.4.3, "Type membership", all translations: The built-in predicates named "pred:is-literal-DATATYPE" actually receive both the literal and the datatype as arguments in "OWL 2 RL in RIF", but according to §4.2 of RIF DTB they should only receive a single argument. Also, the variable "?ty" always occurs non-quantified in the translations. I believe that the translations need to be rewritten, such as (for xsd:integer):
> 
>      Forall ?s ?p ?lt ( ?lt[rdf:type->xsd:integer rdf:type->rdfs:Literal] 
>                       :- And( ?s[?p->?lt] External( pred:is-literal-integer( ?lt )) ))
> 
> Mind the changed triple "?lt[rdf:type->xsd:integer]"!

Argh. I'm surprised to have let those all through. There was originally 
just a few simple rules for type membership and type checking but when 
RIF dropped the generic type predicates those had to get replaced by the 
current horrible rule set. Looks like my regex munging failed.

Fixed.

> * 4.4.3, "Type checking", all translations: The "OWL 2 RL in RIF" document always uses the positive predicates "pred:is-literal-DATATYPE", but I think it should be the negative forms "pred:is-literal-not-DATATYPE" according to §4.3 of RIF DTB. Also, the negative forms should again only receive a single argument, not two. So I guess the correct form would be something like (for xsd:integer):
> 
>        Forall ?lt ( 
>          rif:error() :- And (
>            ?lt[rdf:type->xsd:integer] External(pred:is-literal-not-integer( ?lt )) ))
> 
> Mind the changed triple "?lt[rdf:type->xsd:integer]"!

Part of same problem as above, fixed.

> * 4.4.3, "Fixed vocabulary rules": The formula refers to the non-existing term "rdfs:text". I guess this should be "rdf:PlainLiteral"?

Fixed, no idea where that came from.

> LIST OF EDITORIAL ERRORS
> ========================
> 
> * 4.4.2, last paragraph: "... which include owl:sameAs ...". "owl:sameAs" should be rendered in typewriter font.

Fixed.

> LIST OF SUGGESTED ENHANCEMENTS
> ==============================
> 
> * Alignment of variable names between original OWL 2 RL rules and their translations: I suggest to reuse the variable names of the original rule set wherever possible. This is currently not always the case in the draft. For example, in 4.3.1 the translation of the rule eq-diff2 uses the name "?r" for what the original rule uses "?x", and the translation uses itself "?x", but for something different. And the translation of eq-diff3 uses again a different name "?a" instead of "?r" before (and "?x" in the original rule). This is confusing and makes it unnecessarily hard to compare the original rules with the translations.

Mostly the use of variables does correspond since the translation was 
mechanical. The "list" rules are the main exception where manual 
intervention was required, not least to cope with the hidden variables 
that are implicit in the notation from OWL Profiles. In manually writing 
those rules I found it easier to use semi-mnemonic names (?l for the 
list etc). However, since you say this caused you a problem then I have 
changed those particular cases.

> * 4.3.1, final note starting with "Note: it might be tempting to refactor ...". I suggest to elaborate on this. At least to me this note is completely unclear.

Left for now. If others also find it confusing then I'll delete it, it's 
a very minor point.

Dave

Received on Sunday, 15 November 2009 21:52:20 UTC