# Re: [TF-Ent] RIF Core Entailment section

From: Ivan Herman <ivan@w3.org>
Date: Wed, 10 Mar 2010 13:52:57 +0100
Message-ID: <4B979629.3010806@w3.org>
To: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
CC: Chimezie Ogbuji <ogbujic@ccf.org>, SPARQL Working Group WG <public-rdf-dawg@w3.org>, Axel Polleres <axel.polleres@deri.org>, Sandro Hawke <sandro@w3.org>


On 2010-3-10 12:52 , Birte Glimm wrote:
> see below
>
> On 10 March 2010 10:28, Ivan Herman <ivan@w3.org> wrote:
>>
>> On 2010-3-9 16:54 , Chimezie Ogbuji wrote:
>
> [snip]
>
>>> As long as sk(SG) is finite, any RIF-RDF-entailed graph would also be finite
>>> (since the safety restrictions ensure the Herbrand model is finite by
>>> essentially ensuring no 'new' constants are introduced).  So the finite
>>> restriction would only be relevant for the infinite axiomatic triples, and
>>> Birte's recent modifications to C2 address this:
>>>
>>> (C2) For each variable x in V(BGP), sk( \$B&L (B(x)) occurs in sk(SG) or in
>>> rdfV-Minus.
>>>
>> This is necessary only if we use RIF-RDF-RDF and RIF-RDF-RDFS (and OWL).
>> In the case of RIF-RDF-Simple the issue does not arise, does it?
>
> Simple entailment requires: "μ is a solution for BGP from G when there
> is a pattern instance mapping P such that ***P(BGP) is a subgraph of
> G*** and μ is the restriction of P to the query variables in BGP."
>
> The fact that the instantiated BGP is a sub-graph of G (SG)
> corresponds to what we do with the Skolemization and otherwise also
> simple entailment would not guarantee finite answers since in the
> presence of blank nodes in the answer I can always create another
> answer by just renaming the bnode and I get something that is still
> simply entailed according to the definition of simple entailment.
> Skolemisation is just better able to capture that we in fact work on
> extended graphs (containing also inferred triples) in non-simple
> entailment. Nevertheless, the restriction as for simple entailment
> would not really work for RIF since you don't want to exclude the
> entailed triples, e.g., if we have SG:
> ex:a a ex:b .
> rif-rdf:usesRuleset ex:rules.rif .
> with ex:rules.rif:
> ex:b(x) -> ex:c(x)

Just to be on the safe side, I presume you meant

?x[rdf:type->c] -: ?x[rdf:type->d]

> and query:
> SELECT ?x WHERE { ?x a ex:c }
> then I would expect to get (even with RIF-RDF-Simple)
> ?x/ex:a
> although the instantiated BGP ex:a a ex:c does not occur in G/SG.
> Condition C2 might allow that, but it might also need rephrasing
> because it should also refer to the terms used in the (imported) rule
> set too I guess, e.g.,
> (C2) For each variable x in V(BGP), sk(\mu(x)) occurs in sk(SG) or in
> rdfV-Minus.
> should probably refer to sk(SG) \cup terms from import closure of the
> referenced RIF rule sets. Otherwise I would not get an answer for the
> example above because ex:c only occurs in the rule set.

Ah! I think the issue that backfires here is that the rule set does not
have an RDF representation. In other words, sk(SG) cannot refer to the
symbols in general, but we have to list the RIF import closure
explicitly. I think that is correct

(Unless we have an RDF representation of rules and then we have all of
our problems solved...)

But... how do we handle that with OWL? Isn't it a similar problem? If I
refer to an ontology that does an import, don't we have to say that the
sk(SG) is to be considered as being defined on the import closure? I
tried to find it in the document and did not find, but maybe I just
missed it...

Ivan

> This could all be a misunderstanding due to my limited RIF knowledge,
> but I thought I better ask.
> Birte
>

--

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF   : http://www.ivan-herman.net/foaf.rdf
vCard  : http://www.ivan-herman.net/HermanIvan.vcf


Received on Wednesday, 10 March 2010 12:52:32 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:41 GMT