Re: Issue-34 Back_to_Basics proposal

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. 

Roger

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