Re: [Protocol] Strawperson Principles and Approach

> On 08 Jan 2015, at 18:41 , Robert Sanderson <azaroth42@gmail.com> wrote:
> 
> 
> Ping :)
> 
> Would it help for me to write up a version 0.0001 specification type of document based on these ideas to comment on, or otherwise what would be helpful in making progress?

Yes:-)

Ivan

> 
> Thanks all!
> 
> Rob
> 
> On Thu, Dec 11, 2014 at 5:08 PM, Robert Sanderson <azaroth42@gmail.com> wrote:
> 
> While we collect use cases, I think it's still fruitful to discuss a baseline set of interactions that can be refined and extended in response to the requirements analysis down the line.
> 
> As a strawperson to start from, I would like to kick it off by proposing the following principles and high level design.
> 
> == Principles ==
> 
> 1.  Interactions should be designed to take place over HTTP, but should not prevent their implementation over other low level protocols, potentially via some extension.
> 
> 2.  Interactions should follow the REST best practice guidelines when there is a resource being acted upon.
> 
> 3.  We must respect the web architecture first and foremost, seek to re-use existing systems when possible, collaborate with other working groups if our requirement falls under their charter, and invent only as a last resort.
> 
> 4.  Simplicity and ease of use are important but are ultimately subjective and should not sway us to ignore the above principles other than in extreme cases.
> 
> 
> == Strawperson ==
> 
> * Creation, Updating, Retrieval and Deletion of individual annotations should use the patterns described in the Linked Data Platform API [1].  LDP is currently in last call, and hence will shortly be a stable base on which to build.  It follows the web architecture and REST principles, and mandates the use of JSON-LD which we also require.
> 
> In particular, you create an annotation by POSTing to a container URI [2] with the body of the message containing the JSON-LD serialized annotation.  You update an Annotation by PATCHing with the changes, or PUTing the complete representation.  ETags should be used by both client and server to avoid race conditions.
> 
> The container that is POSTed to is an LDP construction that holds resources and allows its contents to be listed.
> 
> * Further clarifying the LDP specification, we recommend that the Creation and Updating operations (PUT, POST, PATCH) as well as retrieval (GET) return the annotation as modified by the operation in the entity-body.
> 
> * We would engage with the LDP WG on the topic of authentication and authorization, and try to implement any mutually agreeable solution.  The current web ACL solution [3,4] is incomplete and not standardized, but is up for discussion in the current rechartering [5] process.
> 
> * Notification would be done using ActivityStreams from the Social Web WG [6].  We would follow the basic approach of <agent> <created/updated/deleted> <annotation>, rather than attempting to map all of the properties of the annotation into the notification.  There were difficulties with annotations such as bookmarks or highlights that do not have a body in trying to do that mapping [7], for example.
> 
> * Search ... well... how about that local sports team, eh? Didn't they do well? Note, this is not the strawperson you're looking for.  Which is to say I'd prefer to discuss the above first and keep search for its own thread :)
> 
> 
> References:
> 
> [1]  http://www.w3.org/TR/ldp/
> [2]  http://www.w3.org/TR/ldp/#ldpc
> [3]  http://www.w3.org/2012/ldp/wiki/AccessControl
> [4]  http://www.w3.org/wiki/WebAccessControl
> [5]  https://www.w3.org/2012/ldp/wiki/LDPNext2015_Charter
> [6]  http://www.w3.org/TR/activitystreams-core/
> [7]  http://lists.w3.org/Archives/Public/public-annotation/2014Oct/0121.html
> 
> 
> --
> Rob Sanderson
> Information Standards Advocate
> Digital Library Systems and Services
> Stanford, CA 94305
> 
> 
> 
> --
> Rob Sanderson
> Information Standards Advocate
> Digital Library Systems and Services
> Stanford, CA 94305


----
Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704