W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2006

Re: [EDITORIAL] Preface of rq24

From: Eric Prud'hommeaux <eric@w3.org>
Date: Tue, 19 Sep 2006 09:06:24 +0200
To: Kendall Clark <kendall@monkeyfist.com>
Cc: Bijan Parsia <bparsia@cs.man.ac.uk>, RDF Data Access Working Group <public-rdf-dawg@w3.org>
Message-ID: <20060919070624.GB30275@w3.org>

After going through the wordings with Ivan, Ralph, DanC and Sandro,
we came up with some new wording that are hopefully precise without
requiring too much context.

On Sun, Sep 17, 2006 at 06:53:05PM -0400, Kendall Clark wrote:
> On Sep 12, 2006, at 7:26 AM, Bijan Parsia wrote:
> >
> >http://www.w3.org/2001/sw/DataAccess/rq23/rq24.html
> >
> >I would prefer that:
> >	Should DISTINCT be based on lean graphs?
> >Be phrased as
> >	What is the definition of DISTINCT?
> I agree with this suggestion to the editors.

"Should the keyword DISTINCT recognize logically equivilant graphs?"

> >	Should SPARQL care about graphs that are inconsistent by D- 
> >entailment?
> >
> >as:
> >	What are the answers of a query of a D-inconsistent graph?
> And with this one too.

We preferred Kendall's wording
"What are the answers to a contradictory KB?"
though I am not sure the world will comprehend the interaction between
entailment and contradictory KBs...

> >Finally, I would prefer a different phrasing for:
> >	"""Many of these issues reduce to "Is SPARQL a graph query  
> >language or a higher level query language?" """"
> I *really* dislike this current phrasing; it's far too tendentious to  
> be useful. What is a "higher level query language" anyway?
> >But without specifying which issues do so and how, I think it's  
> >more confusing than helpful.
> Agreed.

We put a lot of thought into this one and arrived at
Many of these issues revolve around, "Should SPARQL be sensitive to
only the graph structure (per the 1st last call semantics) or the
semantics of RDF graphs as well."
with a link back to an appropriate part of LC1.

I was advised that
"Is datatype/operator extensibility expressed sufficiently?" was an
issue between editors and should not be in the document that the world
sees. Kendall, could this markup go into the issues list instead?

    <p id="openWorldValueTesting" class="issueBlock"><span class="issueTopic">Open Issue</span>: <a href="http://www.w3.org/2001/sw/DataAccess/issues#openWorldValueTesting">Is datatype/operator extensibility expressed sufficiently?</a><br/>
      <span class="issueTopic">Current specification</span>: extensions done by subtyping from xsd and by adding operator mappings above.<br/>
      <span class="issueTopic">Alternative proposal</span>: have XPath tests invoke <a href="http://www.w3.org/mid/44D317F2.2080006@hp.com">sop:value-compare</a>, which in turn defines a relationship to the above functions for the supported operand types.<br/>
      <span class="issueTopic">Costs</span>: extra level of indirection; does not address XPath Arithmetic.<br/>
      <span class="issueTopic">Benefit</span>: a partial extension that defines = but not &lt; can pass some &lt;= tests.</p>

On Tue, Sep 12, 2006 at 12:26:17PM +0100, Bijan Parsia wrote:
> About:
> 	Should isLiteral observe D-entailment? Should it validate lexical  
> values?
> I thought we settled that isLiteral applies only to literals (not  
> data values). Forgive me if I perpetuated a confusion there. The  
> issue in question is whether operators should apply to arbitrary data  
> values, or to ones with literal form only.

Given this, I removed this issue as well, yielding
Pending issues:

    * Should SELECTed variables be separated by commas?

    * Should the keyword DISTINCT recognize logically equivilant

    * Should SPARQL care about graphs that are inconsistent by

    * Should blank nodes be treated differently than variables in the
      query pattern?

Many of these issues revolve around, "Should SPARQL be sensitive to
only the graph structure (per the 1st last call semantics) or the
semantics of RDF graphs as well." The working group could use guidance
from the community on this point.

home-office: +1.617.395.1213 (usually 900-2300 CET)
cell:       +

Feel free to forward this message to any list for any purpose other than
email address distribution.
Received on Tuesday, 19 September 2006 07:05:19 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:51 UTC