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
Should be able to use prefixes bound in graph's NamespaceManager #5
Comments
Hi @Natureshadow , thanks for reporting the issue. Indeed the It seems like for some reasons RDFLib does not automatically picks up the graph namespaces (only using the query namespaces) I made some changes to extract the graph namespaces and add them to the |
Hmm. For all queries I run myself, it picks them up perfectly fine. Also, as said, it works as well in rdflib-endpoint when running |
Your change will not solve this, as it does not change the |
Hi @Natureshadow, I probably did not understand your issue then. Do you have a snippet to reproduce it so I can test it? If I expose a graph from a turtle file that includes some bindings using rdflib-endpoint, e.g.: from rdflib import Graph, RDF
from rdflib_endpoint import SparqlEndpoint
g = Graph()
rdf = """@prefix sometest: <https://sometest.org/> .
sometest:Test a <http://test> .
"""
g.parse(data=rdf, format="ttl")
app = SparqlEndpoint(graph=g) And I run this SPARQL query without defining the SELECT * WHERE {
sometest:Test a ?t .
} For me it returns the expected results, but from what I understood for you it does not returns anything, because the prefix is not taken into account when executing the query. Is that right? Note that I made those tests with rdflib 6.2.0 |
Prefixes can be bound to a graph using the NamespaceManager. This makes them globally available, when loading and serializing as well as when querying.
rdflib-endpoint, however, requires prefixes to be declared in the query input even for those bound to the graph, because
prepareQuery
is not aware of the graph.It would be convenient if the SPARQL endpoint could use the globally bound prefixes. My suggestion would be to drop the
prepareQuery
completely. I actually don't see why it is there in the first place, given that the prepared query is never used later on.The text was updated successfully, but these errors were encountered: