POSTing binary data - the Atom Use Case

This contribution aims at advancing our understanding of issues

ISSUE-15: sharing binary resources and metadata
ISSUE-37: What is the LDP data model and the LDP interaction model?

In the ISSUE-37 wiki page I put forward an inital interpretation 
of  Atom in Turtle [1] which seemed very reasonable, and
which got Erik Wilde's approval.

Steve Battle pointed out [2]  that the binary content
posted, functions differently from a normal graph post.

When POSTing a graph serialisation to a LDPC the rdfs:member
that results in the collection refers to a resource that 
(usually) contains the information one POSTed ( <entry1> ). 
On the other hand when POSTing a binary the rdfs:member created 
in the  collection refers to an entry ( <entry2> ) not the 
posted binary <mouse.gif> as shown in this subset of 
the graph shown in the wiki here:

  <> a ldp:Container;
     rdfs:member <entry1>, <entry3> .

  <entry1> :summary "some text" .
  <entry3> :content <mouse.gif> . 


If we look at Section 9.6.1. of AtomPub RFC5023 [3],
Where it describes the POSTing of some binary content

   POST /edit/ HTTP/1.1
   Host: media.example.org
   Content-Type: image/png
   Slug: The Beach
   Authorization: Basic ZGFmZnk6c2VjZXJldA==
   Content-Length: nnn

   ...binary data...


The result is the following XML

  <?xml version="1.0"?>
  <entry xmlns="http://www.w3.org/2005/Atom">
     <title>The Beach</title>
     <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
     <updated>2005-10-07T17:17:08Z</updated>
     <author><name>Daffy</name></author>
     <summary type="text" />
     <content type="image/png"
              src="http://media.example.org/the_beach.png"/>
     <link rel="edit-media"
            href="http://media.example.org/edit/the_beach.png" />
     <link rel="edit"
         href="http://example.org/media/edit/the_beach.atom" />
   </entry>

Which we could interpret as ( applying some natural interpretations
on what a link relation means, which may be a bit information lossy )

  _:e1 :title "The Beach";
     :id "urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a";
     :update "2005-10-07T17:17:08Z"^^xsd:dateTime;
     :author [ :name "Daffy" ];
     :content <the_beach.png>;
     :edit <the_beach.atom> .

If this is to enter into an ldp:Container the ldp:Container needs
to know what it is to point to . In the example on the wiki I first
chose to point to the metadata.

  <> a ldp:Container;
     rdfs:member <the_beach.atom> .

But Steve Battle's suggestion is that the following is more
sensible:

  <> a ldp:Container;
     rdfs:member <the_beach.png> .

That is the question is what should be the name we give to the 
blank node _:e1. This is unspecified in atom, so we could go either
way. If we chose the latter then the ldp:Container can show in 
detail upon a GET  the following graph [3] :

  <> a ldp:Container;
     rdfs:member <the_beach.png>. 
  
  <the_beach.png>
     :title "The Beach";
     :id "urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a";
     :update "2005-10-07T17:17:08Z"^^xsd:dateTime;
     :author [ :name "Daffy" ];
     :content <the_beach.png>;
     :edit <the_beach.atom> .

So now we would both know where to get the metadata,
and where to get the content. 

What may not fit so well was the part that I 
left out, and that is that on POSTing the picture
the headers returned by the AtomPub server are
according to the spec:

 HTTP/1.1 201 Created
 Date: Fri, 7 Oct 2005 17:17:11 GMT
 Content-Length: nnn
 Content-Type: application/atom+xml;type=entry;charset="utf-8"
 Location: http://example.org/media/edit/the_beach.atom

That is they contain the location of the metadata, not the 
image, ie the location points <the_beach.atom> .

On refelction this is not that far from what some people 
( such as Alexandre Bertails, and Joe Presbrey who wrote 
data.fm ) have suggested, namely that the result return 
a link to a  metadata resource, using the convetions put
forward in RFC5988 [5], which being much more recent 
than Atom should arguably get precendence. The previous
result could then be:

 HTTP/1.1 201 Created
 Date: Fri, 7 Oct 2005 17:17:11 GMT
 Content-Length: nnn
 Content-Type: text/turtle
 Link: <the_beach;meta>, rel="meta"

In this way one could allow the Atom intuitions to work
nicely with the LDP ones I think, whilst having a very
clean model that makes no special case about binary,
graph or other data. Graphs and binaries can have
their metadata or acl resources. 
ACLs would then just be a specific metadata of 
type rel="acl".

Having resolved these momentous issues I wish you all
a good weekend.

	Henry


[1] http://www.w3.org/2012/ldp/wiki/ISSUE-37#POSTING_Binary_Content
[2] http://lists.w3.org/Archives/Public/public-ldp-wg/2013Feb/0006.html
[3] https://tools.ietf.org/html/rfc5023#section-9.6.1
[4] ( It looks better with owl:sameAs notation as shown in the wiki
    but wrapping in e-mail does not work so well, and these 
    lines get long )
[5] http://tools.ietf.org/html/rfc5988



Social Web Architect
http://bblfish.net/