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

Re: Creating non-Atom LDPRs: AtomStrict & AtomRelax

From: Steve Battle <steve.battle@sysemia.co.uk>
Date: Sun, 3 Feb 2013 16:17:48 +0000
Cc: public-ldp-wg@w3.org
Message-Id: <ECB8883A-9587-4F5A-B455-7E4CCE91BBE4@sysemia.co.uk>
To: Henry Story <henry.story@bblfish.net>

On 3 Feb 2013, at 13: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. 

...
> 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:
> 

I can feel the tension building...
> 
> Atom-Relax
> ==========

Yes, I like where you're taking this; Atom as an application vocabulary, rather than being baked into the LDP.

> 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> .
...
> Having posted this it should add to the container </account/>
> the following triple at least:
> 
>  <> rdfs:member <jack> .
...

> 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.

Agreed, so when we're talking about the membership of a container, the only membership triples that are relevant are those asserted within the confines of the RDF representation of that container.
Each LDP Container or Resource is a self-contained cell of assertions that don't leak outside the cell walls of that resource - as you say, resources should be able to contain jokes and lies.

> 
> So here the atom metadata role starts making sense. 
...
> 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.    

So member metadata should be asserted within the RDF representation of the container itself. 

I wonder also, if the entity tag should properly be thought of as part of the explicit metadata of an LDP Resource (and not part of the LDP resource data - that gets very circular, very quickly).
This begs the question; is every LDP Resource member of an LDP container, which provides a natural home for it's metadata? Maybe they should be.

> Henry
Received on Sunday, 3 February 2013 16:18:17 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 9 May 2013 13:44:29 UTC