Re: ISSUE-37 WAS:Proposal for containers

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

http://www.w3.org/2012/ldp/wiki/ISSUE-37#Relation_of_Atom_Ontology_to_LDP

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

http://www.w3.org/2012/ldp/wiki/Issue-34_-_Aggregation:_simple_proposal


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


Henry

> 
> 
> Steve.
> 

Social Web Architect
http://bblfish.net/