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

Re: Comments on SPARQL protocol document

From: Kendall Clark <kendall@monkeyfist.com>
Date: Fri, 16 Sep 2005 08:32:31 -0400
To: Graham Klyne <GK@ninebynine.org>
Cc: public-rdf-dawg-comments@w3.org
Message-ID: <20050916123231.GF9375@monkeyfist.com>

On Fri, Sep 16, 2005 at 10:09:10AM +0100, Graham Klyne wrote:
> 
> With reference to:
> http://www.w3.org/TR/2005/WD-rdf-sparql-protocol-20050914/
> 
> I have not close-read this.  On a quick skim, two thoughts come to mind:

Graham, thanks for your comments. A few quick notes in response, though this
is only a personal response, not one from the WG:

> (1) the SPARQL query language makes reference to the possibility of
> generating warnings under certain circumstances; cf.
> http://www.w3.org/TR/2005/WD-rdf-sparql-query-20050721/#construct
> 
> In light of this, it might be appropriate for there to be some way to
> return any warnings along with the query results.

Not sure what you mean about including warnings with the query results. Do
you mean a warning in the protocol itself or including a warning in the
query results themselves?

One way to read the QL spec ("a warning may be generated") is that one of
the protocol faults is returned instead of query results. But I agree that
it's vague and underspecified as-is. That may be intentional, but I'm not
sure.

My personal inclination is to return one of the faults already defined, to
define another one, if necessary, or to add some kind of warning facility
into the results themselves.

> (2) Security considerations

> Concerning anonymizing services, there may well be reasons for not
> providing client information.  E.g., I have recently been told that
> there is a principle in library systems that a reader should be able to
> access any publicly available information anonymously.  Making the
> logging of client identification a normative requirement seems to be in
> violation of this principle.

Well, it's a "should", not a "must", but I take yr point and will think more
about it. At the very least I suspect you are right that the prescriptivity
should be removed.

> Concerning privacy, the normative "must take care that facts disclosed
> in or implied by query results do not violate applicable privacy ..."
> also seems to be over-prescriptive.  Again, I think that mention of this
> issue is appropriate, but I also think that the appropriate response to
> this is really a matter for the application, not the protocol
> specification.  I think it would be more helpful to suggest possible
> technical remedies.

Can you suggest some?

> In particular, I think it would be helpful to suggest ways in which
> authenticating information can accompany a query, so that the
> information service that is being queried can decide whether or not it
> is appropriate to release the requested information. 

Ah, yes, that should be mentioned in the policy section.

> Also, suggest
> mechanisms for maintaining privacy of the query results.  I imagine such
> suggestions might simply be references to appropriate security protocol
> specifications, but I also note that security mechanisms at several
> levels might be applied (e.g. TLS/https, SOAP-level security
> mechanisms, MIME object security mechanisms, XML-level security
> mechanisms, etc.).  Does the working group have any view concerning what
> mechanisms are most appropriate for a general-use SPARQL query protocol
> implementation?

I can't speak for the WG, of course, but I don't remember much conversation
about that, specifically. That doesn't preclude us having a view, but I
don't know what it is. :>

> Also on the subject of security considerations, I think it would be 
> worth mentioning the problems of spoofed server responses, and 
> suggesting use of mechanisms that allow the client to authenticate the 
> SPARQL query server and/or results.  It also occurs to me that the query 
> processor may need to be able to relay authenticating information from a 
> back-end or 3rd-party information source.

Okay, spoofing servers (especially via IRI hacks) also seems worth mentioning.

> ...
> 
> Also, I note that the reference for RDF-Concepts contains a URI for the
> RDF-primer ("This version").

ACK.

Cheers, 
Kendall
--
In times of universal deceit, telling the truth is a revolutionary act.  
					  --George Orwell
Received on Friday, 16 September 2005 12:33:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:14:49 GMT