W3C home > Mailing lists > Public > public-ldp-wg@w3.org > November 2013

Re: We need to step up to database functionality

From: Wilde, Erik <Erik.Wilde@emc.com>
Date: Mon, 4 Nov 2013 12:11:27 -0500
To: "ashok.malhotra@oracle.com" <ashok.malhotra@oracle.com>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
Message-ID: <CE9D12CD.123A6%erik.wilde@emc.com>
hello all.

john already answered this, and it all comes down to that in REST, the
resource model decided everything. if you model resources in a way that
require you to lock some and interact with all of them and then release
the lock, then most likely you have chosen a resource granularity that is
not a good fit for the interaction patterns you want to support. i wrote
about this a little while ago:


the main point is that even when you have an RDF model of something, you
still haven't answered the hypermedia questions about the services on top
of that: what are the interaction patterns you support, and on which "RDF
documents"? that's critical for REST.

On 2013-11-03, 16:58 , "Ashok Malhotra" <ashok.malhotra@oracle.com> wrote:
>    But I want to touch on a broader issue.  With LDP we allow multiple
>    users access to a web resource,
>    and some of these users may be able to update the resource or some
>    part of it.  This takes us into
>    database territory but we have steadfastly chosen to ignore
>    functionality like
>    - access control
>    - transactions
>    - locking    
>    We need to consider these because it will come back and bite us in
>    the butt when, for example, users' updates are partially reflected

john's claim and mine as well is that access control is out of scope (and
i think we said so explicitly earlier on), while transactions and locking
should be relegated to an appropriate resource granularity model. if an
LDP server has problems with transactions/locking, then it probably has
been set up in a way which exposes a resource model that's not a good
choice. instead of changing LDP, the server then should change its
resource model, so that interactions are actually stateless.


Received on Monday, 4 November 2013 17:12:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:17:46 UTC