Followup Review of Graphstore HTTP Protocol, for LC

Short version: This spec is too SPARQL-centric, both in editorial ways
and in the design of the protocol.  As I read our charter (the wording
on this is not very precise), we're supposed to define the way HTTP
verbs work on "RDF graphs".  But this spec ends up more suggesting
than defining (lots of SHOULDs, few MUSTS), while also enforcing a
world-view that is too SPARQL centric for many REST users.  I think
will cause a lot of confusion in the market, and as it stands, this
document might actually do more harm than good.

For me to support this document, I'd need to see the following
non-trivial changes (in addition to some trivial editorial changes,
listed later).  Also, procedurally, it's not good form to publish a
next version without being responsive to all timely comments on the
previous version; I believe we still have the one from Arnaud
outstanding.

I want to be very clear that I think Chime is doing a good job as
editor of this spec.  My non-trivial comments concern the guidance and
decision from the Working Group, not editorial issues.  And I don't
fault anyone in the WG, except perhaps myself for not understanding
these matters clearly earlier.  Also, if we need to postpone this
document getting to Last Call, I don't see any need for that to delay
any of the other documents.

My substantial issues:

1.  Take "SPARQL" out of the title.  One goal of this protocol is to
be an alternative to SPARQL Update; the fact that it was defined by
this Working Group should be nothing more than a footnote in history.
Having SPARQL in the title will cause people to completely
misunderstand it.  I suggest something like "RDF REST Protocol Level
1."  In general, I think the SPARQL bits of the document need to be
winnowed and flagged, but that would be hard to do on our timeframe,
and is editorial.

2.  Change the term "RDF Graph Content" to something better.  The RDF
WG resolved at its F2F2 to use the term "Graph Container", which I
think could reasonably be rendered as "RDF Graph Container" when
ambiguious.  Lately, I've been arguing for "(RDF) Graph-State
Resource", but that hasn't been discussed much yet by the RDF WG.

     http://www.w3.org/2011/rdf-wg/meeting/2011-10-12#resolution_1
     http://lists.w3.org/Archives/Public/public-rdf-wg/2011Dec/0033

3.  Change the semantics of POSTing RDF to an RDF Graph Container.  The
current draft says a POST "SHOULD" be understood as a request to merge
new content.  This makes some sense when thinking only of graphstores,
but for the wider world of things that want to provide a REST interface
to RDF, I think that's too restrictive.  For instance, POSTing to some
sort of "directory" or "collection" (even if it's also represented by
RDF) should be allowed to mean "Create a new resource at a different
location" (the original meaning of POST).  The "SHOULD" in the current
draft precludes that perfectly reasonable design.  We can change it to
a "MAY" or just say that we're silent on this kind of POST.   This
change doesn't force Steve to change any code -- if resources hosted by
his code treat POST as MERGE, that's fine -- they're just members of a
more-restrictive class of resources.

4.  This is a somewhat weaker issue: I think probably all the
occurances of "SHOULD" need to change to "MUST".  As it is, server
implementors have so much leeway, that a client knows almost nothing
of what to actually expect from a server, even if it knows the server
complies with this spec. 

5.  SPARQL 1.1 Update should, however, not be selected as the PATCH
format that every server "SHOULD" implement it, as in the current
draft.  "It's too much work to implement" is not a legitimate reason to
go against a "SHOULD", so this forces everyone to implement all of
SPARQL 1.1 Update to be in conformance.  That's too high a bar for a
protocol that's supposed to be a simpler alternative to SPARQL Update.
(The section is labeled "Informative", but that makes no sense to me,
since it has content which clearly bears on conformance.  The
"informative" label allows people to skip sections which are purely
explanatory, without affecting conformance.)  Unfortunately, the spec
is very weak without some other PATCH format. I did start to sketch a
possible solution here:

   http://www.w3.org/2001/sw/wiki/TurtlePatch

I know it's late for this.  Maybe the REST document can be silent about
this, and we can do TurtlePatch as a very short WG Note.

That's it, I think.  There are a few issues about Service Description
and the connection between the endpoint address, the graphstore/dataset
address, and the service address, but ... I can live with the current
design, and don't have a much-better one handy.  The one obvious thing
would be to say that the service address is the endpoint address, and
that it's entirely optional -- if you're not doing SPARQL, you probably
don't have either one.   

Actually, I'm going to send this now, and leave the trivial editorial
stuff for later, since we're meeting to talk about this in 11.5 hours.

      -- Sandro

Received on Monday, 19 December 2011 03:30:06 UTC