Re: POSTing binary data - the Atom Use Case

On 2/1/13 2:18 PM, Henry Story wrote:
> 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/
>
Awesome job !!

-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen