discussion: SPARQL endpoint

[justin2004]

The SERVICE keyword instructs a federated query processor to invoke a portion of a SPARQL query against a remote SPARQL endpoint.

https://www.w3.org/TR/2013/REC-sparql11-federated-query-20130321/

SPARQL endpoint
    The URI at which a SPARQL Protocol service listens for requests from SPARQL Protocol clients.
SPARQL Protocol service
    An HTTP server that services HTTP requests and sends back HTTP responses for SPARQL Protocol operations. The URI at which a SPARQL Protocol service listens for requests is generally known as a SPARQL endpoint. (Also known as: service)

https://www.w3.org/TR/2013/REC-sparql11-protocol-20130321/

so a critic of sparql-anything might say that the URI inside the following <> is no SPARQL endpoint

...
    service <x-sparql-anything:https://gist.githubusercontent.com/justin2004/edaaef0137f1c066c88d2c0b43adc254/raw/7d2852cfaef082fb923717b9f22b3b34ca157780/sample.csv> 
...

because it doesn't respond to all SPARQL Protocol requests.

i feel like sparql-anything might address this concern because the scheme is x-sparql-anything: and not http:.

have you thought about this critique or does your x-sparql-anything: scheme avoid the critique?

[enridaga]

That's an interesting point. I am not sure about how extensive the SPARQL protocol is assumed to be used in SERVICE clauses, apart from the GET/POST query methods. However, the goal of this system is to enable access to diverse resources and limiting as much as possible changes to the SPARQL syntax. Overriding the SERVICE clause seemed to be a good option. We may even argue that this limitation of the SPARQL spec could be removed in future versions as there is no added value in assuming that the remote service is a SPARQL endpoint, the assumption should be that what is returned is a SPARQL result set. There is an interesting discussion on this here: w3c/sparql-dev#10

[justin2004]

We may even argue that this limitation of the SPARQL spec could be removed in future versions as there is no added value in assuming that the remote service is a SPARQL endpoint

one thing of value is the ability to do something like this:

select distinct ?s where {
graph ?g { ?endpoint a :SparqlEndpoint }
service ?endpoint { ?s a :Person }
}

i totally agree with the goal:

However, the goal of this system is to enable access to diverse resources and limiting as much as possible changes to the SPARQL syntax.

so i'd like to see that sparql-anything checks all the boxes!

[enridaga]

I think that query is supposed to work if ?endpoint is a URL to the SPARQL endpoint. If it doesn't, I think this is a BUG!

[enridaga]

I checked the following two queries and both run smoothly with the current version at 0.3-DEV:

select distinct ?t where {
 SERVICE <https://dbpedia.org/sparql> { <http://dbpedia.org/resource/Category:People_by_location> a ?t }
}

and

select ?p ?o where {
 VALUES(?endpoint){(<https://data.open.ac.uk/sparql>)}
 SERVICE ?endpoint { <http://data.open.ac.uk/context/led> ?p ?o }
}

So, going back to your original query:

select distinct ?s where {
graph ?g { ?endpoint a :SparqlEndpoint }
service ?endpoint { ?s a :Person }
}

and assuming you have a local file in N-Quad to pass to the CLI option --load, which will have the data expected in graph part of the query, the service call should work.

[justin2004]

my colleague pointed this out to me today:
w3c/sparql-dev#10

it seems other teams are interested in relaxing the spec about what can a service clause URI can refer to.

and this as well:
https://github.com/oeg-upm/morph-gft/blob/10a83c72020c738eafdf9f13b2491e9056f39243/oegmembers.sparql#L12

EDIT: oh you already referenced that issue! i missed it.

[justin2004]

from the comment
w3c/sparql-dev#10 (comment)

i do like the get:soft idea

 get:soft

 is the retrieval mode, supported values are "soft" and "replacing". If
 the value is "soft" then the SPARQL processor will not even try to
 retrieve triples if the destination graph is non-empty.

also get:refresh is helpful too.

if sparql-anything were to do something like that it would have to maintain a TDB (as a cache) though. not a terrible idea.