Specify conformance with info model

[clange]

• define release schedule – we so far agreed on the following:
  • a new release (major or minor) before each plugfest
  • before, solicit input and feedback from the infomodel SWG
  • afterwards, inform the architecture WG
  • continue using semantic versioning
• define durations in which components have to support some released version of the info model
• define migration paths from one version to another one
• define core classes and properties that have to be supported
• specify that, when I receive a message that contains infomodel instances with non-IDS metadata fields (e.g., SHACL shapes describing datasets), I may ignore the latter
• provide positive / negative tests (good negative test: wrong datatype, omitting mandatory property) – this will be handled in FDS T35.2
• separately: make sure that our Java reference implementation conforms. Possible approaches:
  • preprocessor that converts, e.g., infomodel 2.0, to infomodel 3.0 messages
    • could be realized by SPARQL construct queries (this could, e.g., be done by FIT in a 2020-Q3 FDS project)
  • Java library that supports multiple infomodel versions (either natively or by dynamically loading the full library for the version currently used)