Creating a PATCH request

[melvincarvalho]

I'd like to PATCH a resource that I dont have access to.

For example adding myself to a .acl file.

Is there a way to create a "PATCH REQUEST" so that when applied by someone with permissions the resulting triples would be merged into the resource?

If not could we fire up a quick spec? What would be best to capture the triples/quads in the HTTP request the way data browser does, or to create a Sparql Update body in a wrapper Class?

cc @kidehen

[csarven]

I think this use case can be generalised to:

x requests permission on y (in order to perform operation z)

We've discussed the notion of requesting previously in chats, as well as issues eg. #229 , nodeSolidServer/node-solid-server#992

IMO, we should first test and demonstrate the limits of existing specs.

I think an LDN notification can handle this, where a notification is sent to an (system/admin/resource/whatever's...) inbox indicating that:

• a WebID requests one or more ACL Access;
• for a or a set of URIs (individual or class);
• payload to be applied

(that's just an idea what the notification may contain for the purpose of discussion.. not trying to specifying anything right now.)

The bit of information on providing the payload is interesting on its own.. ie. the request provides the payload to be applied, but doesn't necessarily require or requests any changes to an ACL.

Some entity needs to process that request, and I think this would be an application on its own ("requestulator").

So, my suggestion is to experiment with a sender and a consumer application first.

[csarven]

@rubensworks Can you please elaborate?

Just to be clear, I am indeed making the distinction between the use cases about requesting access and requesting changes to be made. The notification would speak for itself. There can be other kinds of requests.

[melvincarvalho]

@csarven I like the direction you are going with this. A bit more detail and I can get to a proof of concept.

What's the payload here? Some Sparql Updage (solid subset).

[melvincarvalho]

Both valid, but slightly different use cases.

1. Alice requests a change to Bob's Resource -- e.g. to add herself as a friend.

2. Alice wants to access Bob's lecture notes, and wants Bob to add her to the ACL.

[melvincarvalho]

Right, so I think the inbox route is worth exploring.

Alice says, Hey Bob, could you add these triples to this resource.

My question is what the payload would be. Perhaps we can think about a single resource first, before generalizing to multiple resources (tho that would be quite cool!).

• Do we put in a sparql update, with some meta data

or

• Do we put in a bunch of triples to mimic the HTTP PATCH Request

"The latter being, hey, here's an HTTP Request, could you run it for me"

[melvincarvalho]

So it would be like a CSRF but instead a CSRR Cross Site Request Request, via an inbox.

[csarven]

You're right. I've generalised and then added related stuff. The original issue pertains to what you've emphasised in Melvin's request. What I was trying to get at is that eventually some 'request' needs to inform the stakeholders and the mechanism for that can probably also handle other requests. Just need an agreement on the payload shape.

Any way.. if a notification pertaining to a patch-like operation is a reasonable step forward, solid:patches.. sounds decent to me. A client application would need to help the user process that of course.

While that'd be fine for this issue and in and itself, I just suggest we also consider other (any?) requests which may be put or post-like for RDFSource(s) or NonRDFSource(s). Just so that we can identify any common pattern across, if any. For NonRDFSource, there can be different approaches eg. send the NonRDFSource separately to some temporary container, or the notification references the location of the NonRDFSource where it can be fetched from.

Server's response to the original request should be a 202.

[csarven]

I think 201 is not guaranteed in this case since the server only signals that the request will be looked into - which is kind of what we're saying with the request any way.

The server could do 201 and assign a URI for the notification, but it need not to ie. making the consumers besides the sender (original requester) be aware of the notification URI. No particular footprint.

The server could proceed to create the notification immediately any way so that the consumer that's going to actually process it can eventually discover it.

One other use from 202 would be to indicate the status of the request somewhere that can be looked up.

(I'm glad we are considering/thinking through these options... )

[csarven]

A follow-up question is if we need to have special containers.. where one would signal the location of a created resource (201), and the other not (202). This is orthogonal to whether the inbox or the notifications within are accessible - most likely not for this use case.

I was thinking from the point of a dedicated system inbox returning 202 because it avoids publicising notification URI (in Location) - as in the case with 201.

The 201 case would be simple right now since we don't have a way to handle 202 yet (that I'm aware of). So, agreement on the payload shape is all that's needed to proceed.

[csarven]

Depends if the use case requires to know whether the request is fulfilled or not.. or why not eg. the status monitor location gives an opportunity for the requester to take note, and make a subsequent request if need to - which is common in PR-like scenarios.

What I'm sensing is that, 201, 202, 204 are equally useful.

[csarven]

I agree in the most strict sense. As I said, the server doesn't need to publicise the URI and gets to point to a monitor.

[csarven]

I'm open to all of this. 201 would enable: "hey, did you process my request x?"

[melvincarvalho]

This is good progress!

Good discussion on 2xx, which I think we could bake into the overall work flow.

Let me just summarize so far. So we have the outline of 3 different ways to solve this use case. Each one solves in turn other use cases.

• Alice creates an an HTTP request she'd like Bob to run
• Alice creates a solid sparql update with insert and delete statements
• Alice creates a solid : patch with solid : where and solid : insert/delete

All three I think are mini specs in themselves and useful in different ways. I only need one at this point and am a lot closer to creating a prototype.

We also may get further on the important issue of access requests here : nodeSolidServer/node-solid-server#992 -- thanks for pointing that one out!

Now on the protocols. We should I think (and I could be wrong) typically make distinctions between .acls and content. Which absolutely in solid they are both just rdf documents, that was a design decision, and in a sense a clean separation of controls creates a healthy thought process. As I say, I could be wrong on that, more thinking out loud. So we could have a 4th way which is "Alice asks bob for access to X".

So the transport and delivery I think is the last piece. I do like this idea of the prototyping around the inbox, because I think I could get things done quickly.

A client application would need to help the user process that of course.

This is also helpful, so I could write that.

[melvincarvalho]

BTW : Tongue in cheek, did we just invent CORN -- Cross Origin Request Notifications :)

[melvincarvalho]

re :

<> solid:patches <https://tim.localhost:7777/read-write.ttl>;

• Should it have a class solid:Patch?

• Is <> valid in a POST if we dont know what it's relative to? Is [] better?

[melvincarvalho]

@prefix solid: <http://www.w3.org/ns/solid/terms#>.
 
[] a solid:Patch
    solid:patches <https://tim.localhost:7777/read-write.ttl> ;
    solid:body "INSERT ... " .

Another similar (and compatible) route?

[melvincarvalho]

@csarven I'm thinking about an implementation for this, and because there are many moving parts (and my use case has more), I'd like to make a simple prototype.

To that end I'm thinking of putting ACL PATCH Requests in :

/inbox/request/acl/

This will allow me to quickly iterate on this use case without having to take into account the general case. Any thoughts on this approach?

[csarven]

Yes, that works - the location of the inbox doesn't matter. I think the target resource with the inbox is more interesting because eventually discovery will start from there. So this is fine:

<http://example.org/#request-reviewer>
  ldp:inbox <http://example.org/inbox/request/acl/> .