HTTP headers and metadata - was: establishing conversational context

On 4 Feb 2013, at 13:44, "Wilde, Erik" <Erik.Wilde@emc.com> wrote:

> hello henry.
> 
> good stuff, as usual, and i'll send a full response later on. a brief
> remark:
> 
> On 2013-02-04 11:37 , "Henry Story" <henry.story@bblfish.net> wrote:
>> HTTP after all comes with a method to distinguish data and
>> metadata: headers and  content. This is not super-elegant
>> because the HTTP syntax is pretty awkward and its semantics
>> vague - but as far as the semantics goes that is not that
>> different from atom, and the advantage is that it is widely
>> deployed.
> 
> HTTP does not specify a general metadata delivery architecture. it has a
> select few places where  data that matters for the uniform interface of
> the web can be put. and if you have metadata that matters on the protocol
> level, then you shold put it into these headers (such as ETags).

Http may or may not specify a general metadata delivery architecture:
it all depends what one means by that . It is clear that an HTTP request 
contains two parts: the headers and the content, and that at least some
(if not most) of the headers are about the content, ie they are metadata 
about it. 

RFC5988 provides existential proof for at least one header being of this 
nature in its text on the Link header. In Section-5 it states:

[[
   The Link entity-header field provides a means for serialising one or
   more links in HTTP headers.  It is semantically equivalent to the
   <LINK> element in HTML, as well as the atom:link feed-level element
   in Atom [RFC4287].
] http://tools.ietf.org/html/rfc5988#section-5 ]

So it even ties the header to elements of an atom:feed, which as it happens
have the same semantics as the atom:entry.

> however, seeing RFC 5988 as a general invitation to stuff any kind of metadata into
> HTTP headers is not what this spec is about.

Of course. Care should be taken in use of this feature, and one
thing we need to explore is when it helps make the protocol simpler
to use it.

One important use case is that it makes it possible to provide 
a uniform metadata interface for all resources including binary 
ones and so provide a means to satisfy ISSUE-15 .

For example it would allow each resource, binary or not, to point
to an ACL resource, or a general metadata entry:

---------------------------------
HEAD /pix/cat.gif HTTP/1.1
------------------------->>
HTTP/1.1 200 OK
Content-Type: image/gif
Link: <cat.gif;acl>; rel="acl"
Link: <cat.gif.atom>; rel="meta"
...
---------------------------------

or for a foaf profile:

---------------------------------
HEAD /card HTTP/1.1
------------------------->>
HTTP/1.1 200 OK
Content-Type: text/turtle
Link: <card;acl>; rel="acl"
Link: <card.atom>; rel="meta"
...
---------------------------------


> media types should have their
> ways of doing this, however they see fit (linking between data/metadata
> usually is a good idea, if they are exposed as different resources, and
> such describedby/describes links may be good candidates for Link: exposure
> because they may be interesting for clients to traverse). ideally, you'd
> like to divide things so that (in RESTspeak) the *client* can handle the
> uniform interface and get what it needs to do that just from the uniform
> interface level (parsing HTTP headers according to the well-defined
> semantics of those headers), and the *user agent* then mostly works on
> resources, and maybe some selective information exposed to it that might
> be interesting for the user agent as well ("here's the expiry date of this
> response.").

RDF does give one the opportunity to do this with any statement 
of the form

   <> ?rel ?obj 

This provides a way for the document to make statements about itself.
For example a foaf profile could declare

{
 @prefix : <http://bblfish.net/work/atom-owl/2006-06-06/#> .
 @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
 @prefix foaf: <http://xmlns.com/foaf/0.1/> .

 <> a foaf:Profile;
    atom:updated "2013-02-06T10:34:06Z"^^xsd:dateTime;
    atom:author <#spdr>;
    foaf:primeryTopic <#spdr> .

 <#spdr> a super:Hero;
     atom:name "Spiderman" .
}

The difference with the atom wrapper we discussed earlier in
this thread, is that N3 allows us to clearly distinguish data and 
metadata. We can see this here:

@prefix log: <http://www.w3.org/2000/10/swap/log#> .

<card.atom> a atom:Entry;
   atom:updated "2013-02-06T10:34:06Z"^^xsd:dateTime;
   atom:author <#spdr>;
   atom:content <card> .
                <card> log:semantics {
   <> a foaf:Profile;
      foaf:primeryTopic <#spdr> .

     <#spdr> a super:Hero;
           foaf:name "Spiderman" .
   } .

A client receiving the above n3 would be able to parse that
into a graph containing (or referring to ) another graph and 
thereby cleanly distinguish the data and the metadata.

So there are a number of places for the metadata to occur:

* in the HTTP headers
* in a resource that speaks of another resource ( eg: <card.atom> )
* in the body of the Turtle content
* in N3 the same content can distinguish both data and metadata
  clearly

This gives one a lot of space to manoeuvre. It seems to me that
requiring therfore POSTed content in Turtle to an LDPC 
to be of an atom:entry type, as put forward in the Atom_Pub_example [1]
would require eliminating quite a  lot of options first.

All the best,

	Henry

[1] http://www.w3.org/2012/ldp/wiki/ISSUE-37#Atom_Pub_example_in_LDP


Social Web Architect
http://bblfish.net/