Re: OWLRL (safeness)

Hi Sandro,

> I just read much of your OWL-RL document [1].  It's very nicely written
> and thorough.

Thank you.

> I did manage to find three typos:
> 
>> Note gain that the last universal fact is not executable by a
>        ^?   "again" ?   if so, the referent is unclear to me
> 
>> The following table summarizes the which of the OWL 2 RL datatypes
>                                  ^^^
>> which only differ by virtual of the ABox assertions.
>                             ^^ "virtue"

Fixed.

> A general editorial note: I don't know how much automation you used in
> generating this document, but if it's not too much trouble, it'd be nice
> to keep the rule names in their translations (as links into OWL Profiles
> like [2] when it's HTML).

Agreed. Stuart, who has tried to use these rules for an OWL 2 RL 
implementation pointed out the same thing.

When I did the translation work back in October the rules in the OWL 
profiles document didn't have names.

My process was only partially automated but could be improved.  If we do 
a new version of the document I'll fix this.

> Looking at the Haskey rule, I think we can make it safe by
> moving/repeating the type-check on ?c down into _sameKey, like this:
> 
>   Forall ?x ?y ?c ?u ?c (
>     ?x[owl:sameAs->?y] :- And (
>       ?c[owl:hasKey->?u]  ?x[rdf:type->?c]  ?y[rdf:type->?c]
>       _sameKey(?c ?u ?x ?y) ))
> 
>   Forall ?u ?x ?y (
>     _sameKey(?c ?u ?x ?y) :- And (
>       ?u[rdf:first->?key rdf:rest->?tl]
>       ?x[?key->?v] ?y[?key->?v]
>       _sameKey(?c ?tl ?x ?y) ))
> 
>   Forall ?x ?y (
>     _sameKey(?c rdf:nil ?x ?y) :- And (
>        ?x[rdf:type->?c]  ?y[rdf:type->?c]
>     )

Yes, thanks, I should have spotted that.

> The document doesn't say that 4.3.2 and 4.3.4 also violate safeness
> (maybe that's the "again" referent?), but it looks to me like they do.
> I think we can make safe versions, though, using the same kind of trick,
> where we bring some tests down into the universally-quantified recursion
> base case. 

Agreed.

>  If that works, does that obviate the need for the second
> appendix/translation approach?

Strictly, yes.

Part of my mind set was that the RIF OWL 2 RL ruleset would not be of 
usable performance in practice and that some practical implementations 
would use a translation approach, so defining that might lower the 
implementation barrier. However, you are right that we could produce a 
static rule set which is at least executable and could drop the 
translation algorithm approach. That would significantly simplify the 
document and would get round one problem with the translation algorithm 
that Stuart identified.

Note. There is a basic error in the datatype rules for the fixed rule 
set which is not present in the translation algorithm. The datatypes 
rules should be of the form:

  Forall ?l1 ?l2 ( ?l1[owl:sameAs->l2] ) :-
               ?s1[?p1->?l1], ?s2[?p2->?l2],
               External(pred:isLiteralEqual(?l1 ?l2)) )

In the translation algorithm the two ungrounded triple matches are 
handled in the translation step, in the static rule set they are omitted 
by accident. Again if we update the document I will fix that.

I say "if" we update the document because assuming Jos replaces his 
OWL-DLP embedding by an OWL 2 RL embedding then we might decide that the 
this document is redundant.

Dave
-- 
Hewlett-Packard Limited
Registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Thursday, 11 December 2008 14:15:30 UTC