[MagmaFusion] Récupération des documents liés aux Sims suite au changement dans le modèle de BDD

[GtanSndil]

@ChristopheYon
Corrections réalisées sur operations/rappportQualite/{id} :

• le sims 2179 et sa rubrique S.10.6 :
  Actuellement cette rubrique est absente quand on lance le end-point sur la base de gestion. Cela est dû au fait que les requêtes viennent de Metadata-Api et donc avec du id.insee.fr dedans (par ex BIND(IRI(CONCAT("http://id.insee.fr/codes/langue/", ?LANG)) AS ?langueURI))
  Actuellement quand on lance le end-point sur la base de diffusion, on a Documents: [ ]
  Avec le correctif : la rubrique apparaît 1 fois, que ce soit côté Gestion ou côté Diffusion, avec 4 documents
• le sims 2226 et sa rubrique S.3.2 :
  Actuellement la rubrique est absente côté Gestion, et est visible côté diffusion (normal car Catherine ne l'a pas publié donc le rapport n'a pas été modifié), 4 fois
  Avec le correctif : la rubrique apparaît 2 fois, que ce soit côté Gestion ou côté Diffusion
• sims 1979 et sa rubrique S.10.6 :
  Actuellement, son document de label en français "Note méthodologique EEC juillet 2021" ressort deux fois
  Avec le correctif : il ne ressort plus qu'une fois

Quand la recette sera OK, on corrigera côté Metadata-API

A parte : Anomalie en base ?
En base de diffusion, pour le rapport 1979, la rubrique I.18.7 ressort 4 fois de la requête https://api-rmes-magma-fusion.developpement.insee.fr/operations/rapportQualite/1979.
En base, je vois par exemple qu'il y a deux lignes http://id.insee.fr/qualite/attribut/1979/I.18.7/text rdf:value mais avec un objet différent (textes équivalents mais l'un avec des blancs, l'autre sans blanc). En tout cas pour cet exemple, on n'a pas ce doublon en base de gestion.

[ChristopheYon]

Pour http://id.insee.fr/qualite/attribut/1979/I.18.7/text et http://id.insee.fr/qualite/attribut/1979/I.18.7/texte c'est normal, ce sont les deux ressources représentant la valeur de la rubrique en anglais et en français (si on devait refaire, on ne referait pas comme ça mais pour l'instant, c'est comme ça que ça marche).
Ensuite la valeur principale d'un champ texte enrichi est désormais du markdown dans la propriété rdf:value. C'est la seule qu'on a dans la base de gestion. Mais pour permettre la survie de Metadata, on a ajouté un insee:html où le markdown est transformé en HTML. Et effectivement il semble doublonné dans la base de dev (une fois avec le contenu HTML et une fois avec le contenu markdown), ce qui explique sans doute le problème dans l'API. Cela vient sans doute d'un problème au moment du passage du script de reprise des données.
Je viens de republier le rapport qualité en question, cela supprime le doublon dans la base et par suite dans l'API.

[CatherineGoillot]

Test : KO
Tests effectués sur le sims 2292 de la série s2288 : documents dans la rubrique S.3.2 et liens dans la rubriques S.3.6

• Dans API Metadata : les documents et les liens n'apparaissent.
• Dans Magma fusion/Gestion et fusion/diffusion : les documents et liens apparaissent. Pas dans l'ordre de Bauhaus mais on les a, même quand on supprime docs et liens et qu'on change l'ordre.

[GtanSndil]

@CatherineGoillot si je comprends bien , le test est OK côté Magma Fusion ?
j'attendais que cela soit le cas avant de corriger Metadata-API. Tu me confirmes que c'est tout bon côté MagmaFusion du coup ?

[CatherineGoillot]

Oui c'est bon pour MagmaFusion.
Une question : tu peux jouer sur l'ordre des documents ou liens dans MagmaFusion, c'est à dire qu'ils sortent tels qu'ils apparaissent dans bauhaus ou pas ?

[GtanSndil]

2 requêtes ont été modifiées : getDocumentationRubricsByIdSimsQuery.ftlh et
getDocumentsQueryByIdSimsIdRubric.ftlh

[GtanSndil]

@ChristopheYon je viens de voir une coquille dans la requête getDocumentationRubricsByIdSimsQuery :
?textLg1 dcterms:language ?langEn .
au lieu de
?textLg2 dcterms:language ?langEn .
Je fais un fix

[ChristopheYon]

Pour gérer l'ordre, on peut faire un truc du genre :

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX insee: <http://rdf.insee.fr/def/base#>
# La position dans la liste est le nombre d'éléments intermédiaires entre le début de la liste et l'élément courant
SELECT ?startList ?element ?doc (COUNT(DISTINCT ?intermediate) AS ?position)
WHERE {
	# Récupération du début de la liste
	<http://bauhaus/qualite/attribut/1813/I.18.12/texte> insee:additionalMaterial ?startList .
	# Petit hack parce que dans l'exemple, on a aussi les documents directement reliés à la rubrique par insee:additionalMaterial, donc on ne garde que le noeud vide 
	FILTER(isBlank(?startList))
	# On récupère tous les éléments de la liste
	?startList rdf:rest* ?element .
	# On récupère tous les éléments intermédiaires entre le premier élément de la liste et l'élément courant
	?startList rdf:rest* ?intermediate . ?intermediate rdf:rest* ?element .
	# Et tant qu'à faire, on récupère le document associé à l'élément de la liste
	?element rdf:first ?doc .
}
# On groupe par élément de la liste
GROUP BY ?startList ?element ?doc 
ORDER BY ?position

(à adapter dans la requête réelle)

[GtanSndil]

@GtanSndil reste à gérer l'ordre des documents

[GtanSndil]

@GtanSndil modif à répercuter dans Metadata-API quand la recette sera OK côté MagmaFusion

[GtanSndil]

@CatherineGoillot @ChristopheYon
Pour info, le problème des documents absents en diffusion quand ils sont accompagnés de texte était déjà présent en prod (exemple : rubriques S.3.2 et S.6.1 du sims 2230) C'est corrigé. Pour le sims 2230, on récupère bien dans l'ordre les 6 documents de la rubrique S.3.2, et le document et le lien de la rubrique S.6.1 (par contre, doc puis lien en diffusion, mais lien puis document en gestion)

[GtanSndil]

@CatherineGoillot @ChristopheYon
Le problème de certaines rubriques absentes en gestion était lié au fait que la requête faisait un filtre sur dcterms:language http://id.insee.fr/codes/langue/fr, alors qu'il faudrait http://bauhaus/codes/langue/fr => j'ai paramétré selon qu'on tape sur la base de diffusion ou la base de gestion