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

I forgot the reference:

[1] http://www.debruijn.net/publications/frames-rdf-workshop.pdf

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