I'm just putting some ideas down here for how a JSON-LD patch system might be implemented. This may or may not turn into a spec we want to produce.

Suppose that we defined (loosely for now, can be more rigorous later) a JSON-LD patch like so:

{
 "@context": "https://w3id.org/jsonld-patch/v1",
 // the target object to be patched
 "target": "urn:some-uri-for-an-object",
 // a frame could be a URL to a frame or an embedded frame
 "frame": "urn:some-uri-for-a-frame-or-an-embedded-frame",
 // a JSON patch (https://tools.ietf.org/html/rfc6902)
 "patch": [{"op": "add", "path": "/foo", "value": "bar"}]
}

The processing rules for this would be:

1. Dereference the target object.
2. Apply the frame to the target object producing framed_output.
3. Apply the JSON patch to framed_output producing patched_output.
4. Optionally, apply a system-specific frame to patched_output to produce result.

For the optional final step, a system (aka application) may wish to allow clients to patch its documents but it will want to ensure that those documents maintain a certain shape and context. To do this, it could, as a final step, reframe the patched output using a system-specific frame that would include any context from patched_output with its own system-specific context appended to it. This would ensure that the system-specific shape and context had precedence over any changes by the client that incorporated new contextual information (i.e. any conflicts are resolved to the system-specific context).

This approach would allow developers to use JSON patch (which they are often familiar with) along with JSON-LD. For clients that only speak idiomatic JSON, the frame could be omitted and assumed to be some system default with some restraints on which fields they could add (i.e. only fields in the system default context).

Thoughts on this approach?