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

Re: Some Embedding necessary for RIF-Simple - Was Re: [TF-Ent] RIF Core Entailment section

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

I do not understand...

On 2010-3-12 21:10 , Chimezie Ogbuji wrote:
> So as I was taking another pass through the Simple RIF Core section, I
> noticed a problem that I will need to addressed.  In short, without some
> amount of 'embedding', RIF-Simple entailment will behave in a
> counter-intiuitive way if there is no correspondence between statements and
> frames, rdf:type and #.
> Consider the example below
> Scoping Graph
> -------------
> _:a rdf:type _:b
> <> rif:imports <emptyRules>

My understanding of the proposed semantics (by Axel) for rif:imports is
that this combination is transformed as follows:

1. Starting point
G: _:a rdf:type _:b .
   <> rif:imports <R> .
R: empty

2. Apply the semantics
G': _:a rdf:type _:b
R': Import(G, <http://www.w3.org/2007/rif-import-profile#Simple>)

(whether the <> rif:imports <R> is removed from G is still an open
question but does not seem to influence this issue)

3. From the RIF point of view, that is equivalent to:

R'' : _a # _b .

(using RIF's unique id-s which look very much like skolemization to me).

Which means that...

> Where emptyRules.rif is an empty document
> A SPARQL query such as SELECT ?THING ?CLASS { ?THING a ?CLASS } will return
> nothing!  In fact (as I understand it - I'm hoping someone else can confirm
> this) *all* queries will return nothing with the current language:
> "A solution mapping μ is a?possible solution [...] such that sk(P(BGP)) are
> well-formed RDF triples that are RIF-Simple entailed by the?RIF-RDF
> combination formed from sk(SG) and the?strongly safe?RIF core documents
> referenced from SG via the rif:imports predicate"
> As a result of condition 7 for common-RIF-RDF-interpretations <I',I> (where
> I' is a RIF-BLD semantic structure and I is a simple interpretation), the
> scoping graph is not satisfiable by such an I in a
> common-RDF-RDF-interpretation.  In particular IEXT(IS(rdf:type)) is *not*
> equal to the set of all pairs (a,?b) in?Dind?×?Dind (since the latter is an
> empty set).  

This is not an empty set, see above...

Do I severely miss something here?

Actually, if what you say was true, then I think there is a problem in
the RIF-RDF document. That has to be signalled to the RIF group


>             This condition, along with others requires this correspondence
> in order for an common RIF-RDF-interpretation to be valid.
> As a result, the combination will not entail anything and since the answers
> are defined with respect to RIF-Simple entailment, there will be no answers.
> The mechanisms in section 9.1.3 Embedding Simple Entailment in the
> compatibility document provide some tools to address the problem and I'm
> inclined to re-use them rather than simply refer to that informative section
> since the goal of embedding (to demonstrate how a RIF-compliant translator
> without native support for RDF can process RIF-RDF combinations) seems very
> different from what we are doing here as I understand it.
> My suggested solution is to form the combination differently:
> SG' = sk(SG)
> <merge(R,?R_{simple-core},tr(SG')), SG'>
> Where merge is the same function that is defined towards the end of 9 of the
> appendix and tr is the same injective function described in the appendix as
> well.  The difference between how tr is used in 9.1.3 and how it is used
> here is that nothing will need to be done with BNodes (since they will be
> replaced with new IRIs by the time the function is evaluated over SG').
> R is the same strongly, safe RIF Core document referenced from SG.
> R_{simple-core} is essentially the same ruleset as R_{Simple} (from 9.1.3)
> except for the exclusion of the rule involving ## (which is not allowed in
> the RIF Core syntax anyways).  So it is:
> Forall??x??y (?x[rdf:type ->??y]?:-??x #??y)
> Forall??x??y (?x #??y?:-??x[rdf:type ->??y])
> This effectively ensures that condition 7 is met.  So, for our example,
> merge(R,?R_{simple-core},tr(sk(SG))) becomes
> Forall??x??y (?x[rdf:type ->??y]?:-??x #??y)
> Forall??x??y (?x #??y?:-??x[rdf:type ->??y])
> <skolem_iri_1>[rdf:type -> <skolem_iri_2>
> <skolem_iri_1> # <skolem_iri_2>
> And without the issue of the conditions regarding the correspondence between
> frames and statements, the subgraph characteristics of simple entailment
> hold, sk(P({?THING rdf:type ?CLASS})) *will* be RIF-simple entailed, and
> answers would be provided.
> Any thoughts before I try to incorporate this?
> -- Chime
> ===================================
> P Please consider the environment before printing this e-mail
> Cleveland Clinic is ranked one of the top hospitals
> in America by U.S.News & World Report (2009).  
> Visit us online at http://www.clevelandclinic.org for
> a complete listing of our services, staff and
> locations.
> Confidentiality Note:  This message is intended for use
> only by the individual or entity to which it is addressed
> and may contain information that is privileged,
> confidential, and exempt from disclosure under applicable
> law.  If the reader of this message is not the intended
> recipient or the employee or agent responsible for
> delivering the message to the intended recipient, you are
> hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited.  If
> you have received this communication in error,  please
> contact the sender immediately and destroy the material in
> its entirety, whether electronic or hard copy.  Thank you.


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 Saturday, 13 March 2010 09:21:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:59 UTC