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 Tuesday, 11 October 2005 02:36:26 UTC