Skip to content

Latest commit

 

History

History
332 lines (229 loc) · 19 KB

File metadata and controls

332 lines (229 loc) · 19 KB
date 2017-06-30
tags cr, tei, corpus, édition critique

Atelier Cahier, Jour 2

Le roman des Morand

http://morand.ens-lyon.fr

Anne Verjus

Création de l’édition en un an. Description des entités nommées. Aspects du fort intérieur. Problèmes de lecture, etc.

Choix du CMS Omeka suite à une discussion avec Emmanuelle Morlock :

  • faciliter de mise en place des parcours
  • mise en place rapide
  • exploiter l’encodage (TEI display, plus maintenu)

Production de la transcription Réalisée avec Word, stylage pour les éléments à encoder. Renvoi à des formes normalisées grace à des notification des styles dans MSWord. Récupération du XML. Transformation pour transformation en TEI. Un document par lettre.

Méthode efficace qui s’est très vite avérée chronophage car à chaque modification du fichier, besoin de refaire la transformation.

Pour la seconde vague, formation individuelle à l’encodage. Mise en place d’un formulaire de saisi pour faciliter l’appropriation de la TEI (vue auteur de Oxygen).

Omeka, utilisation de TEI display et DropBox

DropBox pour l’import en masse Autoriser l’extension XML dans les paramètres d’împort de DropBox. Création automatique d’item pour chaque fichier. Mais besoin de retourner dans les documents pour créer les métadonnées.

Adaptation de la feuille de style, création d’un thème.

Simplicité et rapidité d’installation. Offre de plugins, import en masse et possibilité de publier des fichiers encodés. Adaptibilité, avec création simple de thèmes.

Pour l’exposition, un corpus homogène de lettre. Champs qui s’imposent naturellement expéditeurs, destinataires, etc. Utilité de filtres à facettes, possibilités de visualisation géolocalisation, chronologie.

Mais les métadonnées du header TEI n’étaient pas celles qui se retrouvaient pour les items d’Omeka. Les index trop limités. Afin d’obtenir des index plus personnalisés, construit des feuilles de styles XSLT, et requête en XQuery. = génération d’index de lieux d’écriture, d’expéditeurs, etc. test visualisation avec plugins Omeka. Souvent trop rigide, peu de configurations possibles notamment affichage sur une carte en fonction recherche.

Pas très envie de modifier code des plugins par soucis de maintenance. Pb coordonnées géographiques (mais obligé de le faire item par item, pas de modification par lot possible).

Du côté de la recherche ce que proposait Omeka n’était pas adaptées. Seulement dans les métadonnées des items Omeka, mais pas dans la TEI proprement dit. Pour la recherche à facettes, il aurait fallu à l’époque pouvoir disposer de SolR Search (aujourd’hui plus le cas). Pb maintenance, etc.

Aujourd’hui plugin facet by metadata et seach in file. Choisi d’utiliser Simile exhibit. Une réalisation du MIT simple et facile à mettre en œuvre. Propose des fonctionnalités de recherche simple avec des filtres et offre des possibilités de visualisation de données (timeline, tableaux triables). Paramétrage simple, bonne documentation en wiki.

Besoin de 2 fichiers Un fichier de données au format JSON Un fichier html pour paramétrer l’affichage.

Un service de conversion en ligne (Babel). Export des items directement dans le format également possible. Items, types, properties, property values, value types.

Positionnement des lettres sur une timeline. Chercheur qui a proposé d’autres événements contextuels.

Html Head qui appelle l’API, lien au format de données JSON. Paramétrage affichage avec attributs préfixés avec ex pour exhibit. Trois composantes : les vues (grand cadre tableau, vignettes, etc.), paramétrage un seul item, et les facettes. Précise aussi les sous-ensembles de données auxquels s’intéresse.

Cartes et timeline idem Précise pour ces vues les coders qui permettent d’indiquer comment différencier les différents points (couleur) et sur quels critères repose la différentiation, et style d’affichage.

Facettes, pour chaque critère de tri, définit sur quel champ repose, etc. Facettes intervales, recherche plein-texte.

Simile exhibit a été un outil très simple à mettre en œuvre et très ludique. Bémol lié au temps de chargement des pages et au fait que les URL sont inchangées (pb de navigation ou d’historique).

D’autres points d’accès proposés Index, nombre de citation et formes.

Plugin simplepage dont a trouvé que la capacité était limité. Coupage de documents, etc. Aurait peut-être pu utiliser exhibit builder.

Nuage de mots-clefs proposé par Omeka. Anne Verjus a fourni dans le back-office des tags dans chaque lettre.

Changements de version fréquent. Dépendance aux plugins et à leur suivi selon les versions. Pas passé à la nouvelle version d’Omeka car pas de portage de TEI display. Problèmes de sécurité.

Perspectives. Pour la V2 intention de présenter SynopsX un kit de publication tout XML développé au sein de l’atelier des humanités numériques de Lyon. Rester dans le même format du début à la fin et réduire le nombre de transformations de données. Perspective qui a conduit à intégrer ensemble des données en XML-TEI.


Richard Walter

Présentation et formation au logicel Omeka.

Historique d’Omeka. Dans la présentation tiendra un discours différent. Plate-forme édition XML-TEI Telma. Politique scientifique. Item, génétique textuelle.

Nombreux fonds documentaires, et de fonds d’archives à publier. Pas une optique d’édition, mais plutôt de diffusion et d’archivage de données. Pour cela utilise Omeka.

Toujours important de voir ce que l’on utilise, d’où cela vient, et pourquoi.

Présentation du projet Omeka

Un logiciel produit pour gérer des bibliothèques numériques, pas un site de publication de corpus. Sous licence libre, publié par le CHNM qui est également à l’origine de Zotero. Plusieurs centaine de projets qui utilisent Omeka. De plus en plus nombreuses utilisations en France, même Europeana l’utilise pour ses expositions virtuelles.

Projet débuté en 2009. Fondation Mellon décidé de soutenir le projet. Donc financement et informaticiens qui font du support.

Un logiciel réalisé à l’intersection de plusieurs besoins et de plusieurs professions. Un logiciel en environnement LAMP. Contrairement à d’autres CMS comme SPIP ou Drupal, très simple et bien structuré côté base de données.

Plusieurs besoins

  • diffuser de l’information (existence de CMS pour diffusion de contenu)
  • gérer des fonds d’archives, des bibliothèques, répertoire de données (fédora, dc space, etc.)
  • faire des expositions

Trois technologies différentes, Omeka va tenter de faire un peu tout cela, mais pas tout. Dans l’écosystème des utilisateurs, des gens qui ont besoin de publier du contenu comme les chercheurs, les institutions qui ont besoin de publier des contenus, et organisateurs d’exposition. Collaboré dès 2006 au projet.

Un projet conçu pour des nons spécialistes. Documentation simple sans jargon. Idée de se concentrer sur la publication de contenu, avec du clic bouton. Logique web 2.0 adapté au monde universitaire pour favoriser son interaction. Proposent des interfaces de base sous forme de templates pour faciliter la personnalisation.

Développement robuste open source, avec grosse communauté utilisteur qui assure stabilité.

Un système très modulaire, noyau léger auquel vient ensuite associer des fonctions. Possibilité d’ajout de fonctionnalités. Permet aisance en terme de gestion. Un site wisiwig, possibilité de créer ses propres formulaires, propres champs avec une interface graphique. Permet de montrer tout de suite des choses.

WISIWIG gros avantage pas besoin d’apprendre le langage Gros inconvénient, si change d’outil ne sait plus rien faire.

Compte-tenu ancrage Mellon, Dublin-Core, web sémantique Facilité importation de contenus en masse. Possibilité pour laisser le chercheur créer lui-même sa propre exposition de contenus avec exhibit builder (bien sûr un format imposé, peut s’avérer simpliste mais souvent couvre énormément de besoin avec des outils aussi simples).

Exemples de site

Mame et fils, sur éditeur de littérature de jeunesse. Fait à Tours. Un inconvénient possible, car reconnaît tout de suite que produit par Omeka. Principe de construction de page qui ressemble à un CMS classique. Barre outils, etc. Omeka travaille à partir de notices structurées. Omeka destiné à de la collection de notices structurées.

Albums expositions

Mutual heritage http://mutual-heritage.crevilles-dev.org Pour chaque ville une notice par bâtiment. Tout un travail documentaire de relevé de données effectué.

Les premiers socialismes http://premerssocialismes Projet d’abord réalisé par la bibliothèque de l’université de Poitiers avec Lodel. Depuis migré sur Omeka. Un avantage notable d’Omeka, facilement possible de migrer ses données de Lodel vers Omeka. Production d’une interface similaire. Recherche par facettes. Beaucoup d’index produits avec le nouveau plugin de SolR qui permet de faire de l’exposition d’index et de la recherche plein-texte dans les données des items Omeka. Pas certain qu’aille chercher dans le texte des transcriptions. Ici un site conséquent en terme de volumétrie mais avec une constitution relativement simple du point de vue des données.

Ces différents exemples montre la variété des besoins mais aussi les limites.

Dublin Core

Produit en 95 à Dublin dans l’Ohahio pour définir un tronc commun utilisable pour décrire des documents numériques. Provoqué par le gouvernement américain afin de pouvoir décrire des documents de manière simple et généraliste.

Quinzaine de descripteurs officialisés pour décrire des données. Norme internationale 2003, ISO DMCI qui s’occupe de la maintenance et ateliers de travail.

15 descripteurs que peut également raffiner.

Omeka est entièrement basé sur Dublin Core On respecte la structure DC mais chaque propriété facultative. Un format strict mais qui laisse énormément de liberté. Lorsque lance un projet, passer du temps pour définir la date de l’objet à mettre en ligne, définition des relations, des droits, etc. Un vrai travail intellectuel à produire de ce point de vue là. Selon l’usage que voudra en faire, renseignera de manière différente les même champs.

Pour Omeka en dehors de DC point de salut. Mais avantage du projet comme réalisé par des personnes issues des SHS. Possibilité simple d’enrichir la description selon ses propres besoins et aller plus loin avec de la description personnalisée. Omeka propose de le faire de manière très simple, il propose même des types de métadonnées selon le genre d’objet publié.

Fonctionnement

Philosphie générale Facilité de prise en charge, courte formation qui permet ensuite au chercheur de se débrouiller dans le tableau de bord, où peut gérer beaucoup de choses avec des formulaires. --> Pas besoin d’appeler informaticien pour créer de nouveau champs.

Par rapport à base de données MySQL où avait besoin rajouter ensemble des champs, etc. modifier les formulaires. Aujourd’hui plus besoin de le faire, le chercheur peut le faire. Permet de répondre avec souplesse aux besoins des chercheurs. = Bienfait du WISIWIG

Gestion modulaire qui permet de tester des extensions et des fonctionnalités et de les ajouter au besoin. Si n’existe pas peut créer le plugin (ici besoin informaticiens). En tous les cas beaucoup de besoin auxquels peut répondre directement.

Facilement possible de changer d’interface, de présentation, etc. Ici que sent que créé pour les sciences humaines et sociales, par les sciences humaines et sociales.

Pour l’administration propose 4 rôles

  • superadmin
  • administrateur (celui qui gère collections)
  • contributeur (pas droits de publication, peut poser pb hiérarchiques)
  • chercheur celui qui ne peut rien faire. Celui qui peut voir des contenus non publiés. Ici sans doute des limites dans la gestion des profils par défaut qui sont rudimentaires et ne correspondent pas à la gestion de projet scientifique. Un plugin qui permet d’ajouter d’autres rôles, par exemple pour créer des gestionnaires de collection.

Base de données à sauvegarder toutes les 24 heures, car beaucoup de transformations à la volée qui interviennent dans la structure de la base et peuvent générer des accidents.

Paramètres Pour Omeka, les métadonnées ce sont du Dublin Core, ensuite les items de contenu. Peut regrouper et faire du travail. Quand gère des notices DC, peut dire que date celle d’écriture, sauf que peut être pour collection, etc. Or une seule spécfication pour ça dans Omeka.

Types de contenu Plusieurs types préexistants. Permet d’autonomiser les chercheurs, ainsi produit une discussion plus intéressante avec les chercheurs plutôt que de produire du code au km.

Collections Omeka propose de rassembler les items dans des collections. Ici description avec DC également. Parfois besoin de hiérarchie, or un plugin pour les collections parentes et enfantes. Risque de compliquer la navigation, donc réfléchir.

Production de pages statiques. Possibilité de création de pages statiques très simple en passant par Dublin Core. Possibilités de description littéraire, etc. Tout a été pensé pour faire des sites facilement pour des projets qui n’ont pas une grosse informatique à disposition.

Contenus Tout contenu est une notice. Une notice DC, son propre utilisation de DC tel que défini Fichiers, et mots-clefs Selon besoins autres fonctionnalités pour géolocaliser, établir des relations entre notices, faire de la transcription, etc.

Possibilité de faire des nuages de mots-clefs. Mais un champ spécifique pas celui DC. Gestion possible des mots-clefs sur page spécifique.

Géolocalisation dans coverage de DC

Pour l’apparence du site, propose des thèmes par défaut. 18 thèmes dont 7 pour Omeka. Très aisés à programmer en PHP pour un informaticien. Possibilité de personnalisation profonde au risque d’avoir du mal à changer version. Mais toutes les personnalisations sont placées dans un répertoire disctinct. Configurations possibles du thème et des menus, via interface. Très succinte. Travail aisé pour l’informatique si maîtrise PHP et CSS.

Extensions Le « Bazar des fonctions » Tous pas recommandés. Installer une extension suffit d’avoir les accès au serveur. [pb car pas autochargement comme dans wordpress]

Scripto et teiDisplay des plugins qui ne sont plus maintenus.

Des liens vers des outils puissants. Pour adapter moteur de recherche à facettes solr, etc. Intégration R, et statistique.

Citation et exposition des données par défaut

Interopérabilité, limites. Omeka se place dans une perspective d’interopérabilité. Via un plugin Omeka propose un entrepôt OAI-PMH. Le DC permet un échange de métadonnées puissant. Le principe du protocole OAI de constituer et mettre à jour des entrepôts de sources, y compris pouvant se trouver ailleurs. Les métadonnées des données des chercheurs qui vont pouvoir être moissonnées et représentées ailleurs. Ensuite lien qui pointe vers la ressource. Pas de choses hors sol. Une initiative des années 2000 pour accroître la visibilité des contenu, et rendre possible la constitution d’entrepôts thématiques. Des fournisseurs de service qui vont intégrer les ressources dans les collecteurs.

Omeka propose un entrepôt par défaut. Pour accroître la visibilité de vos ressources, mais l’inverse peut aussi ajouter le plugin harvester pour visualiser des données d’autres sites par exemple pour faire un site portail. Aujourd’hui souvent un pré-requis dans un projet de recherche.

Il y a également une compatibilité maximale entre Omeka et Zotero car même labo à l’origine des deux projets. Il est également possible de faire des importations facilement avec l’outil CSV import, avec les notices descriptives, y compris lien du fichier (mais à condition que soient disponible sur un serveur sans mot-de-passe).

Limites d’Omeka

Certains projets que je ne fais pas avec Omeka car des limites réelles. La documentation de la version 2 présente de nombreux trous. Par contre le forum est très bien achalendé et bonne réactivité de l’équipe des développeurs d’Omeka.

Pour le niveau expert, faire attention à la documentation et à la qualité du code sur les plugins non validés. Plugins développés avec Zen framework, un environnement de travail compliqué.

Le moteur de recherche simple donne des résultats très imprécis. Au dessus d’un % de résultats affiche 0. Mieux vaut utiliser la recherche avancée.

Le paramétrage de moissonnage n’est pas paramétrable. On sent parfois que certains plugins pas tout à fait mûrs. Un atelier Omeka Geek à Paris, essaye de monter atelier d’été. Harvester fonctionne mais exige de ne pas être trop compliqué.

Possible d’avoir des versions différentes de sites, mais pas de multi-linguisme. De même dans l’Atelier essaye de développer une interface multi-lingue pour chaque page d’Omeka.

Pour la géolocalisation, par défaut propose Google map. En revanche récupère les données GPS et les place dans la base de données. Saisie sur carte google et visualisation sur Google. En étant expert, possible de récupérer données en GéoJSON et placer sur autre carte.

Autre subtilité, Omeka fait une très large utilisation d’ImageMagick, le logiciel qui permet de calculer les vignettes. Mais OVH refuse de dire où se trouve le logiciel...

Peu de granularité sur les collections malgré le plugin collections hiérarchiques. Un contenu n’est pas défaut que dans une seule collection ! L’interface utilisateur est conçue sur une logique de bibliothéconomie.

Autre limite qui peut être très ennuyeuse pour la mise à jour de contenu, visualisation dans signet séparé et interface d’administration. Pas de bouton modifier directement dans les champs du front office. Pb ergonomie.

Sur le fonds, Omeka n’est pas un CMS, ne gère pas l’actualité ou les articles. Ce n’est pas fait pour ça. Omeka est fait pour publier des notices. Ce n’est pas non plus fait pour faire de l’édition scientifique de contenus. La chaîne éditoriale d’Omeka est pour cela très réduite. Des outils adaptés qui peuvent éventuellement être correllés avec Omeka. Ne pas se tromper sur les besoins. Même si essayera d’aller assez loin dans l’édition scientifique. Mais pas fait pour faire de l’encodage TEI, etc.

Une fiche sur la plateforme Plume. https://www.projet-plume.org

Ceux qui ont popularisé Omeka en France, la bibliothèque numérique de Rennes 2. Collections numériques souvent cité.

Manuscrits francophones

Utilisation de Notix mais pas de communauté.

Mise en commun des besoins et des forces pour éditer les métadonnées des documents. Socle de description DC Transcription Représentation des processus.

Mutualisation Tour d’horizon bonnes pratiques dans le domaine du catalogage. État des lieux des normes de description des archives d’écrivain. Inspiration de différents modèles.

Consensus de bonnes pratiques : pratiques littéraires Suisse. Puis publication bonnes pratiques BNF inspirées par EAD.