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

After discussion locally, we (LANL) are in favour of option 2a.

oa:State  would have two (or more) subClasses, such as:

oa:ArchivalState
   -- State to do with time and archiving/caching
   -- This would have the properties oa:when and oa:cachedSource as
currently defined

oa:RequestState
  -- has a single property, rdf:value, which contains the header
string as sent by the original client to request the resource.

Rationale:

* Option 1 doesn't scale to other headers that may be required as we
would need to introduce new predicates for every header.  As the
request headers could be x- custom ones, this would be impossible.

* Option 2b isn't really correct semantically.  There isn't a resource
with a representation of the headers, and the encoding will always be
plain ascii due to the HTTP restrictions.

* Option 3 seems like overkill.

* As time and HTTP requests are fundamental to the web architecture,
and across domains and communities, we would put it all in OA rather
than OAX.

We also posited a oax:BrowserState that would include information such
as internal browser preferences, the rendering frame's height and
width, and so forth.

Hope that helps!

Rob & Herbert


On Fri, Oct 26, 2012 at 12:54 PM, Jacob Jett <jgjett@gmail.com> wrote:
> 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 Monday, 29 October 2012 22:29:44 UTC