- From: Wilde, Erik <Erik.Wilde@emc.com>
- Date: Wed, 27 Mar 2013 14:52:01 -0400
- To: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- CC: Richard Cyganiak <richard@cyganiak.de>
hello richard. On 2013-03-27 11:36 , "Richard Cyganiak" <richard@cyganiak.de> wrote: >What are the entries in those feeds? Generic RDF payloads? Specific RDF >payloads? Something else? i don't think that should matter for us at all, because we want to be a platform (i.e., provide LDP services for clients that are managing any kind of resources, whatever they may be). the entries are LDP resources (maybe exposing the "updated" timestamp), the content is what matters most to PROV. in this particular case, i would expect the content to be provenance statements in RDF, and a client POSTing such a resource would use the PROV-DM vocabulary, for example informing the pingback container that it just used something (http://www.w3.org/TR/2013/PR-prov-dm-20130312/#term-Usage). then somebody GETting the pingback container would see such a new entry (assuming it's sorted by update, a conditional GET would thus actually result in a new container representation, and the client would see that there is one new member URI it hasn't seen before), could GET the PROV pingback resource if they're interested in the details of what happened, and would thus understand that the a new PROV used() event happened. i am sure i did get some/many of the PROV details wrong here, but in terms of general interactions, this is how i think it could work. for DELETE (just making sure the subject is mentioned) we would not have any support, though, because that would require some special property in the container that, in the time-sorted list of members would represent the fact that this member has been DELETEd. but maybe the whole DELETE story doesn't matter to PROV, it all depends on their scenarios. cheers, dret.
Received on Wednesday, 27 March 2013 18:52:58 UTC