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

Anyway, I was in particular referring to
     http://www.eswc2007.org/pdf/eswc07-munoz.pdf
which provably is complete for a subset of RDFS and the one rule I refer 
to is not expressible in RIF Core, as far as I can see. Anyway, if you 
can convince me that there is a complete set of rules expressible in RIF 
core which covers bnode renaming, fine. I will check [1] again.

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

Fair enough, this is also what is done in several existing approaches.


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

well, a) this is why I asked today what you meant by N3-like.
Do you count SPARQL's CONSTRUCTs into N3 like rules? If not what does 
count as N3 like?
b) I did not say that these rules USE function symbols, but in order to 
do Skolemization properly you DO NEED function symbols (or special 
built-ins which "emulate" a skolem function by generating something like 
a "parametrized" new ID)


best,
Axel

>>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 18:56:53 UTC