W3C home > Mailing lists > Public > public-ldp@w3.org > February 2014

Re: lossless paging & volunteering for the army

From: <henry.story@bblfish.net>
Date: Fri, 21 Feb 2014 19:16:02 +0100
Cc: Mark Baker <distobj@acm.org>, Steve K Speicher <sspeiche@gmail.com>, public-ldp <public-ldp@w3.org>
Message-Id: <C068C263-304D-4219-ACA1-5989A873D291@bblfish.net>
To: Sandro Hawke <sandro@w3.org>

On 21 Feb 2014, at 18:05, Sandro Hawke <sandro@w3.org> wrote:

> On 02/21/2014 09:55 AM, Mark Baker wrote:
>> On Fri, Feb 21, 2014 at 4:24 AM, henry.story@bblfish.net
>> <henry.story@bblfish.net> wrote:
>>> I was thinking that there is an additional reason to have lossless paging
>>> which is best explained with the "Volunteering for the army" counter
>>> use-case. [1]
>>> 
>>> Given the recent resolution to name ldp:Container what was previously known
>>> as the ldp:IndirectContainer [2] a client doing a GET on an LDPC will not
>>> know
>>> if it can POST to the container without the danger of that action
>>> volunteering
>>> its owner to the army -- unless it has read through all pages of the
>>> container, which
>>> may be close to impossible as argued by Sandro.
>> AIUI, the POST to a container modifies it's membership. In order to
>> volunteer for the army, the client would need to POST directly to the
>> member that offers that service. Hopefully I haven't missed some
>> esoteric aspect of LDP containers during my review?
> 
> The container is the resource that offers the service.  The container is an "army signup list", like a sign up list that might be posted on a wall.
> 
> Let me switch to a scenario that I find much more realistic, so I can fill in all the details.
> 
> Picture a room reservation service, where the container contains room reservation records.  If you have access to POST a room reservation to that container, and you do so, you've now reserved a room.    To cancel your reservation, you DELETE the resource that got created in the container.     People with access can GET the container to see the room reservations.  If they want, they might HEAD it instead and see if there's a FIRST link, so they can page through it more slowly.
> 
> If you reserve a lot of rooms that you're not supposed to, or you reserve rooms for inappropriate activities (that end up going viral), you might well lose your job.  And maybe that means you have no choice but to join the army.  :-)

Your example is more mundate for sure, and so does hides the dangers that I am trying to make crystal clear with the volunteering
for the army example. A compromise solution may be a LDPC form to buy a car or some big ticket purchase :-)

> 
> Of course it wont be humans using curl to POST and GET and DELETE, it'll be some room reservation app, or some calendaring app.   I tend to use Google Calendar (on the web) and aCalendar (on android), myself.  It's not unreasonably that either or both of them would have access to some information about me, including links to where I work.    Maybe I link to http://www.csail.mit.edu/ from some profile of mine, saying I work there.  And that really does link (under "Book a Room") to https://calendar.csail.mit.edu/calendars/2/day which links to a Web form which submits to https://calendar.csail.mit.edu/meetings.  If I POST there with my (csail employee client cert), I can create room reservations. Right now, it's an HTML interface, but with LDP it could become an API, a Container of room reservations that Google Calendar and aCalendar could use to offer me room reservatations when I make a new calendar event.   They could also use it to show room reservations I have made.
> 
> Beyond LDP, what's needed to make this work is (1) a vocabulary for describing room reservations, used by CSAIL and my calendaring apps, and (2) the predicates that connect my profile to https://calendar.csail.mit.edu/meetings and convey what it is.   I think that's just foaf and/or org stuff, plus one special new predicate, something like: <organization> roomReservations <roomReservationsContainer>.   In this case it would be something like:
> 
> <http://www.csail.mit.edu/#csail> eg:roomReservations <https://calendar.csail.mit.edu/meetings>.
> 
> I'd expect to see that triple if I GET https://calendar.csail.mit.edu/meetings, which would be its way of claiming that it's a room reservations container for CSAIL.   That's nice, but one should not trust it.
> 
> I'd also expect to see that triple if I GET http://www.csail.mit.edu/ .  That would be how my apps would find this container, and that's something I would trust as an official statement from CSAIL that this is a way to really reserve rooms.

Ok. I think your example is straying somewhat from the point I was trying to make by considering issues of epistemology, in particular the question as to how do we get to trust that the container is the type of container it says it is. My counter-use-case is focused on considering
the protocol aspects relating to POSTing to an ldp:Container ( which used to be known as an ldp:IndirectContainer, but a similar argument
could be made to work with the ldp:DirectContainer ). Both the ldp:IndirectContainer and the ldp:DirectContainers create new relations in addition to the ones in the body of the POST and in addition to the ldp:contains relation. That is a client that POSTs to an ldp:SimpleContainer need only know that it is publishing the document it is POSTing. ( The same works for PUT). In the other containers the client needs to know that it is also creating an additional relation, and that this relation could be a statement about joining the army, buying a car, booking a room, etc...  Assuming the LDPC is describing itself correctly, a client needs to know when POSTing to such containers that it is doing something more than creating an information resource ( aka source in RDF1.1 ). It needs to understand the new relation it is going to create. And since a well programmed client will know what the effect of POSTing to such containers is, it will also be liable to the conesquences of the statement it creates.


> 
> As I've sketched it out here, Henry's concern does not manifest. The essential triple that told me I might be getting myself into trouble was outside the container resource itself, and I couldn't have found the container without knowing that predicate.
> 
> As I think about other ways the information could be laid out, I have similar results.  Whatever information led the client to think this container was useful at all could also be telling it how dangerous it is.
> 
> One COULD design a vocabulary with eg:RealRoomReservationsAndJokeRoomReservations and in which case you might get yourself into a lot of trouble.
> 
> One could accidentally do it like this:
> 
> <http://www.csail.mit.edu/#csail> eg:maybeRoomReservations <https://calendar.csail.mit.edu/meetings>.
> <http://www.csail.mit.edu/#csail> eg:maybeRoomReservations <https://calendar.csail.mit.edu/test-meetings>.
> <https://calendar.csail.mit.edu/test-meetings> a eg:TestSystem.
> 
> Here, you could SAY in the definition of eg:maybeRoomReservations that clients must check for whether the system is a eg:TestSystem, and let users know.   And here Henry's problem might arise (in reverse).   Dropped triples would mean the user might be told it's real when it's really a test system.  And then, when my important colleagues from across the industry show up for their LDP F2F, it might turn out all the rooms are already allocated to other people, because I accidentally made my reservation on the TEST system. Ooops.
> 
> So, I don't like lossy paging, but I think this particular kind of problem can (and should) be prevented instead by more careful vocabulary design.  This is monotonicity.   In RDF, in general, we want it so that if you're missing triples, it just means you know *less*, not that you know something *false*.

I don't think my example fails on montonicity requirements. The membership triples that are created on a POST
are created by the action of POSTing.  This puts those in the same real as what John Austin and later Searle 
called speech acts: when a priest says that two people are man and wife, he is not making a statement of fact,
he is making it true. When you sign a contract you are not stating a truth about a pre-existing condition you 
are making it true. 

http://www.amazon.com/Speech-Acts-Essay-Philosophy-Language/dp/052109626X/ref=sr_1_1?ie=UTF8&qid=1393006510&sr=8-1&keywords=john+searle+speech+acts

> 
>      -- Sandro
> 

Social Web Architect
http://bblfish.net/
Received on Friday, 21 February 2014 18:17:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:03:11 UTC