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

Re: ISSUE-37 WAS:Proposal for containers

From: Henry Story <henry.story@bblfish.net>
Date: Fri, 1 Feb 2013 15:57:54 +0100
Cc: public-ldp-wg@w3.org
Message-Id: <A78B2E04-F17D-4E7D-914E-7F3B5264D523@bblfish.net>
To: Steve Battle <steve.battle@sysemia.co.uk>

On 1 Feb 2013, at 15:20, Steve Battle <steve.battle@sysemia.co.uk> wrote:

>> -----Original Message-----
>> From: Henry Story [mailto:henry.story@bblfish.net]
> ...
>> On 1 Feb 2013, at 11:08, "Wilde, Erik" <Erik.Wilde@emc.com> wrote:
>>> to avoid confusion, what's the problem of using rdfs:member to always
>>> represent membership, ldp:content to always represent member content, 
>>> and then to distinguish between containment and aggregation simply by
>>> letting the user decide whether they embed the content or not when 
>>> creating new members?
> ...
>> - The Atom-Pub solution does not require this distinction since it
>>  creates an indirection from Container to entry, and places the links in
>>  the Entry. See the examples "Posting a link to another resource"
>>  http://www.w3.org/2012/ldp/wiki/ISSUE-37#POSTing_a_link_to_another_resource
> So, is the difference you're pointing out above that the use of
> atom:content is merely contingent to the example (ie. you're not mandating
> use of atom), and there's no requirement to define ldp:content
> (any indirection will do).

Yes, you are right. I am not mandating the use of Atom, because I argued 
from the history of the development of atom, and from attempts to build
an ontology that is faithful to atom one has a few modelling issues to 
overcome if one wants to make a simple identity LDPR=atom:Entry and 
LDPC=atom:Feed .

This is the strongest I can say for the moment:

@prefix awol: <http://bblfish.net/work/atom-owl/2006-06-06/#> .

awol:Feed rdfs:subClassOf ldp:Container .

awol:Entry rdfs:subClassOf [ 
          a rdfs:Class;
          rdfs:label "LDP_:X";
          owl:intersectionOf ( [ owl:complementOf ldp:Container ] ldp:Resource ) 
  ] .

Perhaps when Erik gets good at Ontology design after reading Dean Allemang
and Jim Hendler's book "Semantic Web for the Working Ontologist" 
we can go over this and see if I made a mistake... :-)


> What seems to be identical in both your positions is that all direct
> members of the container are deleted on deletion of the container
> (containers only do composition).

I am saying that Atom is a good model to show how this can be done.
It is more persuasive than my example on Aggregation because Atom is 
in wide use and is RESTful.


> So, If we need aggregation then we can do it with indirection (e.g.
> atom:content or ldp:content).

It looks like that yes. 
> I agree that this approach would obviate the need for ldp:contains, as no
> such distinction would be necessary.


> The 'POSTing Binary content' example seems to be inconsistent with this
> approach as it is also referenced indirectly.
> Could it be made consistent with your approach if the <mouse.gif> content
> were the direct member of the container, and the subject of the metadata
> about it.

I agree. I was just putting forward what I took to be Erik Wilde's views
there. I think he is saying, that atom functions like this
(removing the owl:sameAs indirection ) after POSTing a binary:

<> a ldp:Container;
   rdf:entry  <entry3> .

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

But I don't think that this is in fact the only interpretation 
one can have of Atom. I think one could have an interpretation 
of Atom that would bring it closer to LDP. 

So I completely agree with your attempt below at making
it more uniform ( fixing a bug in your code ):

> In the excerpt below, <mouse.gif> will definitely be deleted along with
> the container, as it is a direct member (of the composition).
> This seems to be much more uniform:
> <> 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> ],
>               <mouse.gif> .
> <mouse.gif>  a :Entry;
>          :author <http://joe.example/#i>;
>          :id "http://atom.example/entry3";
>          :title "mouse";
>          :updated "2013-01-13T19:10:02Z"^^xsd:dateTime .
> The naming of the gif honours the slug; the important point is that the
> gif is named by the container, and it isn't an indirect link.
> I guess you could also add the content type to the gif metadata.
> I recall some conversation earlier on about whether the binary should be
> the subject of the metadata, or the object of a :content link, but doesn't
> this way round make more sense in the context of your proposal?

I am 100% with you. And I think we could make it fit with Atom.
Because I think if you look carefully atom, we'll find it just
adds a link from the entry to the image, and we could interpret 
that as  meaning what you describe above.

That would be cool, and would make things fall in place neatly.


> Steve.

Social Web Architect

Received on Friday, 1 February 2013 14:58:25 UTC

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