-
Notifications
You must be signed in to change notification settings - Fork 25
Feature/sparql fed query #1134
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Feature/sparql fed query #1134
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bbc0aac to
56ec445
Compare
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.
d9fe3d5 to
07c405e
Compare
zonotope
approved these changes
Oct 23, 2025
Contributor
zonotope
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🔦
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
https://github.com/fluree/core/issues/207
Introduces support for the SPARQL
SERVICEclause: https://www.w3.org/TR/sparql11-federated-query/#serviceThe 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
SERVICEclause is retained as a raw string. This raw SPARQL string is turned into a valid SPARQL query by prepending it with aWHEREand prepending that with any defined prefixes from the json-ld@contextand and aSELECT *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.