Re: PROV-AQ SPARQL endpoint discovery (ISSUE-609)

Graham,

On Dec 10, 2012, at 9:32 AM, Graham Klyne <GK@ninebynine.org> wrote:

> 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

+.5 (since HTTP GET'ing the service would give me an RDF description that says it's a SPARQL endpoint -- 
-.5 since what I just said would be a best practice that people would need to figure out themselves.

> 2. Use a new link relation

-1 it's superfluous proliferation that is more eloquently handled.

> 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)

I don't see how the distinction of "same or different" URI applies.
I think you need to demote your "REST provenance service" as an option among many, instead of the "requirement" that you're framing it as now.
When you do, "same or different URI" becomes moot, and it would either report back that it's a URITemplate service or a SPARQL endpoint service or a JDBC service or a TheNextWay 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 ;
>    …


Then I think prov:ProvenanceService as it stands is over specified.
prov:ProvenanceService should be defined as "A service that provides provenance information", and a SPARQL endpoint that returns PROV-O should be a legitimate instance of this class.
(THIS has the beginnings of a blocker issue)
Otherwise, you're demanding *how* it should behave, instead of permitting anyone's service to indicate that it is indeed something that PROV-savy clients can "poke around in".
I suggest you relax your "RESTful service specification" to a suggestion among many options and make it less of a requirement (similar to how I'm suggesting you treat the URI template in another thread).




> 
> ...
> 
> 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].

Yes, I call it superfluous proliferation.

> 
> 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").


The "why" should be "there's a service offering PROV over ?there" (*independent* of implementation), not "There's a SPARQL (i.e., specific implementation) endpoint over there". 
Let linked data and REST do the work. If you want PROV, go request the server's URI and find out about how it accepts requests.

> 
> - 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").
> ]]


Exactly. Follow the rel="provenance" and GET HTTP Accept application/rdf+xml (or text/turtle) to get an RDF description of the service.
Find out it's a SPARQL endpoint (or, JDBC, or uritemplated, or whatever) and then follow suit if you know how to talk SPARQL, JDBC, uritemplated, or whatever.
If the server uses another technology to describe it's interface, then it can return that regardless of the HTTP Accept. It's just not a great citizen of the [semantic] web.


> -- 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.
> ]]


Yes, REST's dependence on MIME is unfortunately working at the format == frbr:Manifestation level, not the content ==  frbr:Expression level.
If one wants the same behavior for "all RDF formats", then they need to map those MIMEs into "abstract RDF" and behave appropriately regardless of format.


> -- 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.


Yes, breaking how and why would be pretty bad.


> 
> 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.


Yes, this is a good argument for superfluously proliferating your link types. 
But you're just pushing the logic from one place to another, so why not keep it where it is most natural?
Practically, how many different service implementations would one resource have? I would think few.
Also, a well designed service could handle multiple service request types, so it's not clear that the service implementations would proliferate.


> 
> (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.

+.5, since my suggestion would go into the FAQ.

-Tim



> 
> #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 Tuesday, 11 December 2012 17:11:36 UTC