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: Chimezie Ogbuji <ogbujic@ccf.org>
Date: Sun, 14 Mar 2010 20:48:26 -0400
To: "Ivan Herman" <ivan@w3.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>, "Jos de Bruijn" <debruijn@inf.unibz.it>
Message-ID: <C7C2FC1A.1055C%ogbujic@ccf.org>
Ivan,

On 3/13/10 5:19 AM, "Ivan Herman" <ivan@w3.org> wrote:
> Chime,
> I do not understand...

Okay, I'll see if I can help with that.  I've sent Jos a separate email
about this as well.
 
> On 2010-3-12 21:10 , Chimezie Ogbuji wrote:
..snip.. 
> 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)

Okay, but independent of how rif:imports is interpreted (for a lack of a
better word), the SG still only has one triple relevant to RIF-simple
entailment, right?:

_:a rdf:type _:b
 
> 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).

Okay, this is the point where the issue comes in.  I'm not sure what you
mean by 'from the RIF point of view', because - as I understand it -
entailment does not involve any RIF interpretation of the RDF graph (which
is the reason why we need to embed the triples from the scoping graph into
the RIF document in order to interpret them using RIF semantics).

So, at this point (i.e., before 3 above) we form the following combination:

<Rempty,G''>

Where G'' is sk(G'):

<unique-URI-1> rdf:type <unique-URI-2> (lets refer to this triple as t1)

The problem is that there is no (simple) interpretation for G'' in which
IEXT(IS(rdf:type)) is empty.  Since, G'' is ground, we know I(t1) is true
and that IEXT(IS(rdf:type)) must not be empty (from what tr/rdf-mt says
about how simple entailment interprets ground RDF graphs in 1.4).
    
Since Rempty is empty, I_truth(I_isa(a,b))= false, and by the wording of
condition 7, IEXT(IS(rdf:type)) must be empty.  However, above we see that
it can't be empty.
 
> 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

I'm not sure if this necessarily indicates a problem with the RIF-RDF
document (hopefully Jos can speak on this) but perhaps suggests that the
embeddings (or at least some of them: Simple and RDF for example) should be
made normative since implementations cannot practically implement RIF-RDF
entailment without them.  Or at least, a simple paragraph emphasizing the
counter-intuitive behavior of combinations where there is not already a
correspondence between triples, frames, and their terms.

-- 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.
Received on Monday, 15 March 2010 00:49:11 GMT

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