Re: nested SOURCE graph-patterns

Alberto Reggiori wrote:
> 
> hi all,
> 
> while doing a walk-through the grammar in the current editor draft [1] 
> I found that we allow nested SOURCE patterns - these are two 
> productions relative to it:
> 
> [6]   SourceGraphPattern   ::=   'source' '*' PatternElement | 'source' 
> VarOrURI PatternElement
> [10]   PatternElement   ::=   TriplePattern | GroupGraphPattern | 
> SourceGraphPattern | OptionalGraphPattern | 'and'? Expression
> 
> which legally allow to write queries like (note the nesting of SOURCE)

Yes - the language is compositional via the production PatternElement.

> 
> PREFIX data: <http://example.org/foaf/>
> PREFIX foaf: <http://xmlns.com/foaf/0.1/>
> 
> SELECT ?mbox ?age ?ppd
> GRAPH  data:aliceFoaf data:bobFoaf
> GRAPH  data:peterPanFoaf #this is being nested
> WHERE
>    SOURCE data:aliceFoaf
>    {
>      ( ?alice foaf:mbox <mailto:alice@work.example> )
>      ( ?alice foaf:knows ?whom )
>      ( ?whom foaf:mbox ?mbox )
>      ( ?whom PersonalProfileDocument  ?ppd )
> 
>      # nested SOURCE
>      SOURCE data:peterPanFoaf
>       {
>        ( ?peter foaf:mbox <mailto:peter_pan@not-working.example> )
>        ( ?peter foaf:knows ?peter_whom )
>        ( ?peter_whom foaf:mbox ?mbox )
>        ( ?peter_whom PersonalProfileDocument  ?ppd )
>       }
>    }

Nesting of SOURCE (now "GRAPH" - I'll try to stick to the new keywords but I 
might slip into old ways) here does not mean a further restriction.  Nesting is 
not subquery - its writing a pattern.

GRAPH data:peterPanFoaf accesses the graph with URI  ...peterPanFoaf.  It does 
not mean peterPanFoaf within aliceFoaf (maybe nested datasets).  There is no 
scoping anywhere in rq23.  (I don't see the value in nested datasets when we 
have only just agreed on the flat paradigm.)

So the simple case of (applying the new s/SOURCE/GRAPH/ renaming):

GRAPH <x>
{
    ... P1 ...
    GRAPH <y>
    { P2
    }
    ... P3 ...
}

has the same results as:

GRAPH <x>
{
    ... P1 ...
}
GRAPH <y>
{ P2
}
GRAPH <x>
{
    ... P3 ...
}

I wouldn't expect application writers to do this but people write things to be 
clear and different people have different ideas of "clear" - we should not 
mandate a way of doing it.  There are lots of ways to write queries cryptically!

I much prefer a query language without lots of special cases.  That makes the 
description harder, gets people confused, and can makes some implementations 
harder especially where the implementation is attempting to be strict (it has to 
special case things).  Rewritng to the best form for a given implementation is 
best left to the implementation.  It will differ from implementation to 
implementation.

>    SOURCE ?ppd
>    {
>       ( ?w foaf:mbox ?mbox )
>       ( ?w foaf:age ?age )
>    }
> 
> Even if syntactically correct, it could make hard to the reader being 
> convinced that such a query makes sense in the real world - by trying 
> to follow the current editor's draft design it seems we have two nested 
> "trusted graphs" (??).
> 
> Anyway, I find nesting of SOURCEs useful at some stage, but hard to fit 
> in our design - also the GRAPH/LOAD design discussing at the 
> face-to-face is less clearer when nesting is faced....
> 
> Does this make sense to you ?

Yes - thanks for pointing it out.

> 
> Is the design meant to cover this part?

Yes - by the compositional production that building large query patterns from 
smaller query patterns.

> 
> cheers
> 
> Alberto

	Andy

> 
> [1] http://www.w3.org/2001/sw/DataAccess/rq23/
> -
> Alberto Reggiori, Senior Partner, R&D @Semantics S.R.L.
> www.asemantics.com Milan Office
>

Received on Wednesday, 26 January 2005 14:25:30 UTC