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

> On 18 Nov 2014, at 13:27, Sandro Hawke <sandro@w3.org> 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.

I think that is what we have. An LDP server could implement only one of each of the 
containers or any set of them.

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

In agreement with Steve Speicher that HTTP contains the notion of 
client and server. One can see this here:
  http://www.w3.org/Protocols/rfc2616/rfc2616.html

As for "No RDF dependency", this is exactly the type of bad argument 
on the part of so called RESTafarians that we have to resist very strongly. 
  They are completely inconsistent here: I worked on the Atom protocol and there 
they were adamant about XML.  The same people now abosolutely convinced 
that JSON is the magical thing, and they will change when the fashion changes of course.
A cynic could argue that this is a way to keep them employed: Everytime the 
syntax changes you can re-invent the protocol, and you have a few more years 
of paid work. I am no cynic so I don't argue that: there is enough to
do at the semantic layer to keep everyone employed :-)

  Our argument is that moving to the semantic layer ( RDF ) we in fact reduce
syntactic dependencies and so make things much more modular. We can show this
in that our protocol will age very well as syntactic preferences change.

  Really we need to stick by the line that we are doing REST correctly 
here.


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

That "not tied to RDF" is a completely cynical argument. There is no way they 
can argue from REST principles that building a protocol with RDF is bad REST.

To add one point to the list of things to do, I notice that RESTafarians like 
beautiful URIs with patterns in the URIs. As I previously argued I really think we should
define an iContainer that allows one to know that POSTs into it will create resoures that
are extensions of the container URI but don't contain any slash. This would allow one
to make very simple arguments built up from file system intuitions that most people
know deeply about.



> 
>      -- Sandro
> 
>> 
>>> 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/
>> 
>> 
>> 
> 

Social Web Architect
http://bblfish.net/

Received on Tuesday, 18 November 2014 17:47:24 UTC