Re: Comments on PAQ

Stephen,

Thanks for your comments.

On 18/11/2011 12:59, Cresswell, Stephen wrote:
>
>
> Graham, Paul,
>
>
>
> I have a few comments on PAQ document (not obstructing its release).  I
> read it from the perspective of needing to decide on some solution to
> deploy.  I think the document works and I learned quite a lot reading
> from it.  The biggest question I had was why some possibilities seem to
> be missing, which I think Luc already flagged. I just wanted to
> emphasise this because (unless I misunderstand it) the missing
> possibilities are (from my perspective) some of the most important ones.
>
>
>
> I got these:
>
> If a resource is published by HTTP, or it is HTML or XHTML, then we can
> link to provenance by provenance-uri or provenance-service-uri.
>
> If a resource is some form of RDF, then we can give provenance-uri (but
> apparently not a provenance-service-uri?).

You're the second person to raise this, and on reflection I'm finding it harder 
to justify the asymmetry.  (Originally I had this idea that the RDF case was 
somehow different, or aiming at use-cases where the provenance service made less 
sense, but on reflection I find it hard to sustain that argument.)

I've raised this as ISSUE 154 (http://www.w3.org/2011/prov/track/issues/154).

> Despite the coverage of querying provenance in SPARQL, the document
> doesn't tell us how to publish a resource and indicate that its
> provenance can be retrieved from a particular SPARQL endpoint (using a
> given entity-uri and/or a given named graph).  Neither does there seem
> to be a way for a provenance service to give back a link to a SPARQL
> endpoint.  SPARQL endpoints can be self-describing through SPARQL
> service descriptions, but surely we still need to be able to indicate
> that a URI provided for provenance is a SPARQL endpoint.  That seems to
> be a conspicuous gap.

I see two possible points here:
(a) how to publish a resource and associated metadata accessible via SPARQL
(b) how to specifically indicate a SPARQL endpoint for retrieving provenance

(a) Hmmm... my original assumption had been that developers using SPARQL would 
know how to deploy a SPARQL endpoint.  I think my preference would be to 
reference some existing documentation, rather than try to write a description of 
how to do this.   (I think you are not actually suggesting this, but I thought 
I'd cover it just in case.)

(b) I agree there is a gap here:  the link relations introduced are intended to 
be used with direct URI retrieval scenarios.  (In theory, the provenance service 
description could provide a template that encodes a SPARQL query URI, but I'm 
not confident that's a practical option.)

I am conflicted about this as I think this takes is into the general territory 
of query endpoint discovery - I imagine a SPARQL service would typically not be 
used *only* for provenance.  If there are existing techniques we can reference, 
I'd be completely happy to include references to them.  I'm less comfortable 
about defining provenance-specific mechanisms that are likely to overlap 
non-provenance requirements.  I think the natural mechanism would be to 
introduce a new link relation to designate a corresponding SPARQL endpoint.

I'll ask around.

> Section 5.3 - Did you consider using "DESCRIBE
> <http://example.org/resource>  {}" instead of the CONSTRUCT query?

No, I didn't consider that.  Using DESCRIBE is not excluded (this section 
provides examples of possible use rather than prescriptions).

Personally, I'm not a fan of DESCRIBE as a standard construct because it doesn't 
have an interoperable specification, and there's no framework for naming 
interoperable versions - but I know I'm in a minority here - my comments to this 
effect to the SPARQL working group were not accepted.

But for specific applications, I recognize that DESCRIBE can be a useful 
mechanism, and if you think it makes the document more useful I'm not against 
adding it as another example.

> C.1 Gap Analysis - drops into 1st person (not in an annotation).

Yes - it's out of style.

I'd like to remove this section - I think it has served its purpose, and is now 
somewhat outdated.  I've raised this with my co-editor.

#g
--

Received on Saturday, 19 November 2011 09:59:46 UTC