W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > January to March 2010

Re: [TF-Ent] RIF Core Entailment section

From: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
Date: Wed, 10 Mar 2010 14:35:39 +0000
Message-ID: <492f2b0b1003100635h6fe28e68ie9b1e8f0b097d536@mail.gmail.com>
To: Ivan Herman <ivan@w3.org>
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>
Resent and extended, because I just clicked Reply instead of Reply All...
> 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]

If that's the way to write it in RIF, then I meant:
?x[rdf:type->ex:b] -: ?x[rdf:type->ex:c]

In words, I want to have a rule such that if something (x) is of type
ex:b, then it is also of type ex:c.

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

Yes, that's what I mean. As I understand it SG or sk(SG) is the graph
you get from the triples and it knows nothing about the rule set. We
would have to specify a vocabulary that is the union of the vocabulary
of SG/sk(SG) and the vocabulary of the import closure of the
referenced rule sets. That's not difficult to do, we should just add
it.

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

Yes, but even without it is an easy to solve problem.

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

Here I noticed that my initial reply to Ivan only just works for OWL
Direct Semnatics. For Direct Semantics, all that is defined in the OWL
spec (Sec. 3 of Mapping from RDF graphs to OWL,
http://www.w3.org/TR/owl2-mapping-to-rdf/#Mapping_from_RDF_Graphs_to_the_Structural_Specification),
so O(G) refers to the OWL ontology obtained from the graph G and that
is precisely defined in the OWL spec in exactly the way I need it,
i.e., will give me the axiom closure also over all imports. The OWL
spec is really doing most of the work already :-)

For RDF-Based, I quickly looked and didn't yet see a suitable
definition of a graph incl. the imports closure. I think I saw that
somewhere, so I'll keep looking, but it might be the case that we have
to either explicitly refer to some graph containing the imports
closure and not just to SG or we even need to define that. I'll check
that.

Birte

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



-- 
Dr. Birte Glimm, Room 306
Computing Laboratory
Parks Road
Oxford
OX1 3QD
United Kingdom
+44 (0)1865 283529
Received on Wednesday, 10 March 2010 14:36:15 GMT

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