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: Wed, 27 Feb 2013 23:14:24 +0000
CC: "public-ldp-wg@w3.org Working Group" <public-ldp-wg@w3.org>
Message-ID: <4F11A80F-803A-45F7-9E60-3C70C3C0BDF6@uk.fujitsu.com>
To: John Arwe <johnarwe@us.ibm.com>

hello John, 

Responding to an email from a few weeks back ... 

> > 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 (??)   
> Sorry Roger, there's not enough here that I can follow clearly enough to attempt to reply substantively to. 
> The motivating use cases we had included cases where a client wanted to display information about a collection (like its title, description for a UI) without having to retrieve the entire contents of the collection.  Since RDF triples are unordered, that gross level of filtering was a case where we invented an interaction mechanism sufficient to keep the UI responsive even for very large collections (reductio ad absurdum, a billion-member collection). 

Doesn't that make an assumption that the "member" predicates are the ones contributing the largest volume of triples ? What about non-member predicates with high triple volumes ? 

What about predicates which don't want to be non-member predicates and don't want to be member ones either ? :) Do they exist ? 

> If you're arguing that use cases like that imply that servers must allow each property to be individually addressable in every resource (LDPR?  LDPC?  other?),

I am ultimately trying to argue for something similar to that, yes.
But, I am building it up in small pieces :) 

So, first, I am trying to build up a case for every predicate being treated the same way. 


> I find my theoretical side mildly liking it but my practical side "reacting badly" as overkill and probably making things net-worse (e.g. the UI case - it wants title, description, possibly other info like last-mod time, and MORE HTTP flows to obtain those is not what it wants... it wants a minimal number of flows, implying a more "arbitrary filtering" mechanism).  Collections whose implementations that "expect themselves" to always be very small would probably not spend the implementation cost just to say they "comply" with LDP. 

Received on Wednesday, 27 February 2013 23:15:17 UTC

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