Modification du modèle éditorial : implications pour future revue OpenEdition

[ssonnet]

Bonjour,

Nous hébergeons une petite quinzaine de revues qui ont été construites (probablement) sur la base du modèle éditorial revues.org, pour les anciennes, et du modèle OpenEdition fourni avec Lodel 1, pour la plus récente. Je souhaite harmoniser et simplifier les choses pour arriver à un modèle éditorial adapté aux besoins de notre établissement. Notamment, beacoup de classes d'objets éditoriaux ne sont pas utilisées sur nos revues, et je souhaiterais les supprimer pour faire un peu de ménage... Mais pas seulement, je souhaiterais aussi restructurer le ME (modifier/simplifier les arborescences possibles).

Comme certaines de nos revues sont candidates pour intégrer OpenEdition, y-a-t-il une limite à ne pas franchir dans ce travail de réorganisation ? Ou est-ce qu'au contraire cela n'a aucune incidence sur la possibilité pour nos revues d'intégrer votre plateforme ?

Bien cordialement. Sylvain Sonnet

[jfriviere]

Bonjour,

Il faut savoir que dans Lodel, l'import et l'export des données contient les données ET le modèle de données (le modèle éditorial). De ce fait OpenEdition ne peut importer simplement les données des revues dont le modèle éditorial diffère ce celui qu'il utilise.

Nous avons publié récemment le modèle éditorial d'OpenEdition Journals que nous utilisons sur la plateforme https://github.com/OpenEdition/oej.em. Nous le maintiendrons à jour lors des évolutions à venir accompagnés de script permettant la mise à jour d'une version à la suivante. Nous ne pourrons importer sur OpenEdition que des sites préexistants utilisant ce modèle éditorial avec quelques "tolérances" de différences mais réduite au minimum. Donc la limite de réorganisation permettant une importation future directe dans OpenEdition Journals est proche de 0...

Il est aussi possible à une revue qui rejoint la plateforme OpenEdition Journals avec peu de numéros de réimporter ses documents Word stylés ou ses documents XML-TEI. Selon le nombre de documents, c'est parfois la solution la plus rapide, et dans le cas de modèle éditoriaux trop différents, c'est presque la seule solution.

Cordialement, Jean-François Rivière

[ssonnet]

Bonjour,

Merci pour votre réponse. Je profite que vous évoquiez la question de la mise à jour du modèle éditorial pour vous poser quelques questions supplémentaires :

• Au vu du script de mise à jour (https://github.com/OpenEdition/oej.em/blob/master/upgrade/upgrade_1.0.X_to_1.0.2.php), je présume que nous pouvons l'utiliser même si nos modèles éditoriaux diffèrent de celui d'OEJ ? Dans l'hypothèse où les champs mis à jours par le script (ceux de la table tablefields) ne seraient pas présents dans notre base, ça ne doit pas poser de souci (au pire on peut adapter le script si besoin) ?

• Si j'ai tout bien compris du mail d'information reçu hier, vous allez faire évoluer le schéma xml-tei d'OpenEdition (la mise en oeuvre du TEI chez OpenEdition, en somme). Ces évolutions nécessiteront la mise à jour du modèle éditorial (les données xpath) et, si besoin, la mise à jour d'OTX, tout cela étant à surveiller, c'est bien ça ?

• Donc logiquement, si le schéma xml-tei a évolué, et que l'on souhaite recharger un fichier xml dans Lodel, il faut au préalable l'adapter au nouveau schéma ?

Cordialement. Sylvain sonnet

[jfriviere]

Bonjour,

Bonjour,

Merci pour votre réponse. Je profite que vous évoquiez la question de la mise à jour du modèle éditorial pour vous poser quelques questions supplémentaires :

• Au vu du script de mise à jour (https://github.com/OpenEdition/oej.em/blob/master/upgrade/upgrade_1.0.X_to_1.0.2.php), je présume que nous pouvons l'utiliser même si nos modèles éditoriaux diffèrent de celui d'OEJ ? Dans l'hypothèse où les champs mis à jours par le script (ceux de la table tablefields) ne seraient pas présents dans notre base, ça ne doit pas poser de souci (au pire on peut adapter le script si besoin) ? Oui, vous pouvez l'appliquer. La version 1.0.0 du modèle éditorial est proche de la version distribuée dans Lodel. Et en effet si le champ n'exsite pas, le script de mettra pas à jour le Xpath, c'est tout.

• Si j'ai tout bien compris du mail d'information reçu hier, vous allez faire évoluer le schéma xml-tei d'OpenEdition (la mise en oeuvre du TEI chez OpenEdition, en somme). Ces évolutions nécessiteront la mise à jour du modèle éditorial (les données xpath) et, si besoin, la mise à jour d'OTX, tout cela étant à surveiller, c'est bien ça ?

Tout à fait, nous communiquerons à chaque évolution sur la liste tei@groups.openedition.org Pour recevoir les prochains messages de cette liste vous pouvez vous abonner en cliquant sur le lien suivant : https://groups.openedition.org/sympa/subscribe/tei

• Donc logiquement, si le schéma xml-tei a évolué, et que l'on souhaite recharger un fichier xml dans Lodel, il faut au préalable l'adapter au nouveau schéma ?

Oui, je confirme. Idéalement il faudrait préparer une petite XSLT pour transformer les fichiers TEI produit pour une version vers une version suivante. Pour l'instant nous ne l'avons pas fait, mais ce n'est pas exclu à l'avenir. Ca fonctionnerait je pense assez facilement pour les petites évolutions que nous avons apportées. Ca peut être plus compliqué dans l'hypothèse de modifications futures plus conséquentes.

Cordialement, Jean-François Rivière

Cordialement. Sylvain sonnet