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

On Wed, Nov 19, 2014 at 9:15 AM, ashok malhotra
<ashok.malhotra@oracle.com> wrote:
> Shall we add a bullet:
> o Refactor/Reorganize/Simplify LDP Spec
> to the LDPNext charter?

-1

We should instead just focus on building incremental capabilities,
perhaps as their own standalone spec.  There has been too much work to
get it where it is today and the refactoring only appears to be
recasting the same spec slightly differently.  Hard to say at this
point it would increase adoption by any factor.  Would invalidate
probably all test suite results, etc.  Primer is a good document to
help people who don't want to read the spec to understand the
concepts.

- Steve

> Ashok
>
> On 11/19/2014 8:30 AM, Sandro Hawke wrote:
>>
>> On 11/18/2014 08:59 AM, Steve Speicher wrote:
>>>
>>> On Tue, Nov 18, 2014 at 7:27 AM, 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.
>>>
>>> The HTTP spec have a notion of "HTTP Client" and "HTTP Server". An LDP
>>> Server doesn't have to support the entire LDP spec, I see it as more
>>> of a convention as a way to refer to the piece of software that has
>>> been written to receive requests that match the expectations as
>>> outlined in the LDP spec.
>>>
>>>> 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.
>>>
>>> I'm not sure what good a standard is without conformance, I believe
>>> I'm missing the point somehow.
>>
>>
>> Yeah, I didn't explain this very well.  Let me try again.
>>
>> I think it's analogous to code refactoring to improve modularity and
>> reuse.
>>
>> What we have now is specified as if it were a monolithic function with
>> many toggles for optional features.  A "loosely-coupled" alternative would
>> look more like a bunch of independent functions, each useful in its own
>> right, which happen to work nicely together.
>>
>> Mostly this is just about presentation in the spec, but in some cases my
>> sense of a good refactoring would also change interoperability, eg splitting
>> Container into Creator + PageSet. In a sense this is a total coin-flip
>> decision: do we want everything to be a container, where some containers
>> create but don't act as sets and some act as sets but don't allow creation,
>> or do we want two different interfaces that might be implemented by the same
>> resource?     Right now that's kind of an annoying "who cares" question, but
>> as each of those functions grows in complexity, with different ways one
>> might want to use it, the overall system probably stays simpler if Creators
>> are defined in one spec and PageSets are defined in another.    At least,
>> that's the loose-coupling hypothesis, as I understand it.   (This might not
>> be the best example: separating patching from containers is a much more
>> appealing example, and we're all convinced that's a good idea, I think.)
>>
>> On conformance/servers, it's probably just editorial, but it has a
>> somewhat different feel.  Something like:
>>
>> 1.  When an LDP Server responds to a GET on a Creator, it MUST include a
>> Link <...Creator> rel=type" header.   In handling a POST, the server MUST
>> make the posted content available at a new URL.
>>
>> vs
>>
>> 2.  A Creator resource is any resource whose server responds to POST
>> requests on that resource by making the posted content available at a new
>> URL.   In responding to GET and HEAD requests on a Creator, its server MAY
>> include a Link <...Creator> rel=type" header to signal to clients how POST
>> will be handled. HTTP Servers MUST NOT include such a Link header on
>> non-Creator resources.    A conforming "LDP Server" is one which always
>> includes all the optional LDP headers.
>>
>> In a sense the first only applies to LDP servers and the second applies to
>> all HTTP servers, but I think there's an unwritten (?) rule, "HTTP Servers
>> MUST NOT include Link headers unless they understand them and agree with
>> what they mean", which makes the practical meaning of (1) and (2) the same.
>>
>>>> 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.
>>>
>>> Personally I'm not sure this changes much from where we are at, just a
>>> different way to express it but not seeing how this would change
>>> "market acceptance" or something the rechartered group would need to
>>> do.   I think reflection is healthy to evaluate how to improve on the
>>> future.  Though some of this discussion seems less constructive on how
>>> we take the work we have agreed on thus far and work together to get
>>> support/adoption (market adoption) and feedback.
>>
>>
>> I haven't had a lot of conversations with people who had heard of LDP and
>> were not in this WG, but in the ones I have had, they seemed to think LDP
>> was really complicated.   It's the problem of people thinking they need to
>> understand the whole menu before they can order a dish.    The modular
>> approach would make it more clear, I think, that they only need to read the
>> specs for the bits they want.   This will become much more important as we
>> grow the functionality.   Of course we're already doing this with Paging and
>> Patch.
>>
>>>> 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.
>>>
>>> I don't understand this last point, the concepts or so general or the
>>> deployment of a spec supporting the concepts are in widespread use?
>>> Also I don't get the point about clients can't detect them, to allow
>>> for interoperability.  I would have expected you to say, that clients
>>> that don't know about them can continue to work (graceful
>>> degradation).
>>
>>
>> I hope the way I phrased defn (2) above makes clear what I meant.
>> Creators, PageSets, Pagables, etc already exist on the Web, but they're not
>> telling clients (in machine readable ways) that that's what they are.  (And
>> they differ in arbitrary ways.)
>>
>> To phrase this one more way: loose coupling is more like paving the
>> cowpaths, or letting people pave their own cowpaths.  LDP 1.0 is more like a
>> flexible order form for paved paths.   For a lot of people the order form is
>> nicer, but it might turn out to be harder to maintain, and it gives people
>> less flexibility for mixing-and-matching with other products.   That
>> mixing-and-matching is a hallmark of the Internet and the Web, and that's
>> the banner I think the RESTafarians are flying.
>>
>> In terms of actually moving forward?   I think we should expect the next
>> WG to produce 5-15 somewhat independent Recs.   Maybe after we've gotten the
>> hang of that, and like that style, we can go back and re-articulate LDP 1.0
>> as several smaller specs.
>>
>> This could also shape the way we talk about the new group and the existing
>> work to the world, although nothing specific springs to mind.
>>
>>       -- Sandro
>>
>>>
>>> - Steve
>>>
>>>>        -- 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/
>>>>>
>>>>>
>>>>>
>>>>
>>
>>
>
>
>

Received on Wednesday, 19 November 2014 14:23:33 UTC