- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Wed, 18 Jan 2006 15:41:42 +0000
- To: Sven Groppe <Sven.Groppe@deri.org>
- CC: public-rdf-dawg@w3.org
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