Re: suggestions about "RDF* and SPARQL*" draft

Thanks a lot for those suggestions, comments below.

On 29/11/2020 17:01, Bob DuCharme wrote:
>
> https://w3c.github.io/rdf-star/rdf-star-cg-spec.html looks great and I 
> learned a lot. I have listed some suggestions with the more picky 
> copyediting ones at the end.
>
> Thanks,
>
> Bob DuCHarme
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> - "the purpose of this section will be to provide an informal 
> introduction" How long do you want it? I could draft something.
>
Feel free to submit a PR
>
>
> - Before Example 1, I would add this: "(In all examples, prefix 
> declarations have been omitted for brevity.)" Even better: say "In 
> most examples, prefix declarations..." and then include the prefix 
> declaration in Example 4, which would be clearer with it. (Too many 
> people think that there is something magic about certain common 
> prefixes so that they don't need to be declared.)
>
Yes of course. That was implicitly part of the TODOs in section 1. I 
added an explicit TODO.
>
> - Section 2. "is called an asserted triple" At this point in the 
> document I was confused about how a triple could be in a dataset 
> without being asserted. After I read section 6.2.1 I understood. I 
> think that this paragraph could use something like "Non-asserted 
> triples are discussed further in section 6.2.1".
>
Again, I expect the motivation and overview section to provide this kind 
of information. So hopefully, this will make section 2 easier to understand.
>
>
> - "Each named graph is a pair consisting of an IRI or a blank node 
> (the graph name), and an RDF* graph" This would be clearer as "Each 
> named graph is a pair consisting of either an IRI or a blank node 
> serving as the graph's name and an RDF* graph". This plays up the 
> importance of role played by this IRI or blank node more.
>
it is more than stating a role, it is a definition. I changed it to 
"(called the graph name)" in order to make it clearer.
>
>
> - Section 3.1 (and 4.2) "which replace the productions with the same 
> number (any) in the original grammar". Saying "replace with X" implies 
> that X is the replacement--in this case, the number itself, which I 
> would read as meaning "amount" here. This would be better as "which 
> replace the productions that were assigned the same numbers in the 
> original grammar."
>
good point, I changed that to "having the same numbers"
>
> - After the reference to "function eval(D(G), algebra expression)" 
> there are two references to "function eval" without showing the 
> parameters or any formatting of "eval" to show that it's a reference 
> to a syntax expression (although I suppose a high-level one). I think 
> saying "the eval function" instead of "function eval" would read 
> better in those two references.
>
I leave this one to Olaf. ;)
>
>
> Copyediting:
>
I applied all the changes below, except for one.
>
>
> - "allowing to represent" -> "allowing the representation of"
>
> - "a embedded" -> "an embedded"
>
> - "The subject and embSubject productions sets the curSubject" The 
> sentence has a plural subject (pardon the overloading), so verb should 
> be "set" and not "sets"
>
> - "nothing prevents other concrete syntaxes of RDF* to be proposed" -> 
> "nothing prevents other concrete syntaxes of RDF* from being proposed" 
> (or "nothing prevents the proposal of other RDF* concrete syntaxes")
>
> - "solution mappings: Two SPARQL*" lower-case "t" in "two" because 
> it's all one sentence
>
> - "These embedded triple patterns are allowed in subject ([75], [81]) 
> and object ([80], [105]) position of SPARQL* triple patterns" -> 
> "...are allowed in *the* subject ... position*s* of..."
>
> - "Based on the SPARQL grammar the SPARQL specification" add comma 
> after "grammar"
>
> - "is not in Ω)." Move period inside of parentheses because the entire 
> sentence is inside of them
>
> - 4.4 after "following four properties:" the bulleted list looks like 
> the conversion from a sentence to a bulleted list wasn't quite 
> finished. The bulleted items shouldn't have the commas or "and" after 
> them.
>
I am not a native spealer, but in French, I would consider this more as 
a matter of taste than a strict rule. As this is Olaf's work, I leave it 
to him to make the fix or not.
>
> See the numbered list in 6.1, although the 4.4 ones don't need a 
> period because they're not complete sentences.
>
> - "semantics, in order" drop comma
>