Re: Graph store protocol editor's draft updated

Hi Sandro, Chime,

Thanks, just to get that clear: Does that mean approval for LC?
Are there any open issues or comments left?

If I see it correctly, in that case we only miss Birte's final approval to
to vote for publication, don't we? 

Thanks Chime (and also  Sandro & Birte!) for your efforts,
Axel

On 28 Feb 2012, at 13:16, Sandro Hawke wrote:

> 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 14:08:31 UTC