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

On 11/18/14 12:46 PM, henry.story@bblfish.net wrote:
>> >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.

Yes, because for some reason RDF is now locked in the "Data Format" realm.

How can we get folks to understand, and then ultimately accept the fact 
that RDF is a Language (system of signs, syntax, and semantics for 
encoding and decoding information) that's loosely associated with a 
variety of notations (mechanism for representing the words of a language)?

>    They are completely inconsistent here: I worked on the Atom protocol and there
> they were adamant about XML.

They are utterly and eternally inconsistent because the nature and form 
of entity relation semantics aren't part of their narrative, or 
world-view. They see markers, marking, and syntax for marking. They 
don't see (be oversight or sheer cognitive dissonance) the semantics 
associated with the roles (subject, predicate, object) of each of the 
markers (words) in the marking (sentences) that constitute a language, 
so to speak.

>   The same people now abosolutely convinced
> that JSON is the magical thing, and they will change when the fashion changes of course.

Yes, they are focused on markers and marking.

> 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 have come to believe this is pure lack of understanding. Many parties 
are at fault here, and that includes the poor draconian narratives 
associated with RDF, especially in the early days. This problem is 
bigger than many of us ever imagined.


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

Yes, but we have to keep working on better narratives that ultimately 
replace those of yore. Objectively speaking, RDF narratives are 
generally poor, which is why it is still perceived as a format circa., 
2014.

>   We can show this
> in that our protocol will age very well as syntactic preferences change.

Personally, success comes from applications that possess implicit 
dexterity -- as a consequence of their ability to leverage entity 
relations semantics.

We just need to make more useful applications. We can never deliver a 
spec from the high heavens and demand mankind MUST follow. Humans (as 
far as I know) simply aren't wired that way :)


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

Just demonstrate that its being done right :)


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


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