- From: Luke Wilson-Mawer <luke.wilson-mawer@garlik.com>
- Date: Mon, 19 Oct 2009 18:48:19 +0100
- To: Paul Gearon <gearon@ieee.org>
- CC: Simon Schenk <sschenk@uni-koblenz.de>, "public-rdf-dawg@w3.org Group" <public-rdf-dawg@w3.org>
Hi Paul, Comments inline. Luke Paul Gearon wrote: > This is just because <i></i> and <b></b> are not permitted. I've been > replacing <i> with <em> and it looks better. > Excellent. > >> * Subheadings are inconsistent. Issues headings aren't graded >> particularly clearly; it's hard to see where an issue begins and ends. >> > > I'll look at this, but specific suggestions would be appreciated. > > I suppose this isn't absolutely critical for FPWD. I just thought that in e.g. section 2.1, the heading "Issue (ISSUE-27):" ought to be a level up from its subheadings ("Resolution:", "Note:" etc.) so that it's easy to see where an issue begins and ends. Also, even less importantly, in the Examples section, a), b) etc. is used, but isn't used anywhere else in the document. > It looks like the word "contains" was missing. > That makes sense. >> * I'm not sure it is clear what authoritative means in this >> sentence: 'A Graph Store needs not be authoritative for the graphs >> it contains.'. >> > > I presumed that it meant that if you get a local copy of a graph, then > you may have updated it. Either that, or it may have fallen behind > revisions if you grabbed a snapshot of a graph that was still under > active development. For instance, the authoritative graph for > <http://example.com/data/foo.rdf> may be the document found at that > location. But it's also possible to get a copy of that graph (as an > RDF/XML document) and load it up in a graph store. This would improve > efficiency by avoiding network overhead, and indexing the data > locally. > > That's just my reading of it. If that doesn't make sense, or the > phrasing is still obscure then we can try again. > > Thanks for the explanation. I think that the use of the word authoritative is clear here - it was just my understanding that wasn't. >> * I think that the note ought to be an issue, and perhaps the >> wording of 'it seems...' is too conversational for a FPWD. Also, >> I'm not sure whether there is consensus that this actually is the >> position of the working group. (I originally added that issue to >> the UpdateIssues page and there wasn't any discussion on it then). >> > > I've always liked the idea of an update service being able to do > queries in general, though I don't know if there is support for this. > If it's not, then I suggest that a SELECT and an INSERT should *not* > be allowed in the same query. I'd like to hear more comments before > changing this (though I agree that the style is not right). I think that there is support in the working group for update services doing queries. My point was more around whether the working group actually recognise the note as a real issue. >> >> >> * Some of the 'Notes' in this section seem to be more like issues, >> but don't reference issue numbers. E.g. 'Is DELETE too verbose?', >> 'Is MODIFY syntax required?' >> * 'empting a graph.' should say 'emptying a graph.' >> * 'but on GraphGraphPatterns' - typo. >> > > Actually, no. This is the name of the element in the syntax from the > SPARQL/Query definition: > http://www.w3.org/TR/rdf-sparql-query/#rGraphGraphPattern > > My mistake - looked for that element in the update grammar, not the query grammar. >> POST FPWD >> >> There is a pattern to each mention of an issue. Anything in braces in >> the following template is different for each issue: >> Issue (ISSUE-{##}): >> {Description} >> Source: ISSUE-{##} >> Resolution: >> {Description of resolution - typically "None recorded"} >> >> The only times that issues are ever linked is from "Source" and they >> are linked consistently. >> >> I'm all for changing the above (ISSUE-## comes up twice, for instance, >> and it's hard to see where one issue ends and the next starts), but >> the usage is currently consistent. >> Ok, fair enough. >> >> >> 5.1 >> >> * I think it would be more accurate to say 'The INSERT operation is >> equivalent to the' rather than 'The INSERT operation is similar to >> the'. >> > > This implies interchangeability to me, which I don't think is the > case, is it? (Is it legal to have MODIFY without both INSERT and > DELETE?) > I'll check this, but perhaps similar is the safer bet in the meantime. >> * My colleague pointed out that having the query 'CLEAR' with no >> arguments just clear the default graph is likely to lead to >> accidents in practice - perhaps 'CLEAR DEFAULT' might be a better >> choice. Also, this behaviour isn't explicitly mentioned in the >> prose of the document, maybe it ought to be. >> > > I've added a note here. The implications warrant further discussion. > Agreed. > Regards, > Paul Gearon > >
Received on Monday, 19 October 2009 17:48:51 UTC