Re: federated query review, reprised

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

Received on Thursday, 12 May 2011 13:09:41 UTC