Re: Requesting reviews of Provenance Access and Query document.

hello graham.

my apologies for obviously misinterpreting "pingback". i always found 
this term terribly confusing, and i think i have fallen into this 
terminology trap again by reading the term too literally.

given this misunderstanding and now hopefully understanding better what 
you're asking for, it seems basically what you're looking for is the 
service model of feeds (which is what typical pingbacks are using). a 
way how clients can consume updates in a well-defined and unified way, 
based on a regular pull model, adding create/update/delete capabilities. 
clients creating pingbacks can POST to the pingback feed, clients 
interested in learning about pingbacks can GET the pingback feed.

this interaction pattern in general is something that LDP wants to 
support. a container accepts POST, and then creates a new resource as a 
result. this resource would represent the pingback, and in your case 
might represent the information about how a resource has been used by 
somebody who now POSTs the pingback.

as a result, the newly created pingback resource now is linked to from 
the container, and anybody GETting the pingback container will see this 
link, and then can GET the pingback resource itself (if they're 
interested in actually consuming it).

here are some things to look out for, given where we are:

- this depends on date-ordered containers, so that pingback listeners 
can do conditional GETs, and will only see updates when the container 
has actually changed. as in feeds, we don't say anything about a 
"default order", but it certainly can be by update timestamp.

- we currently have no defined ordering. it is not sure whether we will 
have client-requested ordering. servers can order any way they like 
(including the default behavior that many feed servers use, which is 
update-based). we need a way how to represent order in containers at the 
very least, and that is currently being discussed.

- we may or may not have client-controlled paging. this again  might not 
matter, because as with regular feeds, pingbacks probably are based on a 
service model where all you GET to see is the last 10/20/100 pingbacks, 
and that might be enough for most clients. if you need a full history, a 
service could either always expose the complete history of pingbacks 
(which can of course become very large), or, should LDP not have paging 
at least in the form of "next page" links on containers, then pingback 
containers could introduce their own paging links.

- for this to scale, common metadata is critical. feeds have "updated" 
timestamps, so that entries can be aggregated, filtered, and republished 
based on a common metadata model of entries. currently, it seems that 
the LDP WG majority does not want to have a metadata model for 
containers and resources. in that case, provenance/pingback would need 
to define their own timestamp model, and mechanics would depend on LDP 
servers supporting this particular metadata for ordering their containers.

- in terms of resource orientation, we should have what you need: you 
can POST to a container, which creates a new resource. this resource 
then represents the provenance pingback. clients GETting the pingback 
container will see this new member, and caching and conditional GETs 
work fine. clients can then GET the pingback resource to see the new 
provenance information. the original pingback provider can even go in an 
PUT an updated version of that resource (let's say there was an error in 
the initial POST), and it should show up again (with a newer "updated" 
timestamp) in the container. for removing a pingback, you can DELETE the 
pingback, and then LDP has the interesting problem of how to communicate 
that "this member now no longer is a member" (this problem was only 
recently solved in atom by http://tools.ietf.org/html/rfc6721 which adds 
an entry that, when showing up in feed, tells the feed consumer that a 
certain entry has been deleted from a collection). that last part 
(communicating DELETE) is not something we have discussed so far, and i 
don't see it being discussed/addressed for v1.

to summarize: i think we have the resource model that supports the 
interactions you're looking for. we might not have the full data model 
support you need to make it work out of the box, because we might not 
give you the "updated" timestamp to work with. we also might not support 
communicating the deletion of resources. it's still not quite clear what 
LDP eventually will or will not provide out of the box. but i will 
suggest to the group that we add this example to our use cases. we're 
not far off, and it's very good input for us. thanks a lot!

cheers,

dret.

Received on Wednesday, 27 March 2013 16:56:21 UTC