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

Hi Graham,

I think I'm with Tim here. We seem to be generating a ton of new link
types. I'm already not that happy with the service/resource distinction,
but understand why we need it.

I think this idea of using the description of the service as a way to
check, motivates the need for a service description other than rest
compatibility.

cheers
Paul


On Tue, Dec 11, 2012 at 6:10 PM, Timothy Lebo <lebot@rpi.edu> wrote:

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