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

Re: [EDITORIAL] Preface of rq24

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Tue, 19 Sep 2006 08:35:31 +0100
Message-Id: <02B948FF-64DF-433A-B46A-839CBB83A138@cs.man.ac.uk>
Cc: Kendall Clark <kendall@monkeyfist.com>, Ivan Herman <ivan@w3.org>, "Ralph R. Swick" <swick@w3.org>, Dan Connolly <connolly@w3.org>, RDF Data Access Working Group <public-rdf-dawg@w3.org>, Sandro Hawke <sandro@w3.org>
To: Eric Prud'hommeaux <eric@w3.org>

On Sep 19, 2006, at 8:06 AM, Eric Prud'hommeaux wrote:

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

I cc your coauthors so they can respond directly.

> 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?"

All the forms of distinct, except term-distinct, "recognize" (give  
the same answers to up to isomorphism) logically equivalent graphs.  
Now, it is true that I underemphasized term-distinctness (though I  
believe Andy's post mentioned it), but the choice isn't between term- 
distinct and (some other form), but between term-distinct, and source- 
lean distinct, and answer-lean distinct.

So I think it's imprecise and actutally requires far more context  
than the simple "What is the definition" variants.

>>> 	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?"

Yes that's fine.

> though I am not sure the world will comprehend the interaction between
> entailment and contradictory KBs...

They don't need to.

>>> 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)

I object to the parenthetical. For example, DISTINCT is independent   
to a large degree to the underlying BGP semantics. Furthermore,  
DISTINCT was *unspecified*, that is, it didn't have a settled  
semantics in the 1st last call.

So, I'm not sure that "many" of these issues revolve around that.

I would raise it as a distinct issue thought. But it's not like  
settling "Query RDF syntax or semantics" will *settle* everything. It  
will be suggestive and directive, of course.

> 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
>       graphs?

As above, I object.

>     * Should SPARQL care about graphs that are inconsistent by
>       D-entailment?

"Care about?" Obviously, on any approach, it "*cares*" about them.  
How about:
	What are the answers of a query against an inconsistent KB?

(A la Kendall?)

>     * 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.

See above. Kill the parens, and I would prefer "graph structure" be  
replaced with the more transparent "syntax".

Received on Tuesday, 19 September 2006 07:42:22 UTC

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