kjetilk / p5-atteanx-query-cache

Experimental prefetching SPARQL query cacher, take 2
0 stars 1 forks source link

Support protocol to find LDF start URL from SPARQL endpoints #30

Open kjetilk opened 8 years ago

kjetilk commented 8 years ago

I future feature would be that if you have a SPARQL endpoint, you would need to find an LDF start URL. And possibly the reverse. The current code assumes there is an LDF that can answer the same triple patterns as the SPARQL endpoint, but it would be nice if the hypermedia could tell us when this is the case and not.

kasei commented 8 years ago

Yeah, we should have a property that can be used in a service description for this. I've always had a hard time committing to a namespace for these things, but otherwise this should be a trivial thing to do.

kjetilk commented 8 years ago

Yeah. It has been discussed at length in the Hydra group, with @RubenVerborgh active, but it has been difficult to reach consensus on something with sufficiently clear semantics.

kasei commented 8 years ago

Really? I would have thought the semantics are obvious. What's the concern?

kjetilk commented 8 years ago

I don't quite remember... There is the hydra:search predicate that someone proposed for the purpose, but it erupted into a 150-message thread on the list or something like that... :-) I couldn't keep up.

RubenVerborgh commented 8 years ago

@kasei I believe we had a thread about this on the Hydra mailing list. hydra:search doesn't have sufficiently strong semantics (it just says: "this form is searching based on" but not "this form is an AND filter for equality matching"). The proposed solution, hydra:filter, is severely delayed unfortunately (see https://github.com/HydraCG/Specifications/issues/45).

kasei commented 8 years ago

@RubenVerborgh Maybe I've misunderstood what @kjetilk is after here. I took this to be an issue about wanting a way to indicate in a SPARQL service description that the default graph (or any named graph, I guess) of the default dataset is also accessible via TPF. I guess that might be able to use hydra:search (I'm not entirely clear on what the range of that property is), but it could also be simpler to provide just an IRI (not a template) that will return the all the LDF hypermedia metadata... Does that make sense?

kjetilk commented 8 years ago

So, I suppose the SPARQL SD could include the LDF control information in its entirety... That would be a good solution, right, @RubenVerborgh ?

RubenVerborgh commented 8 years ago

That would be great!

kasei commented 8 years ago

Doesn't that run the risk of the SD having stale control data? Why should the control data have to be managed in two different places when only one of them is (or might be) authoritative?

The only case where this makes sense to me is if the exact same software is providing both the SPARQL and LDF interfaces.

kjetilk commented 8 years ago

See, it wasn't that easy to reach consensus ;-) So, yes, I suppose, there is no real reason to include it, rather than link to it in the SD.