Open lzehl opened 3 years ago
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) 3) digitalIdentifier (optional, count: 1) extended by: 4) hasComponent (required, count: 1-N; either »»DatasetVersion, »»ModelVersion, or etc)
What do you think?
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.
@lzehl this seems also solved. Should we close it?
@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.
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.
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:
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)