Re: Intro + question

Sven Groppe wrote:
> Dear members of the DAWG working group,
>  
> I am an employee of the Digital Enterprise Research Institute (DERI), which
> has a big focus on the Semantic Web and contributes already to other W3C
> working groups like RIF, at the University of Innsbruck.
> See below for my business contact.

Hi there - good to have you join.

>  
> Originally, I came from the database community. My topic of my Doctorate is
> "XML Query Reformulation for XPath, XSLT and XQuery" (ISBN 3-933893-24-0).
>  
> I hope I can contribute to the DAWG working group regarding my background
> and although the working group seems to be nearly finished.
>  
> I have a question concerning the
> "SPARQL Query Language for RDF
> W3C Working Draft 23 November 2005".
> I think it is similar to the remarks of
> http://www.w3.org/2001/sw/DataAccess/issues#cascadedQueries,
> but I apologize if I oversee further discussions.
> 
> I am of the opinion that is important
> to support nested queries. Nested queries are important if you want e.g.
> support views, which plays is a key point for integrating heterogeneous
> sources.
> 
> I would expect that the production
> [9]   DatasetClause   ::=   'FROM' ( DefaultGraphClause | NamedGraphClause )
> 
> 
> would allow to query also the result of
> a ConstructQuery, i.e. 
> 
> [9]   DatasetClause   ::=   'FROM' ( DefaultGraphClause | NamedGraphClause |
> ConstructQuery) 
> 
> Simple Example:
> 
> PREFIX foaf:    <http://xmlns.com/foaf/0.1/>
> PREFIX vcard:   <http://www.w3.org/2001/vcard-rdf/3.0#>
> 
> SELECT ?mbox
> FROM
> 	CONSTRUCT   { <http://example.org/person#Alice> vcard:FN ?name }
> 	WHERE       { ?x foaf:name ?name }
> WHERE
>   { ?x foaf:name "Johnny Lee Outlaw" .
>     ?x foaf:mbox ?mbox }
>  
> Note that this is a simple example and that for other views in real
> integration scenarios of course more complicated CONSTRUCT queries would
> occur.
> 
> I apologize again if I oversee something in the specification that allows
> some kind of nested queries or if there was a discussion with the decision
> not allowing nested queries.
> In the latter case, I would be interested in the arguments not to support
> nested queries as I cannot imagine reasonable arguments (except
> implementation effort).
>  
> Cheers,
> Sven.

It's a reasonable long-term goal - one non-technical factor is whether it is 
better to wrap up what we have now and accept there will be a SPARQL-2.  I 
side with the wrap-up/move-on view.

Some observations:

First, if the FROM is some long URL, it coudl be the CONSTRUCT query.  I agree 
it's not a very pretty query that way but it does mean that the URL will be 
executed and a graph returned that is queryable by the outer query.

Second, (and it is as much a counter to 1) the query can be collapsed to:

SELECT ?mbox
WHERE
   { ?x vcard:FN "Johnny Lee Outlaw" .
     ?x foaf:mbox ?mbox }

That is, the CONSTRUCT template is inserted into the SELECT pattern (and in 
general with all the CONSTRUCT selection pattern as well.  Lots of variable 
renaming to be managed and I don't think it is a good, long term argument as 
it is inconvenient.

Third, this is one case of "subqueries" (in the general sense) and it might be 
better to have a complete approach to them.  That is a "release now, do 
SPARQL-2" viewpoint.

e.g.

SELECT ?mbox
FROM
    SELECT ?name { <http://example.org/person#Alice> vcard:FN ?name }
WHERE
   { ?x foaf:name "Johnny Lee Outlaw" .
     ?x foaf:mbox ?mbox }

this being the same "?name" from the nested SELECT whereas before it was a 
different ?x (doubly so if it's a blank node).

Anyway - good to have DERI join,

	Andy

Received on Wednesday, 18 January 2006 15:42:00 UTC