Re: Requesting reviews of Provenance Access and Query document.

Hi Nanada,

My apologies for the delay in my reply - I've been travelling with limited 
Internet access for a few weeks...

Briefly, I agree with all you say.  It's good to see this perspective 
articulated, as it vindicates (for me, at least) many of the design choices made 
in the specification of provenance pingback.

Thanks!

#g
--

On 24/04/2013 18:34, Nandana Mihindukulasooriya wrote:
> Hi  Graham,
>
> I had a look at both the PROV Model primer and PROV-AQ documents and I like
> the simplicity of the approaches proposed for locating, querying, accessing
> and submitting provenance records. I think this complements LDP spec and
> this can be leveraged quite well when someone wants to
> state provenance information about Linked Data Platform Resources (LDPR) or
> want to use LDP for managing provenance records about any kind of resources
> using LDP.
>
> On Wed, Mar 27, 2013 at 8:37 PM, Graham Klyne <graham.klyne@zoo.ox.ac.uk>wrote:
>>
>> That all sounds like a reasonable deployment scenario, and one that I
>> think is broadly consistent with use of pingbacks to trigger such
>> operations.  If a pingback service is modelled as a container, LDP-style,
>> then the pingback POST might trigger addition of additional information to
>> the container.  Note that the pingback doesn't contain content, just links
>> to content, but I don't think that is a problem.
>>
>
> If I model this LDP-style, I would rather model pingback as a resource not
> a container. I will only need a container when I am actually creating a new
> provenance record itself (if it resides in some LDP server) that is not in
> the context of this PROV-AQ document.
>
> Trivial case would be having provenance records about LDPR [1] i.e.
> resources represented in RDF as presented in section 3.3 [2]. In this case,
> locating, accessing and provenance pingback can be done quite transparent
> to the LDP using the existing LDP capabilities. Provenance pingback can
> be achieved by just using LDP to update (PUT/PATCH) the resource with
> new prov:has_provenance properties given that the updating is allowed.
> However, the server could also have a separate pingback-uri if the directly
> updating the resource is not allowed or if it is more efficient so that
> server doesn't need to look into every update for executing any special
> logic required for provenance.
>
> If the other case where a resource (LDPR or otherwise) uses a pingback-uri,
> I would use an LDPR as the pingback-uri. So if I dereference the
> pingback-uri I will get an aggregation of provenance-uris represented in
> RDF. LDP spec does not enforce any additional requirements on a POST to a
> LDPR so what's there in RFC2616 applies. The server can decide what to do,
> so the server can allow the POSTing text/uri-list and update the provenance
> information accordingly. If I wanted to do it more LDP-style, I would
> actually allow updating pingback resource with PUT or PATCH to add new
> pingback-uris. The server will still use validation, security and all the
> other logic before actually deciding whether to go ahead with the update
> just like in anyother pingback service. But if the use of POST and
> text/uri-list content-type is nominative, that won't be fit with the
> current PROC-AQ document.
>
> Just my 2 cents looking at the PROV-AQ from the LDP perspective.
>
> Best Regards,
> Nandana
>
> [1] -
> https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#linked-data-platform-resources
> [2] -
> http://www.w3.org/TR/2013/WD-prov-aq-20130312/#resource-represented-as-rdf
>

Received on Monday, 20 May 2013 09:51:35 UTC