responsibility in LDP, was Re: TWO PROPOSALs involving Prefer - volunteering for the army -> ldp:index PROPOSAL

On 03/01/2014 03:58 PM, henry.story@bblfish.net wrote:
> On 1 Mar 2014, at 18:03, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>
>> On 3/1/14 4:23 AM, henry.story@bblfish.net wrote:
>>> But the rules are not excessive. The rule is that the client understand the meaning of the membership triples that will be added as a consequence of the POST. It can gain this understanding by asking a human agent of course (as browsers currently do on an html form), or the client can be specialised on specific vocabularies, ( a meeting organiser for example ), or it can work with relations that are well understood to have little dangerous implications, such as ldp:contains. And since there exists an ldp:BasicContainer that clients can work with without danger, those that do not wish to take risks should use only that.
>> It's impractical, to expect this of Web clients.
> I don't see how it is impractical to require of Web Clients that don't want to use Direct or Indirect Containers not to use them. That pretty simple to do: they just can use DirectContainers.
>   

I assume you mean BasicContainers at the end of that sentence.

> It is also not impractical to require of a Web Client that does wish to use Direct or Indirect Containers that it understand the membership predicates of a particular container, and that if it does not, that it not POST there. Crawlers and user agents of all types come accross HTML forms that can POST things to resources, and they don't just arbirarily POST things there. So this habit of not POSTing blindly to any resource that accepts POSTs is already wide spread and central to the current web architecture.

As in my room-reservation example [1], there may be ways to know what 
the container is for without ever GETing it.  In fact, in that example, 
I provided a solid example of how the alternate ways are more like the 
current Web and more reliable.

Henry, you want to make the client responsible for the triples the 
server adds to the container, and I think I'd agree that if the client 
knows the triples are going to be added it bears some responsibility for 
the consequences of them being added.  But what I think Kingsley and I 
are saying is that on the open Web, this Working Group doesn't have the 
power to compel clients to obtain that knowledge, and without that 
knowledge they no longer bear the responsibility.   I don't believe us 
saying in the spec that they are responsible will make it so.

I think the solution is to be clear that clients bear responsibility for 
the triples they POST, and if you want them to be responsible for their 
membership triple, then have the server require them to include it in 
the POST.   (That is, membership triples become just a kind of 
often-inlined member triple.)

But ... there's a lot more going on here.   Maybe we do need to figure 
it out.    I'll start with briefly summarizing how I think 
responsibility works on the Web:

1.  Each Web Resource (aka Web Page) is a social entity, with social 
behavior.  Basically, it says things.  Those things might be lies, they 
might be out of date, they might be useless.    Hopefully they're true 
and interesting.   When the Resource is a really good one, if we act on 
the assumption what it says is true, good things will happen for us.   
If it's a bad one and we trust it, bad things will probably happen.   
That's a kind of loose definition of trustworthy.

2.  We need ways to figure out which resources are trustworth, which 
ones we can trust to lead us in the right direction.  But there are a 
lot of resources, far more than we could ever keep track of.   And we 
move between them a lot, using many of them only once, so we have no 
chance to learn if it's trustworthy.

3.  The general solution is to cluster resources, with one taking 
responsibility for a set of others.   Sometimes it's partial 
responsibility.   Every domain owner has some responsibility for the 
content served with URLs in that domain.  Domain certificate holders 
have some additional responsibility for https content signed with that 
certificate.   On my business card, I have some URLs for which I'm 
taking responsibility.    Those URLs convey some level of trust onto 
other Resources by linking to them without a big warning (or rel=nofollow).

4.  We probably need some good Linked Data ways to handle this.   It 
looks feasible, but I haven't seen it done.  But basically, I'm pretty 
strongly responsible for the content served from my webid, and I should 
be able to take responsibility for other resources chaining out from 
there.   By doing so, I signal that trust in me should be to some degree 
linked to trust in all these resources. Some of those resources might be 
human, too.   (This sounds a lot like pagelink, of course.)   I guess 
owl:import is the predicate we have that signals complete trust; we 
probably want more control than that.

So what happens during POST?    My proposal is that we be clear that 
clients doing a POST are responsible for the content of the post. To a 
first approximation, if my client certificate is used for the POST, then 
I'm responsible for the posted content.  Looking closer, probably 
there's some software that's responsible, too; in some situations that 
can be made explicit. (This is like the "Posted Via..." links in 
Facebook and Twitter, which show which client software/app was used to 
make the posting.  This is important when those screw up or might be 
malicious.   I had some android malware once, posting spam as me, but it 
was easy to fix because of the client software attribution and access 
control.  I guess using the Origin header might address this for a class 
of webapps.)

When the server gets the POST and makes it available to others, I expect 
it to keep the responsibility pointed at whoever did the post.   This 
might be done cryptographically, but I'm expecting it to more like 
rel=nofollow.

Considering only general LDP servers for now, I imagine client A creates 
container AC and controls its configuration.  It sets things up so 
client B can POST, but not edit AC's configuration.   Now B uses POST to 
create container BC, for which only it controls the configuration.   It 
allows C to do a POST there, at URL CP.

Someone comes along and see the post CP.   Do A and B have any 
responsibility for the triples in CP?     Does it matter what the 
configuration of AC and BC are?

It seems like a good model to say simply that clients are responsible 
for the triples they post.   LDP servers use HTTP headers (and maybe 
some special resources, named by the headers) to tells clients which 
other clients (or entities) are responsible for content.

Alternatively, I guess one could say that by granting write access, one 
is giving complete trust.     That's probably the model in most existing 
rww applications.    My sense is that's too naive to work for my apps.

       -- Sandro

[1] http://lists.w3.org/Archives/Public/public-ldp/2014Feb/0012.html


>> Yes, RDF is about machine discernible and comprehensible semantics, but none of that means that a client MUST possess any such capabilities. In my eyes, RDF comprehension resides in vocabularies, never in the behavior of a client that's using HTTP to interact with content. i.e., a majority of HTTP clients will not exploit all the semantic implications expressed in a vocabulary or ontology.
> When reading RDF this is not a problem, because of the monotonicity requirement of RDF implication: you still have a true graph if you remove statements that you do not understand. Every graph implies its subgraphs.
>
> But when POSTing a graph to an Direct or Indirect Container you
>    1) create a new resource with your POSTed graph
>    2) create a new relation on top of the ones contained in the graph POSTed
>
> RDF does _not_ say that a subgraph implies every super graph.
>
> Take for example a graph A = { c a Car }. It is compatible with each one of
>
>     B = { c a Car; unicolor blue }
>     R = { c a Car; unicolor red }
>     W = { c a Car; unicolor White}
>
> But given the right definition of unicolor B, R and W are not compatible. There  is no possible world where the car is all three.
> So a client knows that when posting to a direct or indirect container it needs to agree with the graph AND the extra triple that
> the protocol very clearly lays out as being created.
>
>> This (I think) is the point Sandro is trying to relay in regards to his concerns about the above. We have to understand that (fundamentally) the Web's strength lies in its tolerance of the good, bad, and the ugly during client and server interactions.
>>
>> On the Web (or any network with heterogeneous clients and servers) you could inadvertently sign up for the Army, but that signup will never stand up in the real world :-)
> I'd be pretty pissed of with my software if it inadverently signed me up for the army even if I was then able to go to court and win my case.
> There were times when you needed much less to get signed up to the army (see the http://en.wikipedia.org/wiki/King's_shilling )
>
> I purposefully took an extreme case to get people thinking, but you can take many more realistic ones.
>
> If you go to e-bay and you POST a bid and win, you are liable to have to spend money.
> If a microtransaction system is set up with LDP and you post to it, then you'd still later need to UNDO your POST.
>
> In each of these cases you may be able to UNDO harm, but the harm still happened. Undoing the harm is one extra event on top
> of the initial harmful event.
>
>> I've always seen entity relation semantics comprehension as a feature that clients and servers use to distinguish themselves competitively, but never the basis for MUST requirements in specs.
> LDP is new in the space of RDF usage. So expect things here to be a bit different :-)
>
>
>> -- 
>>
>> Regards,
>>
>> Kingsley Idehen	
>> Founder & CEO
>> OpenLink Software
>> Company Web: http://www.openlinksw.com
>> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
>> Twitter Profile: https://twitter.com/kidehen
>> Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
>> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>>
>>
>>
>>
>>
> Social Web Architect
> http://bblfish.net/
>
>
>

Received on Sunday, 2 March 2014 03:22:03 UTC