Metadata / provenance in a delta

[joepio]

Being able to tell when something has changed by whom is a powerful thing to have in any information management system. Git is so incredibly popular partly because of this. I think linked-delta, as a project, has huge potential for the web. It takes the simple RDF model, and extends it with just one link per statement (which is extendible!) to standardize dynamic data, instead of static data. I feel like this project could help to standardize (decentralized) ledgers. For example, users could get linked-deltas from a third party, even if the true data source is offline, and use signatures to verify that the deltas originate from the actual source:

For usecases such as this one, but also many others, we'll need some form of provenance.

Let's say a user modifies a resource. The modifications to the resource itself are stored in a delta, of course, but what about the metadata? Should the delta contain any information about the User, some dateTime, perhaps even a signature? Should linked-delta standardize this, and if so, how? Some options:

1. Keep it simple, don't think of this as something that linked-delta should standardize. It's the responsibility of source system (that creates the delta), some middleware (that appends / modifies the delta) or the loader (that applies the delta to some stateful query system) to add metadata anyway he / she likes to. For example, the source system might append the original delta with some extra statements and generate an IRI for the delta itself, but this is the responsibility of some other spec. It keeps the linked-delta spec simple and clean, and it makes it easy to build a data processor, but it makes it harder to popularize the decentralized architecture mentioned earlier.
2. Standardize metadata on the delta resource with a special ld:meta field which is used in the graph field of statements.
3. Use HTTP headers for metadata, and store them in the Delta metadataobject instead of in the delta statements itself.
4. Something else?

For 2 and 3, delta processors should could (but should not be required to) use the metadata for various purposes: create notifications and activity feeds / streams, validate incoming delta's and their signatures / verifiable credentials, create various versions of resources.