proposal for PATCH workflows

Some ideas from timbl on the possible evolution of the patch workflow
currently used by some systems

https://github.com/solid/solid/blob/master/proposals/patch-directions.md

Reasonable future features for the patch distribution system include:

   - When listening for updates, the client should get a patch instead of a
   ping, and so will be able to apply the patch instead of, as currently,
   reloading the file.
   - Move to an N3 compatible patch format, like <#patch> :where {...},
   :delete {...} etc etc
   - Extend the patch format to allow multiple files to be patched as an
   atomic operation
   - When receiving a stream of updates, the server could cache the graph
   in memory, not reading it again from the file system
   -

   Further the server doesn't write back the patched file every patch, only
   every few seconds.

   Longer term ideas, larger projects:
   -

   When clients of listening to the same resource are in fact located
   physically close, they could exchange patches through other medium like
   wifi or bluetooth.
   - The system can evolve (under stress) to work entirely with distributed
   patches, making the original HTTP server unnecessary
   - The patches could be combined with hashes of versions of folders to be
   the basis for a git-like version control system, or connect to git itself,
   etc