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: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
Date: Mon, 15 Mar 2010 16:08:49 +0100
Message-ID: <492f2b0b1003150808nd2b3f51ldfbd0a4c77fa197a@mail.gmail.com>
To: Jos de Bruijn <jos.debruijn@gmail.com>
Cc: Ivan Herman <ivan@w3.org>, 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>
Sorry, I am a bit late catching up on this. As I understand it, we
don't have a problem any more right? What Jos says makes sense to me
and I hope that is how RIF works. Otherwise it would be really
counterintuitive.
Birte


On 15 March 2010 08:20, Jos de Bruijn <jos.debruijn@gmail.com> wrote:
> Ivan,
>
> I can confirm that your basic intuition about the combinations is correct.
> Chime may not have fully understood the RIF model theory. RIF does not have
> a minimal model semantics; it has a standard first-order style model theory.
> Let's consider the empty RIF document R. Since it is empty, there are no
> constraints on the models, and so every RIF interpretation is a model of R,
> in particular also every interpretation that satisfies the formula :a#:b.
> If we now look at combinations of R with the graph S={:a a :b. } we have
> that only RIF structures I that satisfy :a#:b can be part of common models.
> Certainly, such structures I satisfy R, and so the combination is
> satisfiable.
>
> Cheers, Jos
>
> -- sent from my PDA
>
> On 15 Mar 2010, at 06:25, Ivan Herman <ivan@w3.org> wrote:
>
>>
>>
>> On 2010-3-15 01:48 , Chimezie Ogbuji wrote:
>>>
>>> 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).
>>>
>>
>> This is the crucial point and I think you did the best thing by asking
>> Jos on this, and there might indeed be a terminological/editorial issue
>> in the RIF-RDF document (and it is the right time to signal this if
>> there is!).
>>
>> My mental model of the RIF-RDF combination has always been that when a
>> RIF rule set 'imports' an RDF graph, than this means as if all triples
>> were effectively defined in terms as RIF frames. Ie, the import will
>> definitely create the following:
>>
>> _a[rdf:type->_b]
>>
>> furthermore, the definition of the common interpretation with the 10
>> rules puts an extra set of correspondence on how to 'see' the RDF
>> triples through a RIF glass. Ie, in my mind, that means that the RIF
>> entailment part operates on the single rule
>>
>> _a # _b .
>>
>> If true, this means that your issue below becomes moot. If false, than I
>> am not sure any more how this common thing works...
>>
>> So Jos, you are the source of all wisdom!
>>
>> Ivan
>>
>>
>>
>>> 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.
>>>
>>
>> --
>>
>> 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 Monday, 15 March 2010 15:17:26 GMT

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