Starting to enforce recordMetadata via Schema

depends on decision in #49

@lucas.kulla @j.broeder @markus.kubin @karl-uwe.stucky @steinm01 @henrik.lange

Hey there.

In !33 (closed) I propose a recordMetadata update with a couple of additional elements I think are neccesary based on our TF-DP discussions. Most of this is self cooked, and we should think as early as possible about aligning this with PROV, Schem.org, KIP etc. (as well as a JSON-LD serialization).

On the other hand the earlier we implement some CCT1-wide format for provenance, the better off we are with ingesting the CCT-1 data into different systems and also having a base for the above mentioned cross-walks / alignments.

I put some considerations for each property into the "description" fields for now. For a nicer way to look at this, I recomend pasting the Schema into here and clicking on "Generate Form" at the top.

New Properties:

• shouldValidateAgainst
• additionalContributors
• supersedesArchivedRecords

If we want to start enforcing this recordMetadata as well, we need to think about how to ensure that all Records will have this info added from now on. - historic records could be batch filled with git-history info - new info-portal records can have metadata added in the backend - new git-introduced records will probably need a pipeline that automatically enriches the 'recordMetadata' with git-commit-info

Technically I would image the RecordMetadata-Schema to be imported by the commonProperties Schema via a $ref? Also considering Jens point (#47)

P.S.: One aditional thing I wondered if it is better practice to group some of these properties into objects (e.g.: 'creationInfo' as an object holding 'creationDate' and 'creationId')