Re: Issue-37: Ontological Modelling

On 22 Jan 2013, at 17:21, "Wilde, Erik" <Erik.Wilde@emc.com> wrote:

> hello henry.
> 
> On 2013-01-22 15:03 , "Henry Story" <henry.story@bblfish.net> wrote:
>> On 22 Jan 2013, at 14:34, Ashok Malhotra <ashok.malhotra@oracle.com>
>> wrote:
>>> Erik's solution will work.
>>> You either POST to a collection which will create the LDPR
>> You POST a Graph or a binary to a collection,  right? Those are pretty
>> much complementary classes of things.
> 
> let's not mix the three cases we may want to clearly specify:
> 
> 1. how to POST a self-contained entry.
> 2. how to POST an entry that's only protocol metadata and links to the
> entry's content.
> 3. how to POST something that's not RDF.

yes, you are speaking about Atom Entries, but this is not what we are doing,
here.

Atom it seems to me is just an attempt to XMLify HTTP. Consider what your
Atom entry is as simply: metadata about some content.

<entry>
       <title>Atom-Powered Robots Run Amok</title>
       <link href="http://example.org/2003/12/13/atom03"/>
       <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
       <updated>2003-12-13T18:30:02Z</updated>
       <summary>Some text.</summary>
</entry>

Well why bother with all that? 

In HTTP we have it already: it's called headers and content,
and the rest you can do  through hyperlinking.

POST /2013/01/22/ HTTP/1.1
Host: example.org
Content-Type: text/turtle
Slug: card
Content-Length: 20

<#me> a <http://xmlns.com/foaf/0.1/Person> .

HTTP/1.1 201 Created 
Content-Length: 0
Link: <card;acl>; rel=acl
Location: atom03


> 
> for me, the simplest model is to treat 1 and 2 the same and simply
> distinguish them by what you're POSTing. like i said, the server doesn't
> even need to care, it behaves in exactly the same way. the only difference
> is in what you POST, and how the "complete entry" (LDP protocol data plus
> content) has to be retrieved by a client (one GET in the self-contained
> case, two GETs in the linked case).
> 
> 3 is different because we're POSTing something that's a non-RDF media
> type. i still think atompub is a good model to look at: POST it to a
> special collection which handles non-RDF things (and advertises its
> supported media types through the LDP protocol), let the LDP server store
> the blob, and generate an RDF entry as a proxy. from then on, manage both
> concurrently, i.e. DELETEing one will DELETE the other.
> 
> cheers,
> 
> dret.
> 

Social Web Architect
http://bblfish.net/