Re: comments/questions on SPARQL document

Pat,

Thanks for the comments:

Pat Hayes wrote:
> http://www.w3.org/2001/sw/DataAccess/rq23/#introduction
> link from contents is broken.

v1.102:
Fixed.

> 'set of statements' / 'set of triples'

v1.102:Applied a global replace:
s/statement/triple/g ;

> Is the list of three kinds of graph intended to be exhaustive? Suggest 
> not, so say something like "A graph may be encoded in a variety of 
> forms; for example, ..."

Couldn't find a list of three kinds of graph.  Did you mean the list of three 
facilities provided?

> 'based on  information' has extra NBspace

v1.102:
Removed.

> No reference for [protocol]

Awaiting document to reference!

> Outline:
> 'the SPARQL' (the?)
> section 5 is (delete 'is')
> Why are fonts used in section 9 and section 11 descriptions different?

Outline removed as it is out of step with the doc.  Will replace when the doc is 
stable if the doc needs it.

 > Document Conventions: suggest delete first sentence.

Done.

> 
> http://www.w3.org/2001/sw/DataAccess/rq23/#basicpatterns
> HTML anchor is misplaced inside the header

This is the form used through out the doc.  Copied from another W3C rec but can 
change later.

> " Patterns are descriptions of graphs with" / "Patterns are like graphs 
> but may have"
> (reason: calling them descriptions suggests a metalanguage, and lets not 
> go there.)

v1.102:
I'll try not to.  Changed.

> "graph labels or relationships" / "nodes or predicates" (use a link to
> http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-data-model 
> if needed to justify terminology)
> In general, avoid the term 'graph label' throughout. The RDF core WG 
> went through hell until we decided that RDF graphs are not labelled 
> graphs in the mathematical sense. There are no labels in RDF: the nodes 
> *are* the labels. (Hence they are unique.)

v1.102:
Have tried to remove 'graph label' as I passed through the document.  However, 
if the wording became bad I left it for now.

> Graph labe...sorry, nodes and predicates, are not values as defined in 
> [Concepts]: those are datatype values, see 
> http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-Datatypes-intro
> . So:
> "The graph labels are values as defines in [..]" / "Nodes (as defined in 
> [concepts])  may be"  or some such.
> Also, why did you leave out blank nodes ?

v1.1.02
bNodes included.


> (BTW, there isn't a single term for nodes-or-predicates in the RDF 
> concepts terminology, I now realize. [Later: you provide one in section 
> 2.2, so use it here.])
> 
> "The result of a query is a set of mappings from variables to values 
> such that, for each mapping, assigning values to variables in the query 
> produces a subgraph of the target graph."
> /
> "A <em>binding </em> is a mapping from the variables in a query to 
> terms. A <em> result mapping </em> is a binding which, when applied to 
> the variables in the query, produces a subgraph of the target graph; a 
> <em> result </em> is a set of result mappings. If there are no result 
> mappings, the result set is empty."
> 
> (BTW, does the result have to be the set of *all* possible result 
> mappings or just include some of the possible mappings? If the former 
> this should be stated.)

It's all a query solution is one match, query results (plural) is all.
Will need to make this consistent after publication.

> "we will get one solution with three variable bindings" /"we will get 
> one result mapping which binds three variables".
> (A single mapping may bind more than one variable)

v1.102:
Done.


> http://www.w3.org/2001/sw/DataAccess/rq23/#WritingSimpleQueries
> HTML anchor is misplaced
> "It is also possible to write integers and floating point doubles directly."
> Really?? That is, without using a typed literal? Yuck, I suggest this is 
> a bad idea: RDF recidivism!!. In any case, why FP doubles, for goodness' 
> sake?

"FP double" is an built-in XML Schema datatype.
http://www.w3.org/TR/xmlschema-2/#built-in-datatypes

This is just syntactic shorthand for the full typed literal.
     ?x + "1"^^xsd:integer < "2"^^xsd:integer * ?y
is a bit long.  IMHO.

> 
> "Variables are indicated by '?'; the '?' does not form part of the 
> variables name."
> This belongs in earlier section.  Also, why does the query not form part 
> of the name? In fact, what does this idea of the 'name' of a variable 
> mean? Surely the variable *is* the name, right? Why not just say, 
> variables start with the character '?' ?

Under debate - we may change to / also allow "$".

Also - APIs tend to use the name without the "?"

> 
> Delicate point in the example. The title here is an RDF plain literal, 
> right? So does the result binding bind the variable to the literal, or 
> to the character string? (Suppose the literal had a lang tag?)

To the literal.  Not the lexical form or character string.  Lang tag would be 
included.

> 
> intepretted/interpreted
> therefor/therefore
> Text flows oddly: prefixes, data, typed literals, prefixes again. 
> Reorder the last paragraph?
> 
> http://www.w3.org/2001/sw/DataAccess/rq23/#TriplePatterns
> HTML anchor is misplaced (They seem to all be like this, so I will not 
> mention it again.)
> 
> Definitions should have been stated earlier, or forward links provided. 
> Also they can be tidied up. Right now they are a bit of a mess

Two author effect.  Intro text duplicates, and it in a different style from, 
2.1.  Will fix after this WD publication.

> and I 
> think they have mistakes in, but am not sure. See below.
> .
> Blank nodes is some set disjoint from U and L (see [Concepts]) and we 
> can use the same trick, where query variables V is a set disjoint from U 
> union L union BN. We don't need to define it.

Somewhere before v1.100:
Done.  Thanks for that.

  Or, we can define it to be
> the set of all strings starting with '?', and remark that this is 
> disjoint from U union L union BN. The first is more of an 
> abstract-syntax way of doing things.
> A triple is anything in (U union BN) x U x (U union BL union L), and an 
> RDF graph is a set of triples. [Concepts].
> OK, following this, a triple pattern is anything in
> (U union BN union V) x (U union V) x (U union BN union L union V)
> and a pattern is a set of triple patterns.
> 
> I'd suggest not using 'ground' to mean lack of variables as RDF already 
> uses 'ground' to mean lack of bnodes.

Somewhere before v1.100:
Done.


> How about 'variable-free' or 
> 'complete' if we want a single word. But do we even need this concept? 
> In the case of query variables, unlike bnodes, do we even want to 
> consider an instance of one query still being a query with some 
> variables still not bound? We surely do not want to consider instances 
> which bind one query variable to another, right? (??)
> 
> Before suggesting rewordings, let me get the definitions straight. What 
> it says is:
> "*Triple Pattern T matches* graph G with binding set B if subst(T, B) is 
> a ground triple and, as a triple, is entailed by G."
> 
> Where presumably 'ground' here means in the sense defined here, ie not 
> containing a query variable: (and NOT in the sense defined in RDF, 
> meaning not containing a bnode). So under this assumption, then, this 
> would be an example:
> G= { ex:a ex:p ex:b }
> T= {?x ex:p ex:b}
> with the result having ?x bound to a blank node:
> ?x//_:1
> since G simply entails {_:1 ex:P ex:b}
> 
> BTW, if 'ground' here means as in RDF, i.e. having no bnodes, then the 
> first example in the document is wrong, since it binds variables to 
> bnodes and hence produce non-RDF-ground instances.
> 
> What exactly does 'entails' mean? The above example assumes simple 
> entailment (the weakest interpretation.)  If entails means RDF-entails, 
> then this would be an example:
> G = { } (the empty graph)
> T= {?x rdf:type rdf:Property}
> with the result having ?x bound to rdf:type, since
> rdf:type rdf:type rdf:Property
> is RDF-valid all by itself, ie is RDF-entailed by anything.
> 
> Sorry I was out of the loop long enough to not know the answer, but is 
> this really what is intended here?

Chnages made during preparation for publishing: Hopefully the revised 
definitions are clearer.

> 
> ----
> 
> The Graph pattern match definition in section 2.3 refers to the triple 
> definition, and so requires only that each triple of the instance is 
> entailed, rather than the instance graph itself be entailed. This are 
> not the same thing. For example:
> 
> G = {ex:a ex:p ex:b
> ex:b ex:p ex:c
> ex:c ex:p ex:a}
> 
> T= {?x ex:p ?y
> ?y ex:p ?x}
> 
> then binding ? x and ?y to distinct blank nodes will give an instance
> 
> _:1 ex:p _:2
> _:2 ex:p _:1
> 
> which is not itself entailed by G but every triple of which is entailed 
> separately by G when considered in isolation. So is this a legal match? 
> (suggestion: no. But it is according to the current definitions.)

Now no "entails" in the doc.  Much more data-centric in tone.  Will need to come 
back to this or at least sort out text for "virtual graphs" that means the rest 
of the doc does not have to dance around.

> 
> ------
> 
> I think I had better stop at this point and wait for some answers before 
> proceeding.
> 
> Pat
> 

	Thanks again,
	Andy

Received on Friday, 8 October 2004 16:01:07 UTC