Re: comments/questions on SPARQL document

On Fri, Oct 08, 2004 at 05:00:13PM +0100, Seaborne, Andy wrote:
> 
> 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?
1.05:
That's how I took it. Not *too* pleased with this wording, but it
addresses Pat's issue:
[[
These triples can come from a variety of sources. For instance, they
may come directly from an RDF document. They may be inferred from
other RDF triples. They may be the RDF expression of data stored in
other formats, such as XML or relational databases.
]]

> >'based on  information' has extra NBspace
> 
> v1.102:
> Removed.
> 
> >No reference for [protocol]
> 
> Awaiting document to reference!
1.05:
added references indicating that:
[[
[@@ protocol document not yet published @@]
]]

> >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.
1.05:
I knocked them back out again and added 
[[
(At this time, blank nodes (bNodes) are not allowed in triple patterns
— The working group has not disucssed use cases or semantics of
existential variables.) Graph patterns can be
]]

> >(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?
1.05:
Moved "prefixes are syntactic" to before the "typed literal" section.

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

-- 
-eric

office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
                        Shonan Fujisawa Campus, Keio University,
                        5322 Endo, Fujisawa, Kanagawa 252-8520
                        JAPAN
        +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +1.857.222.5741 (does not work in Asia)

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.