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

>> 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 realize now that you meant the entailment rules as they were written
in the specification.  I do not propose to embed these entailment rules.

I propose a direct embedding of the normative model theoretic semantics
of RDF(S) using logical rules.

> 
> 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.

What we cover is well defined.  We cover simple entailment, RDF
entailment, and RDFS entailment.  See [1].

> 
> 
> 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. 

I would rather assume that bnodes are not shared between the body and
the head in these N3-like  rule languages.

> 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.

as far as I understood, N3-like rule languages do not use function
symbols [we had a discussion about this issue a couple of weeks ago in
the telephone conference]; the semantics of rigid bnodes requires some
more investigation

Best, Jos
> 
> 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
> 
> 

-- 
Please note my new email address:
                         debruijn@inf.unibz.it

Jos de Bruijn,        http://www.debruijn.net/
----------------------------------------------
In heaven all the interesting people are
missing.
  - Friedrich Nietzsche