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

Re: Issue-34 Back_to_Basics proposal

From: Roger Menday <roger.menday@uk.fujitsu.com>
Date: Mon, 4 Feb 2013 14:49:13 +0000
CC: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
Message-ID: <F0DDD63B-310F-486D-9966-F5E9769B8DCF@uk.fujitsu.com>
To: John Arwe <johnarwe@us.ibm.com>

John, 

I am not convinced by non-member properties.

LDP is based on using a secondary layer of LDP-specific resources. Then we have different  requirements to "add an arc", "paginate", etc. Solutions to these requirements all depend on mechanism in this secondary layer, and should be available to *all* properties. So, all properties are 'member' properties - therefore making the 'non-member' properties to be empty set (??)  

Roger

p.s. In the spec, why is only links from the container to the LDPR ? I think the links in the other direction are the more important ones. 


> "non-member properties" refers to http://www.w3.org/TR/2012/WD-ldp-20121025/#http-get-1 5.3.2 
> I updated the wiki page with this link (to the FPWD which should be Cool-er on the 5.3.2 ptr numbering over time)
> 
> Best Regards, John
> 
> Voice US 845-435-9470  BluePages 
> Tivoli OSLC Lead - Show me the Scenario 
> 
> 
> 
> 
> From:        "Wilde, Erik" <Erik.Wilde@emc.com> 
> To:        John Arwe/Poughkeepsie/IBM@IBMUS, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>, 
> Date:        02/01/2013 05:17 AM 
> Subject:        Re: Issue-34 Back_to_Basics proposal 
> 
> 
> 
> hello john.
> 
> On 2013-01-31 22:01 , "John Arwe" <johnarwe@us.ibm.com> wrote:
> >Not having seen any replies to [1], wondering if it got lost in the
> >shuffle.  This is the same proposal [2] mentioned on this week's call for
> >how to resolve the issue and define an interaction model covering both
> >aggregation
> > and composition.[1]
> >http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jan/0330.html
> >[2] http://www.w3.org/2012/ldp/wiki/Issue-34:_Back_to_Basics
> 
> when you say that in aggregations, there is a separate GET for "non-member
> properties", are you referring to properties of members that are not
> specified by LDP? if so, why would you split members this way? we can
> cleanly specify which properties we regard as being meaningful in the
> context of LDP, and then when you GET a member, those ones which are
> specified as being meaningful for LDP can be identified, and all the other
> ones are the ones which i think you were referring to. but i may have
> misunderstood the term to begin with. did i?
> 
> cheers,
> 
> dret.
> 
> 




Received on Monday, 4 February 2013 14:50:11 UTC

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