Comments on WD

"""The term "binding" is used as a descriptive term to refer """

I would say, "is used to refer".

======
"""to a pair of ""

perhaps strike the "of"

======
""(variable, RDF term). In this result set, there are variables x, y  
and z (shown as column hearers). Each solution is shown as a row in  
the body of the table.  Here, there is a single solution, where  
variable x is bound to "Alice", variable y is bound to <http:// 
example/a>, and variable z is not bound to an RDF term. Not every  
binding needs to exist in every row of the table."""

I found this a bit confusing (the double "every"). How about,  
"Variables are not required to be bound in a solution, for example,  
optional matches and alternative matches may leave some variables  
unbound in some row."

======
======
http://www.w3.org/TR/rdf-sparql-query/#basicpatterns

Is this section normative or informative? If it is informative, it  
should be marked as such. It looks as if it is meant to be informative.

======
"""Combining triple patterns gives a basic graph pattern, where an  
exact match to a graph is needed to fulfill a pattern."""

In DBland (where the models are finite, and the queries good  
lookin'), I believe the terminology is "exact match", "partial match"  
and "range match". And exact match uses equality, whereas a range  
match (as one might expect) uses inequalities (e.g., =5 vs. >5 and <10)

In <http://www.w3.org/TR/rdf-sparql-query/#BasicGraphPattern> we do  
get that a basic graph pattern is a set of triple patterns, (and thus  
an exact match situation) *but* in <http://www.w3.org/TR/rdf-sparql- 
query/#BGPsyntax>:

"""In the SPARQL syntax, Basic Graph Patterns are sequences of triple  
patterns mixed with value constraints."""

Thus, can involve range matches.

I think there are two senses of BGP at work: in the algebra (thus in  
the formal definition) and in the syntax. It would be helpful to keep  
them even more distinct (perhaps with a different name).

======
"""The simplest graph pattern is the triple pattern, which is like an  
RDF triple, but with the possibility of a variable instead of an RDF  
term in the subject, predicate or object positions."""

s/possibility of a variable/possibility of a query variable/ (BNodes  
are variables and are available in the sub/obj positions).

======
"""The pattern in the following query has a solution :x because 42 is  
syntax for"""

First, isn't the solution a *binding*, so we need the variable? And  
shouldn't the uri be absolute (as modeled in <http://www.w3.org/TR/ 
rdf-sparql-query/#docResultDesc>)?

======
Very next section:

"""The following query has a solution with variable v being :y. The  
query processor does not have to have any understanding of the values  
in the space of the datatype because, in this case, lexical form and  
datatype IRI both match exactly."""

Shouldn't it be "with variable v being *bound* to <...y>"?

Are variables, in general, not spelt with a ? in tables (and in  
text)? Is there a reason to spell them differently than in queries?

======
In the very next section:

"""but this does find a solution where variable x is substituted  
by :z:"""

I would prefer that we stick to the use of "binding" and "bound to"  
instead of colloquialisms like "being" and "substituted by".

======
2.4.1:

"""Variable bindings can be restricted to strings matching a regular  
expression by using the regex operator. Only plain literals with no  
language tag and XSD strings are matched by regex. regex can be used  
to match the lexical forms of other literals by using the str  
operator."""

Isn't that a rather complex operator to use in an example like this?  
Given the complexity of the operator, the example is just sugar for a  
directly expressed exact match.

The second query seems wrong:

PREFIX  dc:  <http://purl.org/dc/elements/1.1/>
SELECT  ?title
WHERE   { ?x dc:title ?title
           FILTER regex(?title, "web", "i" )
         }

That shouldn't match "The Semantic Web" should it? I clicked on  
"regex" and got to a function fn:matches (wha?) Ok, we renamed it.  
(Bit scary.) Oh I see, it's not "is this string an instance of this  
regular expression", but "is there a substring which is in that  
expression". er...ok. Pretty standard I guess if you are using  
"matches". I felt quite lost in the XSD document, which is par for  
the course, but wouldn't it make more sense to indirect through a  
description by us? In fact, through:
	<http://www.w3.org/TR/rdf-sparql-query/#funcex-regex>

I mean, *normal* references are routed through the references list, a  
practice which annoys me about w3c specs, but here is a good case  
where seeing our text is essential.

(I think that putting numbers first would be easier.)

(And do we want to use the phrase "matches" here? Esp. since we  
changed the name of the function :))

(Sorry, not reviewing 2.6. I have a policy of not reading anything  
about reification :))

======
"""Blank nodes in the results of a query are from the scoping set,  
but this information cannot be used by an application or client which  
receives these results, since all blank nodes in subsequent queries  
are treated as being local to that query. In effect, this means that  
information about co-occurrences of blank nodes may be treated as  
scoped to the results as defined in "SPARQL Query Results XML Format"  
or the CONSTRUCT result form."""

So, no one knows what a scoping set is at this point. And it's not  
necessary to know. How about:

"Blank nodes are local to the result set of a query. That is, blank  
node labels in distinct SPARQL query Results XML Format or construct  
result form documents do not refer to the same BNode. This means that  
one cannot usefully use BNode labels in a result form to formulate a  
new query about *that* BNode."

It's strange that there are no co-reference between *or* within  
answers. Perhaps we could introduce a bit more text explaining how to  
interpret answers or how to compare them with a database situation?

=======

That's all the editorial for today. As I work through the document  
for my action items, I'm also separating out these editorial points  
and will send them as they are sensible to send :)

Cheers,
Bijan.

Received on Monday, 9 October 2006 14:04:43 UTC