More "digitalIdentifier" options for DatasetVersions

[lzehl]

adding https://openminds.ebrains.eu/core/IdentifiersDotOrgID as option for digitalIdentifier in DatasetVersion

(not sure if we can assume that for DS as well, because I'm uncertain if Identifier.org, supports the concept of identifier versioning)

[lzehl]

@apdavison if you can it would be great if you could take this review over from Oli. I think he's too busy at the moment.

[UlrikeS91]

I can review it. Is it a question of whether it should be an option on the dataset version or just reviewing the changes?

[lzehl]

@UlrikeS91 could you check if Identifier.org would make sense on the DS too?

[UlrikeS91]

I've got a few questions:

1. In which context was the IdentifiersDotOrgID schema introduced? I cannot find any schema that actually links to it.
2. Was there any specific use case that would justify adding it for DSV? It's a very large registry, so it's likely that it will be useful and valid to add to DSV, but it would make the decision a lot easier if a use case already existed.
3. Whether or not this will be added to DSV, I would argue that it absolutely should be an option for model versions since it is a consistent access point to modelDB entries (https://registry.identifiers.org/registry/modeldb) or neuroMorpho.org (https://registry.identifiers.org/registry/neuromorpho).

From your original text, you wondered about whether or not it supports the "concept of identifier versioning". I think the registry itself may not, but if the resource it links to does, it should also reflect that. It seems to be an alternative access to a specific entry from a specific resource. If each version in the original resource has it's own entry, then it's no problem. But if not, I don't know how to handle this.

Based on this, @apdavison do you think it would make sense to have it as an option for model versions?

For DSV, unless there is a specific use case, I think we should maybe wait with adding it as an option. This would allow so many things that we cannot control or be sure are good identifiers in the end. When a good use case comes up, and we agree that this is the only way to add an ID, we can revisit this.

[lzehl]

@UlrikeS91

to 1) this exactly what this PR for (connecting the schema to at least one other schema in core)

to 2) EBRAINS use case that brought this up were connected to Neurovault data publications: PR for adding the PID was raised at the same time at this one, but this one got stuck

to 3) up to @apdavison ; from my side of course can this be added to whatever we see fit. Question: should we not rather introduce categories of PIDs for the different RPs/RPVs to more fluently add new PIDs when needed? @olinux would that be dynamically adopted in the KG system?