You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 :
cvocconf should be apply to associated Dataverse collection and Dataverse sub-collections
cvocconf empty or null should mean no configuration unless a parent configuration is effective (rule n°1)
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)
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 :
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 acvocconf
column in database tabledataverse
(credits to @jeromeroucou).The content would give the rules :
empty
ornull
should mean no configuration unless a parent configuration is effective (rule n°1){}
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:
:CVocConf
setting related code with a removal in a flyway scriptcvocconf
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 useDatasetFieldServiceBean.getCvocConf()
CVocConf
on a Dataverse collection should be created in/api/admin
scope as POST accepting json body (superuser + localhost restrictions)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)@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
The text was updated successfully, but these errors were encountered: