imported>Maria Sadek |
|
| (23 révisions intermédiaires par 3 utilisateurs non affichées) |
| Ligne 1 : |
Ligne 1 : |
| − | {{Titre page article | + | __NOTOC__ |
| − | |titre=C2M : Chaînes éditoriales collaboratives multimédia}}
| + | {{Début 2 colonnes}} |
| − | | + | {{H2 Wicri|Le wiki des colloques CIDE}} |
| − | {{CIDE boîte bibliographique|texte= | + | Ce wiki est un espace de travail pour la communauté scientifique fédérée par les colloques CIDE ('''[[Colloque international sur le document électronique]]'''). |
| − | ;Titre: [[A pour titre::C2M : Chaînes éditoriales collaboratives multimédia]]
| + | :'''''[[Visite Ticri CIDE|Pour bénéficier d'une visite guidée]]''''' |
| − | ;Titre (anglais) : ''''
| + | Quelques chiffres sur l'activité de ce wiki : |
| − | ;Auteurs: [[A pour premier auteur::Stéphane Crozat]]
| + | {|border="1" cellspacing="0" cellpadding="2" |
| − | ;Affiliation:[[A pour affiliation auteur::Bibliothèque nationale de France|BnF]], Chaire Unesco ITEN, [[A pour affiliation auteur::Université Paris 8|Université Paris-VIII]], [[A pour affiliation auteur::Paragraphe (laboratoire)|Laboratoire Paragraphe]]
| + | |- |
| − | ;In: [[Est dans les actes::CIDE 2015 Montpellier|CIDE'18]] (Montpellier 2015)
| + | |Date de création |
| − | ;En ligne: https://hal-bnf.archives-ouvertes.fr/hal-01239425
| + | |align="right"|12 décembre 2011 |
| | + | |- |
| | + | |[[Spécial:Statistiques|Nombre de pages]] |
| | + | |align="right"|{{NUMBEROFPAGES}} |
| | + | |- |
| | + | |align="center"|''dont'' |
| | + | |''{{NUMBEROFARTICLES}} pages de contenu'' (estimation) |
| | + | |- |
| | + | |Nombre de modifications |
| | + | |align="right"|{{NUMBEROFEDITS}} |
| | + | |- |
| | + | |} |
| | + | {{H2 Wicri|Le réseau Wicri}} |
| | + | Le wiki CIDE est associé au réseau Wicri et plus particulièrement au sous-réseau Ticri. |
| | + | <center> |
| | + | {{Wicri carte globale |
| | + | |taille carte=280 |
| | + | |taille 1 = 32 |
| | + | |taille 2 = 26 |
| | + | |taille 3 = 24 |
| | + | |taille 4 = 22 |
| | + | |taille 5 = 18 |
| | + | |taille 6 = 17 |
| | }} | | }} |
| − | | + | </center> |
| − | | + | Pour naviguer dans cet ensemble, voir la page [[CIDE:Accueil|pointée par l'onglet Communauté]]. |
| − | | + | {{H2 Wicri|Les serveurs d'exploration}} |
| − | | + | Pour élargir le paysage scientifique donné par les colloques CIDE, le wiki offre un ensemble de serveurs d'exploration sur les thématiques du document numérique. |
| − | Stéphane CROZAT (1)
| + | {{#ask: [[A pour taille ISTEX::>0]] OR [[A pour taille PubMed::>0]] OR [[A pour taille PubMed Central::>0]] OR [[A pour taille Pascal::>0]] OR [[A pour taille Francis::>0]] OR [[A pour taille HAL::>0]] |
| − | (1) Unité ICS, Université de Technologie de Compiègne, France
| + | | ?A pour volumétrie (serveur d'exploration)=Volumétrie |
| − | stephane.crozat@utc.fr
| |
| − | __TOC__
| |
| − | ;Résumé: Nous présentons dans cet article le résultat principal du projet C2M à travers Scenari4, un système de gestion de contenus structurés et fragmentés en contexte collaboratif. La principale difficulté est la gestion de la rééditorialisation et de la transclusion. Nous proposons les concepts d'atelier dynamique et de réseau de fragments vivants, et de bibliothèque et de document-dossier pour y remédier. Scenari4 est disponible sous licence FLOSS et est expérimenté dans plusieurs contextes expérimentaux et commerciaux.
| |
| − | | |
| − | ;Mots-clés: XML, Chaîne Éditoriale, Document Structuré, Document Fragmenté, Transclusion, Rééditorialisation, ECM.
| |
| − | {{boîte déroulante | |
| − | |titre=''C2M : Chaînes éditoriales collaboratives multimédia''
| |
| − | |contenu=
| |
| − | ;Abstract: We present in this paper the main result of the C2M project through Scenari4, a system able to manage structured and fragmented contents in a collaborative context. The main issue is related to repurposing and transclusion management. We submit the concepts of dynamic workspace and network of live fragments, and static library and folder-documents to deal with it. Scenari4 is released under FLOSS license and has been being used in several experimental and commercial contexts.
| |
| − | ;Keywords: XML Publishing Chain, Structured Document,
| |
| − | Fragmented Document, Transclusion, Repurposing, ECM.
| |
| | }} | | }} |
| | + | {{H2 Wicri|Bienvenue aux étudiants de Master}} |
| | + | Le wiki CIDE s'adresse aussi aux étudiants en sciences de l'information. Ceux-ci peuvent aussi expérimenter la création de documents numériques et l'exploration de corpus avec ISTEX. |
| | | | |
| − | {{CIDE début corps}} | + | {{Article principal|Un espace pour les étudiants de Master en Sciences de l'information}} |
| − | ==1 Introduction==
| + | |
| − | | + | {{H2 Wicri|Quelques articles}} |
| − | Le projet C2M (Chaînes éditoriales Collaboratives Multimédia) | + | * Le plus ancien : [[CIDE (1998) Richy|Édition comparative et hypertextuelle]] ([[Hélène Richy]], [[Jacques André (informaticien)|Jacques André]]) 1998 |
| − | est un projet français de recherche industrielle soutenu par
| + | * en lien avec l'actualité CIDE : |
| − | l'Agence Nationale de la Recherche et les pôles de compétitivité | + | ** [[CIDE (2015) Laborderie|Éditorialisation des bibliothèques numériques : le cas des Essentiels de Gallica]] ([[Arnaud Laborderie]]) 2015 |
| − | Cap Digital et Systematic, mené de septembre 2009 à mars
| + | ** [[CIDE (2008) Boismenu|La communication scientifique et ses enjeux politiques : un regard transatlantique]] ([[Gérard Boismenu]]) 2008 |
| − | 2012. Le projet a été coordonné par l'Université de Technologie
| + | {{H2 Wicri|La "famille proche" : H<sup>2</sup>PTM et VSST}} |
| − | de Compiègne et a associé les sociétés Kelis et Amexio, les
| + | [[{{Logo Ticri H2PTM fr}}|right|100px|link=ticri-h2ptm.fr:Accueil]] |
| − | laboratoires UMR-CNRS 7253 Heudiasyc et INRIA Rhône-Alpes,
| + | [[{{Logo Ticri VSST fr}}|left|100px|link=ticri-vsst.fr:Accueil]] |
| − | ainsi que l'Institut National de l'Audiovisuel.
| + | <center>'''<br/><br/>''Données Documents Connaissances : <br/>Perspectives de recherche et d'enseignement''<br/><br/>Cnam – Paris - France<br/><br/>9 - 10 décembre 2021''' </center> |
| − | | + | Deux autres wikis du réseau sont consacrés au traitement de colloques qui s'adressent à une communauté proche : |
| − | Le projet C2M se positionne à l'intersection de deux évolutions -
| + | {{Clr}} |
| − | technologiques et d'usages - centrales dans le contexte des
| + | :: {{Wicri lien|wiki=VSST}} et {{Wicri lien|wiki=H2PTM}} |
| − | mutations documentaires liées à l'avènement du numérique :
| + | {{Saut 2 colonnes}} |
| − | les chaînes éditoriales XML et les ECM (Enterprise Content
| + | {{H2 Wicri|Le colloque CIDE.22 Paris}} |
| − | Management).
| + | [[File:CIDE 22 Cropped-entete-copie.jpg|center|400px|link=CIDE 2021 Paris]] |
| − | | + | <center>'''<br/>[[CIDE 2021 Paris|22<sup>e</sup> Colloque International sur le Document Numérique]]<br/>''Données Documents Connaissances : <br/>Perspectives de recherche et d'enseignement''<br/>Cnam – Paris - France<br/>9 - 10 décembre 2021''' </center> |
| − | La première de ces évolutions est celle de la chaîne éditoriale,
| + | |
| − | une technologie orientée vers la production et de publication de
| + | {{H2 Wicri|Les actes des colloques CIDE en hypertexte}} |
| − | documents structurés. Un document structuré est un
| + | Les actes des colloques CIDE sont en cours de réédition dans une approche hypertexte. Leur traitement est parfois limité mais souvent significatif. Tous les sommaires sont disponibles. |
| − | document : «décrit comme une collection d'objets comportant
| + | * 2019 : [[CIDE 2019 Djerba|CIDE.21 (Djerba)]] |
| − | des objets de plus haut niveau composés d'objets plus primitifs.
| + | * 2017 : [[CIDE 2017 Lyon|CIDE.20 (Lyon)]] |
| − | Les relations entre ces objets représentent les relations logiques
| + | * 2016 : [[CIDE 2016 Athènes|CIDE.19 (Athènes)]] - ''{{CIDE articles traités|colloque=CIDE 2016 Athènes}}'' |
| − | entre les composants du document. Par exemple [...] un livre
| + | * 2015 : [[CIDE 2015 Montpellier|CIDE.18 (Montpellier)]] - - ''{{CIDE articles traités|colloque=CIDE 2015 Montpellier}}'' |
| − | est divisé en chapitres, chaque chapitre en sections, soussections,
| + | * 2014 : [[CIDE 2014 Fès|CIDE.17 (Fès)]], - ''{{CIDE articles traités|colloque=CIDE 2014 Fès}}'' |
| − | paragraphes, etc. (André & al., 1989)». Les premiers
| + | * 2013 : [[CIDE 2013 Lille|CIDE.16 (Lille)]], - ''{{CIDE articles traités|colloque=CIDE 2013 Lille}}'' |
| − | développements datent du début des années 80, avec LaTeX et
| + | * 2012 ; [[CIDE 2012 Tunis|CIDE.15 (Tunis)]], - ''{{CIDE articles traités|colloque=CIDE 2012 Tunis}}'' |
| − | SGML, en particulier dans les milieux ayant des enjeux
| + | * 2011 : [[CIDE 2011 Rabat|CIDE.14 (Rabat)]], - ''{{CIDE articles traités|colloque=CIDE 2011 Rabat}}'' |
| − | documentaires prégnants (l'aéronautique typiquement). L'accès
| + | * 2010 : [[CIDE 2010 Paris|CIDE.13 (Paris)]], - ''{{CIDE articles traités|colloque=CIDE 2010 Paris}}'' |
| − | aux chaînes éditoriales a depuis été démocratisé par le standard
| + | * 2009 : [[CIDE 2009 Montréal|CIDE.12 (Montréal)]], - ''{{CIDE articles traités|colloque=CIDE 2009 Montréal}}'' |
| − | XML et les outils logiciels qui se sont développés autour.
| + | * 2008 : [[CIDE 2008 Rouen|CIDE.11 (Rouen)]], ''{{CIDE articles traités|colloque=CIDE 2008 Rouen}}, |
| − | L'intérêt de cette approche est de pousser la puissance
| + | * 2007 : [[CIDE 2007 Nancy|CIDE.10 (Nancy)]], - '''''{{CIDE articles traités|colloque=CIDE 2007 Nancy}}'''' |
| − | éditoriale du document numérique et de dépasser les pratiques
| + | * 2006 : [[CIDE 2006 Fribourg|CIDE.09 (Fribourg)]], ''{{CIDE articles traités|colloque=CIDE 2006 Fribourg}}, |
| − | bureautiques : encadrement rédactionnel, publication multisupports,
| + | * 2005 : [[CIDE 2005 Beyrouth|CIDE.08 (Beyrouth)]], ''{{CIDE articles traités|colloque=CIDE 2005 Beyrouth}}, |
| − | réutilisation sans recopie, intégration multimédia...
| + | * 2004 : [[CIDE 2004 La Rochelle|CIDE.07 (La Rochelle)]], ''{{CIDE articles traités|colloque=CIDE 2004 La Rochelle}}, les actes en PDF'' |
| − | (Crozat, 2007). | + | * 2003 : [[CIDE 2003 Caen|CIDE.06 (Caen)]], - ''{{CIDE articles traités|colloque=CIDE 2003 Caen}}'' |
| − | | + | * 2002 : [[CIDE 2002 Hammamet|CIDE.05 (Hammamet)]], ''{{CIDE articles traités|colloque=CIDE 2002 Hammamet}}'' |
| − | La seconde de ces évolutions est celle du documentaire
| + | * 2001 : [[CIDE 2001 Toulouse|CIDE.04 (Toulouse)]], - ''{{CIDE articles traités|colloque=CIDE 2001 Toulouse}}'' |
| − | collaboratif, développé dès les années 80 à travers la GED
| + | * 2000 : [[CIDE 2000 Lyon|CIDE.03 (Lyon)]], - ''{{CIDE articles traités|colloque=CIDE 2000 Lyon}}'' |
| − | (Dupoirier, 1995), prolongé dans les années 90 par les CMS | + | * 1999 : [[CIDE 1999 Damas|CIDE.02 (Damas)]], - ''{{CIDE articles traités|colloque=CIDE 1999 Damas}}'' |
| − | Web, et consacré au milieu des années 2000 par l'ECM en
| + | * 1998 : [[CIDE 1998 Rabat|CIDE.01 (Rabat)]], - ''{{CIDE articles traités|colloque=CIDE 1998 Rabat}}'' |
| − | entreprise d'une part, et les usages grand public dit "Web 2.0"
| |
| − | d'autre part (C2M:L2e)(C2M:L5c). La force de ces nouveaux
| |
| − | usages est avant tout la démocratisation des outils de création
| |
| − | et de diffusion : chacun peut facilement écrire et publier en
| |
| − | ligne. Elle est également vecteur d'une interrogation sur les
| |
| − | acteurs et les pratiques : les frontières classiques entre auteurs,
| |
| − | lecteurs, éditeurs, rédacteurs ou contributeurs tendent à se
| |
| − | reconfigurer.
| |
| − | | |
| − | Le projet C2M repose sur l'idée qu'il y a un intérêt très fort à
| |
| − | faire cohabiter les avantages de la chaîne éditoriale et ceux des
| |
| − | outils documentaires collaboratifs. L'objectif est de concevoir un
| |
| − | système permettant à la fois la réalisation d'une documentation
| |
| − | hautement qualitative, respectant les exigences de contextes
| |
| − | professionnels pour lesquels le document a une valeur
| |
| − | essentielle (documentation technique, formation...) ; et des
| |
| − | usages collaboratifs permettant à des communautés de
| |
| − | s'organiser autour de cycles innovants de gestion de
| |
| − | l'information : production, maintenance, qualification, diffusion,
| |
| − | etc. Il s'inscrit scientifiquement dans la recherche en ingénierie
| |
| − | documentaire, au sens des systèmes informatiques optimisant
| |
| − | l'articulation de la manipulation technique et de l'interprétation
| |
| − | humaine des documents (Bachimont, 2007) ; et
| |
| − | technologiquement dans la continuité du projet Scenari initié à
| |
| − | l'UTC en 1999 et édité depuis 2004 par le société Kelis. Le
| |
| − | principal résultat du projet est le logiciel Scenari4, qui ajoute la
| |
| − | dimension collaborative de la gestion de contenus structurés et
| |
| − | fragmentés grâce à l'intégration d'une base de données
| |
| − | orientée graphe (qui s'appuie sur les couches bas niveau
| |
| − | d'OrientDb).
| |
| − | | |
| − | ==2 Rééditorialisation par transclusion==
| |
| − | | |
| − | La rééditorialisation est un processus documentaire consistant à
| |
| − | reconstruire un nouveau document à partir d'archives. Dans les
| |
| − | systèmes éditoriaux non numériques, la rééditorialisation est
| |
| − | essentiellement un travail de recopie fondamentalement peu
| |
| − | différent d'un travail de production originale. Les systèmes
| |
| − | numériques ont apporté une rupture avec la possibilité de
| |
| − | cloner (copier/coller) un fragment documentaire. Ce principe
| |
| − | fonctionnel a considérablement affecté les pratiques éditoriales
| |
| − | par l'automatisation de la rééditorialisation qu'il supporte, et
| |
| − | nombre de documents sont aujourd'hui reconstruits par un tel
| |
| − | processus. Si le clonage du contenu dans les systèmes
| |
| − | numériques est un principe d'automatisation de la production, il
| |
| − | engendre la redondance de l'information. En effet le même
| |
| − | fragment documentaire, copié/collé à plusieurs reprises, existe à
| |
| − | plusieurs endroits au sein d'un fonds documentaire, avec les
| |
| − | conséquences néfastes que cela engendre sur la qualité de
| |
| − | l'information (typiquement, incohérence des mises à jour).
| |
| − | | |
| − | L'alternative au clonage est la transclusion (Nelson, 1981), c'est
| |
| − | à dire le référencement multiple via une adresse d'un contenu
| |
| − | inscrit une unique fois, plutôt que sa recopie. Ce concept est
| |
| − | peu mobilisé dans les processus d'écriture ordinaire, bien que
| |
| − | des standards comme XLink et Xpointer (Wilde & Lowe, 2002)
| |
| − | aient tenté d'oeuvrer en ce sens et que des technologies comme
| |
| − | HTML permettent d'implémenter en partie ce concept (iframe
| |
| − | par exemple). En revanche ce principe est mobilisé dans
| |
| − | certains domaines métier comme la documentation technique à
| |
| − | travers les principes du standard DITA et les Component
| |
| − | Content Management Systems (C2M:L5c) qui l'instrumentent ;
| |
| − | ou dans le domaine de l'audiovisuel où le coût de la copie est
| |
| − | élevé, l'éditorialisation est alors «une activité d'écriture par un
| |
| − | auteur qui puise dans un fonds d'archive et qui réagence des
| |
| − | contenus jugés pertinents pour son propos (Gaillard, 2010)».
| |
| − | | |
| − | C'est ce principe qui est au coeur de la chaîne éditoriale XML
| |
| − | Scenari qui instrumente nativement un contenu comme un
| |
| − | | |
| − | réseau de fragments qui se manifeste en document au moment
| |
| − | de la publication (Geurts & al., 2011).
| |
| − | | |
| − | ==3 Principe de la transclusion== | |
| − | | |
| − | Soit un document d1 contenant une information i1 à l'adresse
| |
| − | &1. Dans le premier cas (clonage) l'information i1 est copiée à
| |
| − | l'adresse &2 dans le document d2, devenant de fait une autre
| |
| − | information i1' (bien qu'identique au moment de sa copie, elle
| |
| − | pourra librement diverger par la suite). Dans le second cas
| |
| − | (transclusion) une référence vers l'adresse &1 est ajoutée au | |
| − | même endroit du document, à l'adresse &2. Un programme
| |
| − | informatique adéquat saura résoudre la référence située à &2 et
| |
| − | rapatrier le contenu pointé i1.
| |
| − | | |
| − | | |
| − | | |
| − | | |
| − | | |
| − | Figure 1. Clonage et transclusion pour la réutilisation de
| |
| − | fragments documentaire
| |
| − | | |
| − | Finalement les documents d2 et d2' contiennent la même
| |
| − | information, mais la façon dont cette information est stockée est
| |
| − | différente, avec des conséquences profondes sur la nature
| |
| − | documentaire associée à chaque approche. Avec la copie, les
| |
| − | documents d1 et d2 restent représentés par deux instances
| |
| − | numériques indépendantes, comme dans un cas traditionnel ils
| |
| − | peuvent être indépendamment transportés, mis à jour, détruit...
| |
| − | Avec la transclusion en revanche, d1 et d2' sont représentés par
| |
| − | une seule et même instance numérique devenu un réseau de
| |
| − | fragments qui dépendent les uns des autres, ainsi par exemple
| |
| − | la mise à jour de i1 dans d1 entraînera a priori la modification de
| |
| − | d2'. Elle l'entraînera de fait si cette modification est inscrite
| |
| − | directement à l'adresse &1, elle ne l'entraînera pas si elle est
| |
| − | inscrite à une adresse &1' (correspondant alors à une nouvelle
| |
| − | version de i1), et que la référence n'est pas mise à jour dans
| |
| − | d2'.
| |
| − | | |
| − | ==4 Rééditorialisation en contexte collaboratif==
| |
| − | | |
| − | Le numérique met intrinsèquement à mal la notion traditionnelle
| |
| − | de document (Pedauque, 2005). En effet celui-ci n'est
| |
| − | objectivable qu'à travers la reconstruction calculée d'une
| |
| − | ressource binaire, qui n'est elle même jamais accessible
| |
| − | directement (Bachimont & Crozat, 2004). Tout document
| |
| − | numérique n'est donc déjà plus vraiment un document : ce
| |
| − | qu'on lit n'est pas ce qui est écrit.
| |
| − | | |
| − | La notion de document structuré renforce ce décalage en
| |
| − | assumant la non identité entre ressource binaire et document
| |
| − | lisible, afin d'en proposer plusieurs reconstructions - ou vues -
| |
| − | qui se constituent en un dossier (Ibid.). Une ressource permet
| |
| − | alors d'engendrer plusieurs documents : on passe d'une relation
| |
| − | de type 1:1 à une relation 1:N.
| |
| − | | |
| − | La transclusion accentue encore le décalage : le document n'est
| |
| − | plus le résultat d'un calcul à partir d'une ressource, mais à partir
| |
| − | d'un réseau de ressources, dont chacune a une vie propre, dont
| |
| − | chacune peut être connectée à d'autres ressources, qui ont des
| |
| − | vies propres. Plusieurs ressources permettent alors d'engendrer
| |
| − | plusieurs documents, on passe à une relation de type N:M. Un
| |
| − | problème typique de cette relation N:M est qu'une mise à jour
| |
| − | d'un fragment peut être souhaitable pour un document qui
| |
| − | l'exploite, mais pas pour un autre. Un système de rédaction de
| |
| − | documents fragmentés doit alors proposer une couche logicielle
| |
| − | de gestion qui permettra à l'auteur à la fois l'intelligibilité et le
| |
| − | maintien de la cohérence de l'ensemble.
| |
| − | | |
| − | Enfin l'introduction de la collaboration, c'est à dire l'intervention
| |
| − | de plusieurs acteurs, au sein d'un système fondamentalement
| |
| − | transclusif introduit une quatrième couche de complexité :
| |
| − | chaque acteur n'a plus qu'une appréhension parcellaire du
| |
| − | réseau et par conséquent ne peut à lui seul maintenir la
| |
| − | cohérence, qui devient du ressort d'un collectif.
| |
| − | | |
| − | L'enjeu est donc in fine la capacité à maintenir la cohérence de
| |
| − | plusieurs documents issus d'un même réseau de fragments
| |
| − | vivants, dans un environnement où plusieurs utilisateurs sont en
| |
| − | concurrence. La stratégie visée est de repenser, de rendre
| |
| − | opérationnelles et d'étendre les fonctions classiques du
| |
| − | documentaire collaboratif (gestion des accès, historisation,
| |
| − | transaction, workflow...) pour ces objets nouveaux que sont les
| |
| − | fragments et les réseaux de fragments.
| |
| − | | |
| − | ==5 Problème de la propagation des modifications==
| |
| − | | |
| − | Dans la figure ci-après les fragments 1 et 4 référencent le
| |
| − | fragment 3. Al effectue une modification de 3 en 3'. La
| |
| − | transclusion implique que ce changement aura un impact sur 1,
| |
| − | mais également sur 4. Or Al peut très bien ne pas maîtriser le
| |
| − | contexte de 4, voire ne pas savoir du tout que le fragment 3
| |
| − | qu'il a modifié est utilisé dans d'autres contextes par d'autres
| |
| − | acteurs. Il ne peut donc en tenir compte dans son travail de
| |
| − | rédaction. Seul Bob pourra interpréter dans son contexte les
| |
| − | modifications faites par Al et en étudier la cohérence.
| |
| − | | |
| − | | |
| − | | |
| − | | |
| − | | |
| − | | |
| − | | |
| − | Figure 2. Fragmentation en contexte collaboratif
| |
| − | (http://utc.fr/ics/c2m)
| |
| − | | |
| − | | |
| − | | |
| − | Il devra alors prendre une décision parmi : référencer 3' et donc
| |
| − | répercuter la modification ; continuer de référencer 3
| |
| − | (l'ancienne version), sachant que les prochaines modifications
| |
| − | de Al n'y seront plus répercutées ; faire une copie de 3 en 3''
| |
| − | dans son contexte propre pour l'intégrer aux fragments qu'il va
| |
| − | maintenir par la suite ; faire une copie de 3' en 3'' dans son
| |
| − | contexte pour créer un hybride entre 3 et 3'... Bien entendu ces
| |
| − | questions dépendent fondamentalement de la nature de la
| |
| − | modification, la correction d'une erreur, d'une faute
| |
| − | d'orthographe sera a priori toujours à propager, la modification
| |
| − | de données techniques dépendra toujours du contexte. Par
| |
| − | exemple si Al gère la documentation technique canonique d'un
| |
| − | progiciel et Bob la documentation du déploiement de ce
| |
| − | progiciel dans une entreprise, la mise à jour générée par Al lors
| |
| − | de l'évolution du progiciel ne devra être propagée qu'au
| |
| − | moment du déploiement réel en entreprise.
| |
| − | | |
| − | ==6 Problème de cohérence des droits en lecture==
| |
| − | | |
| − | Un autre problème à résoudre est la difficulté de gérer un
| |
| − | réseau de fragments avec les logiques de gestion de droits
| |
| − | usuels (C2M:L2c). En effet si un utilisateur accède à un
| |
| − | fragment, cela signifie logiquement qu'il doit pouvoir accéder à
| |
| − | tout le réseau de fragments que celui-ci référence, puisqu'il n'y
| |
| − | a pas de différence sémantique entre la réutilisation d'un
| |
| − | fragment par clonage ou par transclusion. Donc pouvoir lire un
| |
| − | fragment implique de pouvoir lire les fragment qu'il référence.
| |
| − | | |
| − | Or cela est contradictoire avec la définition d'accès fichier par
| |
| − | fichier, ou même répertoire par répertoire, traditionnellement en
| |
| − | vigueur dans les systèmes documentaires collaboratifs comme
| |
| − | les ECM. Dans le cas 1 illustré ci-après, Albert est propriétaire de
| |
| − | l'espace EA qui contient le fragment A et Bob est propriétaire de
| |
| − | l'espace EB qui contient les fragments B1 et B2 tel que B1
| |
| − | référence B2. Bob donne l'accès à Albert sur B1 mais pas sur
| |
| − | B2. La référence transclusive A->B1 est théoriquement possible,
| |
| − | mais comme Albert n'a pas le droit d'accéder à B2, elle est
| |
| − | pratiquement impossible, il y a contradiction : par exemple
| |
| − | Albert ne pourra pas générer un document complet à partir de
| |
| − | A. Dans le cas 2, Albert est propriétaire de l'espace EA qui
| |
| − | contient le fragment A, Bob est propriétaire de l'espace EB qui
| |
| − | contient B, et Charlie est propriétaire de l'espace EC qui contient
| |
| − | C. Albert donne l'accès en lecture à Bob sur EA et Bob à Charlie
| |
| − | sur EB. Le réseau C->B->A est possible, or Charlie n'a pas le
| |
| − | droit d'accéder à A, il y a encore contradiction et Charlie a créé
| |
| − | un réseau qu'il ne peut pas publier sous forme de document.
| |
| − | | |
| − | | |
| − | | |
| − | | |
| − | Figure 3. Incohérences entre les droits accordés et les réseaux
| |
| − | correspondants
| |
| − | | |
| − | | |
| − | | |
| − | | |
| − | | |
| − | On notera que ces problèmes n'affectent en rien les droits
| |
| − | d'écriture, si Charlie a le droit d'écrire dans EB, mais pas dans
| |
| − | EA, cela ne pose aucun problème, tant qu'il a le droit de lire et
| |
| − | référencer les fragments de EA.
| |
| − | | |
| − | ==7 Atelier et production collaborative==
| |
| − | | |
| − | Pour résoudre les problèmes de cohérence relevés
| |
| − | précédemment, le principe retenu est de limiter les
| |
| − | référencements par transclusion à un espace bien délimité au
| |
| − | sein duquel tous les utilisateurs forment une équipe de
| |
| − | collaborateurs participant à un projet éditorial commun (Ibid.).
| |
| − | On appelle atelier ce lieu de travail hautement collaboratif, et
| |
| − | entrepôt l'ensemble des ateliers d'une organisation,
| |
| − | correspondant à autant de projets et équipes différents. Les
| |
| − | ateliers sont hermétiques entre eux, la réutilisation de contenu
| |
| − | entre deux ateliers se fait par clonage (typiquement via un
| |
| − | document-dossier, voir ci-après).
| |
| − | | |
| − | Le comportement par défaut d'un atelier est : d'une part que
| |
| − | tous les utilisateurs autorisés à y accéder ont tous les droits en
| |
| − | lecture sur tous les fragments (pas nécessairement en
| |
| − | modification) ; et d'autre part que toutes les modifications sont
| |
| − | automatiquement propagées au sein de l'atelier.
| |
| − | | |
| − | L'atelier est donc un espace de travail ouvert. Afin de mettre à
| |
| − | disposition des utilisateurs des espaces de travail privés, non
| |
| − | accessibles par les autres, une solution est de proposer à
| |
| − | chaque utilisateur un atelier personnel auquel il est seul à
| |
| − | pouvoir accéder. Une solution alternative (non implémentée à
| |
| − | ce jour dans Scenari4) est d'autoriser des îlots privatifs au sein
| |
| − | d'un atelier, qui peuvent être restreints en lecture, mais en
| |
| − | contre-partie ne peuvent pas être la cible d'une relation de
| |
| − | transclusion. Dans les deux cas le passage de la zone
| |
| − | personnelle isolée à la zone collaborative commune se fait par
| |
| − | copie (ou déplacement).
| |
| − | | |
| − | L'atelier est aussi un espace de travail dynamique, réceptacle
| |
| − | d'un réseau de fragments vivants. Il permet une interaction très
| |
| − | forte entre les acteurs mais engendre une forte instabilité
| |
| − | documentaire, le réseau étant en constante mutation. Le
| |
| − | contenu peut être modifié facilement et la perception de ces
| |
| − | modifications n'est pas facile par chaque acteur pris
| |
| − | indépendamment. Plusieurs pistes méthodologiques sont
| |
| − | explorées pour pallier le risque de perte de la maîtrise des
| |
| − | modifications par les utilisateurs : circonscrire l'atelier à un
| |
| − | nombre limité d'acteurs ; maîtriser les relations transclusives
| |
| − | inter-acteurs ; limiter les relations transclusives entre des
| |
| − | fragments "éloignés" du point de vue des usages... Des
| |
| − | fonctions logicielles sont également développées pour assister
| |
| − | la gestion humaine de la dynamique de l'atelier.
| |
| − | | |
| − | ==8 Sécurisation des contenus face aux modifications==
| |
| − | | |
| − | Un système fortement dynamique doit assurer à ses utilisateurs,
| |
| − | que, quelque soit son activité, ils auront la possibilité de
| |
| − | retrouver tout contenu dans un état qu'il ont connu.
| |
| − | Typiquement tout utilisateur doit pouvoir retrouver un contenu
| |
| − | dans l'état où il l'a laissé avant que d'autres utilisateurs ne le
| |
| − | modifie. Dans Scenari4, cette sécurité passe par deux fonctions,
| |
| − | l'historisation automatique de chaque fragment, et le
| |
| − | versionnage manuel de réseau de fragments.
| |
| − | | |
| − | À chaque modification et sauvegarde d'un fragment, le système
| |
| − | crée automatiquement une nouvelle version du fragment
| |
| − | modifié, et conserve l'ancienne en lecture seule. C'est le modèle
| |
| − | de fonctionnement de la plupart des Wikis. Ceci permet de
| |
| − | remonter dans le temps et retrouver l'état antérieur de
| |
| − | n'importe quel fragment. Néanmoins, en contexte fortement
| |
| − | fragmenté, retrouver l'état voulu d'un réseau de fragments peut
| |
| − | vite devenir un casse-tête insoluble, puisqu'il faut identifier une
| |
| − | par une chaque version de chaque fragment.
| |
| − | | |
| − | Le versionnage manuel de réseau de fragments vient pallier
| |
| − | cette difficulté : l'utilisateur peut à tout moment demander au
| |
| − | système de créer un snapshot (une image instantanée), d'un
| |
| − | fragment et de l'ensemble de ses fragments liés
| |
| − | (récursivement). Le résultat est un réseau de fragments morts
| |
| − | (en lecture seule), qui pourra donc être consulté en vase clôt à
| |
| − | tout moment.
| |
| − | | |
| − | | |
| − | | |
| − | | |
| − | Figure 4. Historisation versionnage dans Scenari4 (C2M:L5c)
| |
| − | | |
| − | | |
| − | | |
| − | | |
| − | On visualise sur cette copie d'écran le fragment
| |
| − | "anomalie.chapter", en haut à droite son historique de
| |
| − | modification, et an bas à droite la version "v1" qui permettra
| |
| − | notamment de retrouver le fragment lié
| |
| − | "cfNoticesIndividuelles.chunk" dans l'état où il était au moment
| |
| − | de la création de la version v1 de "anomalie.chapter".
| |
| − | | |
| − | | |
| − | ==9 Autres fonctions de gestion de la dynamique éditoriale au sein des ateliers==
| |
| − | | |
| − | D'autres fonctions ont été conçues, expérimentées et
| |
| − | implémentées pour assister la gestion du réseau de fragments
| |
| − | vivants par les utilisateurs (C2M:L2d)(C2M:L3e), on pourra citer :
| |
| − | | |
| − | l'information des utilisateurs sur l'activité du système :
| |
| − | des logs permettent aux utilisateurs de connaître les
| |
| − | actions concurrentes en cours dans le système, ou
| |
| − | passées en leur absence ;
| |
| − | | |
| − | la programmation et l'organisation des modifications : la
| |
| − | gestion de tâches et cycles de vie au niveau des
| |
| − | fragments permet de planifier le comportement du
| |
| − | système et d'anticiper les modifications à venir ;
| |
| − | | |
| − | la possibilité de ne pas répercuter des modifications : au
| |
| − | moment de la modification d'un fragment les utilisateurs
| |
| − | qui l'utilisent au sein de leurs réseaux sont alertés et
| |
| − | peuvent choisir de rester brancher sur une version
| |
| − | historisée du fragment ou de se brancher sur la version
| |
| − | courante (live), la difficulté étant de n’interroger les
| |
| − | utilisateurs que lorsque c'est nécessaire ;
| |
| − | | |
| − | | |
| − | * les outils de comparaison et fusion : les utilisateurs
| |
| − | doivent pouvoir facilement visualiser les différences
| |
| − | entre fragments et réseaux de fragments pour décider
| |
| − | lesquels référencer, voire créer des versions hybrides (Vu
| |
| − | & al., 2011) ;
| |
| − | | |
| − | *les outils de communication éditoriale et d'aide à
| |
| − | l'interprétation : les utilisateurs peuvent échanger
| |
| − | (annotations, commentaires...) autour des fragments
| |
| − | pour discuter leurs évolutions ;
| |
| − | | |
| − | * le principe de la dérivation d'atelier : il est possible de
| |
| − | créer une copie virtuelle d'un atelier, afin d'effectuer des
| |
| − | surcharges de certains fragments, les fragments non
| |
| − | surchargés restant ceux de l'atelier d'origine (et
| |
| − | continuant donc d'évoluer comme eux), tandis que les
| |
| − | fragments surchargés sont informés des modifications de
| |
| − | leur fragments d'origine pour éventuellement suivre
| |
| − | leurs mises à jour (cette fonction de dérivation-surcharge
| |
| − | permet de sortir de la logique purement transclusive,
| |
| − | pour lui associer une logique de clonage contrôlée).
| |
| − | | |
| − | ==10 Document-dossier et bibliothèque pour la stabilisation documentaire==
| |
| − | | |
| − | L'atelier est le lieu de l'élaboration du contenu, mais son
| |
| − | caractère dynamique le rend peu propice à l'établissement
| |
| − | documentaire, au sens d'une forme stable, fermée, objectivable
| |
| − | et appropriable. Dans le prolongement de travaux antérieurs
| |
| − | (Bachimont & Crozat, 2004), nous avons forgé le concept de
| |
| − | document-dossier comme pendant statique au réseau de
| |
| − | fragments vivants (C2M:L2a). Un document-dossier (DD) est une
| |
| − | version figée d'un réseau de fragments, associée
| |
| − | éventuellement à ses formes documentaires (HTML, PDF...). Un
| |
| − | DD est composé : d'une unique forme génératrice FG' ; de
| |
| − | plusieurs (zéro à n) formes publiées FP ; d'un modèle M ; et de
| |
| − | métadonnées MD. FG' est un ensemble de fragments XML reliés
| |
| − | entre eux, versionné à un instant t à partir d'un réseau FG
| |
| − | vivant dans l'atelier. Les FP sont des formes lisibles de FG'
| |
| − | permettant son interprétation humaine. Le modèle correspond à
| |
| − | l'ensemble du code (schéma, fonctions de transformation...)
| |
| − | nécessaire à la manipulation informatique de FG'. Et les
| |
| − | métadonnées permettent l'identification documentaire du DD
| |
| − | via des descripteurs standard (comme Dublin Core par
| |
| − | exemple).
| |
| − | | |
| − | | |
| − | Figure 5. Structure d'un DD
| |
| − | | |
| − | | |
| − | | |
| − | | |
| − | Si l'écriture collaborative s'effectue sur des réseaux de
| |
| − | fragments vivants au sein d'un atelier, la stabilisation
| |
| − | documentaire et les échanges d'objets identifiés comme
| |
| − | documents sont effectués via des documents-dossiers, qui
| |
| − | peuvent alors être rangés dans des bibliothèques. Les DD
| |
| − | stockés dans des bibliothèques peuvent être consultés par les
| |
| − | lecteurs, les FP offrant des formes stables et fermées
| |
| − | permettant l'appropriation du contenu ; ou peuvent être
| |
| − | réinjectés dans des ateliers et ainsi trouver une seconde vie, la
| |
| − | FG' et la connaissance du modèle permettant de ré-ancrer les
| |
| − | fragments dans un nouveau réseau vivant (le document-dossier
| |
| − | est ainsi un support à une collaboration restreinte entre
| |
| − | ateliers). Une bibliothèque peut typiquement être implémentée
| |
| − | avec un ECM (comme Nuxeo, Alfreco, Documentum...), une
| |
| − | version expérimentale simplifiée a été réalisée dans le cadre de
| |
| − | C2M (C2M:L3d), et l'intégration d'une bibliothèque native dans
| |
| − | Scenari4 est prévue à terme (C2M:L2f).
| |
| − | | |
| − | | |
| − | | |
| − | | |
| − | Figure 6. Organisation atelier-bibliothèque
| |
| − | | |
| − | | |
| − | | |
| − | | |
| − | Figure 7. Source XML de la description d'un DD
| |
| − | | |
| − | | |
| − | | |
| − | | |
| − | | |
| − | ==11 Conclusion et perspectives==
| |
| − | | |
| − | Le projet C2M a permis d'aboutir au logiciel Scenari4, disponible
| |
| − | sous licence FLOSS, qui propose une solution unique pour
| |
| − | l'édition collaborative de documents structurés et fragmentés,
| |
| − | indépendamment de tout modèle de document et de tout
| |
| − | processus de collaboration a priori. Ce produit a été présenté
| |
| − | aux salons Documation et Elearning Expo et est d'ors et déjà
| |
| − | valorisé par Kelis avec ses clients (Essilor, Total, ENFIP,
| |
| − | Ucanss...) et dans le cadre de nouveaux projets, comme le site
| |
| − | service-public.fr, dont Kelis a remporté l'appel en mars 2012.
| |
| − | La recherche et développement de Scenari4 est également
| |
| − | poursuivie au travers de contextes expérimentaux : l'Ina pour la
| |
| − | valorisation d'archives radiophoniques ; la société de
| |
| − | restauration Quick pour la création d'une base de ressources
| |
| − | communes entre différents départements ; l’institut de
| |
| − | formation burkinabé 2IE pour la mise en place d'une base
| |
| − | documentaire pédagogique multi-contextes ; ou le laboratoire
| |
| − | Costech pour la mise en place d'une revue électronique
| |
| − | (C2M:L4c)(C2M:L4d). Ces différents terrains permettent
| |
| − | d'instancier plusieurs modèles de chaîne éditoriale
| |
| − | collaborative, et ainsi de mieux cerner les fonctions nécessaires,
| |
| − | ainsi que leurs variations en fonction des contextes. Deux
| |
| − | démonstrateurs ont également été implémentés avec Scenari4
| |
| − | afin d'illustrer ses nouveaux potentiels. Graphene pour la
| |
| − | documentation technique collaborative (C2M:L5c), et
| |
| − | Webmedia2 pour la publication multimédia de web-conférences,
| |
| − | web-documentaires, web-clips... (C2M:L4d)
| |
| − | | |
| − | Enfin deux thèses CIFRE UTC-Kelis prolongent les recherches
| |
| − | théoriques. La première, commencée en septembre 2011,
| |
| − | cherche à approfondir la question de la modélisation des
| |
| − | processus collaboratifs en relation avec les structures
| |
| − | documentaires, pour rationaliser la spécialisation du logiciel en
| |
| − | fonction du contexte. La seconde, prévue en 2012, vise à établir
| |
| − | des outils philologiques d'analyse des documents structurés et
| |
| − | fragmentés pour aider les rédacteurs dans leurs décisions face à
| |
| − | la dynamique du système (C2M:L5f).
| |
| − | | |
| − | ==12 Remerciements==
| |
| − | | |
| − | L'auteur remercie l'ANR pour son soutien, l'ensemble des
| |
| − | acteurs du projet C2M, et Sylvain Spinelli pour le formidable
| |
| − | travail de conception et de développement réalisé sur Scenari4.
| |
| − | | |
| − | ==13 Références==
| |
| − | | |
| − | ==13.1 Bibliographie==
| |
| − | | |
| − | André J., Furuta R., Quint V. (1989). Structured documents.
| |
| − | Cambridge University Press.
| |
| − | | |
| − | | |
| − | Bachimont B., Crozat S. (2004). Instrumentation numérique des
| |
| − | documents : pour une séparation fonds/forme. Revue I3, vol 4,
| |
| − | num 1.
| |
| − | | |
| − | Bachimont B. (2007). Ingénierie des connaissances et des
| |
| − | contenus : le numérique entre ontologies et documents.
| |
| − | Lavoisier. Hermès.
| |
| − | | |
| − | Crozat S. (2007). Scenari, la chaîne éditoriale libre. Eyrolles.
| |
| − | | |
| − | Dupoirier G. (1995). Technologie de la GED : Techniques et
| |
| − | management des documents électroniques. Hermes.
| |
| − | | |
| − | Gaillard L. (2010). Modélisation rhétorique pour la publication de
| |
| − | discours multimédias : applications audiovisuelles. Thèse de
| |
| − | doctorat de l'UTC.
| |
| − | | |
| − | Geurts J., Morizet-Mahoudeaux P., Crozat S. (2011). Édition
| |
| − | collaborative de documents fragmentés. Actes du colloque
| |
| − | IC2011, Paris.
| |
| − | | |
| − | Nelson, T. H. (1981). Literary Machines. Mindful Press.
| |
| − | Pédauque R. T. (2005). Le texte en jeu : Permanence et
| |
| − | transformations du document. [http://archivesic.ccsd.cnrs.fr/
| |
| − | docs/00/06/26/01/PDF/sic_00001401.pdf]
| |
| − | | |
| − | Vu X. T., Morizet-Mahoudeaux P., Geurts J., Crozat S. (2011).
| |
| − | Extension d'un algorithme Diff & Merge au Merge Interactif de
| |
| − | documents structurés. Actes du colloque CIDE.14 "Le document
| |
| − | à l'ère de la différenciation numérique", Rabat, Maroc.
| |
| − | | |
| − | Wilde E., Lowe D. (2002). XPath, XLink, XPointer, and XML: A
| |
| − | practical guide to Web hyperlinking and transclusion. Pearson
| |
| − | Education.
| |
| − | | |
| − | 13.2 Références Internet
| |
| − | | |
| − | ANR. L'Agence Nationale de la Recherche. [http://www.agencenationale-
| |
| − | recherche.fr].
| |
| − | | |
| − | C2M. Chaînes éditoriales Collaboratives Multimédia.
| |
| − | [http://www.utc.fr/ics/c2m].
| |
| − | | |
| − | Cap Digital. Business cluster for digital content.
| |
| − | [http://www.capdigital.com].
| |
| − | | |
| − | DITA. Darwin Information Typing Architecture (DITA) Version
| |
| − | 1.2. OASIS standard. [http://docs.oasis-open.org/dita/v1.2/spec/
| |
| − | DITA1.2-spec.html]
| |
| − | | |
| − | OrientDB. The NoSQL Graph-Document DBMS.
| |
| − | [http://www.orientdb.org]
| |
| − | | |
| − | Scenari. scenari-platform.org : portail de la communauté
| |
| − | Scenari. [http://scenari-platform.org]
| |
| − | | |
| − | | |
| − | Systematic. Paris region systems ans ICT cluster.
| |
| − | [http://www.systematic-paris-region.org].
| |
| − | | |
| − | 13.3 Livrables du projet C2M
| |
| | | | |
| − | Tous les livrables du projet C2M, référencés (C2M:LXx) sont
| + | {{Fin 2 colonnes}} |
| − | consultables via la section "Livrables" du site
| + | ==Installation en cours== |
| − | http://www.utc.fr/ics/c2m.
| + | Voir [[Projets:Installation]] |
