- From: <souripriya.das@oracle.com>
- Date: Sat, 25 Mar 2006 10:33:40 -0500
- To: Dan Connolly <connolly@w3.org>, eric@w3.org
- CC: RDF Data Access Working Group <public-rdf-dawg@w3.org>
- Message-ID: <442562D4.6040001@oracle.com>
Two things: 1) I need more time to discuss this within Oracle. 2) I need a confirmation of my following understanding of the process: A "YES" vote from me at this point for transition to CR does not prevent Oracle from raising new issues or pursuing further any of the issues that have been raised earlier by Oracle folks even after the SPARQL documents move to the CR phase. Thus, for example, if Fred Zemke wants to pursue some of his earlier comments further, even after SPARQL documents move to CR with my "YES" vote, he will be allowed to do that (that is, he will not be prevented from doing that based on any technicalities of the W3C process). Thanks, - Souri.. Dan Connolly wrote: >So we discussed this CR request today. > http://www.w3.org/2001/sw/DataAccess/crq349 > >I edited out all but one of the remaining @@'s >(I still owe PFPS a reply. I'll do that tomorrow). > >The current version is 1.27 $ of $Date: 2006/03/22 00:19:11; >a copy is attached. > >I rushed things a bit, so I'm going to let it sit overnight >before I send it to The Director. I'll log any changes from >here on out in the document, and notify the WG by email >of anything significant. > >Please indicate your support (or otherwise) via this form: > http://www.w3.org/2002/09/wbs/35463/crq349/ > >This questionnaire is open for answers until 23:59, Boston time on >2006-03-26, so that I can have them all when I prepare >the agenda for next week's call. If you need more time, >send me and EricP mail. > >Note that you can change your response any time up to the >deadline, so feel free to give a "yes" answer real quick, >and then think it over and add comments and/or rationale >over the course of the week, and if necessary, flip >to a "no" later in the week in case you find something critical. > > > > >------------------------------------------------------------------------ > >DAWG <./> > > > Status ($Revision: 1.27 $ of $Date: 2006/03/22 00:19:11 $) > > This was discussed and largely endosed by the WG 21 Mar. A WBS survey > <http://www.w3.org/2002/09/wbs/35463/crq349/> to collect explicit > endorsement is in progress. One @@todo <#todo> remains, meanwhile, for DanC > to respond to a comment from PFPS. > >This is a transition request to CR ><http://www.w3.org/2005/08/transition?docstatus=cr-tr> for the three documents >that specify SPARQL. Whereas > > * W3C established our charter <http://www.w3.org/2003/12/swa/dawg-charter> > in February 2004 (and extended it in January 2006) > * we have elaborated on the value of this work to the community by way of > use cases and derived design requirements <http://www.w3.org/TR/rdf-dawg-uc/> > * we have developed specifications for SPARQL that meet our charter and > requirements > * this specification has received wide review, within the Working Group and > the community, and we have addressed the issues raised in this review with > consensus on all but about ten cases <#obj>. > >the RDF Data Access Working Group is evaluating a proposal (21 Mar meeting >minutes ><http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JanMar/0465.html> >1proposal responses <http://www.w3.org/2002/09/wbs/35463/crq349/> ) to request >that you advance this specification to W3C Candidate Recommendation and call for >implementation. > > * SPARQL Query Language for RDF <http://www.w3.org/TR/rdf-sparql-query/> > Abstract: > > RDF is a flexible and extensible way to represent information about > World Wide Web resources. It is used to represent, among other things, > personal information, social networks, metadata about digital > artifacts, as well as provide a means of integration over disparate > sources of information. A standardized query language for RDF data > with multiple implementations offers developers and end users a way to > write and to consume the results of queries across this wide range of > information. Used with a common protocol, applications can access and > combine information from across the Web. > > This document describes the query language part of the SPARQL Protocol > And RDF Query Language for easy access to RDF stores. It is designed > to meet the requirements and design objectives described in RDF Data > Access Use Cases and Requirements <http://www.w3.org/TR/rdf-dawg-uc/> > > specifically, ed draft <rq23> 1.664 2006/03/21 10:19:30, with appendixes: > sparql-defns.html 1.3 2006/02/21 20:14:59, parsers/sparql.bnf 1.1 > 2006/02/09 23:12:43, plus edits as agreed 21 March > > * SPARQL Protocol for RDF <http://www.w3.org/TR/rdf-sparql-protocol/> > Abstract: > > SPARQL is a query language and protocol for RDF > <http://www.w3.org/RDF/>. This document specifies the SPARQL Protocol; > it uses WSDL 2.0 <http://www.w3.org/TR/wsdl20/> to describe a means > for conveying SPARQL queries to an SPARQL query processing service and > returning the query results to the entity that requested them. > > specifically, ed draft <proto-wd/> v1.114 of 2006/03/20 21:58:41 and the 2 > linked WSDL files: sparql-protocol-query.wsdl,v 1.18 2006/03/21 19:18:07 > and sparql-protocol-types.xsd,v 1.17 2006/01/11 19:15:22, plus edits as > agreed 21 March > > * SPARQL Query Results XML Format <http://www.w3.org/TR/rdf-sparql-XMLres/> > Abstract: > > RDF is a flexible, extensible way to represent information about World > Wide Web resources. It is used to represent, among other things, > personal information, social networks, metadata about digital > artifacts like music and images, as well as provide a means of > integration over disparate sources of information. A standardized > query language for RDF data with multiple implementations offers > developers and end users a way to write and to consume the results of > queries across this wide range of information. > > This document describes an XML format for the variable binding and > boolean results formats provided by the SPARQL query language for RDF. > > specifically: ed draft <rf1/> v1.78 of 2006/01/04T15:59:22Z > >-------------------------------------------------------------------------------- > > > Status of these documents (proposed) > >tweaks to be made in the publication process are marked PUBFIX > >This section describes the status of this document at the time of its >publication[PUBFIX which hasn't happened yet]. Other documents may supersede >this document. A list of current W3C publications and the latest revision of >this technical report can be found in the W3C technical reports index ><http://www.w3.org/TR/> at http://www.w3.org/TR/. > >This 29 Mar 2006 [PUBFIX confirm] draft, along with the other working drafts for >SPARQL, are a Candidate Recommendation ><http://www.w3.org/2003/06/Process-20030618/tr.html#RecsCR>; it been widely >reviewed and satisfies the requirements documented in RDF Data Access Use Cases >and Requirements <http://www.w3.org/TR/rdf-dawg-uc/> ; W3C publishes a Candidate >Recommendation to gather implementation experience. > >The first release of this document was 12 Oct 2004[PUBFIX tune to each part) and >the RDF Data Access Working Group <http://www.w3.org/2001/sw/DataAccess/> has >made its best effort to address comments received ><http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/> since then, >releasing several drafts and resolving a list of issues ><http://www.w3.org/2001/sw/DataAccess/issues> meanwhile. The design has >stabilized the Working Group intends to advance this specification to Proposed >Recommendation once the exit criteria below are met: > > * A test suite gives reasonable coverage of the features of the query > langauge and protocol. > > Note that the working group maintains a collection of query tests > <http://www.w3.org/2001/sw/DataAccess/tests/> and a collection of protocol > tests <http://www.w3.org/2001/sw/DataAccess/proto-tests/>. Only a portion > of the tests in these collections are approved at this time. > > * Each identified SPARQL feature has at least two implementations. > * At least two conformant SPARQL service > <proto-wd/#conformant-sparql-protocol-service>s are available. [PUBFIX > update link to /TR/ space] > * Relevant media types are registered: > o The SPARQL specifications introduce two new Internet Media Types. > Review has been requested, but the types are not yet registered: > + application/sparql-query: review request > <http://www.alvestrand.no/pipermail/ietf-types/2005-November/000895.html> > of 24 Nov 2005 > + application/sparql-results+xml: review request > <http://www.alvestrand.no/pipermail/ietf-types/2005-November/000894.html> > of 24 Nov 2005 > o The SPARQL protocol specification uses the ext/rdf+n3 media type, > which is unregistered, in an example > * Normative dependencies, have been advanced to Proposed Recommendation status: > o XQuery 1.0 and XPath 2.0 Functions and Operators > <http://www.w3.org/TR/xpath-functions/> > o Web Services Description Language (WSDL) Version 2.0 Part 1: Core > Language <http://www.w3.org/TR/wsdl20> > o Web Services Description Language (WSDL) Version 2.0 Part 2: > Adjuncts <http://www.w3.org/TR/wsdl20-adjuncts> > >This specification will remain a Candidate Recommendation until at least 30 May >2006[PUBFIX if 29 March slips, so does this]. implementation report ><http://www.w3.org/2001/sw/DataAccess/imp39> is in progress. > >Comments on this document should be sent to public-rdf-dawg-comments@w3.org, a >mailing list with a public archive ><http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/>. > >Publication as a Candidate Recommendation does not imply endorsement by the W3C >Membership. This is a draft document and may be updated, replaced or obsoleted >by other documents at any time. It is inappropriate to cite this document as >other than work in progress. > >This document was produced by a group operating under the 5 February 2004 W3C >Patent Policy <http://www.w3.org/Consortium/Patent-Policy-20040205/>. W3C >maintains a public list of any patent disclosures ><http://www.w3.org/2004/01/pp-impl/35463/status> made in connection with the >deliverables of the group; that page also includes instructions for disclosing a >patent. An individual who has actual knowledge of a patent which the individual >believes contains Essential Claim(s) ><http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential> must >disclose the information in accordance with section 6 of the W3C Patent Policy ><http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure>. > >-------------------------------------------------------------------------------- > > > Summary of Review > >The first public working draft of the SPARQL specification was released in Oct >2004, following a June 2004 Use Cases and Requirements release. The November >2004 Last Call milestone from our charter was delayed due to difficulties >reaching consensus on an initial design and requirements; see outstanding >dissent <#obj> below. We adopted a WSDL requirement and a sorting objective in >early 2005, accepting another schedule slip. Our requirements have been stable >since the March 2005 draft. In a number of cases, we have considered features >that go beyond these requirements, but ultimately postponed them due to lack of >implementation and design experience. For example, Features for querying >lists/collections ><http://www.w3.org/2001/sw/DataAccess/issues#accessingCollections> have been >frequently requested, but the requestors seem to be satisfied with our decision >to postpone the issue. > >About 75 people participated in the comments mailing list, including editors and >WG members. Tutorial articles include: > > * Search RDF data with SPARQL > <http://www-128.ibm.com/developerworks/xml/library/j-sparql/> by Philip > McCarthy 10 May 2005 on IBM developerWorks > * Introducing SPARQL: Querying the Semantic Web > <http://www.xml.com/pub/a/2005/11/16/introducing-sparql-querying-semantic-web-tutorial.html> > by Leigh Dodds November 16, 2005 on XML.com > >A community-maintained list of SPARQL software ><http://esw.w3.org/topic/SparqlImplementations> includes SPARQL engines in >progress in PHP, Java, Perl, python C, and Common Lisp, as well as client side >utilities and parsers. The companion list of services and applications ><http://esw.w3.org/topic/DawgShows> includes interactive forms that allow >developers and users to evaluate the language over the web and a few medium to >large scale, though experimental, services. We have not evaluated the >completeness of these services and software, though this level of support >clearly indicates significant investment in and satisfaction with the SPARQL >specifications and justifies continued investment in finishing the test materials. > >Dependencies were discharged as follows: > > * The XML Query WG and XSL WG sent review comments > <http://www.w3.org/mid/20050913082804661.00000000668@amalhotr-pc> in Sep > 2005. We sent a response <http://www.w3.org/mid/43843C24.1080901@hp.com> > that addressed them in Nov 2005. > * We requested review from the Semantic Web Best Practices and Deployment > (SWBPD) Working Group > <http://www.w3.org/2001/sw/DataAccess/BestPractices/> in general and > consulted members of that WG in particular on the SOURCE and UNSAID > issues. This has resulted in various individual comments but no comments > from the SWBPDWG as a whole. > * We exchanged comments with the WSD WG on a number of details related to > specifying the SPARQL protocol using WSDL 2.0. While our September 2005 > protocol draft conflicted with the then-current WSDL 2.0 specification, > our 25 Jan 2005 protocol draft is in sync with latest information we have > gotten from the WSD WG and the Woden validator (see 21 March "wsdl fun" > thread in DAWG > <http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JanMar/thread.html#msg466>, > notice to wsd WG 21 March > <http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2006Mar/0044.html>). > * IETF review of SPARQL related media types (application/sparql-query, > application/sparql-results+xml) began with review requests (query > <http://www.alvestrand.no/pipermail/ietf-types/2005-November/000895.html> > review request > <http://www.alvestrand.no/pipermail/ietf-types/2005-November/000895.html> > results > <http://www.alvestrand.no/pipermail/ietf-types/2005-November/000894.html> > review request) > <http://www.alvestrand.no/pipermail/ietf-types/2005-November/000894.html> > on 24 Nov 2005. We have not received any comments as a result. We accept > registration of these media types as a CR exit criterion. > >In July 2005 and September 2005, we released last call working draft of the >query language and protocol (respectively) since we had closed all outstanding >issues and met all our requirements. Since then, there has been a sustatined >tension between a growing user and implementor community that is ready for the >specification to advance despite any remaing flaws and a dilligent review >community that is insisting on a high level of rigor. > >We tracked status of comments since July 2005 ><http://lists.w3.org/Archives/Public/www-archive/2006Mar/att-0022/lc-status-report.html__charset_us-ascii>, >including 55 cases of comments that the WG addressed to the documented >satisifaction of the commentors. Due to a number of small technical changes and >an increasing number of cases where the WG addressed a comment but did not get a >clear indication of satisfaction or otherwise from the commentor, we issued a >second last call of the SPARQL protocol 25 Jan 2006 and the SPARQL query >language 20 February 2006. Comments were due 13 March 2006; our comment status >report <http://www.w3.org/2001/sw/DataAccess/lc-status-report.html> shows 9 >threads where the WG and the commentor reached consensus, one formal objection, >one case where the we "Corrected along the lines of your suggestion" and asked >if it was satisfactory but have not seen a response, and @@one more to address, >as of 1.69 2006/03/21 23:39:23 <todo>. > >Changes since last call have been editorial changes and clarifications only. > > > Outstanding dissent (formal objections) > > 1. the WG RESOLVED 2004-07-15 > <http://www.w3.org/2001/sw/DataAccess/ftf2#initdn3> to adopt BRQL v1.11 as > its strawman query language design, over the objection of RobS and JeffP > of Network Inference > <http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JulSep/0101.html>: > > ...XQuery, with minor extensions, would be the best overall foundation > on which to enable query-based access to the family of Semantic Web > languages. ... > > This view did not meet with a critical mass of support in Working Group > discussions, though it continued to be explored in the community. One of > the most thorough explorations of the relationship of SPARQL to XQuery and > SQL concludes: > > We have, somewhat reluctantly, concluded that the design goals of SQL > and SPARQL are sufficiently different that there is adequate > justification for the creation of a special-purpose language for > querying RDF collections. We are comforted by the belief that it is > possible to translate SPARQL expressions into SQL expressions, > allowing users to store their RDF collections in relational databases > if they wish to do so, and to write their queries in either SQL or in > SPARQL, as they see fit. While predicting that it will be similarly > possible to serialize RDF collections into XML documents and transform > SPARQL expressions into XQuery expressions, we do not believe that > most users would take that direction. > > SQL, XQuery, and SPARQL What's Wrong With This Picture? > <http://www.idealliance.org/proceedings/xml05/abstracts/paper185.HTML> > by Jim Melton, Oracle Corporation; in proceedings of XML 2005 > <http://www.idealliance.org/proceedings/xml05/index.html> > > 2. Requirement 3.10 Result Limits was accepted 2004-07-14 > <http://www.w3.org/2001/sw/DataAccess/ftf2#req> over the objection of RobS > of Network Inference > <http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JulSep/0104.html>: > > With no definition of ordering, a "limit" feature violates many > properties which can be desirable for a query language, including a > simple desire for deterministic results. > > The working group later accepted an ordering objective and added an ORDER > BY feature to SPARQL. > > 3. Requirement 3.6 Optional Match <http://www.w3.org/TR/rdf-dawg-uc/#r3.6> > was accepted 2004-07-15 <http://www.w3.org/2001/sw/DataAccess/ftf2> over > the objection of RobS of Network Inference > <http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JulSep/0104.html> > > Note that the objection concludes with: > > ...Network Inference certainly sees value in both features, and > supports both as objectives for this working group. If the potential > problems related to these requirements can be overcome, then our > objection to the classification of these features as "requirements" > should not prevent the group from regaining consensus on a final > recommendation. > > And while the theoretical issues with OPTIONAL have been expensive to work > out, they seem to be specified to the satsifaction of the community. > Further, the number of use cases where this feature is critical suggests > that SPARQL would not succeed without it (For example, see MacGregor 24 > Mar 2005 > <http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Mar/0070>.) > > 4. The DESCRIBE <http://www.w3.org/2001/sw/DataAccess/issues#DESCRIBE> issue > was resolved over the objection of Dan Connolly: > > expectations around DESCRIBE are very different from CONSTRUCT and > SELECT, and hence it should be specified in a separate query language > > This objection was supported by a number of public comments; at least one > reviewer wrote to explicitly support this feature, meanwhile. The feature > seems to be specified to the satisfaction of a critical mass of the > community, supported in several implementations, and used in a number of > applications. > > 5. Objective 4.2 Data Integration and Aggregation > <http://www.w3.org/TR/rdf-dawg-uc/#d4.2> was accepted 2004-09-16 > <http://www.w3.org/2001/sw/DataAccess/ftf3-brs#obj564> over the objection > of Network Inference/Rob Shearer > <http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JulSep/0118.html>: > > The only technology that I think we all really agree on is RDF and the > RDF data model. It strikes me as blatantly wrong to attempt a query > standard based on some other data model, and "RDF+some meta > information" is some other data model. If the meta information can be > exposed in RDF, then our query language should support it by default. > If it can't be exposed in RDF, then why are we considering native > support in an RDF query language? > > A comment from outside the WG also says: > > I think these should be removed from the basic SPARQL core, since I > feel they add a fair deal of implementation complexity and an > application can achieve the same result by submitting multiple > queries, possibly to different query processors. > > I also feel it would be premature to standardize an approach to > multi-graph querying ahead of there being a consensus/standard for > something like RDF named graphs. > > Klyne 08 Apr 2005 > <http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Apr/0010.html> > > The feature seems to be specified to the satisfaction of a critical mass > of the community, supported in several implementations, and required by > number of use cases and applications. > > 6. The disjunction <issues#disjunction> issue was closed 2005-01-20 in > Helsinki meeting <ftf4.html#item24> over the objection of Dave Beckett, > which was that it did not merit the implementation cost. A number of > implementors have since found it worth their while to implement this > feature, reporting little difficulty with it. > 7. The fromUnionQuery > <http://www.w3.org/2001/sw/DataAccess/issues#fromUnionQuery> issue was > resolved in our 2005-06-07 meeting > <http://lists.w3.org/Archives/Public/public-rdf-dawg/2005AprJun/0411.html> > over the objection of Steve Harris. This was a design issue where the > group had a lot of difficulty finding consensus, and the chair chose to > act in the interest of schedule concerns: > >DanC summarized by observing 3 designs that seemed to be coherent >and had been developed and advocated sufficiently that we might >be able to finish them in a timely manner: > >OPTIONS: > (a) without FROM/FROM_NAMED, dataset is unconstrained; with > FROM/FROM_NAMED, dataset is bounded from below by given references. > (b) like (a) but FROM/FROM named completely specify the dataset > (c) datasets have "aggregate graph" rather than background/default > graph, and it always contains the merge of the named graphs > >By "bounded from below," DanC clarified that he meant D1 >= D2 iff > D1's background/aggregate graph has everything that D2's has, > i.e. D1's bg graph rdf-simply-entails D2's > and D1 has all the named graphs that D2 has; i.e. > for every named graph (U, G) in D2, (U, G) is also in D1's named > graphs. > >KC observed that this is basically a web-social question of >constraining what publishers do. > >DC observed that constraining publishers might be responsive >to comments on this part of our spec, in the interest of >interoperability at the expense of flexibility. > >Polling showed significant opposition to (b); after that option >was removed, the WG was split nearly 50-50 between (a) and (c). >In the interest of time, the chair chose one of the proposals >and we > >RESOLVED: to go option (a) without FROM/FROM_NAMED, dataset is >unconstrained; with FROM/FROM_NAMED, dataset is bounded from below >by given references. >SH objects. abstaing: EricP, DaveB > > The feature seems to be specified to the satisfaction of a critical mass > of the community, and it seems unlikely that further deliberation of this > issue would result in substantially more consensus. > > 8. The rdfSemantics > <http://www.w3.org/2001/sw/DataAccess/issues#rdfSemantics> issue was > closed in our 2006-01-26 meeting > <http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JanMar/att-0298/26-dawg-minutes.html#item04> > over the objection of Pat Hayes, which was that the definitions are overly > complex. > > This issue arose from comments on the specification of matching in the > July 2005 SPARQL draft with respect to the definition of RDF simple > entailment. After discussing a number of use cases and design > alternatives, the WG chose a design that was phrased in terms of > entialment in such a way that it should extend to OWL more > straightforwardly, but substantively, is not different from the July 2005 > draft. After discussing the details of the definitions for some months, > the chair observed a critical mass around a set of definitions and put the > question despite outstanding dissent. > > 9. On 5 March, Elliotte Harold asked that we don't use ? and $. Pick one. > <http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2006Mar/0006.html> > He was not satisfied by our attempts to justify our decision as part of > punctuationSyntax issue > <http://www.w3.org/2001/sw/DataAccess/issues#punctuationSyntax>: > >> >> A number of design considerations were laid out in: >> >> Draft: open issues around '?' use. <http://lists.w3.org/Archives/Public/public-rdf-dawg/2004OctDec/0160> >> >> >> >> I think this makes some good arguments for using a $ instead of a ?. >> However it doesn't convince me that using both is a good idea. Why are >> two characters considered necessary here? Why not just pick the $ and be >> done with it? > >The use of ?var syntax in SPARQL goes back all the way to the 1st >WD in October 2004 <http://www.w3.org/TR/2004/WD-rdf-sparql-query-20041012/> > >The number of reviewers, users, and implementors that we would need >to collaborate with in order to take ?var out is considerable, and >it's not clear that we have an argument that is sufficient to convince >them. True, allowing both adds various costs, but this is largely >sunk cost. The details of the specification are worked out; we have >test cases and multiple implementations. A growing number of users >have learned the ?var syntax, and those that need to use ODBC-style >systems seem to know about and be happy with $var. >It seems unlikely that we would get consensus around a change >to take out ?var or $var in a reasonable amount of time, and the >number of parties that are interested to see SPARQL advance to >Candidate Rec soon is considerable. > >Again, please let us know whether you find this response satisfactory. > > > >
Received on Saturday, 25 March 2006 15:33:55 UTC