Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rediscuss direction of link between ResearchProduct and ResearchProductVersion #515

Open
apdavison opened this issue Oct 16, 2024 · 3 comments
Assignees
Labels
major update large workload or major update needed to complete request any request or update for schemas

Comments

@apdavison
Copy link
Member

I would like to propose removing the property "hasVersion" from ResearchProduct and adding "isVersionOf" (or some similar name) to ResearchProductVersion**.

The reason is that with the current system, to add a new RPV requires a user to have write permissions for both the RPV and the RP, whereas if we reverse the direction, the user only needs to have write permissions for the RPV. The same goes when deleting a RPV.

In an EBRAINS context, this situation often arises when adding a new RPV (in a collab space) to an already-released RP (in a curator-only space), particularly for Models and LivePapers. The logic needed to manage all the possible situations, juggling a user KG client and a service client, gets very complicated. It would be greatly simplified if the link direction were reversed.

**(we might want to consider renaming "isNewVersionOf" and "isAlternativeVersionOf" at the same time, to avoid confusion, e.g. "isNewerThan" and "isAlternativeTo")

@apdavison apdavison added request any request or update for schemas major update large workload or major update needed to complete labels Oct 16, 2024
@lzehl
Copy link
Member

lzehl commented Jan 15, 2025

@apdavison turning around the linkage between RPs and RPVs makes sense to me. Not sure why we did not set it up that way in the first place. We should re-discuss in this context again how to set up DOIs for the RPs and the inheritance rules between RPs and RPVs.

However, I think "isNewerThan" and "isAlternativeTo" are more confusing for relations between RPVs than "isNewVersionOf" and "isAlternativeVersionOf". For the latter it is always required to have editing writes on all alternative versions (I don't think there is a way around this).

@lzehl
Copy link
Member

lzehl commented Jan 20, 2025

Let's have a look DataCite again (but I'm okay with what @apdavison suggested after the explanation)
https://datacite-metadata-schema.readthedocs.io/en/4.6/appendices/appendix-1/relationType/

@lzehl lzehl self-assigned this Jan 20, 2025
@lzehl
Copy link
Member

lzehl commented Jan 20, 2025

General discuss if version relations should be located in their own schema.

TODO 1:

  • RPV/isVersionOf -> RP (instead of RP -> RPVs)

TODO 2:

  • isNewerThan isSuccessorOf (isNewVersionOf) -> RPV (1)
  • isVariantOf (isAlternativeVersionOf) -> RPV (N) [closer to datacite isVariantFormOf]
    (to be further discussed)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
major update large workload or major update needed to complete request any request or update for schemas
Projects
None yet
Development

No branches or pull requests

2 participants