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

Feature Request: CVocConf customized at Dataverse collection level #11056

Open
luddaniel opened this issue Nov 27, 2024 · 0 comments
Open

Feature Request: CVocConf customized at Dataverse collection level #11056

luddaniel opened this issue Nov 27, 2024 · 0 comments
Labels
Type: Feature a feature request

Comments

@luddaniel
Copy link
Contributor

For the sake of https://entrepot.recherche.data.gouv.fr/ needs, we imagined being able to have different configuration depending on the Dataverse collection you are working on.

For example, with keyword configuration using SKOMOS :

  • in Dataverse collection A I want 3 configured vocabularies
  • in Dataverse collection B I want 2 configured vocabulatires
  • in Dataverse collection C child of A I want no configuration on keyword
  • Dataverse collection D using not SKOMOS but Ontoportal on the same termUri field aka keyword.

Considering the need to customize many Dataverse collections, vocabularies, inheritance or not, different service for the same termUri field we had this simple idea : move the :CVocConf setting to a cvocconf column in database table dataverse (credits to @jeromeroucou).

The content would give the rules :

  1. cvocconf should be apply to associated Dataverse collection and Dataverse sub-collections
  2. cvocconf empty or null should mean no configuration unless a parent configuration is effective (rule n°1)
  3. empty json object {} would mean intention to have no configuration for the Dataverse collection and to not use parent effective configuration (variation to rule n°2)

In advanced search, same rules should be apply. Another idea could be to have no configuration at parent level if one descendant have a different configuration or absence of configuration is set. (rule n°3).

Technical aspects:

  • Remove :CVocConf setting related code with a removal in a flyway script
  • Add the new cvocconf column (same sql type as :CVocConf) and the related code including the flyway script (existing :CVocConf should be moved to root Dataverse collection)
  • DatasetFieldServiceBean.getCvocConf() should handle Dataverse collection identifier as new parameter and all referencies should be updated according to local use
  • Content rules should be handled in DatasetFieldServiceBean.getCvocConf()
  • UT and IT should be updated
  • Add new API endpoint to add a CVocConf on a Dataverse collection should be created in /api/admin scope as POST accepting json body (superuser + localhost restrictions)
  • Add new API endpoint to get the CVocConf of a Dataverse collection (same restrictions), should contain both the current configuration and the effective configuration of a parent if qualified (rule n°2)
  • Maybe a cache mechanism should be considered

@qqmyers @pdurbin depending on your views, we (@jeromeroucou @stevenferey @luddaniel) could develop a part or most of it, anyhow, no development should start before a agreement on the specifications.

If any community member is interested in the feature in any way shape or form, please leave a quick comment below.
Best regards

Tagging our Product Owner: @DS-INRAE

@luddaniel luddaniel added the Type: Feature a feature request label Nov 27, 2024
@luddaniel luddaniel moved this to 🕒 Planned Development in Recherche Data Gouv Nov 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Feature a feature request
Projects
Status: 🕒 Planned Development
Development

No branches or pull requests

1 participant