Re: Issue-34 Back_to_Basics proposal

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

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

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

Member-collection links can be more important, I think it just depends on 
what your favorite app happens to be.  The submission was trying to enable 
a very broad range of apps, including those for example where the members 
have no idea what "collections" link to them.  So again, from an 
interaction model standpoint, it seemed minimally necessary to define how 
a client navigates from collection to its members.  The (implicit) 
assumption was that some additional app-specific ontology would be layered 
on top to cover additional cases... and if those turn out to be widely 
interesting enough, those might even find their way into later specs 
layered on top of LDP.  There are lots of other groups doing 
discipline/app-specific ontologies, my goal certainly would be to enable 
re-use of all that existing work.


Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario