Re: federated query review, reprised

Hi all,

I just applied all changes suggested by Lee, including the conformance
section.

cheers,

Carlos

2011/5/12 Lee Feigenbaum <lee@thefigtrees.net>

> Carlos,
>
> Thanks, I think we are almost there. Here are my remaining comments:
>
> In http://www.w3.org/2009/sparql/docs/fed/service.xml#defn_strongBound,
> the notion of "bound is the set of variables in pattern G" is never used.
> The condition on SERVICE not guaranteeing boundedness does not add to the
> definition and should just be removed or changed to a note at the end of the
> definition.
>
> In that same definition, do we also need to include the case of
>
> GRAPH ?X { P1}
>
> (which binds ?X no matter what)
>
> In "Definition: Evaluation of a Service Pattern", the definition that
> "bound is the set of variables in pattern G" appears to no longer be used,
> so it should be removed from the introduction to the section.
>
> For the case of using SILENT, if execution fails you now say:
>  return {}
>
> This reads to me as returning an empty set of solutions, is that correct?
> (As opposed to returning a solution set with one empty solution.)
>
> In section 4, there is this note:
>
> """
> It is a syntax error if to use a variable as the first argument to a
> ServiceGraphPattern if that variable is not bound (at least optionally) in
> the left hand side of a join with the ServiceGraphPattern on the right. If a
> solution does not bind the variable, or binds it to something which cannot
> resolve to a SPARQL service, that solution is eliminated.
>
> It is a syntax error if the number of elements in any Binding does not
> equal the number of variables in the BindingsClause.
> """
>
> I think the first part should reference the service-safeness definition
> instead of (sort of) restating it.
>
> I think the second part, about bindings, should be removed from this
> document.
>
> Note that I checked in some small updates to the document myself, so please
> update from CVS before working on these remaining changes.
>
> I'll send a separate note about conformance.
>
> thanks,
> Lee
>
>
>
> On 5/3/2011 11:03 AM, Carlos Buil Aranda wrote:
>
>> dear all,
>>
>> I addressed all comments but the one about the conformance section,
>> which I do not really know what to write there.
>>
>> Carlos
>>
>> On 28/04/2011 5:09, Lee Feigenbaum wrote:
>>
>>> I've revisited my review of the federated query document based on
>>> Carlos's changes documented on
>>> http://www.w3.org/2009/sparql/wiki/To_Last_Call/Federated_Query_Review.
>>> This
>>> also discharges ACTION-433, as I took a look at the protocol service /
>>> endpoint terminology.
>>>
>>> == Substantive Comments ==
>>>
>>> These comments must be resolved before the document is ready for Last
>>> Call. Editorial comments follow after, which can be addressed either
>>> before or after Last Call, though many of them would help the
>>> readability of the document.
>>>
>>> 2.3 -- we can't link to a definition on a wiki. If we need that
>>> definition, it needs to be incorporated into this document. It also
>>> should be incorporated into the semantics section, rather than in the
>>> context of an example.
>>>
>>> 3.1
>>>
>>> * The syntax transformation needs to handle "SILENT"
>>>
>>> Definition: Evaluation of a Service Pattern
>>>
>>> * Invocation(IRI, S, P, B) needs to be extended to take a 5th
>>> parameter, the boolean for silent invocation or not.
>>>
>>> * Why are only variables in the intersection of vars and bound
>>> selected? This means that I can't do this:
>>>
>>> SELECT ?x {
>>> SERVICE <iri> { ?x a foaf:Person }
>>> }
>>>
>>> ...which seems strange to me. Is this intentional?
>>>
>>> * The second call to "Invocation" needs to include silentOp
>>>
>>> * " return unbounded variables." needs to be more formal. It needs to
>>> return a single solution with no bindings.
>>>
>>> 4 SPARQL 1.1 Federated Query Grammar -- this document only defines
>>> SERVICE, not BINDINGS. This section should be changed to reflect that.
>>>
>>> 5 Conformance
>>>
>>> I'm still not sure that this conformance section makes sense here. I
>>> need to think more about what would make sense. Perhaps Eric or Axel
>>> has a suggestion here.
>>>
>>> Remove section 7 completely.
>>>
>>> == Editorial Comments ==
>>>
>>> 1. Introduction
>>>
>>> Suggest rewording as follows:
>>>
>>> """
>>> The SERVICE extension allows one to direct a portion of a query to a
>>> particular SPARQL query service, similar a GRAPH graph pattern, which
>>> "directs" queries to particular named graphs in the (local) dataset .
>>> This specification defines the syntax and semantics of this extension.
>>> """
>>> =>
>>> """
>>> This specification defines the syntax and semantics of the SERVICE
>>> extension to the SPARQL 1.1 Query Language. This extension allows a
>>> query author to direct a portion of a query to a particular SPARQL
>>> endpoint to be executed against local graphs. Results are returned to
>>> the federated query processor and are joined with results from the
>>> rest of the query.
>>> """
>>>
>>> (and add a link from "SPARQL endpoint" to
>>> http://www.w3.org/2009/sparql/docs/protocol-1.1/Overview2.xml#terminology
>>> )
>>>
>>>
>>>
>>> 1.1.2 Result Descriptions
>>>
>>> Suggest adding this and removing the similar sentence from 1.1.3:
>>>
>>> """
>>> This example illustrates a solution sequence for a query that projects
>>> three variables, ?x, ?y, and ?z. The solution sequence has a single
>>> solution mapping in which ?x is bound to the plain literal "Alice", ?y
>>> is bound to the IRI http://example/a, and ?z is not bound.
>>> """
>>>
>>> 1.1.3 Terminology
>>>
>>> Remove " (corresponds to the Concepts and Abstract Syntax term "RDF
>>> URI reference")" after "Solution Mapping".
>>>
>>> Remove "In this result set..."
>>>
>>>
>>> 2 SPARQL 1.1 Basic Federation Extension
>>>
>>> Suggest renaming section to "SPARQL 1.1 Federated Query Extension"
>>>
>>> Suggest rewording the first paragraph based on the new introduction
>>> text, as follows:
>>>
>>> """
>>> Queries over distributed SPARQL endpoints often involves querying one
>>> source and using the acquired information to constrain queries of the
>>> next source. This section illiustrates how this can be achieved using
>>> SPAQL1.1's SERVICE Graph patterns by examples.
>>> """
>>>
>>> =>
>>>
>>> """
>>> The SERVICE keyword instructs a federated query processor to invoke a
>>> portion of a SPARQL query against a remote SPARQL protocol service.
>>> This section presents examples of how to use the SERVICE keyword. The
>>> following sections define the syntax and semantics of this extension.
>>> """
>>>
>>> 2.1 Simple query to a remote SPARQL endpoint
>>>
>>> Suggest rewording:
>>>
>>> """
>>> This example shows how to query a remote SPARQL endpoint and join the
>>> returned data with the data at local RDF data store. Imagine we want
>>> to know who do I know. Data about people is in
>>> <http://people.example/sparql> endpoint:
>>> """
>>> =>
>>> """
>>> This example shows how to query a remote SPARQL endpoint and join the
>>> returned data with the data from the local RDF data store. Consider a
>>> query to find the names of the people I know. Data about the names of
>>> various people is available at the <http://people.example/sparql>
>>> SPARQL endpoint:
>>> """
>>>
>>> 2.1 and following -- the examples are much improved. There is still
>>> some inconsistency between the data in the remote endpoints and the
>>> URI of the endpoints. 2.1 uses "people.example" and 2.2 uses
>>> "people.example.org", for instance. It would be good to make these all
>>> match up to help the reader follow the examples without being confused.
>>>
>>>
>>> 2.2
>>>
>>> I think this example needs a couple of changes:
>>>
>>> * The URIs of the services in the description does not match the URIs
>>> in the query
>>>
>>> * The query nests one SERVICE inside another. This requires the first
>>> service to be a federated query processor. This should be mentioned in
>>> the example, or the example changed so that the OPTIONAL is outside of
>>> the SERVICE clause (in which case the foaf:interest triples would need
>>> to be local).
>>>
>>>
>>> 2.3 Variable Services
>>>
>>> "in the default graph" => "in the local default graph"
>>>
>>> """
>>> When having variables for specifying the address of a SPARQL endpoint
>>> in a SERVICE operation this variable must be bounded.
>>> """
>>> =>
>>> """
>>> A variable used with the SERVICE keyword must be bound.
>>> """
>>>
>>> (See comment above.)
>>>
>>> 2.4
>>>
>>> """
>>> the query will stop returning the corresponding SPARQL error.
>>> """
>>> =>
>>> """
>>> the query will stop and return the error.
>>> """
>>>
>>> 2.4 - Can we add &nbsp; or something in the table cell in the results
>>> to make it render as a full-height empty cell to show that there is
>>> one row in which ?name is not bound?
>>>
>>>
>>> 2.5 As per
>>> http://lists.w3.org/Archives/Public/public-rdf-dawg/2011AprJun/0119.html
>>> ,
>>> I'd remove this example completely and substitute the text in that
>>> email message. While SERVICE and BINDINGS _can_ be used in the same
>>> query, that is not the "natural" intent of things -- instead, the
>>> natural intent is that a federated query implementation would
>>> _generate_ queries with BINDINGS to help constrain the results from
>>> the remote endpoint. An example showing this would be helpful, but is
>>> probably too much before Last Call, so I'd remove this example entirely.
>>>
>>>
>>> thanks,
>>> Lee
>>>
>>>
>>
>>