Consolidation du schéma YAML

[alhyss]

Ci-après plusieurs questions ou observations sur le schéma ecospheres_dataset_schema.yaml, dans l'état où il se trouve actuellement sur la branche de référence spatial-for-merge. Tous ces points doivent être clarifiés - et les correctifs induits apportés - pour que le schéma puisse être considéré comme fonctionnel.

1. Pourquoi restait-t-il un subfield theme sur category et un subfield label sur territory ? N'avions-nous pas dit que nous ne stockions que les URI, pas les libellés ?
   Pour information, je les ai supprimés du schéma dans le commit de fusion des branches.
2. territory_full n'était-il pas supposé disparaître en même temps que subcategory, l'information pouvant être obtenue en interrogeant la table ecospheres_territory_hierarchy ?
3. J'ai ajouté les champs status et owner_org dans mes derniers commits. status est certainement à ajouter au mapping DCAT. Pour owner_org (= le champ natif de CKAN qui définit l'organisation à laquelle est rattaché le jeu de données) je suis étonnée que ça ait fonctionné sans. J'ai mis display_snippet: null à défaut d'autre idée, mais je vois aussi preset: dataset_organization dans les exemples de ckanext-scheming... J'imagine qu'il y a un validateur derrière, et ce ne serait peut-être pas un mal ?
4. La version de la branche develop a ajouté un subfield uri sur une partie des champs admettant des valeurs multiples (propriété multiple_values valant True), qu'en est-il des autres ? Est-ce qu'il ne pose pas de problème d'avoir une liste de valeurs dans leur cas ?
   Concerne le subfield url de page, les champs url et download_url des ressources, le subfield type de licenses.

[asboukerram]

1- Ok pour la suppression, c'était un oubli
2- Donc on peut supprimer ce champ
3- Dans ce cas, il faudrait que tu modifies le moissonnage et l'exposition des données
4- peut-on voir plus en détails ce point ensemble

[alhyss]

@asboukerram

2- Donc on peut supprimer ce champ

Pas de changement à faire au niveau de l'interface front/back ? Le champ territory_full n'est pas utilisé actuellement ? Je me charge de le retirer du schéma, mais j'aimerais être sûre que les effets éventuels sont anticipés.

3- Dans ce cas, il faudrait que tu modifies le moissonnage et l'exposition des données

Je note qu'il y a un sujet de qui fait quoi sur ce point. Est-ce que vous avez un avis sur le snippet/preset à utiliser pour owner_org ?

4- peut-on voir plus en détails ce point ensemble

Oui.

[asboukerram]

Ci-après plusieurs questions ou observations sur le schéma ecospheres_dataset_schema.yaml, dans l'état où il se trouve actuellement sur la branche de référence spatial-for-merge. Tous ces points doivent être clarifiés - et les correctifs induits apportés - pour que le schéma puisse être considéré comme fonctionnel.

1- Pourquoi restait-t-il un subfield theme sur category et un subfield label sur territory ? N'avions-nous pas dit que nous ne stockions que les URI, pas les libellés ?
Pour information, je les ai supprimés du schéma dans le commit de fusion des branches.

-  Ces champs là été utilisés pour l’indexation, lors de notre réunion fin septembre, on avait convenu de ne plus indexer ces champs là mais à la place on indexait les uris. On avait convenu de les laisser vu qu'il n'avaient aucune incidence sur le fonctionnement
- Pour remarque, si tu supprime un champ, il faut imperativement tester le code 

2- territory_full n'était-il pas supposé disparaître en même temps que subcategory, l'information pouvant être obtenue en interrogeant la table ecospheres_territory_hierarchy ?

S'il était supposé disparaitre, je ne suis pas au courant, on peut le supprimer du schema sans incidence.

3- J'ai ajouté les champs status et owner_org dans mes derniers commits. status est certainement à ajouter au mapping DCAT. Pour owner_org (= le champ natif de CKAN qui définit l'organisation à laquelle est rattaché le jeu de données) je suis étonnée que ça ait fonctionné sans. J'ai mis display_snippet: null à défaut d'autre idée, mais je vois aussi preset: dataset_organization dans les exemples de ckanext-scheming... J'imagine qu'il y a un validateur derrière, et ce ne serait peut-être pas un mal ?

Je ne saurai te donner mon avis sur ce sujet.
Par contre, il faudra que tu rajoutes le mapping lors de moissonnage et de l'exposition

4- La version de la branche develop a ajouté un subfield uri sur une partie des champs admettant des valeurs multiples (propriété multiple_values valant True), qu'en est-il des autres ? Est-ce qu'il ne pose pas de problème d'avoir une liste de valeurs dans leur cas ?
Concerne le subfield url de page, les champs url et download_url des ressources, le subfield type de licenses.

Est-ce que tu peux être plus précise.
j'ai comparé avec la branch spatial, il me semble qu'il ait peu de differences entre les deux branches concernant ce point.