Re: Aggregation: simple proposal

Just a small question,

In wiki under the assumptions, it says "introduce a new LDP ontology
'ldp:contains' to describe (strict) composition.". I saw that before in the
Steve Battle's email as well. Isn't the ':contains' property
describe aggregation in the proposal ? Did I miss something obvious ?

So in your example I thought, if I do GET (assuming default
ldp:membershipPredicate
and a pre-empty container) I will get the following i.e.
ldp:membershipPredicate
is the property to describe composition. Isn't that correct ?

GET http://example.com/cnt/ HTTP/1.1

<http://example.com/cnt/>
   a ldp:Container;
   rdfs:member
      <http://example.com/cnt/weakColl> .


Best Regards,
Nandana




On Fri, Jan 11, 2013 at 5:20 PM, Henry Story <henry.story@bblfish.net>wrote:

>
> On 4 Jan 2013, at 20:29, John Arwe <johnarwe@us.ibm.com> wrote:
>
> Henry, I'm going to start drafting a proposal on issue 37 ("the model") to
> try and get things moving.  I was going to incorporate your simple proposal
> from [1] and build on it, but I find myself asking many clarifying
> questions about its intent.  Andy seems to divine your purpose, but I have
> a nice linear reading style that dumps on any ambiguity.
>
> > >> 1. Create a aggregation container
> > >> ----------------------------------
> > >>
> > >> POST your collection to the container
> > >>
> > >> <> primaryTopic <#wk> .
> > >>
> > >> <#cnt> a WeakContainer;
> > >>     :contains <*http://remote.org/resource*<http://remote.org/resource>
> >,
> > >>         <localRes> .
> > >>
> > >>     This creates a resource named say <resourceC> which defined
> <resourceC#cnt> .
>
> Q1.1: What is the purpose of the primaryTopic triple?  It seems like a
> distraction from the main purpose.  I wonder if you are mixing
> "before-state of the LDPC" with the POST request entity body's content.
>  When I write this out pedantically I intend to show the LDPC before and
> after each interaction, hopefully to make it unambiguous.
>
>
> The point is to distinguish a collection that in the LDPC case is
> something like a directory, and so a real web resource if you want,
> whereas we are creting a collection that is like another object - like
> giving a URL to a cat perhaps. An LDPC is something you
> POST to create an LDPR. The aggregation collection I am talking about is
> not something you can post to.
>
>
> Q1.2: You use both "collection" and "container" ... should I take
> "collection" to mean 'aggregation' and interpret container 'literally'?
>  [later add] You also use "aggregation container" in the title; I assume
> that's the same as "aggregation" elsewhere in this snip.
>
>
> I wrote it quickly.
> LDPC as they are now are things you can POST to create new resources. The
> collections I am thinking of here are not such things.
>
>
>
>
> Q1.3: Am I correct in thinking that the WeakContainer type is merely a
> mnemonic convention to convey the 'aggregation' intent?
>
>
> yes
>
>
> Q1.4: You are applying the rule "null relative URI denotes the URI
> assigned to the new entry by the container's create implementation"?   So
> far I've only seen that discussed for <> as a "special case", although I
> certainly anticipated that once formally drafted it would cover <#cnt> in a
> similar way, but want to be sure that's your intent as well.  Using that
> interpretation, I'd say that <resourceC> is the server-assigned -portion-
> of the URI (the absolute URI chosen by the server to allow transformation
> of <#cnt> into the absolute URI <resourceC#cnt>).
>
>
> yes.
>
> <> refers to the document created when you POST to a LDPC.
> <#me> and stuff like that refer to identities defined in the document <> .
>
>
> Q1.5: The "This creates..." sentence ties me in knots.  What would you
> expect in response to GET resourceC , assuming the server added+changed no
> triples from the POST representation?  Based on my theory about the answer
> to Q4, I'm guessing you expect back:
> <> primaryTopic <#cnt> . //<-had an error here
> <#cnt> a WeakContainer;
>        :contains <*http://remote.org/resource*<http://remote.org/resource>>,
> <localRes> .
>
> I agree that would all be "legal", btw.  Just being sure I have your
> intent.
>
>
> yes, so of course if the server is <http://example.com>
> and the container is <http://example.com/cnt/>
> which created  <http://exmple.com/cnt/weakColl>
> then the above is in full RDF
>
> <http://exmple.com/cnt/weakColl> primaryTopic <
> http://exmple.com/cnt/weakColl#cnt> .
> <http://exmple.com/cnt/weakColl#cnt> a WeakContainer;
>        :contains <http://remote.org/resource>,
>                       <http://exmple.com/cnt/localRes> .
>
>
> Q1.6: For a "simple" proposal, why start with both a collection and a
> container (regardless of the answer to Q1, "clearly" you intended to
> distinguish by using distinct words)?  Versus, for example, saying "this
> is how an LDPC could be used, without spec changes, to accomplish
> aggregation"?
>
>
> yes, I intended to distinguish both. There is good reason to argue that
> LDP Containers (LDPC) are very different from weak collections. Atom
> Protocol I think has a similar distinction between atom:Feed and
> app:Collection
>
>  https://tools.ietf.org/html/rfc5023#section-8.3.3
>
> The Collection is something that is defined by the protocol, as something
> you can POST to to create new server resoures, and GET, and DELETE to
> delete all of its contents. That is not true of say a normal atom:Feed,
> even thought they are very close.  So similarly here we can distinguish one
> from the other.
>
> Are you asserting that the use of "indirection" in this way is required to
> "implement" aggregation using LDPC rules as they currently exist?  [again,
> just getting your intent - I'm not asserting dis/aggreement at this point]
>
>
> No I think my idea was to keep those separate. I just then chose
> WeakContainer, because I did not know what to call it, and I did not really
> think that this was a further debate one could have. The point at present
> was just to show how one could have a simple and limited concept of a
> strong container, and still have all the freedom needed to do aggregation.
>
>
> Q1.7: For a "simple" proposal, why start with a case where a single HTTP
> resource manipulates multiple (2) RDF resources (subject URIs)?
>
>
> > >>     2. Delete your container
> > >>     send an HTTP delete message
> > >>       DELETE resourceC HTTP/1.1
> > >>     or change the container as below by removing the <#cnt> from
> <resourceC>
>
> Q2.1: You say delete the *container*, but you use resourceC as the request
> URI.  In your 1., 'container' was the pre-existing resource you posted to
> in order to *create* <resourceC>.  Did you mean to say delete the
> aggregation/collection instead?   Same occurs in 3.
>
>
> given my above URLs this should be
>
> DELETE http://exmple.com/cnt/weakColl HTTP/1.1
>
>
>
>
> > >>     or change the container as below by removing the <#cnt> from
> <resourceC>
>
> Q2.2: I think by this you mean either using the method of (3) with a
> request entity body consisting of ONLY the primaryTopic triple, and/or
> using the method of (4) with DELETE { <#cnt> :contains ?o }  [my ?o
> syntax might need some adjustment, working from memory]
>
>
> yes. But the primary topic you are right here is not essential ( or at
> least it may be, but it would need to be argued )
>
> yes, my suggestions was just you could remove all triples mentioning the
> collection. That would be equivalent to deleting it.
>
> Hope that helps :-)
>
> Henry
>
>
>
>
>
> [1] http://lists.w3.org/Archives/Public/public-ldp-wg/2012Dec/0112.html
>
> Best Regards, John
>
> Voice US 845-435-9470  BluePages<http://w3.ibm.com/jct03019wt/bluepages/simpleSearch.wss?searchBy=Internet+address&location=All+locations&searchFor=johnarwe>
> Tivoli OSLC Lead - Show me the Scenario
>
>
>    A short message from my sponsors: Vive la France!
> Social Web Architect
> http://bblfish.net/
>
>