Closed kvistgaard closed 2 years ago
For inspiration https://github.com/blazegraph/database/wiki/QueryHints
What about this: for open endpoints to give the endpoint URL in the SPARQL query as a comment?
This is exactly how i see it
@kvistgaard what do you think about that...
#
# *endpoint https://query.wikidata.org/bigdata/namespace/wdq/sparql
#
PREFIX schema: <http://schema.org/>
PREFIX wd: <http://www.wikidata.org/entity/>
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
PREFIX wikibase: <http://wikiba.se/ontology#>
PREFIX bd: <http://www.bigdata.com/rdf#>
SELECT DISTINCT ?ms ?msLabel ?hos ?hosLabel
WHERE {
?ms wdt:P463 wd:Q458;
wdt:P35 ?hos .
SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
But there is still a default one if it's not specified?
@ktk Yes.
in version 0.0.10
# add the endpoint in a comment like this
# [endpoint=https://lindas.admin.ch/query]
#
SELECT....
This is indeed a good idea.
Why do we need "Endpoint per cell"?
What is not good right now:
These two issues are somehow the same just another point of view.
Technical problems
Possible solution
We can provide a special configuration comment within a SPARQL query. Similar to Stardog query hints e.g. #pragma group.joins.
We have to distinguish two cases. The unauthenticated and the authenticated case. For unauthenticated cases we just need a query hint with the SPARQL endpoint URL e.g. #sparql-notebook.endpoint=https://dbpedia.org/sparql
Advantages
Disadvantages
It's not working well with credentials
How to use it with credentials? Currently passwords are stored within a connection "outside" the notebook. To provide a way to have more than "one" connection within a notebook we can use a query hint to say what connection we have to use for this query. And reference the connection with it's name. e.g. #sparql-notebook.connection='DB Pedia'
Then we have to maintain the connections separate to the endpoint. That is not nice. And there is a relation between the notebook connection names in notebook cells and configured connections. And all users have to use the same name. That is very inconvenient and we cannot assume all Users use the same name for the same connection. It has too many downsides to do it like this.
We may ask for credentials to create temporal connection objects before executing the query.
We don't have to focus on the authenticated case
At the moment we can focus on the simple case where we just need a SPARQL Endpoint. Let's see how it feels.