Re: Followup Review of Graphstore HTTP Protocol, for LC

Short version: while I don't agree on most of this, now that we have
addressed point 3, if we address point 5, I can live with it.  Which is
to say, I still disagree, strongly, but I don't think this is the most
important thing for me (let alone you all) to be spending the next few
weeks on, and that's starting to look like what it will take.

On point five, I did a quick check with my boss, who agreed, "The very
purpose of having MUSTs and SHOULDs is to be normative.  A section
marked as informative by its very definition doesn't include normative
statements.  Hence, no MUSTs and SHOULDs."

I don't think we can justify saying, as in the current draft, that
Graphstore HTTP Protocol implementations SHOULD also implement SPARQL
Update.  So I suggest we take that bit out, and leave on the label
"informative".  

    -- Sandro



On Tue, 2011-12-20 at 07:56 -0500, Chime Ogbuji wrote:
> See my response inline below.
> 
> -- 
> Chime Ogbuji
> Sent with Sparrow
> On Sunday, December 18, 2011 at 10:29 PM, Sandro Hawke wrote: 
> > Short version: This spec is too SPARQL-centric, both in editorial ways
> > and in the design of the protocol. 
> Unfortunately, I still don't know what you mean by SPARQL-centric as it is a protocol for managing something introduced in this round of SPARQL specifications (Graph Store). As I've mentioned before, the term SPARQL no longer applies only to the query language.
> > 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.
> It would be useful for you to be more precise about the 'harm' that will be caused. This is not clear to me from either this email or others in the past. Your main concern has been regarding a very specific scenario that I'm not convinced is ruled out. Please clarify this statement.
> > 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.
> Yes, note however none of the issues in that comment coincide with the issues you list as non-trivial(as was pointed out in the mini teleconference). 
> > 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. 
> Certainly. Similarly, please understand that my objections are on principal - I do appreciate your comments regarding this document.
> > 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.
> Im not in agreement with this change. As it has been said before, we have discussed the title repeatedly (based on suggestions and concerns from both within the WG and from outside comments) and even had a WG resolution on the matter if I'm not mistaken. So, I for one consider the matter settled. I suspect we will need another formal proposal vote if we even decide to re-open this concern. In addition, we also agreed in principle that all the documents should share the same prefix in their title (this document used to not have SPARQL in its title, but it was added for this reason). 
> > 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.
> Similar to the previous point, I'm not inclined to change this given how much effort has already been spent attempting to reach consensus on a term and within a thread involving many individuals. IMHO, the WG has discussed this sufficiently.
> 
> > 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.
> See the most recent proposal and I'm ok with your changes to it (as is Steve). 
> > 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. 
> I don't think there is a substantive justification for this. The pattern of SHOULD/MUST was lifted from RFC2616, with the reason being that an implementation of this protocol should essentially be no more than an HTTP 1.1 server with a more nuanced understanding of what to do with HTTP operations performed on the content it manages. So, your argument would apply to all HTTP servers and that they are sanctioned by this pattern of SHOULD/MUST in RFC2616 has not been a hinderance or cause for concern about ambiguity regarding HTTP clients and servers in general. 
> > 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. 
> It makes simple sense to me. Content in that section does not bear on conformance. Further, your issue with burden of implementation to me seems like one of a bunch of possible 'valid reasons in particular circumstances' to not follow a SHOULD/RECOMMENDED (as RFC 2119 - gives leeway for this) .
> > The
> > "informative" label allows people to skip sections which are purely
> > explanatory, without affecting conformance.) 
> Actually, I've seen the informative label used to defining behavior that was not expected of all implementations - which is the intent here. You can still specify behavior in an informative manner - using the natural english language sense of the word (to provide useful or interesting information).
> > Unfortunately, the spec
> > is very weak without some other PATCH format. 
> You will need to further explain this criticism. Note that the few comments we received regarding PATCH don't suggest any concerns with the use of Update being inadequate or burdensome. See, for example:
> 
> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2010Oct/0060.html
> 
> > 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. 
> Per yesterday's teleconference. All mention of services (and service descriptions) will be removed.
> 
> 
>

Received on Tuesday, 20 December 2011 14:13:29 UTC