Re: SPARQL: Editorial comments on Last Call WD [OK?]

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: SPARQL: Editorial comments on Last Call WD [OK?]

Seaborne, Andy



Ivan Herman wrote:
> Dear all,
>
>
> all these comments (maybe with the exception of the last one) are small scale
> editorial, a.k.a. hair-splitting:-) and is more for readability.

Ivan,

Thank you for the comments.

>
> Ivan
>
> --------------------------------------------------------------------
>
> IRI misuse issue (Section 2.1)
>
> I wonder whether the text on IRI misuse (Section 2.1, Query Term Syntax) should
> really be part of a normative text. Some other W3C recommendations separate in
> the text the 'normative' and 'informative' parts; if this was done in SPARQL,
> this would certainly be an 'informative' paragraph... However, SPARQL does not
> do that separation, ie, everything is normative.

The text in this section has been reworked as part of various comments.

The text on multiple IRIs that may have the same appearance (I take it this is
what you mean by "misuse") has been placed in a separate Security
Considerations section.

>
> --------------------------------------------------------------------
>
>
> Wrong link text (Section 2.2)
>
> Section 2.2 second paragraph after the first definition says: [3987, sec. 3.1].
> I presume '3987' should refer to a RFC 3987 or, more appropriately, to reference
> no. 19

Fixed

>
> --------------------------------------------------------------------
>
> "Matching dataset DS" (Section 2.4)
>
> The formal definition in 2.4 says: "S is a pattern solution for GP matching
> dataset DS". There is no formal definition of what "matching" means at that
> point (it is defined in 2.5 later, ie, a 'post-definition'...). I think moving
> the sententence defining matching from 2.5 to here is better and clearer.

"matching" is used in all the different graph pattern types so I have
mentioned this as covered in various sections to follow this one.  As
solutions are used in matching there is a cirularity that is hard to avoid and
still indicate what solutions are used for.

>
> --------------------------------------------------------------------
>
> Editorial issue on Group Graph Pattern (Section 4.1)
>
> Reading the spec from start to end, and getting to 4.1 gives a stange impression
> on groups. The whole section seems to argue that, in fact, groups are just
> syntactic sugar because they can be flattened, and that is all the section says.
> If my understanding is correct, groups become important when combined with, say,
> Optionals within the groups, but this comes much later in the document. For the
> sake of readability some sort of an explanation would be welcome here.

I have removed the use of "syntactically" which was confusing and moved that
sentence so it is not first.

>
> --------------------------------------------------------------------
>
> Unbound variables in a solution
>
> Section 4.2 says: "Solutions to graph patterns do not necessarily have to have
> every variable bound in every solution that causes a graph pattern to be
> matched. In particular, the OPTIONAL and UNION graph patterns can lead to query
> results where a variable may be bound in some solutions, but not in others."
>
> With my English I could interpret this sentence as follows: I could have a graph
> pattern match *without* OPTIONAL or UNION where not all variables are bound.
> That is probably not the intention, and would be in contradiction with the
> remark at the very end of 2.6 which says "This is a simple, conjunctive graph
> pattern match, and all the variables used in the query pattern must be bound in
> every solution."
>
> I think it should be clearly stated somewhere in the document that *unless*
> OPTIONAL and UNION is used, all variables MUST have a binding in a solution.

I agree it's not very clear - a variable not mentioned in a basic pattern will
remain untouched (bound/unbound), and this is significant because OPTIONAL and
UNIONS are combining patterns which are themselves basic patterns.

Changed to:

[[
Solutions to graph patterns do not necessarily have to have every variable
bound in every solution. SPARQL query patterns are built up from basic
patterns which do associate RDF terms with each variable mentioned in the
pattern; OPTIONAL and UNION graph patterns can lead to query results where a
variable may be bound in some solutions, but not in others.
]]

>
> --------------------------------------------------------------------
>
> Matching Literals in lexical or value space (Section 3.1)
>
> Section 3.1 does not say whether matching datatype literals is done in lexical
> or in value space. Ie, if the data is:
>
> :a :b "10.00000000"^^xsd:double
>
> and the query is
>
> WHERE { ?x :b "10.0"^^xsd:double }
>
> Do I get ":a" as a solution or not?

One of the issues the working group has had to deal with is that both cases of
matching, with and without RDF D-entailment are reasonable.  There is
no requirement that RDF datatype entailment is supported, nor is there a
prohibition that it is not supported and the spec is intentionally not
defining one way of the other.

Another example is

"10"^^xsd:integer and "X"^^roman:Numeral.  Same value - matched if the
processor does D-entailment for roman:Numerals.

RDF semantics says:

[[
These rules may not provide a complete set of inference principles for
D-entailment, since there may be valid D-entailments for particular datatypes
which depend on idiosyncratic properties of the particular datatypes ...
]]

>
> SPARQL may be oblivious to this and it may depend on the RDF data store. If that
> data store does RDFS-D entailement, than the existence of the the
>
> :a :b "10.0"^^xsd:double
>
> is inferred and the query will return ":a". If not, there is no match. However,
> something should be said in the SPARQL document (note that section 11, Testing
> Values, does not answer this because it refers to FILTERS-s only.)

It does apply in the case of RDF term equality: we have a test case for this:

http://www.w3.org/2001/sw/DataAccess/tests/data/ValueTesting/roman.rq

(ARQ now can run with or without Roman Numeral support in FILTERs - by default
it's turned off :-)

>
> [The float case is relatively simple, but more complex issues arise, for
> example, with XML Literals]
>

You're right it coudl be clearer and it is worth picking out explicitly.  I've
added at the end of 3.1

[[
Matching with RDF D-Entailment

RDF defines D-Entailment. When matching RDF literals in graph patterns, the
datatype lexical-to-value mapping may be reflected into the underlying RDF
graph, leading to additional matches where it is known that two literals are
the same value.
]]

>
> --
>
> Ivan Herman
> W3C Communications Team, Head of Offices
> C/o W3C Benelux Office at CWI, Kruislaan 413
> 1098SJ Amsterdam, The Netherlands
> tel: +31-20-5924163; mobile: +31-641044153;
> URL: http://www.w3.org/People/Ivan/


If this addresses the comments rasied, please respond with [CLOSED] in
the subject to allow the issue tracking scripts to close this issue.

        Andy



Reply | Threaded
Open this post in threaded view
|

[CLOSED] Re: SPARQL: Editorial comments on Last Call WD [OK?]

Ivan Herman-2
Andy,

thanks very much. It is all fine with me.

Ivan

-------- Original Message --------
From: "Seaborne, Andy" <[hidden email]>
To: Ivan Herman <[hidden email]>
CC: [hidden email]
Subject: Re:SPARQL: Editorial comments on Last Call WD [OK?]
Date: 7/11/2005 16:29

>
>
> Ivan Herman wrote:
>
>> Dear all,
>>
>>
>> all these comments (maybe with the exception of the last one) are
>> small scale
>> editorial, a.k.a. hair-splitting:-) and is more for readability.
>
>
> Ivan,
>
> Thank you for the comments.
>
>>
>> Ivan
>>
>> --------------------------------------------------------------------
>>
>> IRI misuse issue (Section 2.1)
>>
>> I wonder whether the text on IRI misuse (Section 2.1, Query Term
>> Syntax) should
>> really be part of a normative text. Some other W3C recommendations
>> separate in
>> the text the 'normative' and 'informative' parts; if this was done in
>> SPARQL,
>> this would certainly be an 'informative' paragraph... However, SPARQL
>> does not
>> do that separation, ie, everything is normative.
>
>
> The text in this section has been reworked as part of various comments.
>
> The text on multiple IRIs that may have the same appearance (I take it
> this is
> what you mean by "misuse") has been placed in a separate Security
> Considerations section.
>
>>
>> --------------------------------------------------------------------
>>
>>
>> Wrong link text (Section 2.2)
>>
>> Section 2.2 second paragraph after the first definition says: [3987,
>> sec. 3.1].
>> I presume '3987' should refer to a RFC 3987 or, more appropriately, to
>> reference
>> no. 19
>
>
> Fixed
>
>>
>> --------------------------------------------------------------------
>>
>> "Matching dataset DS" (Section 2.4)
>>
>> The formal definition in 2.4 says: "S is a pattern solution for GP
>> matching
>> dataset DS". There is no formal definition of what "matching" means at
>> that
>> point (it is defined in 2.5 later, ie, a 'post-definition'...). I
>> think moving
>> the sententence defining matching from 2.5 to here is better and clearer.
>
>
> "matching" is used in all the different graph pattern types so I have
> mentioned this as covered in various sections to follow this one.  As
> solutions are used in matching there is a cirularity that is hard to
> avoid and
> still indicate what solutions are used for.
>
>>
>> --------------------------------------------------------------------
>>
>> Editorial issue on Group Graph Pattern (Section 4.1)
>>
>> Reading the spec from start to end, and getting to 4.1 gives a stange
>> impression
>> on groups. The whole section seems to argue that, in fact, groups are
>> just
>> syntactic sugar because they can be flattened, and that is all the
>> section says.
>> If my understanding is correct, groups become important when combined
>> with, say,
>> Optionals within the groups, but this comes much later in the
>> document. For the
>> sake of readability some sort of an explanation would be welcome here.
>
>
> I have removed the use of "syntactically" which was confusing and moved
> that
> sentence so it is not first.
>
>>
>> --------------------------------------------------------------------
>>
>> Unbound variables in a solution
>>
>> Section 4.2 says: "Solutions to graph patterns do not necessarily have
>> to have
>> every variable bound in every solution that causes a graph pattern to be
>> matched. In particular, the OPTIONAL and UNION graph patterns can lead
>> to query
>> results where a variable may be bound in some solutions, but not in
>> others."
>>
>> With my English I could interpret this sentence as follows: I could
>> have a graph
>> pattern match *without* OPTIONAL or UNION where not all variables are
>> bound.
>> That is probably not the intention, and would be in contradiction with
>> the
>> remark at the very end of 2.6 which says "This is a simple,
>> conjunctive graph
>> pattern match, and all the variables used in the query pattern must be
>> bound in
>> every solution."
>>
>> I think it should be clearly stated somewhere in the document that
>> *unless*
>> OPTIONAL and UNION is used, all variables MUST have a binding in a
>> solution.
>
>
> I agree it's not very clear - a variable not mentioned in a basic
> pattern will
> remain untouched (bound/unbound), and this is significant because
> OPTIONAL and
> UNIONS are combining patterns which are themselves basic patterns.
>
> Changed to:
>
> [[
> Solutions to graph patterns do not necessarily have to have every variable
> bound in every solution. SPARQL query patterns are built up from basic
> patterns which do associate RDF terms with each variable mentioned in the
> pattern; OPTIONAL and UNION graph patterns can lead to query results
> where a
> variable may be bound in some solutions, but not in others.
> ]]
>
>>
>> --------------------------------------------------------------------
>>
>> Matching Literals in lexical or value space (Section 3.1)
>>
>> Section 3.1 does not say whether matching datatype literals is done in
>> lexical
>> or in value space. Ie, if the data is:
>>
>> :a :b "10.00000000"^^xsd:double
>>
>> and the query is
>>
>> WHERE { ?x :b "10.0"^^xsd:double }
>>
>> Do I get ":a" as a solution or not?
>
>
> One of the issues the working group has had to deal with is that both
> cases of
> matching, with and without RDF D-entailment are reasonable.  There is
> no requirement that RDF datatype entailment is supported, nor is there a
> prohibition that it is not supported and the spec is intentionally not
> defining one way of the other.
>
> Another example is
>
> "10"^^xsd:integer and "X"^^roman:Numeral.  Same value - matched if the
> processor does D-entailment for roman:Numerals.
>
> RDF semantics says:
>
> [[
> These rules may not provide a complete set of inference principles for
> D-entailment, since there may be valid D-entailments for particular
> datatypes
> which depend on idiosyncratic properties of the particular datatypes ...
> ]]
>
>>
>> SPARQL may be oblivious to this and it may depend on the RDF data
>> store. If that
>> data store does RDFS-D entailement, than the existence of the the
>>
>> :a :b "10.0"^^xsd:double
>>
>> is inferred and the query will return ":a". If not, there is no match.
>> However,
>> something should be said in the SPARQL document (note that section 11,
>> Testing
>> Values, does not answer this because it refers to FILTERS-s only.)
>
>
> It does apply in the case of RDF term equality: we have a test case for
> this:
>
> http://www.w3.org/2001/sw/DataAccess/tests/data/ValueTesting/roman.rq
>
> (ARQ now can run with or without Roman Numeral support in FILTERs - by
> default
> it's turned off :-)
>
>>
>> [The float case is relatively simple, but more complex issues arise, for
>> example, with XML Literals]
>>
>
> You're right it coudl be clearer and it is worth picking out
> explicitly.  I've added at the end of 3.1
>
> [[
> Matching with RDF D-Entailment
>
> RDF defines D-Entailment. When matching RDF literals in graph patterns, the
> datatype lexical-to-value mapping may be reflected into the underlying RDF
> graph, leading to additional matches where it is known that two literals
> are
> the same value.
> ]]
>
>>
>> --
>>
>> Ivan Herman
>> W3C Communications Team, Head of Offices
>> C/o W3C Benelux Office at CWI, Kruislaan 413
>> 1098SJ Amsterdam, The Netherlands
>> tel: +31-20-5924163; mobile: +31-641044153;
>> URL: http://www.w3.org/People/Ivan/
>
>
>
> If this addresses the comments rasied, please respond with [CLOSED] in
> the subject to allow the issue tracking scripts to close this issue.
>
>     Andy
>
>
>
--

Ivan Herman
W3C Communications Team, Head of Offices
C/o W3C Benelux Office at CWI, Kruislaan 413
1098SJ Amsterdam, The Netherlands
tel: +31-20-5924163; mobile: +31-641044153;
URL: http://www.w3.org/People/Ivan/

signature.asc (261 bytes) Download Attachment