Remove bulit-in graph loading for FROM and FROM NAMED in SPARQL evaluation

[mwatts15]

There's logic in rdflib.plugins.sparql.evaluate to evaluate FROM and FROM NAMED in SPARQL queries that calls QueryContext.load in rdflib.plugins.sparql.sparql which loads graphs from remote resources. This behavior would be better handled by Store implementations (possibly indirectly through Graph): Stores can decide whether to use a locally stored graph or download one and from where, and the configuration that goes into the decision can be handled in the construction of the Store instance in Store.open rather than globally (e.g., with rdflib.plugins.sparql.SPARQL_LOAD_GRAPHS). The shared logic for loading the graph can be retained in a utility which stores can call if they need to load a graph and don't have their own mechanisms for doing so.

[nicholascar]

Hi @mwatts15 I need a working RDFlib FROM, FROM NAMED or SERVICE capability shortly as I want RDFlib-powered SPARQL-enabled APIs to query both local and remote endpoints. So I'm interested in this work.

[white-gecko]

I had this issue already in #810, where I decided to just set rdflib.plugins.sparql.SPARQL_LOAD_GRAPHS = False and in #811 regarding the FROM and FROM NAMED part.
It would be very good to clean up the behavior of these.
@nicholascar Isn't SERVICE implemented in #943?

[mwatts15]

@white-gecko Thanks. I had seen #811, but since I see no activity on it since it was written, I think a new issue which is more prescriptive is justified.

[namedgraph]

@aucampia I think this should be disabled by default (i.e. rdflib.plugins.sparql.SPARQL_LOAD_GRAPHS = False should be the default) to make it compliant with the SPARQL spec.

[apicouSP]

here I only load the remote graphs if not found in the given ConjunctiveGraph. Would that solve this issue?
That wasn't my goal so I didn't implemented in the store like you said. But at least you can use named graphs without setting SPARQL_LOAD_GRAPHS to False