- From: Dan Connolly <connolly@w3.org>
- Date: Thu, 01 Sep 2005 13:01:57 -0500
- To: Art.Barstow@nokia.com
- Cc: public-rdf-dawg-comments@w3.org, Ora.Lassila@nokia.com
On Thu, 2005-09-01 at 13:12 -0400, Art.Barstow@nokia.com wrote: > Regarding the 2005-07-21 version of the SPARQL Query > Language for RDF document, we have the following comments: > > 1) This document does not discuss in any way the > *semantics* of the query language. We would like to see > a more formal definition of queries (and their results) > in terms of RDF semantics (right now, the query language > seems to treat RDF graphs as merely data structures from > which something can be extracted). Why would SPARQL now > ignore RDF's model theory when one was created through > a sizeable effort? Could you be more specific about what's lacking? What questions should be answered that are not currently answered? I suppose we could make explicit that for a query pattern P, if S is a solution w.r.t. an input graph G, then S(P) is entailed by G. Is that what you have in mind? I think the idea can be expanded to cover UNION straightforwardly, and perhaps OPTIONAL with some effort, but I don't know how this applies to queries that use the GRAPH keyword. RDF's model theory was not ignored. There is a normative dependency from SPARQL to the RDF model theory in section 7.1. The link was not as clear as it could be in the 2005-07-21 version; In response to comments from other reviewers, we have clarified the references section. In the current editor's draft, you may want to look at... http://www.w3.org/2001/sw/DataAccess/rq23/#RDF-MT > 2) Given that RDF representations -- effectively -- are > graphs, why would the W3C present a query language based > on relational algebra? It is well known [1] that relational > algebra is insufficient for querying graphs (generally, > data structures that exhibit repetitive or recursive patterns). > In order to query, say, hierarchies of arbitrary depth, the > query language should have some means of expressing > a transitive closure. The WG began its design discussion by surveying known technologies: http://www.w3.org/2001/sw/DataAccess/DesignEvaluations Versa was among the designs we considered, and it's fairly strongly path-based. It got some support, but not a critical mass. The level of support for various designs was discussed at the 2nd ftf meeting a few times before we eventually chose BRQL, which is largely relational. http://www.w3.org/2001/sw/DataAccess/ftf2#initdn http://www.w3.org/2001/sw/DataAccess/ftf2#initdn2 http://www.w3.org/2001/sw/DataAccess/ftf2#initdn3 In the use cases we have explored, where transitive closure is needed, the query is run over a notional background graph that includes the inferred transitive closure. By charter, this sort of inference is orthogonal to query. More on that below. > > 3) It does not seem possible to extend SPARQL to be > used with OWL (primarily, perhaps, because of comment > #1 above). A number of WG members (UMD, Agfa) are succesfully using SPARQL with OWL. By charter, OWL inference is orthogonal to query: [[ 2.1 Specification of RDF Schema/OWL semantics The protocol will allow access to a notional RDF graph. This may in practice be the virtual graph which would follow from some form of inference from a stored graph. This does not affect the data access protocol, but may affect the description of the data access service. For example, if OWL DL semantics are supported by a service, that may be evident in the description of the service or the virtual graph which is queried, but it will not affect the protocol designed under this charter. ]] http://www.w3.org/2003/12/swa/dawg-charter#rdfs-owl-queries > Regards, > > Art Barstow > --- > > [1] Aho, A.V., Ullman, J.D.: Universality of data retrieval > languages. In: POPL ¹79: Proceedings of the 6th ACM SIGACT-SIGPLAN > symposium on Principles of programming languages, ACM Press (1979) > 110119. -- Dan Connolly, W3C http://www.w3.org/People/Connolly/ D3C2 887B 0F92 6005 C541 0875 0F91 96DE 6E52 C29E
Received on Thursday, 1 September 2005 18:02:02 UTC