- From: Nandana Mihindukulasooriya <nmihindu@fi.upm.es>
- Date: Wed, 24 Apr 2013 19:34:10 +0200
- To: Graham Klyne <graham.klyne@zoo.ox.ac.uk>
- Cc: Erik Wilde <dret@berkeley.edu>, LDP <public-ldp@w3.org>, W3C provenance WG <public-prov-wg@w3.org>
- Message-ID: <CAAOEr1kHgoea-OC8S+jPwPYLop0ZDTUh4iecT4gCYnAp3=sAdw@mail.gmail.com>
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 Wednesday, 24 April 2013 17:34:59 UTC