Re: Loosely-coupled (modular) LDP, was Re: Recharter scope

On 11/18/14 7:27 AM, Sandro Hawke wrote:
> On 11/18/2014 06:36 AM, henry.story@bblfish.net wrote:
>> During the teleconf there was a discussion about a twitter thread 
>> criticising the RESTfulness
>> of LDP. I think that it is the most important value that LDP bring to 
>> the table, when
>> compared to all the other RDF standards that exist. We should think 
>> of this group as tying
>> loose ends together.  Could someone please point us to that 
>> discussion? Note that I don't
>> think that RESTafarians have the final say  of what REST is, because 
>> they tend
>> to miss the semantic part of what it is that a Representation 
>> transfers: the state of
>> a Resource. So we should not allow us to be buillied by bad 
>> RESTafarian arguments into
>> abandoning the core value that REST represents for the LDP group.
>
> There is this: 
> http://lists.w3.org/Archives/Public/public-ldp/2014Feb/0020.html
>
> in which Mark Baker say, "I consider the design overly complex, 
> tightly coupled (and therefore unRESTful)".
>
> I had a private conversation with him after that, trying to 
> understand, and came to the conclusion that he was right.  In the 
> simplest terms, we shouldn't have any notion of an "LDP Server" or 
> "LDP Client".   In general, we should just have certain kinds of 
> resources that behave certain ways.    An LDP Server could be defined 
> as a web server that happens to support one or more of the ldp 
> container types, or something, for market simplicity.
>
> For example, I think it's possible (and preferable) to express 
> ldp:BasicContainer without talking about server or client conformance, 
> and without any RDF dependency, in a way that would make them more 
> generally useful.
>
> Actually, even better, I'd probably go with:
>
> ldp:Creator -- a resource which responds to POST by making the POSTed 
> entity available as a new Web Resource.   Relative URLs inside the 
> entity or in Link headers are understood to be relative to the new 
> location.  ldp:Creators may have an associated ldp:Container in which 
> created resources automatically appear (or may, in fact, also be a an 
> ldp:Container).
>
> ldp:Container (or ldp:PageSet or ldp:Enumeration or something) -- a 
> resource which is is said to "contain" other resources.  Its state 
> includes these containment relations, so a GET returns an enumeration 
> of its contained resources, possibly along with other data, in an 
> appropriate media type.  In RDF serializations, the container 
> ldp:contains each of its contained resources. Variations on 
> (subclasses of) ldp:Container control what happens when the container 
> or a contained resources is DELETEd, whether subcontainers are 
> allowed, whether resource in a subcontainer are considered elements of 
> the parent container, etc.
>
> These are much more general concepts, not really even tied to each 
> other, not tied to RDF, etc.  They are so general they are already in 
> widespread use -- they're just not named, so clients can't detect them 
> to allow for interoperability.
>
>       -- Sandro

+1 in regards to the fundamental thesis :)



Kingsley
>
>>
>>> On 17 Nov 2014, at 21:24, Arnaud Le Hors <lehors@us.ibm.com> wrote:
>>>
>>> Per our discussion on today's call I invite everyone to help develop 
>>> the list of questions that defines the scope of the new WG we would 
>>> propose to charter. We could change the format if we want to but 
>>> that's secondary. Here is the updated list based on today's discussion:
>>>
>>> 1.        How can retrieval of a container and its contained 
>>> resources be combined so that fewer HTTP operations are required 
>>> than it is necessary with LDP 1.0?
>> I think this needs to be formulated more clearly.
>>
>> As I understand it the aim would be to pass some information about 
>> the contents of the ldp:contain-ed resources
>> in the LDPContainer. In some way Atom does this using the <content> 
>> and <summary> elements. What is desired
>> is that this be part of a GET operation ( and not part of a query )
>>
>> => 1. define a way to allow  a container to respond in GET requests 
>> with full or partial content of the contained
>>     resources.
>>
>>   ( clearly this either requirs literals or quads )
>>
>>
>>> 2.        How can multiple resources be created with a single HTTP 
>>> request?
>> Robert Sanderson wrote:
>> "+0.  This seems like going firmly against the current specification 
>> that the entity body is a single resource, even if it refers to other 
>> non-existing resources on the same server, either by absolute or 
>> relative URIs."
>>
>> The really simple way to do this would be to POST a tar of a 
>> directory to an LDPContainer.
>> What the working group should consider immediately is: does this 
>> contradict our current containers?
>> Ideally POSTing a tar should create a LDPC with each of the tared 
>> files in the created LDPC.
>>
>>> 3.        How can a client request filtering what part of a resource 
>>> or container the server is to return?
>> Robert Sanderson wrote:
>> "+1.  And to keeping it separate from 1 and not using a query syntax"
>>
>> That inevitably will end up being some form of query syntax, if we 
>> have something
>> general enough that it is worth specifying. What I think is desired 
>> is that there
>> be a very simple query syntax available, that anyone can implement, 
>> that has very
>> very low complexity properties, but that is extensible over time.  
>> Most importantly
>> it has to be semantically explicit, so that a client can know what 
>> types of queries
>> he is asking as he jumps across servers by following links. ( That is 
>> property/value
>> queries such as those found in current html forms are not good enough ).
>>
>> (btw, this is another reason for QUERY/SEARCH methods, as that builds 
>> in the variablitiy
>> of syntaxes )
>>
>>> 4.        How can a client be notified when something, such as a 
>>> resource or set of resources, changes?
>> Robert Sanderson wrote:
>> "+1. And to working with SocialWeb to see if ActivityStreams will 
>> solve or already solves the problem for us."
>>
>> That requires polling. We should definitively see how a polling 
>> solution can help.
>> But sometimes active notifications are much more desireable.
>>
>>> 5.        How can a client find out whether a service endpoint, such 
>>> as a SPARQL endpoint, is associated with a resource or set of 
>>> resources?
>>> 6.        How can access to a resource be controlled?
>>> 7.        How can a client have greater control of how paging is 
>>> done (size, sorting, etc.)?"
>>> 8.        How can a client learn what property constraints there are 
>>> when creating or updating a resource?"
>> +1 to all the above
>>
>>> 9.        How can we do efficient transfer of LDP resources, either 
>>> some initial set or rolling updates (feed) of changes?
>> One wonders wether a feed of PATCHes that would allow someone to 
>> reconstitute the changes would be useful.
>> This is what people are calling Event Sourcing
>>
>> ( just found this reference )
>>    http://ookami86.github.io/event-sourcing-in-practice/
>>
>>> Please, propose changes and additions as you see fit, as well as 
>>> deletions if you think that's appropriate.
>>> Thanks.
>>> -- 
>>> Arnaud  Le Hors - Senior Technical Staff Member, Open Web Standards 
>>> - IBM Software Group
>> Social Web Architect
>> http://bblfish.net/
>>
>>
>>
>
>
>
>


-- 
Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this