publicarchi / prosopo

Prosopographie de l’architecture publique en France au XIXe siècle

prosopo

Prosopographie de l’architecture publique au XIXe siècle

prosopo's Issues

Envoyer les dates des réorganisations du Conseil

Prototyper une visualisation chronologique

Adopter les bonnes pratiques proposées par le W3C

Créer une entrée par bonne pratique et tester leur mise en œuvre
https://www.w3.org/TR/dwbp/

Déterminer un format pivot pour la visualisation

Les données du répertoire prosopographique sont structurées en XML-TEI. Si la visualisation est réalisée avec JavaScript, il peut être utile de faire reposer cette visualisation sur un format standardisé. L’avantage d’une telle solution serait de pouvoir par la suite utiliser des visualisations déjà faites.

Plusieurs standards ont été envisagés pour les données chronologiques.

• The Timeline consortium plusieurs exemples d’implémentation anciens

• ChronoJSON standard en cours de développement, utilisé par NodeGoat

• Topotime (GitHub) et Topotime (Stanford), Hestia mais ancien et plus lié à la géographie

• Voir si les systèmes de visualisation de chronologie les plus connus sont compatibles avec certains de ces standards

• Explorer ces standards et leurs implémentations

• Rechercher des exemples d’implémentation de ChronoJSON

Créer les notices XML-EAC pour le CBC

Relire la prosopographie

La prosopographie des membres du Conseil des bâtiments civils contient des courtes biographies des membres du Conseil dont il faut faire la relecture pour la correction syntaxique et orthographique. Les fiches sont structurées en XML-TEI. Il faut donc les ouvrir avec Oxygen XML editor et travailler en mode auteur.

cf. le fichier cbc.tei.xml dans https://github.com/publicarchi/prosopo

Ne pas verser les modules nodes dans le repo

Salut Lena,

Je viens de recevoir une alerte de sécurité de GitHub concernant ce repo. C’est sans doute lié au fait qu’il contient une tonne de modules nodeJS.

C’est une mauvaise pratique que de verser du code dont on n’est pas l’auteur dans un repo. Pour une application node on utilise généralement un fichier de config avec un outil de déploiement pour installer les modules nécessaires, mais ceux-ci ne doivent pas figurer dans l’historique du répertoire. Sinon, on utilise des sous-modules git.

L’idée est d’éviter d’avoir un historique chargé de code inutile et d’autre part de pouvoir faire les mises à jour lorsque nécessaire.

La prochaine fois que l’on travaille ensemble, je vais réinstaller le repo et on règlera ces détails. On peut aussi utiliser une branche.

Amitiés,
Emmanuel

Faire un export des données vers un format pivot

En fonction des résultats de #3 et #4

Préciser les années pour les auditeurs

Certaines dates d’auditeurs ne sont pas renseignées : Ballu, Baltard