Re: rq25 (1.18) review (part III)

* Lee Feigenbaum <feigenbl@us.ibm.com> [2007-03-06 18:04-0500]
> 
> Continuing with responses to part III of Kendall's review.
> 
> Kendall Clark wrote on 03/05/2007 04:39:52 PM:
> > On Mar 2, 2007, at 10:36 AM, Seaborne, Andy wrote:
> > 
> > > > What's a "knowledge base"? What's a "target knowledge base"?
> > > >
> > > > What's a "SPARQL query processor"? Is that different than the 
> > > "service"?
> > 
> > I don't know how to interpret the non-response to this. I can phrase 
> > it differently: strike 'knowledge base' or define it. Strike "SPARQL 
> > query processor" or define it.
> 
> I changed 'knowledge base' to 'RDF Dataset'. 'Query processor' occurs in 
> several places throughout the document. @@Eric@@ I've asked Eric to look 
> at these usages.
> 
> > > > Finally, the sentence starting "Note that the SPARQL protocol
> > > > describes" should be struck. Any such commentary or note doesn't 
> > > belong
> > > > in the query language spec at all, IMO, and certainly not in the
> > > > section on conformance. It sticks out like a sore thumb.
> > > >
> > > > If there is interest in a statement like this in the protocol spec,
> > > > that should be handled in the normal process for the WG. In fact, 
> > > #4 in
> > > > the protocol conformance section already says that, so this 
> > > statement
> > > > is also redundant and further muddies the normative status of the 
> > > query
> > > > spec...
> > 
> > Is EricP going to reply to these bits?
> 
> @@Eric@@ As before, Eric will be looking at the conformance situation.

There was a conformance thread [CF] a while ago that resulted in
the current text.

KendallC suggested tallying the places in rq25 where "error" or
"warning" are mentioned. While I was at it, I looked "implementation"
and "process". The goal is that the spec make it clear how errors are
reported if they are reported, and see how RFC2119 could make things
clearer.

Conclusion: tx to Kendall for inspiring a small whichhunt which
resulted in some changed language. I believe that the remaining text
defines a language and would not benifit from MUST/MAY/MIGHT keywords.
Below, ignoring the abstract and the SOTD, are the intimate details of
the survey:



#matchArbDT
[[
The query processor does not have to have any understanding of
the values in the space of the datatype because the lexical form
and datatype IRI both match so the literal matches.
]]

This is basically about extended implementations. This is explaining a
particular result rather than defining a behavoir; I think it's OK.
Also, it's in a non-normative section



#describe
[[
The DESCRIBE form returns a single result RDF graph containing RDF
data about resources. This data is not prescribed by a SPARQL query,
where the query client would need to know the structure of the RDF in
the data source, but, instead, is determined by the SPARQL query
processor.
]]

This basically says it's at the discression of the service. I'm
content that the word "processor" here does not imply conformance
implications as we have no way to describe conformance of DESCRIBE
anyways, apart from the fact that it's a graph. To that end, this
section is non-normative.



#tests
[[
SPARQL FILTERs restrict the set of solutions according to a given
expression. Specifically, FILTERs eliminate any solutions that, when
substituted into the expression, either result in an effective boolean
value of false or produce an error. Effective boolean values are
defined in section 11.2.2 Effective Boolean Value and errors are
defined in XQuery 1.0: An XML Query Language [XQUERY] section 2.3.1,
Kinds of Errors. These errors have no affect outside of FILTER
evaluation.
]]

The last sentence asserts that the errors in section 11 are only
relevent to the tri-state FILTER evaluation scheme, and has no
protocol or API impact.



#operatorExtensibility
[[
SPARQL language extensions may provide additional associations between
operators and operator functions; this amounts to adding rows to the
table above. No additional operator may yield a result that replaces
any result other than a type error in the semantics defined above. The
consequence of this rule is that SPARQL extensions will produce at
least the same solutions as an unextended implementation, and may, for
some queries, produce more solutions.
]]

This describes language extensions and constrains them to change only
errors that would have resulted in removing solutions. These errors
are the ones described above, and do not leek out of the language.



#defn_SolutionModifier repeats the definitions from #solutionModifiers.



[CF] http://www.w3.org/mid/20051112163924.GX8297@w3.org
-- 
-eric

office: +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA

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