W3C home > Mailing lists > Public > public-ldp-wg@w3.org > January 2013

Re: Example of Atom publication using LDP

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Wed, 30 Jan 2013 07:22:42 -0500
Message-ID: <51091092.2050103@openlinksw.com>
To: public-ldp-wg@w3.org
On 1/30/13 6:40 AM, Henry Story wrote:
> Since it is incredibly unlikely that Erik Wilde
> will end up explaining clearly in Turtle what it is
> he is thinking of doing, I thought I would do
> this for him as part of ISSUE-37.
>
> It is clear from what Erik is speaking about that
> he wishes to see that the Atom Protocol model
> he able to function in LDP pretty much as is.
> Here is then an example of what things would look
> like if one stuck very closely to the Atom model.
>
> It satisfies the properties Erik has been going on
> about:
>
> - only rdfs:member for collections as specified in current
>    ontology
> - one can add a contained member
> - one can add a light weight relation ( ie without deletion
>    behavior )
> - one can POST binaries which create intermediate
>    metadata resources
>
> The following may not be abosolutely up to what Erik
> is thinking of - only he can know that in the end -
> but it should at the very least provide a template
> from which with I believe a few major changes he
> can let us know what it is he really needs.
>
> To do this I am using the Atom-OWL ontology, available
> http://bblfish.net/work/atom-owl/2006-06-06/AtomOwl.html
> which comes with XSLTs and XQuery transforms from atom xml
> to the ontology. We spent a lot of time on this ontology,
> so it is a good starting point. I have made some obvious
> simplification to the ontology for the sake of clarity.
>
> 0. Presupposition: an empty Container
> =====================================
>
> Let us start with an empty Container at http://atom.example/
> which we GET
>
> -----------------------------------------------
> GET / HTTP/1.1
> -------------->>
>
> <> a ldp:Container .
> -----------------------------------------------
>
> Let me ignore other data that could be part of it of
> that container, for this example.
>
> 1. POSTing Content
> ==================
>
> Now we post an Atom entry using the AtomOWL ontology,
> with some obvious simplifications.
>
> -----------------------------------------------
> POST / HTTP/1.1
> ...
>
> @prefix : <http://bblfish.net/work/atom-owl/2006-06-06/#> .
>
>   <> :Entry;
>      :author <http://joe.example/#i>;
>      :title "Atom Powered Robots Run Amok";
>      :id "urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a"^^xsd:anyURI;
>      :updated "2013-01-13T18:30:02Z"^^xsd:dateTime;
>      :summary "Some text.";
>      :content "Some text or other content - of course the mime type of the content needs to be specified" .
> -------------->>
> HTTP/1.1 201 Created
> Content-Type: text/turtle
> Link: <http://bblfish.net/work/atom-owl/2006-06-06/#Entry>; rel="http://www.w3.org/1999/02/22-rdf-syntax-ns#type"
> Location: <entry1>
> ...
> -----------------------------------------------
>
> Note that in the Atom Protocol RFC5023 they mix the content type
> and the returned type of the content. In section 9.2.1
> they show the 201 created returns a Content-Type of:
>
>   Content-Type: application/atom+xml;type=entry;charset="utf-8"
>
> ( https://tools.ietf.org/html/rfc5023#section-9.2.1 )
>
> Given that we don't want to make the same mistake of mixing
> syntax and semantics as the AtomPub protocol did I have moved
> the type to a link element. Then say if Twitter abandonds one
> format - as it recently abandoned Atom XML in favor of JSON
> http://www.mguhlin.org/2012/09/darn-its-happened-again-abandoning.html -
> then the protocol will have no problem and still be able to adapt
> itself.
>
> Note that this would create a new entry in the ldp:Container, of type :Entry
> which one could find out by doing a GET on the container:
>
> -----------------------------------------------
> GET / HTTP/1.1
> -------------->>
>
> @prefix : <http://bblfish.net/work/atom-owl/2006-06-06/#> .
>
> <> a ldp:Container;
>     rdfs:member [ owl:sameAs </entry1>;
>                   a :Entry;
>                   :author  <http://joe.example/#i>;
>                   :title "Atom Powered Robots Run Amok";
>                   :id "urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a"^^xsd:anyURI;
>                   :updated "2013-01-13T18:30:02Z"^^xsd:dateTime;
>                   :summary "Some text." ] .
> -----------------------------------------------
>
> Notice that the ldp:Container does not show all the information: for
> example it does not show the content. To do that one has to
> GET </entry1> like this:
>
> -----------------------------------------------
> GET /entry1 HTTP/1.1
> ------------------->>
>
> @prefix : <http://bblfish.net/work/atom-owl/2006-06-06/#> .
>
> <> a :Entry;
>     :author  <http://joe.example/#i>;
>     :title "Atom Powered Robots Run Amok";
>     :id "urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a"^^xsd:anyURI;
>     :updated "2013-01-13T18:30:02Z"^^xsd:dateTime;
>     :summary "Some text.";
>     :content "Some text or other content - of course the mime type of the content needs to be specified ." .
> -----------------------------------------------
>
> So to DELETE </entry1> would delete also the rdfs:member information in the
> <http://atom.example/> container, with of course all the metadata about it.
>
>
> 2. POSTing a link to another resource
> =====================================
>
> Next we want to post a link to something without content
>
> -----------------------------------------------
> POST / HTTP/1.1
> ...
>
> @prefix : <http://bblfish.net/work/atom-owl/2006-06-06/#> .
>
>   <> :Entry;
>      :author <http://joe.example/#i>;
>      :title "picture of a cat";
>      :updated "2013-01-13T18:45:23Z"^^xsd:dateTime;
>      :summary "Cat with a funny hat made of bread";
>      :content <http://cat.example/cat1.jpg> .
> -----------------------------------------------
>
> So this creates a resource <entry2> which which contains exactly what
> was POSTed as in the example with the content. A GET on the container
> now has the following ( assuming we have not deleted </entry1> yet of
> course )
>
> -----------------------------------------------
> GET / HTTP/1.1
> ------------->>
>
> @prefix : <http://bblfish.net/work/atom-owl/2006-06-06/#> .
>
> <> a ldp:Container;
>     rdfs:member [ owl:sameAs </entry1>;
>                   a :Entry;
>                   :author  <http://joe.example/#i>;
>                   :title "Atom Powered Robots Run Amok";
>                   :id "urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a"^^xsd:anyURI;
>                   :updated "2013-01-13T18:30:02Z"^^xsd:dateTime;
>                   :summary "Some text." ],
>                 [ owl:sameAs </entry2>;
>                   a :Entry;
>                   :author <http://joe.example/#i>;
>                   :id "http://atom.example/entry2";
>                   :title "picture of a cat";
>                   :updated "2013-01-13T18:45:23Z"^^xsd:dateTime;
>                   :summary "Cat with a funny hat made of bread";
>                   :content <http://cat.example/cat1.jpg>  .
>    
> -----------------------------------------------
>
> Now again deleting </entry2> deletes it from the container
> <http://atom.example/> but does not delete the content.
>   
> 3. POSTING Binary Content
> =========================
>
> So here we post some binary content onto the container
> at <http://atom.example/>
>
> -----------------------------------------------
> POST / HTTP/1.1
> Slug: mouse
> Content-Type: image/gif
> Content-Length: 1024
> ...
> -----------------------------------------------
>
> The result is meant to be that the server will create
> a binary and an atom entry about that published resource.
>
> -----------------------------------------------
> GET / HTTP/1.1
> -------------->>
>
> @prefix : <http://bblfish.net/work/atom-owl/2006-06-06/#> .
>
> <> a ldp:Container;
>     rdfs:member [ owl:sameAs <entry1>;
>                   a :Entry;
>                   :author  <http://joe.example/#i>;
>                   :title "Atom Powered Robots Run Amok";
>                   :id "urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a"^^xsd:anyURI;
>                   :updated "2013-01-13T18:30:02Z"^^xsd:dateTime;
>                   :summary "Some text." ],
>                 [ owl:sameAs <entry2>;
>                   a :Entry;
>                   :author <http://joe.example/#i>;
>                   :id "http://atom.example/entry2";
>                   :title "picture of a cat";
>                   :updated "2013-01-13T18:30:02Z"^^xsd:dateTime;
>                   :summary "Cat with a funny hat made of bread";
>                   :content <http://cat.example/cat1.jpg> ],
>                 [ owl:sameAs <entry3>;
>                   a :Entry;
>                   :author <http://joe.example/#i>;
>                   :id "http://atom.example/entry3";
>                   :title "mouse";
>                   :updated "2013-01-13T19:10:02Z"^^xsd:dateTime;
>                   :content <mouse.gif> ].
> -----------------------------------------------
>
> Here DELETEing <entry3> may or may not also delete <cat.gif> or
> vice-versa. I am not sure. But a GET on <entry3> would return
>
> -----------------------------------------------
> GET /entry3 HTTP/1.1
> -------------------->>
>
> @prefix : <http://bblfish.net/work/atom-owl/2006-06-06/#> .
>
>   <> :Entry;
>      :author <http://joe.example/#i>;
>      :title "mouse";
>      :updated "2013-01-13T19:10:02Z"^^xsd:dateTime;
>      :content <mouse.gif> .
> -----------------------------------------------
>
> Ok, so that seems to be along the lines of what
> it would take to include Atom as part of LDP.
>
>
> All the best,
>
>      Henry Story
>
> Social Web Architect
> http://bblfish.net/
>
>

+1

Very nice explanation and demonstration.

-- 

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







Received on Wednesday, 30 January 2013 12:23:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:44 UTC