Skip to content
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

Suggestion: Dereferencing of URIs used in FROM and FROM Named clauses without corresponding graphs in the dataset #129

Open
MaillPierre opened this issue Jun 19, 2023 · 2 comments

Comments

@MaillPierre
Copy link
Member

As seen in a previous issue, Corese has implemented a dereferencing mechanism that uploads a file as a graph. This mechanism could be implemented to dereference URIs used in SPARQL queries in FROM and FROM NAMED clauses.

Detailed Description

In the SPARQL norm, the dereferencing of URIs in FROM and FROM NAMED clauses is left to the implementor. Only security remarks are left as information for the implementation of the norm.
Currently, Corese already implements a dereferencing and loading mechanism for files that contain the owl:imports property.
This mechanism could be transposed to SPARQL queries when a FROM clause is given but does not name an existing graph.

Context

The implementation of this mechanism would make it possible to test the dereferencability of URIs. In best practices for Linked Data, URIs are encouraged to be dereferenceable but no way to verify or take advantage of that is available is SPARQL. With this change in Corese, one could test if the graph resulting from the dereference of a URI contains any triples, and deduce if the URI can be dereferenced or not.

Furthermore, the SPARQL-SD and the VoID define ways to retrieve metadata descriptions, of SPARQL endpoints and datasets respectively, hosted in an RDF document. Despite their usefulness, those descriptions are not natively usable in SPARQL queries. With the proposed change, one could make SPARQL that adapt themselves to a SPARQL server or a dataset according to their self-descriptions.

Possible Implementation

A security audit of possible ways to abuse this mechanism is necessary. The mechanism of file retrieval and load as it exists seems usable as is. If the URI given correspond to an existing graph, then no dereferencing should be done, and the query should be executed as done currently.

Your Environment

@ocorby
Copy link
Contributor

ocorby commented Jun 19, 2023 via email

@MaillPierre
Copy link
Member Author

This work for my use case, while I wait for the implementation of the suggestion ;)

Thanks

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

No branches or pull requests

2 participants