Lien de téléchargement pour les Lieux

[tfrancart]

Voir le commentaire original à #73 (comment)

Pour les lieux, il faudrait aussi afficher le lien de téléchargement RDF, comme pour cette notice d'agent

[tfrancart]

@florenceclavaud : le problème est que la structure des répertoires actuelle nous empèche de générer le lien vers le fichier. Impossible de savoir que FRAN_RI_025-d3nz8cnn4x-19o7h8gh730c3 est dans le sous-dossier lieux-de-paris/voies.

[florenceclavaud]

Ah oui, mince.

Pour régler le problème, comme nous connaissons l'organisation des répertoires de sortie, nous pouvons facilement ajouter, lors de la génération du RDF, un dcat:downloadURL au rico:Instantiation qui décrit la version RDF du rico:Record ; ça donnerait par exemple :

<rico:hasOrHadDigitalInstantiation>
         <rico:Instantiation rdf:about="instantiation/FRAN_RI_005-d-13p814kqj--yf15boemr1ys">
            <rico:isOrWasDigitalInstantiationOf rdf:resource="record/FRAN_RI_005-d-13p814kqj--yf15boemr1ys"/>
            <rico:isOrWasDerivedFromInstantiation rdf:resource="instantiation/FRAN_RI_005-d-13p814kqj--yf15boemr1ys-src"/>
            <dc:description xml:lang="fr">Version RDF de la notice, conforme à
                                    RiC-O 1.1, résultant de l'enrichissement et de la
                                    restructuration de la notice source.</dc:description>
            <dc:format xml:lang="en">rdf+xml</dc:format>
            <rico:identifier>FRAN_Place_RI_005-d-13p814kqj--yf15boemr1ys.rdf</rico:identifier>
             <dcat:downloadURL rdf:resource="https://raw.githubusercontent.com/ArchivesNationalesFR/Referentiels/refs/heads/main/lieux/rdf/amenagements-et-constructions/FRAN_Place_RI_005-d-13p814kqj--yf15boemr1ys.rdf"/>
            <rico:hasOrHadHolder rdf:resource="agent/005061"/>
         </rico:Instantiation>
</rico:hasOrHadDigitalInstantiation>

On l'a déjà fait pour les vocabulaires contrôlés. Et on pourrait aussi le faire pour les agents, ce qui serait pratique une fois réorganisés leurs dossiers (voir mon commentaire ici)

Par contre là on donne l'URL du fichier dans le dépôt GitHub des référentiels. Est-ce qu'il ne faudrait pas plus logiquement donner l'URL du fichier qui sera ou est déposé sur le serveur ?

Qu'est-ce que tu en penses ?

[tfrancart]

Je ne crois pas que ce soit utile. Pour la négociation de contenu voilà ce que je propose:

• On scanne toute la hiérarchie des répertoires du dépôt de référentiel
• Pour chaque fichier, on le recopie dans le dossier final du site généré, donc soit ̀entities/agent/xxxx soit entities/place/xxxx. Cette recopie serait hautement simplifiée si les noms de fichier correspondait exactement aux URI (donc par exemple sans le "Agent_" dedans, ou sans le "Place_") - penses-tu que ce soit possible pour vous ? ce serait en tous cas plus cohérent.
• Ainsi dans la négociation de contenu, aussi bien que pour le lien de téléchargement, on redirige simplement vers ce fichier

Comme ça vous pouvez garder la structure de répertoire que vous voulez (et la faire changer si vous voulez), sans impacter les fichiers de donnée. Ce serait juste mieux si les noms de fichiers correspondaient exactement aux URI.

[florenceclavaud]

J'ai déjà en fait ajouté la ligne dcat:downloadURL dans les notices d'agents sur ma machine, ce n'est pas compliqué.
Je peux revenir en arrière facilement.

On peut aussi modifier les noms de fichiers maintenant et tout régénérer ; il faudra juste noter que pour les notices de producteurs ça fait encore une modif. à prévoir par la suite pour RiC-O Converter.

Si les fichiers ont des noms différents des URI, c'était pour garder le nom abrégé de l'institution ('FRAN', comme pour tous les fichiers que les AnF produisent) et le type d'entité dans le nom de fichier (donc l'URI 'https://rdf.archives-nationales.culture.gouv.fr/agent/1234546' devenait 'FRAN_Agent_123456.rdf'). Plus, parfois, le nom du fichier source (par ex. FRAN_RI_012.xml).
Si on garde le préfixe 'FRAN', ça vous gêne ?

Donc

• pour l'agent agent/123456, 'FRAN_Agent_123456.rdf' deviendrait 'FRAN_123456.rdf'. On n'a pas d'équivalence stricte entre URI et nom de fichier ici. Ca irait quand même ?
• pour l'agent agent/FRAN_RI_012-d699mu0lwwu-jtit5df8fqmn, 'FRAN_Agent_RI_012-d699mu0lwwu-jtit5df8fqmn.rdf' deviendrait 'FRAN_RI_012-d699mu0lwwu-jtit5df8fqmn.rdf'

En tout cas personnellement je préfère garder l'organisation arborescente des fichiers dans le dépôt des référentiels, donc dans les releases. Ces fichiers ont des sources différentes et les processus de génération sont différents ; leur organisation a un sens (pour les lieux par exemple en interne aux AnF on distingue depuis le début les lieux dans Paris des autres ; ou encore on distingue les communes des départements des lieux-dits des pays etc.), et nous aide dans leur gestion.

Comment fait-on pour les vocabulaires ? L'idéal serait de laisser en l'état ('FRAN_RI_011_activityTypes.rdf' et FRAN_placeTypes.rdf) car là aussi c'est plus facile pour nous d'avoir le nom de la classe et l'indication du fichier source dans le nom de fichier.

Il faudrait qu'on décide assez rapidement, j'ai un peu de temps ces jours-ci pour travailler quasiment en continu sur ces données, mais ensuite ce sera beaucoup plus compliqué ;-)

[tfrancart]

Bon, ne fait rien sur les noms de fichiers, on se débrouillera.

[florenceclavaud]

Tous les fichiers de lieux et d'agents ont maintenant un dcat:downloadURL qui donne (dans un rico:Instantiation, celui qui décrit le fichier RDf et est dérivé du fichier source) le chemin complet d'accès au fichier RDF dans la branche main.