PROV-AQ SPARQL endpoint discovery (ISSUE-609)

Indicating SPARQL endpoints fort provenance information is one of the points in 
PROV-AQ that I was actioned to raise for discussion as of the last teleconference.

See also: http://www.w3.org/2011/prov/track/issues/609

The question is asked:  how do we discover a SPARQL endpoint for provenance 
querying?

The latest version has removed all text about using SPARQL to query provenance, 
as this has been considered more appropriate for the FAQ (it adds no new 
specification).  But the question of discovering an endpoint remains on the table.

Here are some options (not necessarily exhaustive):
1. Say nothing: treat it as out of scope
2. Use a new link relation
3. Make it part of the provenance service description (different URI from 
current REST provenance service)
4. Make it part of the provenance service as an option (same URI as current REST 
provenance service)

Somewhat perversely, maybe, I'm going to discuss these in reverse order...

...

Of these, I oppose number 4:

I think it makes a simple and RESTful interface service description potentially 
much more complicated, and would drag us into a mire of detail whose ultimate 
value is highly questionable.

...

I think option 3, or something very similar, is proposed by Tim at 
http://lists.w3.org/Archives/Public/public-prov-wg/2012Nov/0324.html

The idea as I understand it is that on retrieving the service description 
indicated by a provenance-service link, the description indicates a SPARQL endpoint.

Tim proposes that the service description returned should be (per 
http://www.w3.org/TR/sparql11-service-description/):

   <service-URI> a prov:ProvenanceService, sd:Service ;
     ...

I could go with this with one change: DO NOT return prov:ProvenanceService as a 
type for this endpoint, as that causes confusion with the RESTful service 
specification we already have; i.e. return just:

   <service-URI> a sd:Service ;
     ...

...

Option 2 was my first suggestion.  I think it has the advantage of simplicity, 
but Tim argues against this "I'm not fond of another link relation just to point 
to one specific service technology" 
[http://lists.w3.org/Archives/Public/public-prov-wg/2012Nov/0324.html].

It seems to me that link relations are cheap and easy to decode, so I don't 
fully go with this argument.  But there's a comment by Eric Wilde that I think 
is worth thinking about:

[[
while this may be a bit fuzzy, typically link rels and media types serve
different needs:

- a link rel allows a client to understand why it might want to follow
some link from a resource ("get a picture of the product here").

- a media type then governs the actual interaction, where client and
server need to agree on how to interact when the client has made the
choice to engage in the interaction ("here's an image/gif, because you
told me you know how to handle this media type").
]]
-- http://lists.w3.org/Archives/Public/public-ldp/2012Nov/0030.html

Which suggests a decomposition into Why? (link del) and How? (resource type - 
which might conceivable be extended to resource content)

But see also some discussion that sheds doubt on the roles of media type:
[[
Ah, I think I finally understand why you talk about different media
types. I've never seen the need, and still can't quite say that I do,
at least in the sense of "need" that derives from working within the
constraints of REST.
]]
-- http://lists.w3.org/Archives/Public/public-ldp/2012Nov/0014.html

Option 2 also has the advantage of being direct and simple, even though it may 
somewhat go against the spirit of the why/how principle noted by Eric Wilde.

From, a purely pragmatic viewpoint, I'd make a case that finer-grained link 
relations are more efficient:  if there are (say) a provenance REST service (as 
defined by PROV_AQ) and a provenance query service following the SPARQL service 
description, different link relations would allow me to pick the one I want and 
get on with accessing the provenance.  But if the same link relation is used for 
each, I have to read the service documents to decide which one to use.  This has 
two problems:
1. Extra round-trips.
2. Increased client code complexity.

Of these, I think the latter is more compelling.

(An alternative might be to use a link extension parameter, but that too can 
have the effect of making client code slightly more complex, as the link header 
parsing rules get more involved.)

...

Option 1 is our natural fallback if we don't find easy consensus on any other 
approach.

#g
--



FURTHER NOTES

See also:
[[
RDF isn't RESTful it itself because it's not a hypermedia format
]] (!)
-- http://lists.w3.org/Archives/Public/public-ldp/2012Nov/0008.html

[[
RDF isn't RESTFul at all. It's just a webby entity relationship model
  :
RDF based Linked Data is RESTful, ...
]]
http://lists.w3.org/Archives/Public/public-ldp/2012Nov/0019.html

Received on Monday, 10 December 2012 17:34:48 UTC