imported>Rkya Hemi |
imported>Rkya Hemi |
Ligne 35 : |
Ligne 35 : |
| génération, modèle documentaire. | | génération, modèle documentaire. |
| | | |
− | Abstract. | + | Abstract. This paperexamines digital publishing chains, i.e. systems which assist the production and publication of structured documents, especially their design processes. |
− | This | + | After reassertingthe issue of structured document and the subject of |
− | paper
| + | document engineering, we will compare the notions of universal and dedicated document model. |
− | examines
| + | We will then introduce the concept of generating function from Cassirer and combine with the concept of document primitive : a computer code which abstracts the essential principles of document objects to enable the generation of specific code instantiating multiple document models. We will show that the |
− | digital publishing chains, | + | state of the art is divided between solutions favouring efficiency over variability (ability to adapt to the context) by the use of universal document models, and solutions that promote variability at the expense of efficiency through the use of |
− | i. | + | dedicated models. We will defend that a level of abstraction is missing in orderto implement systems which combine efficiency and variability. |
− | e. | + | Our contribution is a formalisation of the Scenari system, |
− | systems which | + | a publishing chains design system developed in 2004. Stemming from works to optimize the design stage of publishing chains, the |
− | assist the production and publ | + | Scenari system offers a level of abstraction through primitives, and can design custom publishing chains with innovative use and economic performance. |
− | ication of structured documents
| + | Keywords. structured document, publishing chain, abstraction, generation, document model. |
− | , especially their | |
− | design processes | |
− | . | |
− | After | |
− | reasserting
| |
− | the issue of
| |
− | structured document an | |
− | d the subject
| |
− | of | |
− | document | |
− | engineering, we will compare the notions of | |
− | universa
| |
− | l
| |
− | and dedicated | |
− | document | |
− | model | |
− | . | |
− | W
| |
− | e
| |
− | will | |
− | then | |
− | introduce the | |
− | concept of generating function | |
− | from | |
− | Cassirer | |
− | and | |
− | combine with | |
− | the concept of | |
− | docu
| |
− | m
| |
− | ent
| |
− | primitive | |
− | : a computer code | |
− | w
| |
− | h
| |
− | ich
| |
− | abstrac
| |
− | t
| |
− | s
| |
− | the essential principles of document objects to enable | |
− | the | |
− | generation | |
− | of specif | |
− | ic code instantiating multiple
| |
− | document | |
− | models | |
− | . We will show that the | |
− | state of the art is divided between | |
− | solutions favo | |
− | u
| |
− | ring efficiency over
| |
− | variability | |
− | (ability to adapt to the context) by the use of universal | |
− | document | |
− | models, and | |
− | solutions that promote variability at the expense of efficiency through the use of | |
− | dedicated models. We will defend | |
− | that | |
− | a level of | |
− | abstraction | |
− | is mi | |
− | ssing in order
| |
− | to implement
| |
− | system
| |
− | s
| |
− | which | |
− | combine | |
− | efficiency and variability | |
− | . | |
− | Our contribution is a formali | |
− | s
| |
− | a
| |
− | tion of the
| |
− | Scenari | |
− | system, | |
− | a | |
− | publishing chains | |
− | design | |
− | system | |
− | developed in 2004. Stemming from work | |
− | s
| |
− | to optimize the design | |
− | stage | |
− | of publishing chains, the | |
− | Scenari | |
− | system offers a | |
− | level of abstraction | |
− | through primitives, and can | |
− | design custom publishing chains | |
− | with | |
− | innovative | |
− | use and | |
− | economic performance | |
− | . | |
− | Keywords | |
− | . structured document, publishing chain, abstraction, generation, | |
− | document model.
| |
− | 1
| |
− | Introduction
| |
− | Le document est un objet dont l’usage s’est considérablement démocratisé
| |
− | depuis l’avènement du numérique (P
| |
− | édauque, 2003). Les contextes donnant l
| |
− | ieu
| |
− | à l’écriture d’un document
| |
− | s
| |
− | e sont démultipliés, devenant un objet d’étude à part
| |
− | entière. Nous citons pour l’exemple l’étude de Zacklad (Zacklad, 2007) qui
| |
− | répertorie ces contextes en domaines
| |
− | : «
| |
− | l
| |
− | e domaine esth
| |
− | étique» (œuvres
| |
− | artistiques)
| |
− | ; «le domaine affectif
| |
− | -
| |
− | fictionnel» (œuvres fictionnelles)
| |
− | ; «le
| |
− | domaine politico
| |
− | -
| |
− | spirituel» (doctrines politiques, livres sacrés)
| |
− | ; «le domaine
| |
− | moral
| |
− | -
| |
− | idéologique» (documents militants, pratiques liturgiques)
| |
− | ; «le domaine
| |
− | s
| |
− | cientifique»
| |
− | (résultats
| |
− | et
| |
− | vulgarisations
| |
− | scientifiques,
| |
− | documents
| |
− | pédagogiques)
| |
− | et «le domaine pratique
| |
− | -
| |
− | efficace» (documentation technique,
| |
− | juridique, administrative).
| |
− | Dans cette contribution, nous nous intéressons à des contextes de forte
| |
− | production de d
| |
− | ocuments relativement homogènes (en reprenant les domaines
| |
− | de Zacklad, nous nous situons principalement dans les domaines «pratique
| |
− | -
| |
− | efficace» et «scientifique»). L’ingénierie documentaire a répondu à la
| |
− | problématique de production de masse en faisant émerg
| |
− | er la notion de
| |
− | document structuré (André
| |
− | et
| |
− | al.
| |
− | , 1988). Son enjeu est de contrôler
| |
− | l’homogénéité des documents par des structures qui s’articulent intimement
| |
− | avec les logiques applicatives d’édition, de manipulation et de publication. Cette
| |
− | mise en éviden
| |
− | ce de la structure permet d’instrumenter la séparation entre le
| |
− | fond et la forme
| |
− | -
| |
− | ou entre le fonds documentaire et ses formes (Bachimont &
| |
− | Crozat, 2004)
| |
− | -
| |
− | permettant ainsi une automatisation de la manipulation
| |
− | documentaire. Les logiciels instrumentant ce
| |
− | tte situation d’écriture sont appelés
| |
− | Cha
| |
− | înes éditoriales numériques :
| |
− | allier efficacité et
| |
− | variabilité gr
| |
− | âce à des
| |
− | primi
| |
− | tives documentaires
| |
− | 3
| |
− | des chaînes éditoriales XML (Crozat, 2007). Ils permettent l'écriture d'un
| |
− | contenu en se conformant à un modèle préalablement défini. La publication
| |
− | s'opère par des transformations automatiques vers des standards tel
| |
− | s
| |
− | q
| |
− | ue PDF
| |
− | ou HTML.
| |
− | Nous qualifierons les chaînes éditoriales en fonction de deux critères
| |
− | : leur
| |
− | faculté à s’adapter à un nouveau contexte, la
| |
− | variabilité
| |
− | ; leur apport pour la
| |
− | production et la maintenance, l’
| |
− | efficacité
| |
− | .
| |
− | Un des objectifs majeurs de l’ingéni
| |
− | erie documentaire est de maintenir la
| |
− | variabilité des contenus
| |
− | -
| |
− | pour respecter la spécificité de chaque contexte
| |
− | d’usage
| |
− | -
| |
− | tout en améliorant l’efficacité de leur gestion
| |
− | -
| |
− | pour gérer la
| |
− | massification.
| |
− | 2
| |
− | Modèle universel versus modèle dédié
| |
− | La notion de doc
| |
− | ument structuré suppose de formaliser un modèle de
| |
− | représentation du document permettant d’en contrôler les opérations (Barron,
| |
− | 1989) (Piwowarski
| |
− | et
| |
− | al.
| |
− | , 2002).
| |
− | 2.1
| |
− | Modèle documentaire dédié
| |
− | Un modèle dédié est un modèle documentaire spécifique à un contexte
| |
− | d
| |
− | ’usage métier en particulier. Le besoin documentaire est analysé puis formalisé
| |
− | dans un modèle, comprenant des schémas structurels, des interfaces d’éditions,
| |
− | des programmes de validation, de transformation... Historiquement portées par
| |
− | SGML ces approches
| |
− | sont aujourd’hui ancrées dans les technologies XML
| |
− | :
| |
− | Schema, XSLT, DOM...
| |
− | L’intérêt du modèle dédié est par construction son adéquation au contexte
| |
− | adressé. C’est la solution juste nécessaire au problème, permettant de traiter des
| |
− | structures documentaire
| |
− | s métiers (tableaux comptables, scénarios pédagogiques,
| |
− | plans numériques, formats dédiés...) sans scories héritées de fonctions liées à
| |
− | d’autres contextes d’usage.
| |
− | L’utilisation d’un modèle dédié impose une forte spécificité de la chaîne
| |
− | éditoriale. Nous p
| |
− | arlerons d’une approche par
| |
− | création
| |
− | car la chaîne éditoriale
| |
− | doit être développée
| |
− | ex nihilo
| |
− | , permettant ainsi de répondre finement à la
| |
− | problématique de la variabilité. Ce gain se paie sur l’efficacité du processus,
| |
− | notamment en raison des coûts de mise
| |
− | œuvre à l’initialisation, puis en
| |
− | maintenance. La chaîne étant fortement adhérente au contexte par construction,
| |
− | elle devient obsolète dès l’évolution de ce contexte et requiert par conséquent
| |
− | des moyens de maintenance importants. Cette barrière rend cett
| |
− | e approche
| |
− | adaptée uniquement à des usages de niche et aux contextes relativement stables
| |
− | du point de vue des formats documentaires (presse, documentation technique
| |
− | des industries sensibles...).
| |
− | 2.2
| |
− | Modèle documentaire universel
| |
− | Un modèle universel est au cont
| |
− | raire un modèle à forte valeur de généralité
| |
− | visant à circonscrire l’ensemble des usages pour une famille de contextes.
| |
− | Généralement porté
| |
− | s
| |
− | par un standard (W3C, OASIS...), les modèles universels
| |
− | visent l’intégration d’un très large ensemble de besoins, et
| |
− | misent sur la
| |
− | mutualisation des développements autour du standard. On citera par exemple
| |
− | DITA, DocBook,
| |
− | ou la partie sémantique de HTML
| |
− | 1
| |
− | .
| |
− | 1
| |
− | http://dev.w3.org/html5/html
| |
− | -
| |
− | author/#understanding
| |
− | -
| |
− | semantics
| |
− | Cha
| |
− | înes éditoriales numériques :
| |
− | allier efficacité et
| |
− | variabilité gr
| |
− | âce à des
| |
− | primi
| |
− | tives documentaires
| |
− | 7
| |
− | Figure
| |
− | 1.
| |
− | Processus documentaires instrumentés par la chaîne éditoriale Quick
| |
− | (
| |
− | http://scenari.utc.fr/c2m/DOCS/L4d/html/co/quick4.html
| |
− | )
| |
− | Pour une société comme Quick, la documentation est un enjeu important
| |
− | sans toutefois être son cœur de métier et justifier un investissement trop
| |
− | important. Dan
| |
− | s cette situation multi
| |
− | -
| |
− | contextes, accompagnée d'un besoin pluri
| |
− | -
| |
− | média, les approches classiques de conception de chaîne éditoriale
| |
− | sont mal
| |
− | adaptées
| |
− | . Le développement d'une chaîne éditoriale ex nihilo couvrant
| |
− | l'ensemble des contextes d'usage nécessite un
| |
− | investissement initial
| |
− | trop
| |
− | important.
| |
− | L
| |
− | a complexité du contexte n'est pas directement adressable par un
| |
− | modèle universel, l'effort de déclinaison serait trop important
| |
− | quel que soit
| |
− | le
| |
− | standard
| |
− | (réutilisation inter
| |
− | -
| |
− | documents DH, bible, supports de
| |
− | formation
| |
− | ;
| |
− | gestion de QCM
| |
− | ; publications pour mobiles
| |
− | ; dérivations internationales...)
| |
− | 4.2
| |
− | Instrumentation Scenari
| |
− | Le système Scenari propose un principe de primitives documentaires
| |
− | permettant de modéliser les documents à manipuler et un système de primiti
| |
− | ves
| |
− | de transform
| |
− | ation dédié à la définition des
| |
− | publications associées. Il existe
| |
− | plusieurs types de primitives (composition de primitives, méta
| |
− | -
| |
− | données
| |
− | associées, structuration de texte, inclusion de ressources binaires, etc.), qui une
| |
− | fois agencées, per
| |
− | mettent de définir de nombreux modèles.
| |
− | Définition du modèle
| |
− | Les primitives documentaires et les primitives de transformation utilisées
| |
− | par le système Scenari s'expriment dans un formalisme XML. Les encadrés 1 et
| |
− | 2 donnent des exemples simplifiés de ces p
| |
− | rimitives. L'encadré 1 définit une
| |
− | «
| |
− | Fiche savoir
| |
− | -
| |
− | faire
| |
− | » comme la composition d'autres primitives
| |
− | : des
| |
− | métadonnées (
| |
− | procM.model
| |
− | ), une première partie «
| |
− | Contexte
| |
− | » (
| |
− | co.model
| |
− | ),
| |
− | suivi
| |
− | e
| |
− | d'une «
| |
− | Procédure
| |
− | » (
| |
− | stepList.model
| |
− | ). L'encadré 2 définit une publication
| |
− | de ce type de fiche pour XHTML, en associant les parties à des blocs titrés
| |
− | (
| |
− | W
| |
− | H
| |
− | eadingBlock
| |
− | ) et des classes qui seront stylées en CSS.
| |
− | <compositionPrim
| |
− | name
| |
− | =
| |
− | "Fiche savoir
| |
− | -
| |
− | faire"
| |
− | >
| |
− | <identification
| |
− | code
| |
− | =
| |
− | "proc"
| |
− | />
| |
− | <structure>
| |
− | <meta
| |
− | refUri
| |
− | =
| |
− | "/qkDoss/model/co
| |
− | ntent/proc/procM.model"
| |
− | usage
| |
− | =
| |
− | "required"
| |
− | />
| |
− | <part
| |
− | code
| |
− | =
| |
− | "context"
| |
− | name
| |
− | =
| |
− | "Contexte"
| |
− | family
| |
− | =
| |
− | "sub
| |
− | -
| |
− | level"
| |
− | usage
| |
− | =
| |
− | "optional"
| |
− | >
| |
− | <allowedModel
| |
− | refUri
| |
− | =
| |
− | "/qkDoss/model/base/co.model"
| |
− | />
| |
− | </part>
| |
− | <part
| |
− | code
| |
− | =
| |
− | "stepList"
| |
− | name
| |
− | =
| |
− | "Procédure : liste d'étapes"
| |
− | family
| |
− | =
| |
− | "sub
| |
− | -
| |
− | level"
| |
− | usage
| |
− | =
| |
− | "required"
| |
− | >
| |
− | <allowedModel
| |
− | refUri
| |
− | =
| |
− | "/qkDoss/model/content/proc/stepList.model"
| |
− | />
| |
− | </part>
| |
− | </structure>
| |
− | </compositionPrim>
| |
− | Encadré
| |
− | 1.
| |
− | exemple simplifié de primitive documentaire
| |
− | CIDE.15
| |
− | Novembre 2012
| |
− | 8
| |
− | <compositionXhtmlTransf
| |
− | >
| |
− | <model
| |
− | refUri
| |
− | =
| |
− | "/qkDoss/model/con
| |
− | tent/proc/proc.model"
| |
− | />
| |
− | <content
| |
− | format
| |
− | =
| |
− | "xhtml"
| |
− | >
| |
− | <inDataOrder>
| |
− | <for
| |
− | codes
| |
− | =
| |
− | "context"
| |
− | >
| |
− | <WHeadingBlock
| |
− | widgetClass
| |
− | =
| |
− | "bk_context"
| |
− | >
| |
− | <title>
| |
− | <subModelTitle/>
| |
− | <fixedTitle
| |
− | value
| |
− | =
| |
− | "Contexte"
| |
− | />
| |
− | </title>
| |
− | <callSubModel/>
| |
− | </WHeadi
| |
− | ngBlock>
| |
− | </for>
| |
− | <for
| |
− | codes
| |
− | =
| |
− | "stepList"
| |
− | >
| |
− | <WHeadingBlock
| |
− | widgetClass
| |
− | =
| |
− | "bk_stepList"
| |
− | >
| |
− | <title>
| |
− | <subModelTitle/>
| |
− | <fixedTitle
| |
− | value
| |
− | =
| |
− | "Procédure"
| |
− | />
| |
− | </title>
| |
− | <callSubModel/>
| |
− | </WHeadingBlock>
| |
− | </for>
| |
− | </inDataOrder>
| |
− | </conte
| |
− | nt>
| |
− | </compositionXhtmlTransf>
| |
− | Encadré 2
| |
− | .
| |
− | exemple simplifié de primitive de transformation
| |
− | Pour simplifier l' écriture, la gestion et la maintenance des primitives, le
| |
− | système Scenari propose un éditeur XML dédié à travers son outil de
| |
− | modélisation SCENA
| |
− | RIbuilder (voir figure 2).
| |
− | Figure 2
| |
− | .
| |
− | Éditeur XML de primitives dans SCENARIbuilder
| |
− | SCENARIbuilder permet ensuite la compilation des primitives
| |
− | documentaires déclarées pour générer un code source spécifique à Quick, qui
| |
− | sera interprété par le code génér
| |
− | ique de Scenari à travers l'outil SCENARIchain.
| |
− | Le résultat de la compilation est compressé dans une archive dédiée (
| |
− | wsppack
| |
− | ),
| |
− | une fois chargée dans
| |
− | SCENARIchain
| |
− | ,
| |
− | la chaîne éditoriale est prête à l'emploi
| |
− | (figure 3). Elle propose alors un éditeur XML dédié
| |
− | au modèle (figure 4), des
| |
− | Cha
| |
− | înes éditoriales numériques :
| |
− | allier efficacité et
| |
− | variabilité gr
| |
− | âce à des
| |
− | primi
| |
− | tives documentaires
| |
− | 9
| |
− | logiques applicatives de gestion posées par les primitives documentaires (par
| |
− | exemple l'adaptation au contexte international, visible via les drapeaux dans
| |
− | l'éditeur) et des publications posées par les primitives de transformation
| |
− | (par
| |
− | exemple la publication XHTML, figure 5).
| |
− | Figure 3
| |
− | .
| |
− | Architecture Scenari de génération et exécution de code spécifique
| |
− | Figure 4
| |
− | .
| |
− | Éditeur XML de fiche savoir
| |
− | -
| |
− | faire Quick
| |
− | CIDE.15
| |
− | Novembre 2012
| |
− | 10
| |
− | F
| |
− | igure 5
| |
− | .
| |
− | Publication HTML d'une fiche savoir
| |
− | -
| |
− | faire Quick
| |
− | 5
| |
− | Conclusion
| |
− | À t
| |
− | ravers cette contribution, nous avons souhaité montrer les limites de
| |
− | l’ingénierie documentaire traditionnelle qui privilégie la variabilité ou l’efficacité,
| |
− | mais peine à concilier les deux. L’abstraction que constitue le modèle d’un
| |
− | document structuré est
| |
− | le premier niveau traditionnellement mobilisé pour
| |
− | monter en efficacité tout en gérant la variabilité documentaire au sein d’une
| |
− | même chaîne éditoriale
| |
− | : le modèle permet de gérer la variabilité de documents
| |
− | qui se ressemblent (ils respectent un même sch
| |
− | éma, mobilisent les mêmes
| |
− | transformations...).
| |
− | En revanche cette solution ne permet pas de gérer efficacement la
| |
− | variabilité de documents qui ne ressemblent pas
| |
− | : à chaque nouveau modèle de
| |
− | document, il faut soit décliner une chaîne existante si le modèle
| |
− | est proche d’un
| |
− | cas maîtrisé, soit réinventer la chaîne
| |
− | ex nihilo
| |
− | lorsque la variation est trop forte.
| |
− | Or ces documents qui ne se ressemblent pas, présentent néanmoins des
| |
− | propriétés intrinsèques que l’on retrouve d’un modèle à l’autre, et qu’il est
| |
− | possi
| |
− | ble d’exprimer sous la forme de fonctions génératrices capables
| |
− | d’engendrer le code spécifique d’un modèle particulier.
| |
− | C’est ce second niveau d’abstraction, celui des primitives documentaires,
| |
− | qui permet de gérer la variabilité des modèles documentaires (
| |
− | au delà de la
| |
− | variabilité des instances gérée par les modèles) tout en conservant un niveau
| |
− | d’efficacité compatible avec la plupart des contextes professionnels.
| |
− | Dans le cas des restaurants Quick, le modèle est complexe mais la solution
| |
− | conçue s'adapte né
| |
− | anmoins aux contextes d'usage dans toutes leurs spécificités.
| |
− | L'utilisation du système Scenari a permis d'adresser la variabilité des contextes
| |
− | d'usage et le principe de modélisation par primitive a été mis à profit pour
| |
− | mutualiser de nombreux aspects du
| |
− | modèle avec des contextes standards, et
| |
− | ainsi maintenir le projet dans une économie acceptable. Le principe de
| |
− | conception utilisé dans Scenari permet ainsi des performances de conception et
| |
− | Cha
| |
− | înes éditoriales numériques :
| |
− | allier efficacité et
| |
− | variabilité gr
| |
− | âce à des
| |
− | primi
| |
− | tives documentaires
| |
− | 11
| |
− | de maintenance inédites. Depuis son développement, l'outil SCENARI
| |
− | builder
| |
− | dédié à l'écriture et à la génération des primitives a permis la diminution du
| |
− | temps nécessaire à la production du code source spécifique d'un facteur de un à
| |
− | dix au minimum (observations empiriques réalisées sur les projets menés par la
| |
− | société Ke
| |
− | lis). Les compétences nécessaires à la conception d'une chaîne
| |
− | éditoriale se sont par ailleurs déplacées d'un niveau technique de type
| |
− | développement informatique à un niveau plus fonctionnel de type modélisation
| |
− | documentaire. Ce glissement renforce l'exper
| |
− | tise documentaire des concepteurs
| |
− | et permet d'améliorer l'efficacité de la conception et la qualité des chaînes
| |
− | produites.
| |
− | Nos prochains travaux seront consacrés à l’étude d’un nouveau niveau
| |
− | d’abstraction, complémentaire des primitives documentaires, perm
| |
− | ettant la
| |
− | génération de logiques applicatives d’
| |
− | écriture collaborative
| |
− | . Dans le cadre du projet
| |
− | ANR C2M
| |
− | 4
| |
− | ,
| |
− | le concept de chaîne éditoriale collaborative a été étudié et
| |
− | instancié dans le logiciel Scenari4. L’enjeu est à présent de concevoir un niveau
| |
− | d’abstra
| |
− | ction pour cette dimension collaborative qui soit cohérent avec celui
| |
− | défini pour la dimension documentaire et permette le même gain autour des
| |
− | enjeux de variabilité et d'efficacité.
| |
− | Références
| |
− | A
| |
− | NDRE
| |
− | ,
| |
− | J.,
| |
− | F
| |
− | URUTA
| |
− | ,
| |
− | R.
| |
− | ,
| |
− | Q
| |
− | UINT
| |
− | ,
| |
− | V.
| |
− | (1988).
| |
− | Structured Documents
| |
− | . Cambridge
| |
− | University Press, the cambridge series on electronic publishing edition.
| |
− | B
| |
− | ACHIMONT
| |
− | ,
| |
− | B.,
| |
− | C
| |
− | ROZAT
| |
− | ,
| |
− | S.
| |
− | (2004). Instrumentation numérique des documents
| |
− | : pour une séparation fonds/forme.
| |
− | Revue I3
| |
− | ,
| |
− | vol.
| |
− | 4
| |
− | ,
| |
− | 95
| |
− | –
| |
− | 104.
| |
− | B
| |
− | ARRON
| |
− | ,
| |
− | D.
| |
− | (1989).
| |
− | Why use sgml?
| |
− | E
| |
− | lectronic publishing
| |
− | ,
| |
− | vol.
| |
− | 2
| |
− | ,
| |
− | 3
| |
− | –
| |
− | 24.
| |
− | C
| |
− | ASSIRER
| |
− | ,
| |
− | E.
| |
− | (1910).
| |
− | Substance et Fonction
| |
− | . Berlin.
| |
− | C
| |
− | ROZAT
| |
− | ,
| |
− | S.
| |
− | (2007).
| |
− | Scenari
| |
− | : la chaîne éditoriale libre
| |
− | : Structurer et publier textes, images
| |
− | et son
| |
− | .
| |
− | Eyrolles, accès libre edition.
| |
− | K
| |
− | ENT
| |
− | ,
| |
− | S.
| |
− | (2002). Model driven eng
| |
− | ineering.
| |
− | Integrated Formal Methods
| |
− | -
| |
− | Lecture
| |
− | Notes in Computer Science
| |
− | ,
| |
− | vol.
| |
− | 2335
| |
− | ,
| |
− | 286
| |
− | –
| |
− | 298.
| |
− | P
| |
− | IWOWARSKI
| |
− | ,
| |
− | B.,
| |
− | D
| |
− | ENOYER
| |
− | ,
| |
− | L.
| |
− | ,
| |
− | G
| |
− | ALLINARI
| |
− | ,
| |
− | P.
| |
− | ,
| |
− | (2002).
| |
− | Un modèle pour la
| |
− | recherche d’information sur des documents structurés. In
| |
− | JAdT
| |
− | : 6es Journées
| |
− | internationales
| |
− | d’Analyse statistique des Données Textuelles
| |
− | .
| |
− | P
| |
− | EDAUQUE
| |
− | ,
| |
− | R.
| |
− | T.
| |
− | (2003). Document
| |
− | : forme, signe et médium, les
| |
− | reformulations du numérique.
| |
− | R
| |
− | ECKER
| |
− | ,
| |
− | J.,
| |
− | M
| |
− | ENDLING
| |
− | ,
| |
− | J.,
| |
− | VAN
| |
− | DER
| |
− | A
| |
− | ALST
| |
− | ,
| |
− | W.
| |
− | ,
| |
− | R
| |
− | OSEMANN
| |
− | ,
| |
− | M.
| |
− | (2006). Model
| |
− | -
| |
− | driven enterprise systems configuration.
| |
− | Adv
| |
− | anced Information Systems Engineering
| |
− | -
| |
− | Lecture Notes in Computer Science
| |
− | ,
| |
− | vol.
| |
− | 4001
| |
− | ,
| |
− | 369
| |
− | –
| |
− | 383.
| |
− | S
| |
− | TIG
| |
− | N
| |
− | ORDHEIM
| |
− | ,
| |
− | T.
| |
− | P.
| |
− | (2004). Customization of enterprise content
| |
− | management systems
| |
− | : An exploratory case study. In
| |
− | Proceedings of the 37th Hawaii
| |
− | International
| |
− | Conference on System Sciences
| |
− | .
| |
− | 4
| |
− | www.utc.fr/ics/c2m
| |
− | CIDE.15
| |
− | Novembre 2012
| |
− | 12
| |
− | Z
| |
− | ACKLAD
| |
− | ,
| |
− | M.
| |
− | (2007). Réseaux et communautés d’imaginaire documédiatisées.
| |
− | In
| |
− | A Document (Re)turn
| |
− | .
| |
− | AM
| |
− | M
| |
− | AIN
| |
− | ,
| |
− | F.
| |
− | (
| |
− | Ed.
| |
− | )
| |
− | , Roswitha Skare and Andreas
| |
− | Varheim and Niels Windfeld Lund.
| |
− | Z
| |
− | INA
| |
− | ,
| |
− | S.,
| |
− | L
| |
− | OMBARD
| |
− | ,
| |
− | M.,
| |
− | L
| |
− | OSSENT
| |
− | ,
| |
− | L.
| |
− | ,
| |
− | H
| |
− | ENRIOT
| |
− | ,
| |
− | C.
| |
− | (
| |
− | 2006).
| |
− | Generic modeling
| |
− | and configuration management in product lifecycle management.
| |
− | International
| |
− | Journal of Computers, Communications & Control
| |
− | , 126
| |
− | –
| |
− | 138.
| |