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

Ambiguity with protocol bindings to HTTP

From: Chimezie Ogbuji <ogbujic@ccf.org>
Date: Mon, 16 Aug 2010 12:37:52 -0400
To: "SPARQL Working Group WG" <public-rdf-dawg@w3.org>
Message-ID: <C88EE1A0.12ECA%ogbujic@ccf.org>
In thinking about where there is ambiguity with the various protocols and
how they bind to HTTP, it seems like if we separate along the following
criteria, it is easier to clarify what are appropriate bindings to HTTP:

1. Languages v.s. Representations ( application/sparql v.s.
application/xml+rdf )
2. Operations that target service endpoints v.s. Operations that target
named graphs (via their graph IRIs)
3. How clearly HTTP specifies the semantics of the verbs (PUT, DELETE, GET,

For operations that directly identify named graphs, use representations, and
make use of well-defined HTTP verbs (GET, PUT, and DELETE), even though the
operations can be replicated with via the 'languages' there is no ambiguity
because it is just two styles for doing the same thing:

CONSTRUCT { ?s ?p ?o }
  GRAPH <http://example.com/rdf-graphs/employees> { ?s ?p ?o }


GET /rdf-graphs/employees HTTP/1.1
Host: example.com
Accept: application/rdf+xml

You might might prefer to use the second if in your deployment scenario it
was important to be able to leverage native HTTP capabilities (such as
security, cacheability, etc.)

For operations involving HTTP methods that are not so clearly defined (such
as POST), it seems to be mostly a question of what are the common use cases
for HTTP when the body is a representation:

- Append triples to a named graph, or
- Create a named graph whose graph IRI is determined by the server
- .. Others? ..

However, if the body is a language (SPARQL Update or SPARQL Query) *and* the
request URI is associated with a named graph, then it is not so clear if
there is any advantage in providing an HTTP mechanism for a controlled
subset of the language.  For example, in the case of SPARQL Query (as TimBL
was suggesting), you can interpret the operation to be directing a query
against the named graph alone but then you need a proviso for situations
where the body doesn't match this intent such as where a GRAPH operator is
used with a different graph IRI, for instance.

It might be better off having such operations target services or endpoints
instead where the request is fully defined by the language.

However, PATCH would seem like an exception.  Despite the fact that it may
be less supported, the operation is well-defined and expects the request to
include a set of instructions (presumably in a particular language) to
determine how the identified resource is modified.  So, it seems reasonable
to interpret a PATCH message where the request URI is a graph IRI and the
body is a SPARQL Update instruction as a request to modify the associated
named graph and that graph only (so if the request has instructions that
target a different graph, then a 400 - Bad Request - is returned).

-- Chime


P Please consider the environment before printing this e-mail

Cleveland Clinic is ranked one of the top hospitals
in America by U.S.News & World Report (2009).  
Visit us online at http://www.clevelandclinic.org for
a complete listing of our services, staff and

Confidentiality Note:  This message is intended for use
only by the individual or entity to which it is addressed
and may contain information that is privileged,
confidential, and exempt from disclosure under applicable
law.  If the reader of this message is not the intended
recipient or the employee or agent responsible for
delivering the message to the intended recipient, you are
hereby notified that any dissemination, distribution or
copying of this communication is strictly prohibited.  If
you have received this communication in error,  please
contact the sender immediately and destroy the material in
its entirety, whether electronic or hard copy.  Thank you.
Received on Monday, 16 August 2010 16:53:09 UTC

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