Re: Creating non-Atom LDPRs: AtomStrict & AtomRelax

Type and solution for ISSUE-15

On 3 Feb 2013, at 14:54, Henry Story <henry.story@bblfish.net> wrote:

> The LDP Model wiki [1] develops in detail the relation between
> Atom and LDP. It has an example of posting an Atom Entry to 
> a container, and an example of posting a binary. This received
> Erik Wilde's approval.
> 
> But a remaining question subsists: What happens when posting 
> other types of RDF content, such a as a foaf profile like this:
> 
> <> a foaf:PersonalProfileDocument;
>   foaf:primaryTopic <#i> .
> 
> <#i> a foaf:Person;
>   foaf:name "Jack Daniels";
>   foaf:interest <http://en.wikipedia.org/wiki/Whiskey>;
>   foaf:knows <http://www.spiritofspeyside.com/#j>,
>        <http://www.bunnahabhain.com/#jim> .
> 
> [] a <http://dbpedia.org/resource/Whisky> ;
>   likes <#i>, <http://www.bunnahabhain.com/#jim> .
> 
> 
> This graphs gives data about some "Jack Daniels", and he also
> adds a statement that Jack likes a whiskey that Jim likes.
> 
> Following the Atom models can lead us down two 
> different paths, which I will call Atom-Strict and Atom Relax.
> 
> Atom Strict
> ===========
> 
> In Atom Strict you can only post an Entry to a container.
> The content has to be wrapped in an atom entry. So if we
> are dead strict we have to POST this in XML:
> 
> <entry xmlns="http://www.w3.org/2005/Atom">
>  <title>My foaf profile</title>
>  <id>urn:uuid:1225c695-cfb8-4ebb-bbbb-80da344efa6a</id>
>  <updated>2013-02-02T16:34:06Z</updated>
>  <author><name>Jack Daniels</name></author>
>  <content type="text/turtle">
>    <> a foaf:PersonalProfileDocument;
>       foaf:primaryTopic <#i> .
> 
>  <#i> a foaf:Person;
>     foaf:name "Jack Daniels";
>     foaf:interest <http://en.wikipedia.org/wiki/Whiskey>;
>     foaf:knows <http://www.spiritofspeyside.com/#j>,
>                <http://www.bunnahabhain.com/#jim> .
> 
>  [] a <http://dbpedia.org/resource/Whisky> ;
>     likes <#i>, <http://www.bunnahabhain.com/#jim> .
>   </content>
> </entry>
> 
> This forces us to have two content types: application/atom+xml and
> the text/turtle content.
> 
> POSTing the whole thing Turtle improve things only a bit:
> 
> <> a :Entry;
>   :title "My foaf profile";
>   :updated "2013-02-02T16:34:06Z"^^xsd:dateTime;
>   :author [ :name "Jack Daniels" ];
>   :content """
>     <> a foaf:PersonalProfileDocument;
>       foaf:primaryTopic <#i> .
> 
>  <#i> a foaf:Person;
>     foaf:name "Jack Daniels";
>     foaf:interest <http://en.wikipedia.org/wiki/Whiskey>;
>     foaf:knows <http://www.spiritofspeyside.com/#j>,
>                <http://www.bunnahabhain.com/#jim> .
> 
>  [] a <http://dbpedia.org/resource/Whisky> ;
>     likes <#i>, <http://www.bunnahabhain.com/#jim> .
>  """^^^xxx:Turtle .
> 
> Here we only have 1 syntax but we still have the data and the 
> metadata as two seperate contents.
> 
> In both cases there are a number of serious problems:
> 
> 1. The content's relative URLs must be abosolutized - meaning we can't really get the 
>    server to do the right job. N3 could help here, but it is not in a standards track.
> 2. The content must be encoded to remove and angle brackets in the XML format and 
>   to make sure there are no """ in the Turtle one ( and """ are legal in Turtle )
> 3. There is a level of indirection between the metadata and the content.
> 4. There seems to be duplication such as the author between 
>   the content and the metadata.
> 
> Could this be solved by extending Atom so that one could have
> 
> <> a foaf:PersonalProfileDocument, a :Entry;
>   foaf:primaryTopic <#i>;
>   content ...?
> 
> Perhaps one can, but one wonders what should go into the atom:content 
> relation then? Does every document need an atom:id and a summary? It seems
> like a Procustean exercise. I think it is much better if we stick to 
> thinking about Atom as a metadata vocabulary. Things will then work
> out much better as we will see in the next section:
> 
> 
> Atom-Relax
> ==========
> 
> Whether or not any content one posts is in fact an atom entry or not 
> ( which it might well be! ), it seems clear that what one really wants
> is to POST the following to the <http://drinks.example/account/> 
> container:
> 
> -------------------------------------
> POST /account/ HTTP/1.1
> Slug: jack
> Content-Type: text/turtle
> ...
> 
> <> a foaf:PersonalProfileDocument;
>   foaf:primaryTopic <#i> .
> 
> <#i> a foaf:Person;
>   foaf:name "Jack Daniels";
>   foaf:interest <http://en.wikipedia.org/wiki/Whiskey>;
>   foaf:knows <http://www.spiritofspeyside.com/#j>,
>        <http://www.bunnahabhain.com/#jim> .
> 
> [] a <http://dbpedia.org/resource/Whisky> ;
>   likes <#i>, <http://www.bunnahabhain.com/#jim> .
> -------------------------------------
> 
> Having posted this it should add to the container </account/>
> the following triple at least:
> 
>  <> rdfs:member <jack> .
> 
> to be precise in n3:
> 
> </account/> log:semantics [ log:includes { </bug/> rdfs:member <req1> } ]

Oops, that should be:

</account/> log:semantics [ log:includes { </account/> rdfs:member </account/jack> } ]

> 
> So what *else* should the container show? Should it show everything 
> that was sent too?  This clearly won't work because it would have to show
> triples such as 
> 
> {
> [] a <http://dbpedia.org/resource/Whisky> ;
>   likes <#i>, <http://www.bunnahabhain.com/#jim> .
> }
> 
> That are pretty detached from the container. What if the
> graph sent had contained the following:
> 
> <http://drinks.example/account/> rdfs:member <http://dbpedia.org/resource/Whisky> .
> 
> perhaps as a joke? Then  a GET on <http://drinks.example/account/>
> would return
> 
> <> rdfs:member <http://dbpedia.org/resource/Whisky> .
> 
> which would clearly be false, since drinks.example can't delete
> resources on dbpedia.
> 
> So here the atom metadata role starts making sense. It makes sense
> not to put much information into the ldp:Container that is inside
> the content, other than its type perhaps, but rather to add 
> the atom metadata about what the contents contain, namely 
> 
> ----------------------------------
> GET /account/ HTTP/1.1
> ----------------------->>
> <> a ldp:Container;
>   rdfs:member [ owl:sameAs <jack>; 
>                 a foaf:PersonalProfileDocument;
>                 :title "Jack's personal Profile";
>                 :id "http://drinks.example/account/jack";
>                 :edit-meta <jack;meta>;
>                 :author <jack#i> ] .
> ----------------------------------

Looking at this one can see how close this is
to ISSUE-15 "sharing binary resources and metadata". 
The behavior there is not that different from this one.
Especially considering this example:
http://lists.w3.org/Archives/Public/public-ldp-wg/2013Feb/0010.html

But then it's also a bit odd to think of Turtle as a binary
format.... So this wold tend to argue for not making the
distinction between binary and other resources, and to make
sure they all function orthogonally:

1. POSTing content (any content) to a container creates a 
new  resource, call it <r1> here
2. The 201 created response contains a link to the resource
  created ( <r1>  ) and to its metadata (let's say <r1;meta> ) 
3. The Container adds to its representations ( what one GETs )
   a. <> rdf:member <r1> 
   b. atom like metadata on <r1> .

I think the above covers all cases.

> 
> Then one does not confuse the container's role as maker
> of metadata statements of its contents, and the contents.
> Atom does not confuse it, and neither should we, as those are
> very fundamental distinctions, between asserting something,
> and asserting things about another assertion.  Ie between you
> saying
> 
>   A: Jane loves Joe.
> 
> And you saying 
> 
>   B: Jim at 5 pm on Sunday said Jane loves Joe
> 
> You may be able to say B quite truthfully, but not want to 
> make the statement A directly yourself.
> 
> The container, will be much more secure by restricting 
> itself to the second.                  
> 
> Henry
> 
> [1] http://www.w3.org/2012/ldp/wiki/ISSUE-37
> 
> 
> 
> Social Web Architect
> http://bblfish.net/
> 

Social Web Architect
http://bblfish.net/