Re: Comments on HTTP Protocol for Managing RDF Graphs

Hey David.  Thanks for the comments.  Since this didn't go to

 public-rdf-dawg-comments@w3.org

I'll (personally) respond here.

On Fri, Oct 15, 2010 at 2:57 PM, David Booth <david@dbooth.org> wrote:
> Hi Chimezie,

> I just looked through
> http://www.w3.org/TR/2010/WD-sparql11-http-rdf-update-20101014/
> Thanks for your work on this.  Some suggestions:

> 1. Section 4.1 says that the request URI "is meant to identify RDF
> triples", and it says that it identifies "the RDF knowledge that is
> represented by an RDF document".  I think both of these
> characterizations are problematic because they are both immutable,

4.1 should say "is meant to identify the meaning of a set of RDF
triples" (the RDF 'knowledge')

> whereas the point of this protocol is to specify how HTTP can be used to
> modify graphs.

It specifies how HTTP can be used to modify 'RDF knowledge' (an
insert-here term for what the IRIs/URIs of named graphs identify, not
the named graphs themselves - this indirection is introduced from
SPARQL 1.0).  All the request URIs identify RDF knowledge in a 'graph
store' that is manipulated over the protocol.  Yes, the RDF graphs
themselves are immutable, but you can replace them with another that
has the same URI for a 'name' (as you discuss below).

> In other words, the URI needs to identify the
> *container* -- not the (current) contents of that container.

The named graphs comprise the content but the request URIs in the
protocol don't identify them directly.  I guess you can think of an
interpretation (or semantic structure) of an RDF graph as that
container, but in what sense of a 'container' do you mean?

> The
> contents of the container may be a particular set of triples, but a set
> is an abstract concept that can never be changed, just as the number 42
> can never be changed.  But if the URI identifies the *container*, then
> we *can* change the content to hold a different set of triples, which
> the URI still identifies the same container.

I believe you can do this already and this is why the term 'RDF
knowledge' is used.

> 2. Section 8 quotes the AWWW definition of "information resource".  I
> think this definition is well known to be flawed, and hence should not
> be perpetuated or used as the basis of any sort of logical argument.

There isn't any 'logical argument' (if you mean this in the formal
sense) being made; the language of the architecture of the web is
being used to better relate SPARQL with that of the traditional web.
Whether or not the definitions in that document are 'flawed' (I would
like to hear what  Ian Jacobs, Norm Walsh et al. have to say about
this) is not at issue with this protocol, but at least it gives useful
distinctions regarding "web resources".

We received a comment here:

http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2010Apr/0003.html

that was requesting the use of httpRange-14 as a normative reference.
We decided to provide a developer with an explanation of how this
protocol interoperates in the face of the issues in that discussion,
which requires a discussion of an 'information resource' and its
relationship with RDF graphs.

> 3. Actually, I think the whole httpRange-14 issue and the question of
> what the URI "identifies" is a distraction from the main goals of this
> document

See above.  It is consistent with the goals, the distinction between
named graphs and what their URIs identify, what the RDF graphs 'mean',
and how to modify this meaning over HTTP.

> and can be omitted entirely if the document instead focuses on
> what is supposed to happen for each HTTP operation, much like the way
> RFC 2616 focuses on what is supposed to happen rather than delving into
> theoretical points about what a URI identifies.

This part is meant to be 'informative' - and not theoretical - in
response to a comment to help clarify the relationship with that
issue.  See (ISSUE-49 Is a graph an information resource) .

http://www.w3.org/2009/sparql/track/issues/49

> In other words, I
> suggest framing this document more narrowly as a protocol spec rather
> than as an architectural analysis:

It was meant to be both.

>  - GET on the URI of an RDF Graph Store with no "?graph=..." query
> parameter returns the default graph;

Good idea, I think that addresses (ISSUE-63 Handling of default graph
in HTTP update protocol)

>  - GET using the "?graph=..." query parameter returns the specified
> graph;

I'm not sure what you mean.

>  - PUT replaces the graph; etc.
>
> I think this will significantly simplify the document and make it more
> accessible and convincing to a wider audience.

Those sections are marked as (informative).  I'm not inclined to
change them because they were meant to inform semantic web developers
about the architecture of the web (and the related issues).

> 4. Typos:
>
> s/The response to such a SHOULD/The response to such a request SHOULD/
>
> s/SHOULD be be understood/SHOULD be understood/

Thanks. I will change in the editor's draft (I need to change back the
status anyways).

-- Chime

Received on Sunday, 17 October 2010 00:47:31 UTC