Re: Requesting reviews of Provenance Access and Query document.

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