Re: Graph store protocol editor's draft updated

On Tue, 2012-02-28 at 15:07 +0100, Axel Polleres wrote:
> Hi Sandro, Chime,
> 
> Thanks, just to get that clear: Does that mean approval for LC?
> Are there any open issues or comments left?

It's okay for LC from me.    Agreed, Birte is probably fine with it
given Chime's changes, but, yes, we should hear that from her.

Greg and Chime had some back and forth on 2/17 that might be leaving
Greg unhappy, with his last comment being:
        
        I'd suggest either including the text from Update about a graph
        store including one unnamed and any number of named graphs, or
        adding text that explicitly states that the GSP uses the
        definition of "Graph Store" from the Update document.

I don't see a response from Chime on that, but I might have just missed
it.

       -- Sandro

> 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:52:01 UTC