Re: lossless paging & volunteering for the army

On 21 Feb 2014, at 20:12, Ashok Malhotra <ashok.malhotra@oracle.com> wrote:

> Hi Henry:
> I'm trying to understand your argument.
> When you do a POST to a container it creates the member.
> I also creates additional triples having to do with membership
> and containment.

yes, when you POST to an LDPC this is an action that will have the following
consequences:

 1) the creation of a new source related to the ldlc by the ldp:contains relation
 2) the creation of the membership triples

> Are you saying that a rogue implementation may create additional
> triples that enroll you in the army or sign some contract?

No, I am just saying that a client that does not know what the 
ldp:membershipResource, ldp:hasMemberRelation and ldp:insertedContentRelation
relations are MUST not POST since it could be that by doing that it is signing 
up for the army, buying a car, ordering someone to die, signing a form to buy 
a year of cable TV, buying a licence for MS Office,... ( imagine whatever horrible 
scenario you want ). I am pointing out what it is one does not know when one does
not know that one does not have an ldp:SimpleContainer.

> If so, that's a concerns about rogue implementations a not about
> containers per se.

So the issue about containers comes up with very large LDPCs. Since
RDF does not have ordering, there is no way for the client to be sure
at what point it will receive the required triples. This is more serious
then for large LDPCs that are pages, because the client may have to 
page through all the pages, which as Sandro pointed out may not be
possible if the LDPC changes fast enough:

   http://lists.w3.org/Archives/Public/public-ldp/2014Feb/0003.html

Now we did move the Paging to a seperate spec, so that of course helps.
But since we want to have a spec on paging this point should also be considered there.
And I think it should be made clearer in the spec what it is that one does not know
when one does not know the ldp:membershipResource, ldp:hasMemberRelation or 
ldp:insertedContentRelation .


As a side issue, the reference to speech acts, may help suggest better names
for the "Membership triples". 


> All the best, Ashok
> 
> On 2/21/2014 1:16 PM, henry.story@bblfish.net wrote:
>> 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/
>> 
>> 
> 
> 
> 

Social Web Architect
http://bblfish.net/

Received on Saturday, 22 February 2014 16:10:41 UTC