This is likely a ticket for http-api-gateway, but I'm specifying it for db in case the implementation decides to update the core APIs directly
@bplatz has mentioned the implementation of the SPARQL FROM syntax in FlureeQL/JSON-LD in fluree/db#526. This is a subtask of that ticket targeting immediate need to replace our proprietary { "ledger": "fluree/cookbook", "query": { ... } } syntax in the http-api-gateway with a SPARQL-compliant syntax of using from to specify the ledger/graph being queried. Later, the adoption of from will also allow queries against multiple ledgers at once (as a virtualized or merged dataset), but this ticket does not cover that.
The desired outcome of this ticket is to be SPARQL-standard compliant with our syntax, such that a query against ledger fluree/cookbook would look like
The only outcome, here, is that the query itself is the top-level object of the message sent to the /query endpoint. The ledger being queried is extracted from the from key. We should only support single string values on from for now, with the desire in the future to support array values where multiple ledgers are specified by name. The same errors that get thrown for specifying an unknown/uninstantiated ledger should still be thrown here, and from should be a required key-value pair on queries, throwing an error if a query is issued without from
Description
@bplatz has mentioned the implementation of the SPARQL
FROM
syntax in FlureeQL/JSON-LD in fluree/db#526. This is a subtask of that ticket targeting immediate need to replace our proprietary{ "ledger": "fluree/cookbook", "query": { ... } }
syntax in thehttp-api-gateway
with a SPARQL-compliant syntax of usingfrom
to specify the ledger/graph being queried. Later, the adoption offrom
will also allow queries against multiple ledgers at once (as a virtualized or merged dataset), but this ticket does not cover that.The desired outcome of this ticket is to be SPARQL-standard compliant with our syntax, such that a query against ledger
fluree/cookbook
would look likeImplementation Details
The only outcome, here, is that the query itself is the top-level object of the message sent to the
/query
endpoint. The ledger being queried is extracted from thefrom
key. We should only support single string values onfrom
for now, with the desire in the future to support array values where multiple ledgers are specified by name. The same errors that get thrown for specifying an unknown/uninstantiated ledger should still be thrown here, andfrom
should be a required key-value pair on queries, throwing an error if a query is issued withoutfrom