crq349 31.5 KB

Raw Blame History Permalink

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <title>Transition Request to advance SPARQL to Candidate
Recommendation</title>
<style type="text/css">
.pub-status {background-color: #F1F1F1; color: #000000;
border-left: dotted; padding-left: 1em}
</style>
</head>

<body>
<div class="nav"><a href="./">DAWG</a></div>

  <p>This is a <a href=
  "http://www.w3.org/2005/08/transition?docstatus=cr-tr">transition
  request to CR</a> for the three documents that specify SPARQL. Whereas</p>

  <ul>
    <li>W3C established our <a href=
    "http://www.w3.org/2003/12/swa/dawg-charter">charter</a>
    in February 2004 (and extended it in January 2006)</li>

    <li>we have elaborated on the value of this work to the
    community by way of <a href=
    "http://www.w3.org/TR/rdf-dawg-uc/">use cases and derived
    design requirements</a></li>

    <li>we have developed specifications for SPARQL that meet our
    charter and requirements</li>

    <li>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 <a href="#obj">ten cases</a>.</li>
  </ul>

  <p>the RDF Data Access Working Group decided (<a href=
  "http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JanMar/0465.html"
  >21 Mar meeting minutes</a>, pending successful outcome of <a
  href="http://www.w3.org/2002/09/wbs/35463/crq349/">ballot</a> ) to
  request that you advance this specification to W3C Candidate
  Recommendation and call for implementation.
  </p>

  <ul>
    <li>
      <cite><a href="http://www.w3.org/TR/rdf-sparql-query/">SPARQL
      Query Language for RDF</a></cite>
      <br />Abstract:
      <blockquote>
        <p>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.</p>
          <p>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
          <cite><a href="http://www.w3.org/TR/rdf-dawg-uc/">RDF
          Data Access Use Cases and Requirements</a></cite></p>
      </blockquote>

      <p><em>specifically, <a href="rq23">ed draft</a>
      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
      </em></p>
    </li>

    <li>
      <cite><a href=
      "http://www.w3.org/TR/rdf-sparql-protocol/">SPARQL Protocol
      for RDF</a></cite>
      <br />Abstract:
      <blockquote>
        <p>SPARQL is a query language and protocol for <a href=
          "http://www.w3.org/RDF/">RDF</a>. This document specifies
          the SPARQL Protocol; it uses <a href=
          "http://www.w3.org/TR/wsdl20/">WSDL 2.0</a> 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.</p>
      </blockquote>

      <p><em>specifically, <a href="proto-wd/">ed draft</a> v1.114 of
      2006/03/20 21:58:41 and the 2 linked WSDL files:
      <tt>sparql-protocol-query.wsdl,v 1.18 2006/03/21 19:18:07</tt>
      and <tt>sparql-protocol-types.xsd,v 1.17 2006/01/11
      19:15:22</tt>, plus edits as agreed 21 March </em></p>
    </li>

    <li>
      <cite><a href=
      "http://www.w3.org/TR/rdf-sparql-XMLres/">SPARQL Query
      Results XML Format</a></cite>
      <br />Abstract:
      <blockquote>
        <p>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.</p>
	  <p>This document describes an XML format for the variable
          binding and boolean results formats provided by the
          SPARQL query language for RDF.</p>
      </blockquote>

      <p><em>specifically: <a href="rf1/">ed draft</a> v1.78 of
      2006/01/04T15:59:22Z</em></p>
    </li>
  </ul>

  <hr />

  <div><h2>Status of these documents (proposed)</h2>

  <p><em>tweaks to be made in the publication process are marked
  PUBFIX</em></p>

<blockquote class="pub-status">
<p><em>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 <a href="http://www.w3.org/TR/">W3C technical reports index</a> at http://www.w3.org/TR/.</em></p>

  <p>This 29 Mar 2006
  <em>[PUBFIX confirm]</em>
  draft, along with the other working drafts for SPARQL, are a
  <a href=
  "http://www.w3.org/2003/06/Process-20030618/tr.html#RecsCR">Candidate
  Recommendation</a>; it been widely reviewed and satisfies the
  requirements documented in <b><i><a href=
  "http://www.w3.org/TR/rdf-dawg-uc/">RDF Data Access Use Cases and
  Requirements</a></i></b> ; W3C publishes a Candidate
  Recommendation to gather implementation experience.</p>

  <p>The first release of this document was 12 Oct 2004<em>[PUBFIX tune to
  each part</em>] and the <a href=
  "http://www.w3.org/2001/sw/DataAccess/">RDF Data Access Working
  Group</a> has made its best effort to address <a href=
  "http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/">comments
  received</a> since then, releasing several drafts and resolving a <a
  href="http://www.w3.org/2001/sw/DataAccess/issues">list of
  issues</a> meanwhile. The design has stabilized and the Working Group intends to advance this
  specification to Proposed Recommendation
once the exit
  criteria below are met:</p>

  <ul id="exitcri"> <!-- hmm... xoxo? VTodos? -->
    <li>A test suite gives reasonable coverage of
    the features of the query language and protocol.
    <p>Note that the working group maintains a <a
    href="http://www.w3.org/2001/sw/DataAccess/tests/">collection of
    query tests</a> and a <a
    href="http://www.w3.org/2001/sw/DataAccess/proto-tests/">collection
    of protocol tests</a>. Only a portion of the tests in these
    collections are approved at this time.</p>
    </li>

    <li>Each identified SPARQL feature has at least two implementations.</li>
    <li>At least two <a href="proto-wd/#conformant-sparql-protocol-service">conformant SPARQL service</a>s are available. [PUBFIX update link to /TR/ space]</li>
    <li>Relevant media types are registered:
    <ul>
      <li>The SPARQL
    specifications introduce two new Internet Media Types. Review
    has been requested, but the types are not yet registered:
        <ul>
          <li>application/sparql-query: <a href=
          "http://www.alvestrand.no/pipermail/ietf-types/2005-November/000895.html">
          review request</a> of 24 Nov 2005</li>

          <li>application/sparql-results+xml: <a href=
          "http://www.alvestrand.no/pipermail/ietf-types/2005-November/000894.html">
          review request</a> of 24 Nov 2005</li>
        </ul>
    </li>

    <li>The SPARQL protocol specification uses the ext/rdf+n3 media type, which is unregistered, in an example</li>
    </ul>
    </li>

    <li>Normative dependencies, have been advanced to Proposed
    Recommendation status:
    <ul>
      <li><cite><a href="http://www.w3.org/TR/xpath-functions/">XQuery
      1.0 and XPath 2.0 Functions and Operators</a></cite></li>
      <li><cite><a href="http://www.w3.org/TR/wsdl20">Web Services
      Description Language (WSDL) Version 2.0 Part 1: Core Language
      </a></cite></li>
      <li><cite><a href="http://www.w3.org/TR/wsdl20-adjuncts">Web
      Services Description Language (WSDL) Version 2.0 Part 2:
      Adjuncts</a></cite></li>
    </ul>
    </li>
  </ul>

  <p>This specification will
  remain a Candidate Recommendation until at least 30 May
  2006[PUBFIX if 29 March slips, so does this].
  An <a href="http://www.w3.org/2001/sw/DataAccess/imp39">implementation
  report</a> is in progress.</p>

  <p>Comments on this document should be sent to
  public-rdf-dawg-comments@w3.org, a mailing list with a <a href=
  "http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/">public
  archive</a>.</p>

<p>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.</p>

<p> This document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 W3C Patent Policy</a>. W3C maintains a <a rel="disclosure" href="http://www.w3.org/2004/01/pp-impl/35463/status">public list of any patent disclosures</a> 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 <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the W3C Patent Policy</a>. </p>
</blockquote>

  </div>
  <hr  />


  <div><h2>Summary of Review</h2>

  <p>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 <a href="#obj">outstanding
  dissent</a> 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, <a href=
  "http://www.w3.org/2001/sw/DataAccess/issues#accessingCollections"
  >Features for querying lists/collections</a> have been frequently
  requested, but the requestors seem to be satisfied with our decision
  to postpone the issue.</p>

  <p>About 75 people participated in the comments mailing list,
  including editors and WG members. Tutorial articles include:</p>
  <ul>
    <li><cite><a href="http://www-128.ibm.com/developerworks/xml/library/j-sparql/">Search RDF data with SPARQL</a></cite> by Philip McCarthy 10 May 2005 on IBM developerWorks</li>
    <li><cite><a href="http://www.xml.com/pub/a/2005/11/16/introducing-sparql-querying-semantic-web-tutorial.html">Introducing SPARQL: Querying the Semantic Web</a></cite> by Leigh Dodds November 16, 2005 on XML.com</li>
  </ul>

  <p>A community-maintained <a
  href="http://esw.w3.org/topic/SparqlImplementations">list of SPARQL
  software</a> includes SPARQL engines in progress in PHP, Java, Perl,
  python C, and Common Lisp, as well as client side utilities and
  parsers. The companion <a
  href="http://esw.w3.org/topic/DawgShows">list of services and
  applications</a> 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.</p>

  <p>Dependencies were discharged as follows:</p>

  <ul>
    <li>The XML Query WG and XSL WG sent review <a href=
    "http://www.w3.org/mid/20050913082804661.00000000668@amalhotr-pc">
    comments</a> in Sep 2005. We sent a <a href=
    "http://www.w3.org/mid/43843C24.1080901@hp.com">response</a> that
    addressed them in Nov 2005. A <a
    href="http://lists.w3.org/Archives/Member/w3c-semweb-cg/2006Feb/0071">20
    Feb 2006 communication in the W3C Semantic Web Coordination
    Group</a> (member-confidential) suggests that the XSL and XQuery
    WGs are satisifed; we have not heard further from them.</li>

    <li>We requested review from the <a href=
    "http://www.w3.org/2001/sw/DataAccess/BestPractices/">Semantic
    Web Best Practices and Deployment (SWBPD) Working Group</a> 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 SWBPD WG as a
    whole.</li>

    <li>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 2006 protocol draft is in sync
    with latest information we have gotten from the WSD WG and the
    Woden validator (see <a
    href="http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JanMar/thread.html#msg466">21
    March "wsdl fun" thread in DAWG</a>, <a
    href="http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2006Mar/0044.html">notice
    to wsd WG 21 March</a>).</li>

    <li>IETF review of SPARQL related media types
    (application/sparql-query, application/sparql-results+xml)
    began with review requests (<a href=
    "http://www.alvestrand.no/pipermail/ietf-types/2005-November/000895.html">query</a>
    r<a href=
    "http://www.alvestrand.no/pipermail/ietf-types/2005-November/000895.html">eview
    request</a> <a href=
    "http://www.alvestrand.no/pipermail/ietf-types/2005-November/000894.html">
    results</a> r<a href=
    "http://www.alvestrand.no/pipermail/ietf-types/2005-November/000894.html">eview
    request)</a> 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.</li>
  </ul>


  <p>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 sustained tension
  between a growing user and implementor community that is ready
  for the specification to advance despite any remaining flaws and a
  diligent review community that is insisting on a high level of
  rigor.</p>

  <p>We tracked <a
  href="http://lists.w3.org/Archives/Public/www-archive/2006Mar/att-0022/lc-status-report.html__charset_us-ascii">status
  of comments since July 2005</a>, including 55 cases of comments that
  the WG addressed to the documented satisfaction 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 <a
  href="http://www.w3.org/2001/sw/DataAccess/lc-status-report.html">comment
  status report</a> shows 9 threads where the WG and the commentor
  reached consensus, one case where the we
  "Corrected along the lines of your suggestion" and asked if it was
  satisfactory but have not seen a response. The remaining two threads
  are discussed under <a href="#obj">outstanding dissent</a> below.
</p>


<p>Changes since last call have been editorial changes and clarifications only.</p>

  </div>

  <div><h2 id="obj">Outstanding dissent (formal objections)</h2>

  <ol>
    <li>the WG RESOLVED <a href="http://www.w3.org/2001/sw/DataAccess/ftf2#initdn3">2004-07-15</a> to adopt BRQL v1.11 as its strawman query language design, over the <a href="http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JulSep/0101.html">objection of RobS and JeffP of Network Inference</a>:

    <blockquote>...XQuery, with minor extensions, would be the best
    overall foundation on which to enable query-based access to the
    family of Semantic Web languages. ...</blockquote>

    <p>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:</p>

    <blockquote>
      <p>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.</p>

      <cite><a
		href="http://www.idealliance.org/proceedings/xml05/abstracts/paper185.HTML">SQL,
      XQuery, and SPARQL What's Wrong With This Picture?</a></cite> by
      Jim Melton, Oracle Corporation; in <a
      href="http://www.idealliance.org/proceedings/xml05/index.html">proceedings
      of XML 2005</a>
    </blockquote>
    </li>
    <li>Requirement <a href="http://www.w3.org/TR/rdf-dawg-uc/#r3.6">3.6 Optional Match</a> was accepted <a href="http://www.w3.org/2001/sw/DataAccess/ftf2">2004-07-15</a> over the <a href="http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JulSep/0104.html">objection of  RobS of Network Inference</a>
    <p>Note that the objection concludes with:</p>
    <blockquote>
      ...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.
    </blockquote>
    <p>And while the theoretical issues with OPTIONAL have been
    expensive to work out, they seem to be specified to the
    satisfaction 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 <a href=
    "http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Mar/0070"
    >MacGregor 24 Mar 2005</a>.)</p>
    </li>

    <li>The <a href="http://www.w3.org/2001/sw/DataAccess/issues#DESCRIBE">DESCRIBE</a> issue was resolved over the objection of Dan Connolly:
    <blockquote>
      expectations around DESCRIBE are very different from CONSTRUCT and SELECT, and hence it should be specified in a separate query language
    </blockquote>
    <p>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.</p>
    </li>

    <li>Objective <a href="http://www.w3.org/TR/rdf-dawg-uc/#d4.2">4.2 Data Integration and Aggregation</a> was accepted <a href="http://www.w3.org/2001/sw/DataAccess/ftf3-brs#obj564">2004-09-16</a> over the <a href="http://lists.w3.org/Archives/Public/public-rdf-dawg/2004JulSep/0118.html">objection of Network Inference/Rob Shearer</a>:
    <blockquote>
      <p>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?</p>
    </blockquote>

    <p>A comment from outside the WG also says:</p>

    <blockquote>
      <p>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.</p>

      <p>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.</p>
      <address><a href="http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Apr/0010.html">Klyne  08 Apr 2005</a></address>
    </blockquote>

    <p>The FROM NAMED and GRAPH features 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.</p>

    </li>

    <li>The <a
    href="http://www.w3.org/2001/sw/DataAccess/issues#fromUnionQuery">fromUnionQuery</a>
    issue was resolved in our <a
    href="http://lists.w3.org/Archives/Public/public-rdf-dawg/2005AprJun/0411.html">2005-06-07
    meeting</a> 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:

<blockquote>
<pre>
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. abstaining: EricP, DaveB
</pre>
</blockquote>

      <p>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.</p>
    </li>

    <li>
      The <a
      href="http://www.w3.org/2001/sw/DataAccess/issues#rdfSemantics">rdfSemantics</a>
      issue was closed in our <a
      href="http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JanMar/att-0298/26-dawg-minutes.html#item04">2006-01-26
      meeting</a> over the objection of Pat Hayes, which was
      that the definitions are overly complex.  <p>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
      entailment 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.</p>
    </li>

    <li>On 22 February, Peter F. Patel-Schneider sent
    <a href="http://www.w3.org/mid/20060222.185654.133907622.pfps@research.bell-labs.com">comments on Section 1 and Section 2 of SPARQL Query Language for RDF</a>:
    <blockquote>
      <p>
In general I found the first two sections of the document <strong>very</strong> hard to
understand.  The mixing of definitions, explanation, information, etc. confused
me over and over again.  I strongly suggest an organization something like:</p>

<ul>
<li>  Introduction (informative)</li>
<li>  Formal development (normative)
<ul>
<li>    Underlying notions (normative)</li>
<li>    Patterns and matching (normative)</li>
</ul>
</li>
<li>  SPARQL syntax (normative)</li>
<li>  Informal narrative (informative)</li>
<li>  Examples (informative)</li>
</ul>

<p>
I also found that things that didn't need to be explained were explained, and
things that did need to be explained were not explained.  A major example of
the latter is the role of the scoping graph.  Examples showing why E-matching
is defined the way it is would be particularly useful.
</p>

<p>
Because of the problems I see in Section 2, I do not feel that I can adequately
understand the remainder of the document.
</p>
<p>
Because of these problems I do not feel that this document should be advanced
to the next stage in the W3C recommendation process without going through
another last-call stage.
</p>
    </blockquote>

    <p>Our <a href="http://www.w3.org/mid/1143049602.12963.360.camel@dirk.w3.org">response of 22 March</a> is:</p>

<blockquote>
<p>
After perhaps overly brief consideration of your comments, we are
somewhat sympathetic to your concerns about organization and
clarity; however, we also have schedule considerations
and the investment in other reviewers. Re-organizing the document
at this stage would delay things considerably; it's not even clear
that we could get a sufficient number of reviewers to take another
look before CR.
</p>

<p>
The specific examples you give below are very valuable; I
am marking this thread [needstest], which allows us to find
it more easily during CR and integrate the examples you give
into our test suite. We have also discussed the possibility
of significant organizational changes after CR, such as
moving the formal definitions to the back of the document.
</p>

<p>
As far as I can tell, all of the examples you give are useful
clarification questions, but they do not demonstrate design errors.
If they do, in fact, demonstrate design errors, I'm reasonably
confident we will discover that as we integrate them into
our test suite during CR.
</p>

<p>
Are you, by chance, satisfied by this response, which does
not involve making the changes you request at this time,
but includes an offer to give them due consideration after
we request CR? If not, there's no need to reply; I'm marking
this comment down as outstanding dissent unless I hear otherwise.
</p>
</blockquote>
    </li>

    <li>On 5 March, Elliotte Harold asked that we <a
    href="http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2006Mar/0006.html">don't
    use ? and $. Pick one.</a> He was not satisfied by our attempts to
    justify our decision as part of <a href="http://www.w3.org/2001/sw/DataAccess/issues#punctuationSyntax">punctuationSyntax issue</a>:
    <blockquote>
      <pre>
> >> A number of design considerations were laid out in:
> >> <a href="http://lists.w3.org/Archives/Public/public-rdf-dawg/2004OctDec/0160">Draft: open issues around '?' use.</a>
> >>
>
> 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 <a href="http://www.w3.org/TR/2004/WD-rdf-sparql-query-20041012/">1st
WD in October 2004</a>

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.
      </pre>
    </blockquote>
 </li>
  </ol>

  </div>

<address>
Dan Connolly, <a href="./">RDF Data Access Working Group</a> chair, 22 March 2006<br/>
<small>$Revision: 1.35 $ of $Date: 2006/04/04 16:09:12 $</small>
</address>


<hr />
<div><h2>Ammendments</h2>

<p>Changes since <a
href="http://lists.w3.org/Archives/Public/public-rdf-dawg/2006JanMar/0470.html">email
proposal of 21 Mar 2006 18:27:57 -0600</a>:</p>

<pre>
$Log: crq349.html,v $
Revision 1.35  2006/04/04 16:09:12  connolly
Network Inference/Cerebra withdraws their
objection to the Result Limits requirement
in a message of Fri, 31 Mar 2006 18:04:07 -0800

Revision 1.34  2006/03/29 13:05:35  connolly
a link to "obj" fixed to "#obj"
most recent protocol spec is Jan 2006, not Jan 2005
tx Ivan

Revision 1.33  2006/03/27 14:09:16  connolly
disjuction objection withdrawn (see w3c-archive)

Revision 1.32  2006/03/22 18:24:31  connolly
found a form of confirmation of XQuery/XSL WG satisfaction

Revision 1.31  2006/03/22 18:12:58  connolly
moved status at top to signature at bottom

Revision 1.30  2006/03/22 18:10:50  connolly
noted PFPS's comments of 22 Mar under outstanding dissent,
and noted our attempt to seek consensus within schedule constraints

Revision 1.29  2006/03/22 18:04:02  connolly
clarify which features are related to outstanding
dissent on Data Integration and Aggregation

Revision 1.28  2006/03/22 17:06:08  connolly
- added changelog

- re-phrased the record of WG decision

- distinguished proposed status with blockquote, grey, border

- matched brackets around "tune to each part"
- ...has stabilized +and+ the...
- +An+ implementation report...
- spellcheck: language, sustained, remaining, diligent,
              satisfaction (x2), abstaining, entailment

</pre>
</div>

</body>
</html>