Skip to content

Conversation

@dpetran
Copy link
Contributor

@dpetran dpetran commented Oct 13, 2025

https://github.com/fluree/core/issues/207

Introduces support for the SPARQL SERVICE clause: https://www.w3.org/TR/sparql11-federated-query/#service

The approach here is a very naive one, but it is in compliance with the spec. There are many performance improvements we can use to make this faster if the current implementation is not sufficiently fast for a given use.

SPARQL is translated into jld-query syntax but the SERVICE clause is retained as a raw string. This raw SPARQL string is turned into a valid SPARQL query by prepending it with a WHERE and prepending that with any defined prefixes from the json-ld @context and and a SELECT * clause. This is then sent to the specified SPARQL service endpoint and the JSON results are parsed and turned into solutions.

It is not possible to test a working SPARQL service endpoint within this repo, so the tests are incomplete. However, Fluree Server does implement a valid SPARQL endpoint and it is entirely valid for a query to reference its own hosting service, so there are more complete tests in fluree/server#186.

@dpetran dpetran force-pushed the feature/sparql-fed-query branch from bbc0aac to 56ec445 Compare October 14, 2025 21:00
This is much more inefficient, but some remote services can't handle a VALUES clause
with variables that aren't in the query. We'll need to adding SERVICE var filtering in
the future anyways to account for $-prefixed vars in the SERVICE clause, but this is the
simple and correct way to handle it for now.
onto-chan! closes the channel after it is done putting its collection, and I think it
looks better than calling >! and the close! in a do-block. Without closing the downstream
consumers are blocked.
These will be a useful performance enhancement, but aren't needed for this first
iteration. The only additional validation they require is to only bind vars that are
present in the SERVICE clause - I ran into some errors from 3rd party services when
trying to handle vars not in the clause (though that is not strictly in spec for
SPARQL).
We can't test responsive endpoints within this repo, so we'll just verify that errors
are handled correctly.
@dpetran dpetran force-pushed the feature/sparql-fed-query branch from d9fe3d5 to 07c405e Compare October 22, 2025 19:51
@dpetran dpetran marked this pull request as ready for review October 22, 2025 20:17
@dpetran dpetran requested a review from a team October 22, 2025 20:17
Copy link
Contributor

@zonotope zonotope left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔦

@dpetran dpetran merged commit d862955 into main Oct 23, 2025
29 of 37 checks passed
@dpetran dpetran deleted the feature/sparql-fed-query branch October 23, 2025 20:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants