W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2005

Re: Issue #rdfSemantics / #owlDisjunction

From: <jos.deroo@agfa.com>
Date: Fri, 14 Oct 2005 11:25:18 +0200
To: tessaris@inf.unibz.it
Cc: andy.seaborne@hp.com, RDF Data Access Working Group <public-rdf-dawg@w3.org>, public-rdf-dawg-request@w3.org
Message-ID: <OF44B56B98.90217C71-ONC125709A.0030EA9B-C125709A.0033AE05@agfa.com>

Just a quick ping w.r.t. CONSTRUCT which we implemented in april 2004
using a backward chainer which is given the RDF dataset plus an N3 rule
{ WHERE-triples } => { queryid q:select { CONSTRUCT-triples } } .
and then queried with 
queryid q:select { CONSTRUCT-triples }
and we return all those answers as instantiated CONSTRUCT-triples
(the wrapping with q:select is done to avoid collision with
CONSTRUCT-triples that are in the RDF dataset).

For your test case given { _:a :test :here, :there }

CONSTRUCT { ?x :looks ?y . _:a :connects ?x } WHERE { ?x :test ?y }

euler returns
_:a_0_ :looks :here. 
_:a_0_ :looks :there. 
_:a_1_ :connects _:a_0_. 


-- 
Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/




Sergio Tessaris <tessaris@inf.unibz.it>
10/10/2005 15:39

 
        To:     Jos De_Roo/AMDUS/MOR/Agfa-NV/BE/BAYER@AGFA
        cc:     andy.seaborne@hp.com, RDF Data Access Working Group 
<public-rdf-dawg@w3.org>, public-rdf-dawg-request@w3.org
        Subject:        Re: Issue #rdfSemantics / #owlDisjunction


I'm not saying that the implementations around don't do the sensible 
thing. I just pointed out that the definition as spelled out in rq23 
doesn't match the right intuition. I believe that the fact that the 
implementations don't comply with it is supporting my claim.

The semantic definition in rq23 is the following:

"""
Definition: CONSTRUCT

Let Q = (GP, DS, SM, CONSTRUCT T) where

     * GP is a graph pattern
     * DS is an RDF Dataset
     * SM is a set of solution modifiers
     * T is a set of triple patterns

then, if QS is the set of solutions formed by matching dataset DS 
with graph pattern GP, then write SM(QS) = { Si | i = 1,2 ... n }.

The CONSTRUCT result is the RDF graph formed by the RDF merge of each 
Si(T).
"""

In my example, the set of solution would be the following (let me use 
the same bnode name):
{
   { _:a :looks :here  } # S1(T) from first tuple
   { _:a :looks :there } # S2(T) from second tuple
}

Now, if you take the *RDF merge of each Si(T)* you obtain:

   { _:a :looks :here . _:a1 :looks :there }

by definition. Within this example, you'd obtain the expected answer 
by unioning the two graphs:

   { _:a :looks :here . _:a :looks :there }

However, plain union would break bnodes in templates. Consider a 
template:

T = { ?x :looks ?y . _:a :connects ?x }

with union it'll result in

   { _:a :looks :here . _:a :connects _:a . _:a :looks :there }

which is rather bizarre. From the textual explanation in rq23 I 
gather it should return something like (up to bnode renaming):

   { _:a1 :looks :here . _:a2 :connects _:a1 .
     _:a1 :looks :there . _:a3 :connects _:a1 }

Am I right?

I'm not sure about the proper semantic definition, it'd look 
something like doing the RDF merge of the templates (with the 
variables) and then substitute variables with the assignments. But, 
this isn't a proper definition, since once you generate the union 
graph then you don't know how to replace the variables any more. The 
whole procedure seems like "do the RDF merge the templates, but 
consider bnodes from the solutions as constant" (rhyme to 
skolemisation, isn't it ;).

BTW how do you handle the CONSTRUCT in the implementations? We can 
get a clue on its proper definition.

--sergio
BTW Andy, the "I" in the message posted on the web by Bijan it's 
bound to me.

On Oct 8, 2005, at 12:45 AM, jos.deroo@agfa.com wrote:

>
> [updated ARQ and have similar result]
>
> [...]
>
>>> The definition is plain wrong, since you don't want to "RDF merge"
>>>
> bnodes
>
>>> coming from the graph, just the ones in the template:
>>>
>>>      CONSTRUCT { ?x :looks ?y } with answer set [?x/_:a,?y/:here],
>>> [?x/_:a,?y/:there]
>>>
>>> results in the graph
>>>
>>>      _:a :looks :here . _:a1 :looks :there .
>>>
>>> where the coreference on _:a is lost.
>>>
>>>
>>
>> What you outline looks right -
>>
>
> Not when I run
> cwm test.n3 -think -sparql=test.rq
>
> where test.n3 is
> @prefix : <test#> .
> _:a :test :here.
> _:a :test :there.
>
> and test.rq is
> PREFIX : <test#>
> CONSTRUCT { ?x :looks ?y } WHERE { ?x :test ?y }
>
> Cwm gives
>       [      :looks :here,
>                     :there ].
>
> Also when I run
> euler test.n3 -nope -think -query test.rq
>
> euler gives
> _:a_0_ :looks :here.
> _:a_0_ :looks :there.
>
>
> Also when running
> arq -data test.n3 -query test.rq
>
> ARQ gives
> # ======== CONSTRUCT results
> @prefix :        <file:///C:/temp/test#> .
>
> []    :looks        :there ;
>       :looks        :here .
> # ========
>
> -- 
> Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/
Received on Friday, 14 October 2005 09:26:58 GMT

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