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

Re: Review of http://www.w3.org/2001/sw/DataAccess/proto-wd/

From: Kendall Clark <kendall@monkeyfist.com>
Date: Mon, 5 Sep 2005 09:39:12 -0400
To: "Eric Prud'hommeaux" <eric@w3.org>
Cc: DAWG public list <public-rdf-dawg@w3.org>
Message-ID: <20050905133912.GB29473@monkeyfist.com>

On Fri, Sep 02, 2005 at 06:32:11PM -0400, Eric Prud'hommeaux wrote:
> or something like that. I'm not saying the current words are
> specifically inaccurate, but they do let one make a wrong assumption
> which is corrected by further reading of the spec.

Oh, hmmm, well I understand yr point now. I don't find it very compelling,
but if there are other people who have the same misreading, I'll tweak this.

> > > s/an SPARQL query/a SPARQL query/ as SPARQL is always voiced as a word
> > > rather than an acronym.
> > 
> > Right, which is one reason why "SPARQL Query Language" in the QL spec is
> > fine, despite Andy's claims to the contrary. I sent him this exact comment
> > (about "SPARQL" acting like a noun rather than an acronymy)... Oh well, so
> > much for inter-spec consistency.
> 
> Aha, so I should look inwards before looking at other specs. Pointer?
>   http://www.w3.org/Search/Mail/Public/search?type-index=public-rdf-dawg&index-type=t&keywords=SPARQL+noun+Kendall&search=Search
> got only your message to me.

My point to Andy (and, indirectly, to you) was that the QL spec uses
"SPARQL" to stand for the query language, whereas the protocol spec uses
"SPARQL Protocol" or "SPARQL Query Language" so as to avoid ambiguity. In
response Andy said that "SPARQL" is an acronym, and thus, "SPARQL Query
Language" was equivalent to "SPARQL Protocol and Query Language Query
Language" -- in which case I retorted that, no, "SPARQL" acts like a noun,
is not necessarily expandible in all contexts, and that "SPARQL Query
Language" and "SPARQL Protocol" are perfectly find circumlocutions.

Now yr agreeing with me re: how "SPARQL" is voiced, and I was suggesting, as
a consequence, that we might want the specs to be consistent on this point.

> Technically, neither is HTTP (in OSI-parlance, it's a transfer
> protocol; TCP is a transport protocol). It would be nice to get
> the reader pointed in the right direction, but I don't get the
> impression that you are interested in this level of nitpicking.

No, I actually am, but only when it seems substantive instead of merely
stylistic. Maybe I misunderstood this issue though?

> Hmm, rereading [[
> In the case where both the query and the protocol specify an RDF
> dataset, but not the identical RDF dataset, the dataset specified in
> the protocol must be the RDF dataset consumed by SparqlQuery's query
> operation.
> ]], I think it says it. Maybe an extra sentence will cement the point:
> 
> "Thus, if the protocol specifies either a default-graph-uri or
> any named-graph-uris, the query operation MUST ignore any FROM
> or FROM NAMED directives in the SPARQL query string."
> 
> I'm not super-pleased with introducing "directive", but I feel it's
> worth it to clarify that one can't, say, override the default graph
> without wiping out all the named graphs.

I honestly believe the extant language says that by virtue of "the dataset
specified in the protocol must be the RDF dataset consumed..." -- I'm unsure
whether adding yr sentence really strengthens the point. I'll have to think
about this some.

> or "kosher". i still like "kosher".

Hmm, latkes. :>

> "are not properly encoded". Well, they're not encoded at all. I went
> hunting for the best word (crums below), but the best I can think of
> to replace "properly encoded" is "urlencoded".

I think anyone with even passing familiarity with HTTP will grok "properly
encoded". But "url-encoded" will work, too. I'll change this.

> np. Thanks for your work.

Cheers, 
Kendall
Received on Monday, 5 September 2005 13:40:17 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:24 GMT