W3C home > Mailing lists > Public > public-openannotation@w3.org > October 2012

oa:State - proposal for methods to accommodate HTTP content negotiation

From: Jacob Jett <jgjett@gmail.com>
Date: Fri, 26 Oct 2012 13:54:54 -0500
Message-ID: <CABzPtBKF=ZZwUXWhPng+E_1_j8iXGnHGFPSO8qAoCuZeC1anFg@mail.gmail.com>
To: public-openannotation@w3.org
Hi all,

Tim, Tom, Jordan and I have been looking at oa:hasState and wondering what
the best and/or most correct way of using it to handle content negotiation
through HTTP headers. We've come up with three possible methods to
accomplish content negotiation with oa:hasState all of which make use of
methodologies already in use in various places within the OA specification.

Our first potential solution is expand the scope of oa:State to accommodate
five additional predicates (in addition to the current oa:when), one for
each of the five http request headers (accept, user-agent, accept-charset,
accept-language and accept-encoding). I've added a figure to discussion
page for this issue on the wiki:
http://www.w3.org/community/openannotation/wiki/Proposal_for_Http_Request_Headers_in_State#Option_1

Pros for this solution:

   - defines scope of interaction with HTTP request headers
   - follows established precedent of oa:when predicate

Cons for this solution:

   - relatively complicated, assigning predicates unique to each of the
   five HTTP Request Headers
   - scope may be too narrow, disallows use of GET/POST with oa:hasState
   (although this is probably desirable, so a somewhat tenuous con)


Our second potential solution is to sub-type oa:State (e.g.,
oax:HttpRequestState) and pass information in the same manner as we do for
selectors using either a literal with rdf:value or content as text.
Examples for this possible solution can be found at:
http://www.w3.org/community/openannotation/wiki/Proposal_for_Http_Request_Headers_in_State#Option_2

Pros:

   - simple solution
   - already well established methodology for passing data within the
   specification

Cons:

   - sub-typing state may not be desirable


Our third potential solution is to pass information as a structured
resource (or inline body). The examples for this solution are at:
http://www.w3.org/community/openannotation/wiki/Proposal_for_Http_Request_Headers_in_State#Option_3

Pros:

   - most expressive solution, allows for the most potential precision
   - can be used for POST/GET (although this may be undesirable)

Cons:

   - most complex solution
   - still requires sub-typing of oa:State (e.g., oax:StructuredState)
   - may be abusing content in rdf by passing information in turtle that is
   better expressed as a graph (see example 3b)



Do any of these solutions stand out as particularly good or bad for using
oa:hasState to handle content negotiation? Does anyone have any thoughts or
strong opinions on best to accomplish content negotiation using the OA spec?

Regards,

Jacob


_________________________________________________________
Jacob Jett
Visiting Project Coordinator
Open Annotation Collaboration
Center for Informatics Research in Science and Scholarship
The Graduate School of Library and Information Science
University of Illinois at Urbana-Champaign
501 E. Daniel Street, MC-493, Champaign, IL 61820-6211 USA
(217) 244-2164
jjett2@illinois.edu
Received on Friday, 26 October 2012 18:56:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 26 October 2012 18:56:04 GMT