Re: lossless paging & volunteering for the army

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

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.

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

       -- Sandro

Received on Friday, 21 February 2014 17:05:21 UTC