Revision of the metadata model for collections

[lzehl]

This issue is directed to @olinux @apdavison @Peyman-N @UlrikeS91 @skoehnen @bweyers & @jagru20

@olinux and I discussed (again) the current metadata model for handling research product collections.
As a reminder this was (in summary) the decision we made in core issue 163 :
https://schema.datacite.org/meta/kernel-4.3/doc/DataCite-MetadataKernel_v4.3.pdf

I've implemented an example now and stumbled on a couple of things.
@olinux in parallel also rethought it from the KG Search point of view and also stumbled on a couple of things.

Issues we came across:

• which RP and RPV to display and which not can be only inferred at the moment through their relation to each other
  (is this RP attached as component to another RP, does the RPV of the collection RP also have RPVs as components etc)
  (these implicit rules are easy to crash and hard to fix/keep track of)
• what file repository should be attached to a RPV that is a collection?
  (in principle it should be all repositories of the RPVs attached as components, but who verifies this?)
  (automaticly filling this would again mean a graph interpretation, if an RPV has components the respositories of each RPV component should be added to the repository of the RPV collection)
  (that would also require that we allow multiple repositories to be attached, which we did not do for unambiguous references)
• should each RP and RPV collection get its own DOI / digital identifier ? on top of the normal RP and RPVs?
• who are the developers / authors for the RPV collection?
• etc.

Although adding new schemas is something that should be avoided if possible @olinux and I both tend now towards introducing dedicated schemas for Collections and CollectionVersions.

We therefore would like to bring the discussion up again and hear your thoughts?
(and also maybe your idea of what is necessary to keep as metadata information for a collection/version in comparison to a RP/RPV)

[lzehl]

If we would introduce a new schemas for Collections and CollectionVersions I would imagine the metadata model looking like this:
collection issue - v2.pdf

With the Project being optional (with possible linkages to: all ResearchProducts, ResearchProductVersions, Collections and CollectionVersions).

The CollectionVersion would also need to be specific in order to control that the components are all of the same RPV type (meaning there would be a DatasetCollectionVersion, ModelCollectionVersion, etc).

What attributes/properties need to be captured in Collection and the CollectionVersions ?
Suggestions for Collection:

1. fullName (required, count: 1)
2. description (required, count: 1)
3. digitalIdentifier (optional, count: 1)
4. hasVersion (required, count: 1-N; »»CollectionVersion)

Suggestion for CollectionVersion (extended to: DatasetCollectionVersion, ModelCollectionVersion, etc)

1. fullName (optional, count: 1)
2. description (optional, count: 1)
3. versionInnovation (optional, count: 1)
4. digitalIdentifier (optional, count: 1)
   extended by:
5. hasComponent (required, count: 1-N; either »»DatasetVersion, »»ModelVersion, or etc)

What do you think?

[lzehl]

UPDATE: I will delete the "hasComponent" properties from RP and RPV until we reach a verdict considering how we want to handle research product collections.

At everyone: Please continue collecting feedback / concrete suggestions / use cases in this issue so that we will soon find a solution that will fit all our needs for openMINDS.

[UlrikeS91]

@lzehl this seems also solved. Should we close it?

[lzehl]

@UlrikeS91 this is not solved yet. We postponed the discussion and implementation around Collections. The PR was related, but did not solve the issue. We need to keep this open, and eventually get back to this when we have more time.

[lzehl]

UPDATE: the "hasComponent" property is deleted from all RPs and RPVs until we reach a verdict considering how we want to handle research product collections.

The few Software cases within the new EBRAINS KG v3 which already used this property are saved and can be reintegrated once we decide for a way of properly handling research product collections.