1) In Jena the service must be explicitly part of the query, and therefor the model,
2) In Sesame the basic query patterns must be associated with one or more endpoints before evaluating the query, or
3) Hack the remote query into a graph URI: http://gearon.blogspot.com/2009/05/federated-queries-long-time-ago-tks.html
Although both can be used to achieve the same results, Jena's solution puts more responsibility in the data model, and Sesame's put more responsibility in the deployment. Both have their trade offs, but I believe the query is suppose to be abstracted away from underlying services. The domain model (and therefore the queries) should not be aware of how the data is distributed (or stored) across a network. Therefore, I prefer to describe which graph patterns and relationships are available at each endpoint during deployment and make the application model independent of available service endpoints.
Furthermore, I think it is a bit silly to add yet another level of complexity to the basic query pattern. Adding the service level turns the basic query pattern from a quad to a quint.
To fully index a quint (with support for a service variable, which Jena does not support) would take 13 indexes (nearly double what a quad requires). Below is a table of some complexity levels and how many indexes they require to be fully indexed (variables could appear in any position within the pattern). I have included a theoretical sext that would allow you to group services in a network (just as graphs can be grouped in a service).
Level | #ofIdx | Term | Data Structure |
---|---|---|---|
double | 2 | subject | directed graph |
triple | 3 | predicate | labelled directed graph |
quad | 7 | graph | multiple labelled directed graphs |
quint | 13 | service | replicated multiple labelled directed graphs |
sext | 25 | network | trusted replicated multiple labelled directed graphs |
Hopefully, this topic will have more time to mature before the SPARQL working group makes any official decisions on the matter.