Re: a perspective on LDP

Henry. 

Thank you for your reply.

On a HTML page, the server only publishes <form>s according to what the user is able to do - according to the domain, etc .. One part of a <form> is the "action" attribute which tells where a completed form should be POSTed to. With LDP I see something quite similar to a HTML form, where the LDP equivalent of the form processor is the LDPC - i.e. the primary role of the LDPC is *not* to Contain, it is to Create ! 

For example, if the webpage is about someone's Networth; within the page is a listing of Liabilities, maybe followed by a "Add a new Liability here!" <form>. The 'action' for such a form is a LDPC - in this case it is used for managing the 'Networth's liabilities'. 

So I think that the core of LDP is about defining such endpoints (LDPC) that can receive and process requests. In REST terms this is the more fundamental concept.

Roger


On 14 Dec 2013, at 14:52, Henry Story wrote:
> 
> On 13 Dec 2013, at 16:10, Roger Menday <roger.menday@uk.fujitsu.com> wrote:
> 
>> 
>> hello, 
>> 
>> I have tried to sum up my feelings about the current discussions in LDP ...
>> 
>> There are triples found inside Documents (with URLs). 
>> These triples are using URIs for things (e.g. Photo, Networth, Container ...). 
>> 
>> Some groups of triples (same-subject, same predicate) are named and identified with URLs because in applications this combination is useful ("Photo's comments", "Networth's liabilities", "Container's members", ...). Currently we call these groups LDPC's [*]. 
> 
> Yes, the big problem with all the examples in the spec, is that there is a consistent confusion between
> HTTP Resources that are documents and things in the world. And yet this is HTTP 101 basics.
> 
> The distinction is simple: 
> • one can do HTTP actions on such as POSTing, PATCHing etc. on HTTP resources
> • one usually cannot do such things on Networth's liabilities, people, etc...
> 
> The web is a protocol for transmitting documents. These documents contain triples that speak about things
> in the world. The things in the world have relations, but only the HTTP resources are things that can be manipulated
> using LDP.
> 
>> The meaning of POSTing to such a LDPC is that a new resource is created (returned in the Location: header) and a new triple is added to the group.
> 
> "if by such LDPCs" you mean anything that has same subject triples with a URI then clearly not all such triples
> can be posted to. If you look up the definition of URI you'll see that you cannot POST to a URI with a #tag .
> Here is an example where this does not hold:
> 
> [[
> <> a bt:BugReportCollection, ldp:DirectContainer;   
>    ldp:containerResource <../swfwo#v2>;
>    ldp:containsRelation bt:hasBugReport .
> 
> <../swfo#v2>
>      bt:hasBugReport <1>;
>       ....; 
>      bt:hasBugReport <300000> .
> ]]
> 
> <../swfo#v2> is not an LDPC. You cannot POST, PUT, DELETE, etc to it.
> 
>> That is pretty much the essence of what we could get away with for LDP 1.0.
> 
> If you look at the spec, it's all about PUT, POST, GET, ....
> 
>> 
>> 
>> Then we can do "Containers" as an extension on top of core LDP, i.e. Containers and "Container's members" as the supporting LDPCs. The ldpx:member (or whatever) is a specific type of predicate where it is well understood what this predicate means in applications, and this can have the extended container semantics that I think people want. 
> 
> That gets everything upside down. LDP is a protocol about how to interact through HTTP with documents. 
> LDPCs are core to creating new HTTP resources, and managing them. Everything else can be done
> with the rest of the RDF stack. Since RDF stands for Resource Description Framework. Once you
> can create, edit, delete documents that are in RDF you can speak about anything in the rest of the
> world.
> 
> 
>> 
>> Roger
>> 
>> [*] But, I do think the "container" name causes trouble and is misleading ...
>> 
>> 
>> 
>> 
>> 
>> 
> 
> Social Web Architect
> http://bblfish.net/
> 

Received on Wednesday, 18 December 2013 16:32:18 UTC