Re: Comments on WD

Bijan Parsia wrote:
> """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"

Done

> 
> ======
> ""(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."

Done

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

Could we work of the editors' draft please?
http://www.w3.org/2001/sw/DataAccess/rq23/rq24.html

> 
> 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.

Added "This section gives an introduction to the basic matching features of 
SPARQL."  I'd like to add a sections for the other graph pattern matches but 
it'll depend on time.

> 
> ======
> """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.

That text was to cover filters with BGPs which we're not currently heading 
for.  Removed " mixed with value constraints"

> 
> 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).

Ditto grammar changes.

If there are more doc mentions of BGP including filters, we must remove them.

We need to decide whether

{ _:x :p ?v .
   FILTER (?v < 3) .
   _:x :q ?w .
}

is one BGP or two.  As the grammar stands, it's two : a BGP ends when another 
element starts.  A grammar can't express the case of one BGP; it would take 
text in the doc to modify the lexical interpretation.  I personally don't 
think it's worth it.

> 
> ======
> """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).

Done

(Blank nodes are also RDF terms but I see your point and it's clearer your way).

> 
> ======
> """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>)?

"a solution with variable v bound to :x "

> 
> ======
> 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?

The ? does not form part of the variable name.

> 
> ======
> 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".

Consistency for the section applied.

> 
> ======
> 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?  

It is the first thing users use so it is the most relevant example.

> Given the complexity of the operator, the example is just sugar for a  
> directly expressed exact match.

XQuert/Xpath regular expressions are not anchored unless explicitly done so 
wityh ^ and $.  So it's not equality match - it's substring.

> 
> 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.  

fn:matches (from F&O) is the backing function for regex in the same way that 
"+" is backed up by fn:numeric-add.

> (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>

Yes - link with the document to the sec 11 section #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.

We do some linking to external docs where it is not a reference, but is 
helpful.  For references, we do the W3C style thing.

> 
> (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 :))

It's not about reification so much as about the fact we don't do anything 
special about it!

> 
> ======
> """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."

Yes - it should be blank node labels.

The same label in the same result (XML doc or RDF graph) does refer to the 
same blank node.

Section title changed to:
"""Blank Node Labels in Query Results"""

and text changed to:

"""
The presence of blank nodes in query results can be indicated by labels in the 
serialization of query results.

Blank nodes labels are local to the result set of a query. An application or 
client cannot usefully use blank node labels to formulate a query that 
directly refers to a particular blank node.  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.
"""

Probably have to come back to this text when the BGP defn is revised to make 
sure there is no confusion.

> 
> 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 :)

Great!

> 
> Cheers,
> Bijan.
> 

	Andy

Received on Thursday, 12 October 2006 12:56:35 UTC