Re: [ENT] Editorial Review comments on the SPARQL 1.1. Entailment regime document

Ivan,
thanks a lot for your thorough review. I'll comment on the things that
I fixed below. I haven't looked at the non-editorial suggestions in
your other email. I'll try to do that tomorrow. There are two open RIF
comments that I leave to Chime.
Cheers,
Birte

> -----------
> 1.1.1 Graph syntax, right before the example at the end: the example contains only one non-abbreviated IRI (except the @prefix). So the sentence should be put in singular: "the following triples use prefixes and abbreviated IRIs and also a non-abbreviated IRIs such as <book2>, which is relative to the base IRI of the document."

fixed

> -----------
> Purely stylistic issue: we are in a Unicode world, wouldn't it possible to change things like
>
>   "I union RDF-L union RDF-B"
>
> to
>    "I ∪ RDF-L ∪ RDF-B"
>
> Or do browsers still have a problem with that? (Test: does your email client display a proper union character?)

It is ok in my browsers (firefox&safari), so I changed that now.

> -----------
> 1.1.3, preliminary definitions: I wonder whether it is not worth adding the abbreviation 'BGP', ie:
>
> "A Basic Graph Pattern (BGP) is a set of Triple Patterns."

done

> -----------
> 1.2, paragraph right after the numbered items, I think it should be 'on the Semantic Web' and not 'in the Semantic Web'

both seems possible, google gives ~4,580,000 results for "on the
Semantic Web" and ~4,870,000 for "in the Semantic Web"
I changed it to on nevertheless.

> -----------
> All the tables for entailment regimes: maybe it is because I am too old, but I find the small characters in the Query Answers fairly difficult to read. Is it really necessary to use small characters?

The font size is determined by the style sheet that is shared among
all documents I believe (query at least also uses it), so changing
that would change all documents. The style file specifies the font to
be 88%. Maybe we should get this changed in general, but I don't dare
to do just like that. Currently the IRC channel is quite empty, but
I'll ask that on IRC around the time of the next SPARQL teleconf.

> -----------
> Would be helpful to add a link to the term "pattern instance mapping" (for all tables) to http://www.w3.org/TR/sparql11-query/#defn_PatternInstanceMapping

done (also in the RIF table)

> -----------
> Section 2.1
>
> "node names do not matter, also the following solution mappings are possible solutions"
>
> =>
>
> "node names do not matter, the following solution mappings are also possible solutions"

fixed

> (Do I detect some German background here?:-)

quite possible ;-)

>
> -----------
> Section 2.1
>
> the link from 'condition 2 from the SPARQL Query Specification' goes to the sparql query document, but wouldn't it be better to refer to condition three in section 1.3 of the current document? The same occurs a few words later for condition 4 and, at the end of the section referring to the 'first condition".

done

> I would also add, after the reference to condition 2, a paranthesis saying "(because the blank node _:c3 is shared by the scoping graph and the solution)"

I extended the explanation because it is not just the fact the _:c3 is
shared by SG and the solutions. The problem is rather the sharing of
bnodes in different solutions which introduced an unintended
co-reference since the bnode occurs in two solutions but in the
queried graph the solutions do not involve the same bnode. This is
what condition 3 in the query spec wants to exclude. I hope the
paragraph is clearer now.

> -----------
> Section 2.1, right after the skolemized graph, the text says "and _:a2 to skol:a2". Shouldn't that be "and _:c3 to skol:c3"?

Ups, of course. fixed

> -----------
> Section 2.1, same paragraph: "Skolemized scoping graph, also C2 is satisfied" -> "Skolemized scoping graph, C2 is satisfied, too, "

done

> -----------
> Section 2.2. also refers to RDFS entailment, although we are still in the realm of RDF entailement (and, formaly, RDFS entailment has not yet been defined). It may be better to move that section to the RDFS entailment part...

moved to the RDFS section

> -----------
> Section 2.3, the first paragraph is giving a short overview of some Turtle syntax features. I would move that to section 1.1.1

moved

> -----------
> Section 2.3, right at the end before the numbered items: remove the word 'exemplary'. I do not think it is the right usage of the word and it is not necessary anyway...

removed

> -----------
> Section 2.4, first sentence of first paragraph: cut the sentence into two, it is way too long and difficult to parse... For example:
>
> "Please note that solution mappings that map variables that occur in the subject position of the basic graph pattern BGP to literals will not be returned as solutions even though there might be a pattern instance mapping P for the solution mapping such that P(BGP) is RDF entailed by the queried graph, but P(BGP) is not well-formed as required (..."
>
> =>
>
> "Please note that solution mappings that map variables that occur in the subject position of the basic graph pattern BGP to literals will not be returned as solutions. Indeed, although there might be a pattern instance mapping P for the solution mapping such that P(BGP) is RDF entailed by the queried graph, P(BGP) is not well-formed as required (..."
>

done

> -----------
> Section 3, first paragraph, last sentence: what does "this" refer to?

this case, refers to the case when the queried graph is RDFS inconsistent
I made that explicit now by writing:
The definition of the scoping graph is, however, extended to also
cover the case when the queried graph is RDFS inconsistent.
instead of just
[...] to cover this case.

> -----------
> Section 3.1.1 The typesetting of the first paragraph is wrong: there sees to be an extra line feed after "are returned" but there is no space between this and "If a system", which would suggest a proper new paragraph.

fixed

> -----------
> Section 3.1.1, paragraph right before the first example, "it can be efficiently implemented" => "it can be implemented efficiently"

fixed

> -----------
> Section 3.1.1
>
> "Thus, the processor knows that it does not have to evaluate the query, but a required check for consistency can be very costly (there could be more than 10,000 ex:b ex:s ex:yn tuples) and after a possibly long time the user would get an error."
>
> =>
>
> "Thus, the processor knows that it does not have to evaluate the query. However, if consistency check was required, the processor would have to parse and process the query nevertheless and return an error. Such a test could be very costly (there could be more than 10,000 ex:b ex:s ex:yn tuples)."

done

> -----------
> Section 3.1.1
>
> "Since the use of HTTP for streaming back results places some constraints on what can be done, e.g., the error or success code must be transmitted before results start, at the point where a query processor might discover the inconsistency it might be too late for a conformant way of communicating this to the client."
>
> =>
>
> "The use of HTTP for streaming results places some constraints on what can be done, e.g., the error or success code must be transmitted before starting streaming the results. However, discoverning the inconsistency from the dispatched processors might be too late for the main processor to communicate the error back to the client in a conformant manner."

done

> -----------
> Section 4.1 refers (twice) to XML Schema Datatypes, version 1.1. Is this necessary? What I mean is, isn't it enough, for the sake of this document, to refer to the current Recommendation, ie, version 1.0? Even if the reference is listed as non-normative, it may be a bit touchy to refer to a not-yet-finalized document. (It created an awkward delay in the OWL WG, and will probably do the same in the RIF WG.)
>
> I would propose to refer to the stable document, ie,
>
> XML Schema Part 2: Datatypes, W3C Recommendatation, May 2001, http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/

I changed to:
XML Schema Part 2: Datatypes Second Edition. W3C Recommendation 28 October 2004
which seems to be the successor of the one you point to, but is also rec.

replaced the second of the references with a link pointing directly to
the section on the canonical form

> -----------
> Section 4.1, sentence right before the first example: canonicalisation -> canonicalization

fixed

> -----------
> Section 5, RDF Based Semantics
>
> Strictly speaking, this regime does not need the usage of the Minus set. Indeed, the OWL 2 RDF Based semantics does _not_ include the RDFS axiomatic triples, ie, the issues of infinity vs the container property does not apply.
>
> I am not against keeping it in the document for the sake of consistency, but it may be worth noting in the text that, well, this is really for consistency only. An alternative is to remove it from the entailment definition altogether.
>
> Note that in 6.6. this remark is made explicitly "Due to the absence of the RDF(S) axiomatic triples, owl2V-Minus could equally be replaced by owl2V." which is fine with me, but it should be then mentioned in the RDF Bases Semantics, too.

Actually the main source of infiniteness (captured by C2) in both OWL
regimes is from datatype reasoning with facets and I had a section
with an example in the OWL Direct Semantics part. I moved that up now
to the RDF-Based semantics regime and I also added the comment that
the -Minus is not really necessary.

> -----------
> Section 5.2.1
>
> "OWL 2 RL implementations are not required to include the axiomatic triples of RDF and RDFS, but they may do so. thus, condition C2 will in most cases not have to be applied. Imposing C2 does, however, not do any harm..."
>
> =>
>
> "OWL 2 RL implementations are not required to include the axiomatic triples of RDF and RDFS, but they may do so. Thus, in most cases, condition C2 does not have to be applied. Imposing C2 does not, however, do any harm..."

done

> -----------
> Section 5.2.1
>
> "means that also query answers that use terms, which are not present in the scoping graph, are returned"
>
> =>
>
> "means that query answers that use terms not present in the scoping graph may be returned, too"

done

> -----------
> Section 6.1, second paragraph
>
> "that are no longer visible in the obtained ontology"
>
> =>
>
> "that are no longer visible in the original ontology"

I think here my writing was a bit confusing because I meant that there
were bnodes in a turtle document, but after parsing the turtle into
OWL objects these bnodes are gone. Since I before talked about mapping
FSS into Turtle, I think you think about the original ontology as the
FSS ontology. I tried to make that clearer in the text.

> -----------
> Section 6.1, paragraph before the last example
>
> "used as identifier" => "used as an identifier"

fixed

> -----------
> Section 6.4
>
> The section has several references to UML classes and diagrams, namely the UML diagrams of the OWL 2 specification. I think a direct reference to those should be added.

Hm, do you mean I should add a ref to the structural specification? I
added one now at the end of the first sentence of 6.4. I also linked
the term ontology to the corresponding section in the OWL 2 Structural
spec when I used the term to refer to ontology objects.

>
> -----------
> Section 6.4 overall
>
> I actually wonder whether repeating the definition of structural equivalence is worth here. You do write "where structural equivalence is taken to be extended in the natural way to also allow for variables," which seems to be quite enough for me...
>
> But if we want to have a really precise specification (which is fine) then, maybe, and to ensure readability, the precise definition (including 6.4.1) could be moved into a normative appendix, for example. These details make it fairly difficult to read the document in one flow...

Moved to the appendix. The main text now has now a reference to the appendix.

> -----------
> Section 6.6.1 first sentence: "obtained" -> "resulting"

fixed

> -----------
> Section 6.6.2, the SPARQL query example, a '}' is missing to close the WHERE. It could also be made a bit more readable if
>
> owl:oneOf [
>   rdf:first ?x ;
>   rdf:rest rdf:nil
> ]
>
> was replaced by
>
> owl:oneOf (?x)
>
> Finally, the SELECT variable should be ?x and not ?d.

all fixed, the example is now in Sec 5.1 because it was moved up to
the RDF-Based regime

> -----------
> Section 6.6.3
>
> "one successor has must " => "one successor must"

fixed

> -----------
> Section 6.6.3
>
> "values do neither occur in the ontology nor in the vocabulary owl2V-Minus"
>
> =>
>
> "values occur neither in the ontology nor in the vocabulary owl2V-Minus"

fixed

> -----------
> Section 6.8.4
>
> "also the OWL 2 Direct Semantics can be applied." => "the OWL 2 Direct Semantics can also be applied."

fixed

> -----------
> Section 7 contains a number of direct links to RIF documents. These should all be updated to the Proposed Recommendation versions
>
> http://www.w3.org/TR/2010/PR-rif-rdf-owl-20100511/#def-common-rif-rdf-interpretation
> http://www.w3.org/TR/2010/PR-rif-rdf-owl-20100511/#def-rif-rdf-satisfies
>
> etc.

Chime's part

> ----------
> Reference to RIF-Core and RIF-RDF should be changed to the just-published Proposed Recommendation:
>
> RIF Core Dialect, W3C Proposed Recommendation May 2010, http://www.w3.org/TR/2010/PR-rif-core-20100511/
> RIF RDF and OWL Compatibility, W3C Proposed Recommendation May 2010, http://www.w3.org/TR/2010/PR-rif-rdf-owl-20100511/
>

updated the doc status/date in the references

> I would also propose to move these to the normative reference section. By the time we go to rec, these will become recs, too, so there is no reason to treat them differently than, say, OWL.

done

> On the same token, I think the SPARQL 1.1 Query should also be moved to the normative references list.

done

> -----------
> Reference to Turtle: editors should be 'eds, Dave Beckett and Tim Berners-Lee'

done

Received on Thursday, 13 May 2010 03:35:07 UTC