Re: [Arch] ACTION-259 Start OWL/RDF compatibility section of Arch document

Jos de Bruijn wrote:
> Done. See: http://www.w3.org/2005/rules/wg/wiki/Arch/RDF

I pick up the discussion we had on IRC/in the teleconf today
on Jos' RDF proposal and would like to clarify /raise some issues here:

1) First, the "problem" was that not all RDF(S) entailment rules
can be encoded in RIF.

I meant especially, that the rule

   G
  ---
   G'

    where a Graph G which is obtained
    from a graph G' by a bnode-renaiming

is not expressible as a RIF Core rule.
Jos returned that this rule is not necessary, because
e.g. my example,  ie. querying for

    _:b p o.

on graph
    _:a p o.

would be expressibly by the query

   exists ?b (?b p o)

ie. treating the bnode in the query as a variable. This is probably 
possible for many use cases, but, I would be cautious to say ALL use 
cases, so I'd prefer that we say explicitly what of the RDFS semantics 
we cover, if we add RDFS as an "implicit" rules set.


2) Then in the current discussion on bnodes in heads (I more or less 
agree with the proposed treatment of bnodes in bodies), jos writes
  the following :

</snip>
Using real blank nodes in the head of a rule poses problems, since 
existentially quantified variables are not allowed in the head of a rule 
in any rules language.

However, most N3-like rules languages do not allow blank nodes in the 
head, but rather have some kind of notion like "rigid bnode". Such a 
rigid bnode can be encoded using a new unique constant symbol, which is 
local to the rule set, i.e. combination of the rule set with another 
rule set, as well as entailment checking, requires renaming of all local 
constants. However, in this case there are similar round tripping 
problems as with real bnodes in the body of a rule.
</snip>

I am not sure what is meant by "real bnode" here, but I'd assume a bnode 
only appearing in the head but not in the body. A "new unique constant 
symbol local to the rule set" is probably not enough, but you might want 
a "real" Skolem function here:

   e.g.

     (_:a p ?x .) :- (?x q  ?y .)


  should probably be rather:

     ( sk_a(?x) p ?x .) :- (?x q  o .)

  than

     ( new_constant_for_bnode_a p ?x .) :- (?x q  o .)

  since the former would create a new skolem function for any
  instance of ?x whereas the latter would only create 1 new constant
  for all instances of ?x which causes trouble in the
  general case:

  e.g. when I take a graph

     s1 q o1.
     s2 q o2.

  plus the rule above and ask a query

   \exists ?y,?x,?z  (?y p ?x) AND (?y p ?z) AND  (?x q o1) AND (?x q o2)

  I'd get a 'yes' for the latter translation which I do not necessarily
  want. At least, it would not be compatible with the treatment of bnodes
  in the heads of CONSTRUCTS in SPARQL (I am not sure about N3, since the
  semantics of N3 is not really formally specified, AFAIK)

  This is all basic logics of course, apologies, but ... just to
  exemplify.

3) Also, I assume that the proposal does not treat non-real bnodes yet, 
ie bnodes appearing in the body AND in the head is not yet treated 
explicitly in this proposal. There are two ways of treating such 
non-real bnodes, take a rule

      (_:a p o .) :- (_a: q  o .)

  a) Firstly, you could treat those bNodes in the head as real Bnodes,
     ie. those in the body as a variable, and those in the head using
     a skolem-function,

     the example would therefore yield something like:

     (sk_a(?a) p o .) :- (?a q  o .)

b) Secondly, you could treat those non-real bnodes just as a variable
    in both cases (head and body)

     (?a p o .) :- (?a q  o .)

Note that SPARQL avoids this issue which could theoretically also arise 
with CONSTRUCTs there, by stating that
"The same blank node label cannot be used in two different basic graph 
patterns in the same query".


just my 3 cents,
axel


-- 
Dr. Axel Polleres
email: axel@polleres.net  url: http://www.polleres.net/

Received on Tuesday, 3 July 2007 17:13:59 UTC