Re: Proposal for containers

On 31 Jan 2013, at 12:30, "Wilde, Erik" <Erik.Wilde@emc.com> wrote:

> hello henry.
> 
> On 2013-01-31 11:32 , "Henry Story" <henry.story@bblfish.net> wrote:
>> I am not misunderstanding this.
>> In section 9.2.1 of AtomPub the following example is given:
>> http://tools.ietf.org/html/rfc5023#section-9.2.1
>> 
>>      POST /edit/ HTTP/1.1
>>      Host: example.org
>>      User-Agent: Thingio/1.0
>>      Authorization: Basic ZGFmZnk6c2VjZXJldA==
>>      Content-Type: application/atom+xml;type=entry
>>      Content-Length: nnn
>>      Slug: First Post
>> 
>> The way Atom pub distinguishes the types of the content is
>> by annotating the mime type.
> 
> nope. http://tools.ietf.org/html/rfc5023#section-9.6
> 
> 'For Resource creation, this specification only defines cases where
>   the POST body has an Atom Entry entity declared as an Atom media type
>   ("application/atom+xml"), or a non-Atom entity declared as a non-Atom
>   media type.  When a client is POSTing an Atom Entry to a Collection,
>   it may use a media type of either "application/atom+xml" or
> "application/atom +xml;type=entry".'
> 
> http://tools.ietf.org/html/rfc5023#section-12.1
> 
> 'If not specified, the type is assumed to be unspecified, requiring
>   Atom processors to examine the root element to determine the type of
>   Atom document.'
> 
> simply put, there is no need to distinguish the type of content because
> the content is self-describing. of course, media type matter in atom
> because you can POST entries of any media type (as long as the collection
> accepts those media types), but that's a different issue.
> 
>> This works for something as limited
>> in design and scope as Atom, because the types of things it deals
>> with are either atom/entry or atom/feed elements. But in RDF
>> where you could say the type of a text/turtle document could
>> be infinitely varied, you could not start defining these types of
>> things. Or if you did your type would have to have a URL as value.
>> Which is just to say that you are putting the information in the
>> wrong place.
> 
> there is no difference between XML or RDF on this level.

I was not distinguishing XML and RDF ( though they are in fact
orthogonal, as the fact that we are using Turtle on this group should
allerted you to ), but Atom and LDPRs. 

In that place there is one difference, and that's all I need to counter your argument.

LDPRs which can be any type of RDF groph. In RDF the type of  the <> document 
can be infinite. It could be a foaf:Document, foaf:PersonalProfileDocument, 
ldp:Container, ldp:Resource, mony:ShoppingCart, ...
..

In atom there are only two types atom:Entry and atom:Feed.

So given that application/atom+xml can only contain two subtypes
it is just about ok to put it in the mime/type of the header.

But RDF can appear in any mime type ( Even XML mime types
that were not previously defined as RDF with GRDDL )

So putting the type of the document as specified by <> a ldp:Container or
into the mime type of the header is the wrong place to put it.

No problem we have the link header as you pointed out.
So you can put the information there if you want to put it in the header.

> you POST
> something, and that something has to be self-describing so that in the
> context of the protocol, the server can figure out what to do. in atom,
> the server looks at the ;type= or it looks at the document element. in
> both cases, the server knows what it got. in LDP, we will have to say that
> when you POST a 
> 
> <> a ldp:Container
> 
> or a
> 
> <> a ldp:Entry
> 
> then different things will happen: in one case, you create a container, in
> the other an entry. there likely will be additional metadata in these
> representations (required and optional LDP metadata, and any other
> additional metadata), but this is how the client intent is represented and
> then transferred to the server.
> 
> cheers,
> 
> dret.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

Social Web Architect
http://bblfish.net/