Re: Graph store protocol editor's draft updated

On Tue, 2012-02-28 at 02:27 -0500, Chimezie Ogbuji wrote:
> Thanks for the review, I have incorporated changes from these
> suggestions (along with changes to the abstract from Sandro from later
> in this thread).  See below.

Looks okay to me.   (It still obviously has the problem with how one
finds the graph store URI -- we're making a big mistake here --  but I'm
not going to fight for that any more.)

    -- Sandro

> On Mon, Feb 6, 2012 at 2:47 PM, Birte Glimm <birte.glimm@uni-ulm.de> wrote:
> > Change summary: Does this really just describe the changes since last
> > pub? I had the impression that the title of the document changed quite
> > some time ago, but I didn't check this.
> 
> This has been updated to better reflect recent changes since earlier
> publication.
> 
> > Sec.1: I didn't get the second sentence and how the enumeration items
> > are constraints.
> 
> I have added a clarifying sentence after the list to better describe
> how they are constraints and how they are met.
> 
> > Sec. 3: There is an extra space before the full stop of the second sentence.
> 
> Fixed
> 
> > Fig. 1&2: The figures are hard to read on a b/w printout since only
> > the yellow/orange colour is really different from the others. Although
> > most people will read on the screen, it might be helpful to use
> > dashed/dotted lines or more distinct colours even when printed b/w.
> > Fig.1 has a legend, but Fig. 2 does not.
> 
> Figure 2 is meant to use the same legend as in figure 1.  I have added
> this to the label of Fig. 2.
> 
> In general, I do not really
> > understand how to read the diagrams. It is difficult to see where to
> > start reading. I somehow expected something that illustrates the flow
> > of sending a GET request and how this leads to the identification of a
> > relevant set of triples/a graph, but somehow I can't see that in the
> > Figures.
> 
> I have added a short clarifying sentence for both figures:  "Requests
> to an implementation of this protocol receive HTTP requests using one
> of the HTTP methods that is directed at some RDF graph content.  Above
> the arrows indicating the request is the relevant HTTP methods and
> below is any message body content or additional headers that accompany
> the request.  At the head of the arrows leaving RDF graph content is
> the message body for the corresponding response"
> 
> > In several places sentences start with "So, ...", which is not good
> > style (at least I learned that). For example, in the two paragraphs
> > following Fig. 2.
> 
> I have replaced all sentences that begin this way.
> 
> > Paragraph before 5.1: to the manipulation af RDF graph content: s/af/of/
> 
> Changed
> 
> > Sec. 5.1: involving a*n* RDF payload
> 
> Changed
> 
> > Sec. 5.2.1: returned from dereferencing a*n* IRI (I think so)
> > Why does the paragraph end in a semicolon?
> 
> Both changed.
> 
> > Sec. 5.3: "and using the with an IRI" does not make sense
> 
> Changed to "is empty and there is sufficient authorization to create a
> new named graph using the IRI used in the request IRI"
> 
> > Paragraph before 5.5: The response codes were usually set in
> > typewriter, but 202 (accepted) is not
> 
> Changed
> 
> > Sec. 5.5: contains "Networked-manipulable Graph Store" although the
> > change summary said that this term is replaced with just "Graph Store"
> 
> Fixed.
> 
> -- Chime
> 
>

Received on Tuesday, 28 February 2012 12:16:15 UTC