Disambiguation, Linking and Visualisation of References in TEI Digital Editions

Introduction

As Susan Schreibman (2014) points out, a digital edition, as opposed to a printed one, is never really complete as several layers of annotation may always be added to represent and enrich the original content. TEI [START_REF] Burnard | What Is the Text Encoding Initiative? How to Add Intelligent Markup to Digital Resources[END_REF] allows for several types of information -textual, linguistic and semantic -to be layered and made explicit and retrievable by a machine. Such is the case for instance with what is commonly known as semantic tagging.

In this paper, we focus on Named Entities (NE), in particular names of Persons and Geographical Places. Adding NE mentions is supported by TEI with appropriate tags (such as <persName> and <placeName>), whose addition in a digital critical edition has somewhat the same function that indexes of places and persons have in a printed one. As mentions may be ambiguous (same string for different people, same place with different names,....) some referencing and disambiguating identifiers are required. But digital editions allow for much more than simple internal referencing. By pointing to external sources, structured information contained in the form of linked data in the semantic web becomes available to scholarly research.

In this work we present REDEN ONLINE, a system that enables scholars to automatically add external references to annotations of persons and places. The system is a web interface taking TEI as input, where mentions are already marked up, and automatically disambiguates and links such entities to an appropriate linked data set using a graph based algorithm for disambiguation. Moreover, our system provides data aggregation and visualization facilities by using the information found in the reference sources.

Previous work and general context

Semantic tagging is a hot topic in the digital humanities. Tools for semantic enrichment are, such as Pundit [START_REF] Grassi | Pundit: Semantically Structured Annotations for Web Contents and Digital Libraries[END_REF][START_REF] Grassi | Pundit: Augmenting Web Contents with Semantics[END_REF], already available and allow for the interactive and intuitive annotation of portions of text. Automatic Named Entity Recognition and Linking techniques may be implemented to detect mentions and to suggest links to external knowledge bases.

Input formats to such systems may vary from plain text to html, but ideally a tool should process available standard formats, such as TEI-XML for text and RDF/OWL for information. Using linked data sources for disambiguation and enrichment is thus strongly recommended. By doing this, external sources of structured and regularly updated information can be made available to the scholar without having to be directly incorporated into the inline annotation, that can be left as simple as possible. This in turn allows for several customizable views, as linked data sources may be queried with the SPARQL query language to retrieve only the amount of external information that is necessary for a given task.

The treatment of spatial and temporal information is a typical task for which this approach is particularly effective; the availability of geographical databases and the complexity of the information are best accessed by pointing from within the digital edition to an external link. But also other types of semantic information seem to be particularly apt for connection to rich linked databases. So for instance bibliometric sources can be used to enrich texts with additional information on authors.

Typical targets for references are DBpedia and Geonames, that, for their genericity and connection to other sources, are at the heart of the linked data cloud. But they may be supplemented by more domain specific sources of information. For instance, Pleiades provides geo-historical information for ancient places.

Our project

REDEN ONLINE is set against the background of work carried out at LABEX OBVIL in Paris, where quality digital editions for French literary texts and criticism are produced and used in research and higher education. Recently a series of projects were carried out to semi-automatically annotate and reference places, organizations and authors. Gold standards were also produced, in close contact with researchers in French literature, so as to establish guidelines of annotation that best suit their ongoing research.

The general purpose is to provide tools for both: augmented close reading, to enable researchers to access more information on a specific text portion distant reading and data aggregation, so as to be able to detect trends in large portions of texts [START_REF] Moretti | Graphs, Maps, Trees: Abstract Models for a Literary History[END_REF] OBVIL literary scholars are interested in plotting the distribution of the mentions of given authors over time in French literary criticism, in order to study the appreciation of Molière over the centuries, or in producing charts representing the distributions of professions in authors mentioned in given periods, to trace the influence of scientists and their ideas on art and literature in the age of positivism [START_REF] Riguet | L'impact de la physiologie dans la critique littéraire de la fin du XIXe siècle : l'exemple de Claude Bernard, actes du colloque Littérature et Science au xixe siècle[END_REF]. Other visualizations captured the emerging influence of foreign countries in the French literary panorama over time by combining the date of the publication of the essays with the detected toponyms.

NLP technologies are used to facilitate various aspects of the semantic enrichment of TEI editions, in an annotation echosystem where texts are first processed and then manually checked. The detection of mentions of places, authors (and also organizations) was tackled by using a Named Entity Recognizer and Classifier (UNERD, [START_REF] Mosallam | Unsupervised Named Entity Recognition and Disambiguation: An Application to Old French Journals[END_REF].

Once the entities are correctly detected and classified, external references need to be added to disambiguate mentions and to connect them to additional information. To this purpose we developed REDEN , a Named Entity Linker that uses a graph-based algorithm and linked data sets to identify the correct referent for each mention ( REDEN's input consists of a TEI text with detected mentions and several parameters specifying among others the class of entities to be detected, the reference base to use and a set of pre-compiled indexes. REDEN is applied for each class of entities separately, and works at best when several mentions are disambiguated at the same time. It retrieves all candidate referents for each mention of a context (say a paragraph) and then all the available information from the semantic web. It builds a sub-graph of all http://dh2016.adho.org/abstracts/362 2/6

candidates and chooses the correct referents for each mention with the help of the formal relations between them. From Figure 1 you can get an intuition of how REDEN works.

Figure 1 The graph based algorithm disambiguates between different possible referents for the mentions of "Victor Hugo" (unambiguous in this example), "Lamartine" and "Vigny" (both having several candidate referents) based on information found in DBpedia. Correct referents (in grey) are chosen based on how well connected they are within the context Here the crucial node is clearly that of yago:RomanticPoets.

So far our efforts have concentrated on the production of a text annotation and referencing pipeline for the production of such enriched TEIs with annotated and referenced mentions. Their exploitation for data aggregation and visualization was carried out offline and with ad hoc processing tools. With REDEN ONLINE we now want to make linking technology available online while at the same time providing users with some generic visualization of the results.

In what follows, we present the REDEN ONLINE interface with some screenshots from an example where two texts of the Labex OBVIL digital library have been automatically linked to external sources, namely:

-L'Hérésiarque et cie, a collection of short stories by Guillaume Apollinaire, published in 1910 -place mentions linked to DBpedia entries.

-Réflexions sur la littérature a series of essays on French literary criticism by Albert Thibaudet, published in 1936 -author's mentions linked to entries in the linked data base of the Bibliothèque Nationale de France (BnF).

The user (Figure 2) loads a TEI text with annotated <placeName> or <personName> tags, chooses which class of entities to process (places or nouns) and the system runs the disambiguation and linking algorithm against the given linked data base -here French DBpedia and/or BnF. Then external information is extracted from the source and used for generating a particular view of the text. The result is a summing up of the disambiguated locations (some place names may be non resolvable because they are absent from the linked data base) and a visualization.

For locations the visualization consists in an interactive map that also takes frequency of mention into account. Coordinates are retrieved from DBpedia when available and the map can be zoomed in, up to the level of streets (see Figure 3 where some places in Paris have been identified in the text by Apollinaire), when relevant.

For persons (see Figure 4), portraits of authors are automatically downloaded and visualized.

Conclusion

The conference presentation will demonstrate REDEN ONLINE, a web based tool that enables researchers to connect place names and person names in their texts to existing linked data sources. The underlying technology will also be explained, in particular its use of standard formats, such as TEI and RDF for the linking algorithm, and GeoJSON for the creation of the map. We will also argue in favour of our economicity approach, namely the choice of not embedding semantic information in the TEI, which enables the use of different databases and the production of ad hoc "views" of the document.

It is well known that aggregation and visualizations techniques may "assist the critic in the unfolding of interpretive possibilities" [START_REF] Ramsay | Algorithmic Criticism. Companion to Digital Literary Studies[END_REF] when analysing texts. This tool has been particularly designed for the study of literature and literary criticism; in the presentation examples of use will be given using ongoing research on Apollinaire, highlighting how the visual representation of the itineraries contained in the stories may be considered as a form of novel "digital reading" of the text.

  Brando et al., 2015, Frontini et al., 2015a[START_REF] Frontini | Semantic Web based Named Entity Linking for Digital Humanities and Heritage Texts[END_REF] for the technical details).


Marc Lazareff

The Python user interface of the elsA cfd software: a coupling framework for external steering layers

Keywords: user interface, UX, context checking, CFD, Python, extensibility

The Python user interface of the elsA CFD software: a coupling framework for external steering layers

Introduction

elsA (http://elsa.onera.fr/) is a large cfd software for research and industry, mainly used in aerospace design, for both internal and external flow. It has been described before [START_REF] Gazaix | The elsA object-oriented computational tool for industrial applications[END_REF][START_REF] Cambier | An Overview of the Multi-Purpose elsA Flow Solver[END_REF].

Here we will be interested in the extension of the Python-elsA user interface to additional software, for performing simulations not only at a few discrete specified workflow conditions (e.g. given Mach, Reynolds . . . ) but on a domain of variation, i.e. a Design of Experiment space (doe), with several algorithmic layers added above the cfd solver.

The first step is to automate the spanning of a (given) large number of specified points covering the doe. The second one is to add a stabilization layer for prolongation through unstable doe zones (e.g. when the flow conditions lead to separation). The third one is to use the resulting "stabilized spanning" algorithm as a provider of observable quantities for a sparse polynomial interpolator, driving the simulation and selecting the doe points to compute. If successful, this composite algorithm pro-Email address: marc.lazareff@onera.fr (Marc Lazareff) vides (for the chosen observable) an efficient global representation (response surface) allowing further studies on the doe, at low cost; for example stochastic analysis using the Monte-Carlo method on the response surface would be a fourth step.

The specific point of interest of our approach is that, for this complex composite algorithm, we manage to keep the user interface simple and uniform, using the same concepts as for the base interface. Sections 2-4 explain these concepts; sections 5&6 deal with documentation, error messages, and the gui (Graphical User Interface); finally, sections 7-9 deal with high-level operations and how we use them for doe spanning and analysis. This paper includes a number of elements from the cfd application domain, and software considerations, along with user interface concepts; these concepts (and most of the software implementation) would be applicable to many different domains. Not included here are considerations for field-like data, for which the cfd General Notation System standard (cgns) is better suited1 .

Interface development orientation

User interaction model

In the development of the Python-elsA user interface, we strived to reach an equilibrium between power and usability, both on the user side (running simulations) and on the developer side (adding functionality); also, we have tried to avoid a steep user learning curve.

The Python-elsA user interface has been used since June 2000 with no change in its base principles (see section 2.2), and thus maybe it is not too far off its target demography. The basic interface is readily extended with additional classes allowing external algorithmic layers, see 8.1, to complement the cfd solver coded in the elsA kernel.

The Python-elsA interface is built on a declarative user interaction model (Wikipedia, 2016a), whereas similar software [START_REF] Gerhold | Tau-overview[END_REF] uses an imperative model (Wikipedia, 2016c). The scripts describing the elsA cfd simulations use context sharing to avoid data duplication; and all the tedious details which are possibly automated are kept hidden in the behaviour of the description classes.

The Python language has been a great help in building successive abstract layers. We generally try to go with the Principle of Least Astonishment [START_REF] Seebach | The cranky user: The principle of least astonishment[END_REF][START_REF] Ronacher | Python and the principle of least astonishment[END_REF], and to facilitate an object-oriented and functional (Wikipedia, 2016b;Backus, 1978a;[START_REF] Hudak | Conception, evolution and application of functional programming languages[END_REF] programming style, here in user scripts.

The (functional) Reverse Polish Lisp (rpl) language of some Hewlett-Packard handheld calculators, with its three language levels (User rpl, System rpl, compiled code) (Wikipedia, 2016d), has been the inspiration for an intermediate language where, as for System rpl, a faster checks-less interpreted code -usually generated on the fly from the User level -may be directly accessed by experts.

In Python-elsA, user interaction is mainly through argument-less method calls; this is possible because the would-be arguments are already known as attribute values of the method's owner object; these values may originate: a) from user specification, using the owner object's set() method, see 3.4.1; b) from context rulesset() terminator in contextdependent default rules for the owner objectpossibly involving dependencies on objects other than the method's owner, see 4.2.1; c) using the set() method in the behaviour logic of other objects, possibly also involving context rules (e.g. in coupled problems), see 9.2.

The user interaction model thus includes an explicit part (method calls in the user script) and an implicit part (context rules and other class-specific object behaviour), providing automatically-defined values. The latter part is essential, allowing for a lighter work burden and thus better efficiency and security in problem solving. The potential danger, regarding user confidence, of automatically-defined attribute values is alleviated by the display (view method, see 3.4.2) and introspection features of the interface (show_origin method, see 4.2.4).

Base principles, user & developer sides

The base elements and principles used in the development of this interface are:

For the user (U) side: For the developer (D) side:

D1. the api (Application Programming Interface) between the user interface and the elsA kernel is based on three basic typesfloat (floatingpoint), int (integer) and string -and a few methods and functions, see 3.4; D2. the evolving part of the interface is mainly described through resource files, see section 4, from which the documentation skeleton (L A T E X commands, see 5.2) is automatically generated in a coherent way; D3. functionality may be added through "products", see 8.1, the Python code for which is simply dropped in the adequate place, defining additional description classes; D4. obsolete elements of the interface, see 4.1.3, may be re-activated for version comparison.

Naming things

One important aspect of the interface -for which there are no exact rules and only a few general principles -is the naming of the various interface elements (especially attributes and their values), see 2.3. This aspect is more in the realm of linguistics, and must take into account the culture of the users.

Naming is recognized as a hard problem in software [START_REF] Deissenboeck | Concise and consistent naming[END_REF], and is all graph, traversed by the check() method, see 3.4.2, may be deep (have a large number of levels), see 4.2, and is not always a tree, see 4.2.1.

the more important when dealing with user interaction. In programming, users better understand long, self-explanatory, names [START_REF] Krikhaar | Identifier length and limited programmer memory[END_REF], but "The nonsense words did surprisingly well . . . distinctive names are helpful even when they are not meaningful" [START_REF] Shneiderman | Designing the User Interface: Strategies for Effective Human-Computer Interaction, 3rd Edition[END_REF].

It seems then that there is no symmetry between understanding which concept is behind a name and, inversely, remembering which name corresponds to the sought concept. It is probably better not to use long names which may differ only by one or two characters -better use shorter names where the differences stands out -or to use names with easily confused characters [START_REF] Kupferschmid | Classical Fortran: Programming for Engineering and Scientific Applications, Second Edition, 2nd Edition[END_REF]. Also, we have chosen the underscore style, e.g. global_timestep, for the user interface rather than "camel casing", e.g. GlobalTimestep, although the latter seems more popular with programmers [START_REF] Binkley | To camelcase or under_score[END_REF].

A balance must somehow be found, for users to be able both to read and write scripts without reaching for the documentation at every step. This part of the interface management is probably the most involved with language considerations, and the most dependent on user cultural background (e.g. when reusing variable names from equations).

Python-elsA description language

Python-elsA is built upon the Python language to create a standard of creation and modification of description (attributes container) and script (descriptions container) objects. Only the main elements of the language will be described here, hoping they give a taste of the chosen user interaction model. Both for the text-mode and graphical-mode interfaces, we have tried to respect the design principles of [START_REF] Shneiderman | Designing the User Interface: Strategies for Effective Human-Computer Interaction, 3rd Edition[END_REF], with [START_REF] Clarke | A three-level human-computer interface model[END_REF]) also as a (more abstract) background.

From then on, the <> brackets will be used with general meaning of "realization" (instance, value, . . . ) of the enclosed symbol (class, attribute, . . . ).

Description object creation

Creating an instance of the <desc> description class is performed by: <name> = <desc>(name='<name>')

where <name> (without quotes) is the canonical Python reference to the created object and '<name>' a text identifier using the same characters. This identifier is used both for allowing forward references (to not yet created objects) and for out-ofmemory references, either between computational nodes without shared memory or in databases (for accessing objects directly, not through property search), see 7.1.

Notice: simple test scripts may forgo the <name>= argument, thanks to an automatic canonical name search feature, but this is very costly for large scripts and is precluded in industrial cases.

Script object creation

The script class is derived from the Python module class, to which context-oriented behaviour is added.

A <script> (script instance) is automatically created in-memory when loading a script file (containing Python code) from the elsA command-line; this is the most common way a <script> object is created.

Internally, this creation is performed through the Python-elsA load() function, of which the simplest call form is:

<script> = load(<script_file_name>)
More scripts may be loaded from the main (root) script, script objects may thus be nested.

Global tree structure

Building a problem description in Python-elsA implicitly creates a tree, with the enclosing (toplevel) script object as root:

• scripts reference (include) description constructors (and other method, or function, calls), but own no attributes;

• a script may reference (include) other scripts, through load() calls;

• a description may reference other descriptions, through attach() calls, e.g. cfd1.attach(mod1, num1);

• descriptions own (contain) attributes;

• attributes have values;

• values may be <float>, <int>, <string>, or None (meaning "no value", for all types).

Calls to the check() method of scripts and descriptions (both being contexts, see 3.4.2) will transitively traverse the referenced objects (included scripts, included or attached descriptions).

Methods and functions

We describe below a few methods of description classes, see 3.4.1, and of contexts, see 3.4.2; additionally, the close() function call will end the processing of a script.

Specific methods of description classes

• <desc>.set(<attr>, <valu>): define valu as the value of the attr attribute of the <desc> description class instance;

• <desc>.get(<attr>): return the value of the attr attribute of the <desc> description class instance;

• <desc>.compute(): start the algorithm managed by the desc description class.

3.4.2. Methods of contexts (descriptions and scripts) Description classes and script classes are both contexts: they all inherit from the context class, and thus share a number of methods, which are shown here (in the simplest syntax).

• <context>.check(): perform contextual checking (using influence, dependency and contextual default rules) on the <context> instance; this method is the defining feature of a context;

• <context>.view(): display a compact (using macro-attributes) representation of the <context> instance, masking all non-coherent attribute values;

• <context>.copy(name=<name>): return a copy of the <context> instance, with the <name> identifier;

• <context>.dump(): dump a compact representation of the <context> instance to a file; dumped scripts may not include explicit control structures (loops and tests), which should be managed by description classes.

Abstraction & flexibility: redirections

For better abstraction and flexibility, some functions and methods are redirections to lower levels:

• function to root script method;

• script method to rootboot description method. as explained below in 3.5.1, 3.5.2. These redirections are most powerful when coupling with external layers, see 8.1.

Functions redirected to root script methods

The compute, extract, check and dump functions are indirections to the same-named methods of the top-level root script object. Moreover, the --check and --dump command-line options (clo) trigger the corresponding function call on an explicit close() call or on natural termination of the root script, while the --strict option triggers a check() call before the compute() call.

Script methods redirected to the boot description

The compute (start solver) and extract (build the specified output representation) methods of the current script object are indirections to the samenamed methods of the current boot description object, see 8.2.

Static and dynamic behaviour

New description classes do appear from time to time, but the main mechanism for the evolution of the Python-elsA interface is the addition of new attributes to existing classes. This is performed by augmenting two resource files, one for static definitions and the other for dynamic (context-related) ones.

All resource files (data defining the class attributes and various contextual rules) are structured using varying combinations of the dictionary and list Python types; these varying combinations are allowed (without additional coding) because Python is a dynamically typed language.

Rather than using a uniform formal schema, different ad hoc grammars are used here for each kind of definition, abusing the expert (if dated) advice: "As far as we were aware, we simply made up the language as we went along." -John Backus, Developer of Fortran (1957) and inventor of bnf (1959) [START_REF] Backus | The history of Fortran I, II and III[END_REF].

We thus conveniently "forget" the invention of the more formal Backus Normal (later Naur) Form (bnf), and use a homebrewed grammar; this nonformal character introduces a degree of incompleteness, which has not introduced problems so far for the cfd target application field; a few special cases of rule definitions are treated using lambda expressions (anonymous functions for in-lining rule code), with also some regular expression matching in lieu of plain comparison on <string> values.

Using only the basic dictionary and list Python types for these homebrewed grammar definitions makes the corresponding resource files compact and readable, so that developers may actually augment them; they are also very fast to parse. Again referencing (albeit indirectly) John Backus: "Because the customers of the 704 were primarily scientists and mathematicians, the language would focus on allowing programmers to write their formulas in a reasonably natural notation." [START_REF] Aiken | A memorial given at the 2007 conference on programming language design and implementation[END_REF].

Definitions for static behaviour

The definitions for static behaviour (i.e. excluding contextual checks) are centralized in a global file, as a Python module. They include for each attribute:

• a short descriptive text;

• a type (float, integer or string) for the attribute value;

• one or several checking methods, further restricting the definition domain (e.g. <float> type but further restricted to R * + );

• a list of default value mechanisms, among: static (value), dynamic (reference to rule), None;

• optionally, restrictions to modifications of the attribute value, e.g. interface only (not user).

Example:

'phymod':["""fluid model""",['S','I'], {'euler':0,'nslam':1,'nstur':2}, [CNTX_DEFV,None]]

These definitions are rendered in plain English (along with the context-related items, see 4.2) by the man() function of the interface, see 5.1. Moreover, a number of entries may be defined for each class, defining additional metadata, see 4.1.3.

Part of the attributes definitions (for example inheritance, see 4.1.3) is only finalized at runtime. It is then used to define class singletons, managing the attribute definitions for all the instances of a given class. This allows caching (across same-class instances) the internal representation of the definitions.

Attribute definition details

Description chain. The description chain for each attribute is used by the man() function, the popups in the PyGelsA gui, see section 6, and for generating the skeleton of the User's Reference Manual, see section 5.

Type and definition domain method(s). The basic type (float, integer or string) of the values of each attribute is complemented with a list of allowed of values, a (registered) checking method for the definition domain (e.g. "strictly positive" or more complex), or a combination of both. When the type changes between the interface and the kernel, the list of allowed values is replaced with a conversion dictionary.

Default values. The "default values" item may be an explicit value, a reference to the (possibly converted) kernel default value, a reference to a (possibly non-existent) context-dependent (contextual) default value, or a list of such items (e.g. contextual, then "static" safe value). The single None default value means that the attribute has no default value; if moreover the attribute is defined as always required, context checks will return False unless it has been defined by the user.

Macro-attributes

To give structure to the large number of attributes of some classes, they may be grouped into "macro-attributes", meaning named lists of attributes. Macro-attributes are list-valued and may be managed through set(), get(), view() and generally all methods of the description classes meant for plain attributes (their "atoms").

A macro-attribute may have several versions with differing lengths, e.g. conservative is always the name of the list of the attributes for the conservative variables, whatever the current number of equations. Specific versions (as declared in the resource file) are internally named e.g. conservative*05, conservative*06 . . . but on the user side, for input and output, plain conservative is used. This feature is not guaranteed to always provide as easy a grouping of related attributes, but it is quite useful.

In the gui, see section 6, the widgets for macro-attributes appear as foldable groups of "atom" widgets. Folding is automatic on failed influence/dependency rules (meaningless macroattribute).

Attributes metadata

Additional attributes metadata are structured in class-wide lists for:

• always-required attributes (whose value must be defined);

• obsolete attribute and values, and possibly their current replacement (--allow_obsolete clo);

• attribute and values which may be filtered out (--filter clo);

• not yet documented attributes and values (-unlock clo); • inheritance (with possible modifications) of attribute definitions from other classes.

Definitions for dynamic behaviour

The definitions for dynamic behaviour are the most important part of the base interface, allowing for context management and thus more abstract problem specification. Context management allows the software to behave differently, according either to a few trade-specific indications, see 4.2.4, or to the current global solving operator (in case of coupling), see 9.2.

Context management

The definitions for dynamic behaviour (i.e. rules for context management) are centralized in a global resource file, as a Python module; the inference engine (for applying these rules) is defined in a separate module. Dynamic behaviour is represented here by the context-dependent features of the interface: influence and dependency rules, and contextual default rules, completed by the traversal of relations created through attach() calls and possibly by the hierarchical structure of scripts (through inclusion).

Each problem description thus introduces a realization of a dynamic structure, whose nodes are linked by contextual influence and dependence relations; this structure is a Directed Acyclic Graph (dag), and not a true tree, because a node may have more than one parent (several influence rules may lead to the same attribute being required). The "Acyclic" word is important (also valid for a tree, of course), because we need to ensure that no rules in the grammar lead to circular checking. The "dynamic" qualifier comes both from the influence and dependence rules and from the context-dependent default values, leading to (possibly) different graph realizations for different user inputs, contrary to the static layout of a cgns tree.

Default values are sought when a rules terminator (an end rule) specifies that an attribute value must be defined, and no such value exists; contextual default rules, see 4.2.4, depend on the current state of the descriptions context. The <desc>.get_or_deft(<attr>) method call returns the best-effort result for the value of the <desc>.<attr> attribute -using available context state (attribute values) and rules -or None if no default value may be computed. Each rule is centered on one attribute, Fig. 2, ignoring for the moment the potential complexity which results from traversing all the rules, Fig. 3. When this traversal is performed for a specific case (with user-specified values as initial conditions), a dynamic dag based on contextual relations (context dag) is realized. This dag typically has many levels, quite differently from the flat and static one defined by the class structure, which is used for data storage (and documentation). Optionally, meaningless values may be "pruned" from the context (using the <desc>.check(prune=True) call), hopefully making it both complete (computable) -using default values -and coherent (here meaning minimal).A simple pruning example would be removing the choice of turbulence model if the simulation is declared laminar, as opposed to a plain <desc>.check() which would only flag the combination as non-coherent.

Pruning may not be fully automated, because the rules system cannot decide on which side of the rule the error lies. Thus, in the spirit below, we will not make a decision to remove the value: "In the face of ambiguity, refuse the temptation to guess." [START_REF] Peters | The Zen of Python[END_REF].

For example, the user may have kept the turbulent model definition from a previous case, or forgotten to change the flow model from laminar to turbulent when choosing the turbulence model; in this occurrence, a check() call on the involved model object would lead to a Warning-level message, see 5.4.

When performing pruning, the decision is made according to dependency rules, this is why in the above example the turbulent model choice would be removed while the flow model (higher up the context dag) is left unchanged. On the other hand, if unneeded values are defined and the --strict clo is used (or if the corresponding internal option is set from the script), the simulation will be aborted because in this condition all Warnings are bumped to the Error level.

In propagating an initial context of user-defined values using the various contextual rules, we will call "down-propagation" context flow that is centrifugal (propagating away from the root of the context dag), and "up-propagation" context flow that is centripetal, see Fig. 1. A context check may start at any point in the dag, performing both up-propagation (for dependency) and downpropagation (for influence); this is useful for the gui and for interactive user help (what if). Example rules will be provided for the model class of Python-elsA, which gathers (as attributes) parameters related to the physical model.

Dependency rules

A dependency rule defines the up-propagation of an attribute, and specify that other (source) attributes must have specified values for coherency, see Fig. 1, e.g.:

'visclaw': {'phymod': ['nslam', 'nstur']} meaning that the visclaw attribute has meaning only for the 'nslam' and 'nstur' (laminar and Navier-Stokes respectively) fluid models, and not for the remaining 'euler' model, see 4.1.

Influence rules

An influence rule defines the down-propagation of an attribute value, and specify that other (target) attributes must be defined for coherency, see Fig. 1, e.g.: meaning that the 'sutherland' value of the visclaw attribute requires that the suth_const and suth_tref attributes be defined, together with one of suth_muref and suth_muref_fct.

So-called "strong" influence rules specify moreover that the value of the target attribute must belong to a specified list, depending on the value of the origin attribute, e.g.:

'user_config': {'limited': [{'turbmod':['keps', 'komega']}, 'easy']} would be a strong rule specifying that when user_config='limited' the only possible choices of turbulence model are 'keps' and 'komega', and that the 'easy attribute value is required.

Contextual default rules

Contextual default rules provide a mechanism for defining default values of attributes when neither user-defined nor static defaults are provided, e.g.:

'suth_muref': {1.78938e-5: {'mixture':

['air'],'cfdpb.units':['si']}} meaning that the default value of the suth_muref attribute is 1.78938e-5 (in si units), provided that the fluid composition is defined as 'air' (from the single-element ['air'] list) and the problem is specified in si units.

The dag may be dynamically extended through contextual default rules, which are applied iteratively on a check() call until no new values are defined (or until the maximal iteration count is reached). For each descriptions context stateuser-defined values, "static" default values, and current contextual defaults -influence and dependency rules, together with "always required" rules, define which remaining attribute values must be defined to render the context complete. Each newly defined value corresponds to a state transition of this checking automaton.

For all description classes, trade-specific rules (possibly using regular expressions) may be triggered using the user_config attribute with arbitrary <string> values.

All attribute values may be traced to their creator (kernel, user, static default, contextual rule) using the show_origin method. If the creator is a contextual rule, it is listed.

"Horizon" mechanism

An original "horizon" mechanism has been developed [START_REF] Lazareff | Industrialisation du logiciel elsA pour valorisation en partenariat avec des PME/PMI[END_REF], replacing the definition of various user skill levels with a movable by-attribute boundary across the context-defined dag; it still has to be documented and user-tested.

Documentation & error management

Integrated documentation

The man() function of the interface provides, for any element of the Python-elsA interface (function, class, method, attribute), a compact (and always up-to-date) documentation suitable for a returning user: Notice: some output lines have been truncated. When the same attribute name is shared by several classes, the output of man() is factorized across identical definitions.

User's Reference Manual updating

A pdf version of the User's Reference Manual (urm) is built using the L A T E X typographical software (L A T E X project, 2016). For each new version of the elsA software, the urm must be updated with new attribute descriptions (and possibly new functions, classes, methods, and additions to the specialized appendices).

The updating process is partly automated, but requires some human intervention: the CheckDefs tool included in the Python interface code provides automatic generation of the L A T E X source code for the description of the attributes missing in the current urm version, based on the contents of the resource files. Merging in the new L A T E X source is done manually -using the ediff tool in the emacs editor -and coherency of the manual with the interface definitions checked, still using CheckDefs.

Exceptions (error management)

The Python-elsA interface defines its own exception classes, which use two severity levels:

• WARNING: non-fatal error;

• ERROR: fatal error.

Notice: the --strict clo upgrades all WARNINGs to ERRORs.

Error messages

The structure of Python-elsA error messages is:

• first line: general information about the error, including the severity level;

• a few lines describing in more detail the problem leading to the error;

• last line: the suggested correction.

It has to be noted that, although these messages on their own appear to be quite explicit, users of our software will sometimes not read the message, instead ringing up elsA software support.

This does not appear to be uncommon (UX User Experience, 2011), and could be linked to user stress, which is what we tried to avoid in the first place, or to a desire not to do a mental "context change" by trying to actually solve the problem themselves: "What they want is to pick up the phone, make a call, and have someone tell them what to do." (Slashdot, 2010).

The PyGelsA gui

The PyGelsA gui (Graphical User Interface) is built on-the-fly using the "static" interface definitions, see 4.1; this means that no modification of the PyGelsA code is needed when updating the user interface for new versions. When loaded with a script, the gui then uses the "dynamic" definitions, see 4.2, for coherency in the display of the description objects.

This display stays coherent thanks to on-the-fly application of context checks. As shown on Fig. 4, attributes with missing required values are labeled in red, while meaningful but user-folded macroattributes are labeled in green.

The gui includes (bottom part) a console for text-driven interaction, which is synchronized with the graphical window above. The interface state may later be re-built, either from the logfile or from the file dumped from a dump() call performed at any time during the gui use.

Database and network operations

Script (and description) objects may be serialized (transformed into bytecode) and either dumped to/loaded from a database, or accessed through the network.

Database operations

The script database feature of the interface is built upon a standard underlying database implementation, which may be as simple as a "dictionary on disk".

A script is an in-memory structure of description objects -and usually some operations-built either from an explicit script file or from code. These operations may be kept "pending" (not executed) if the script is to be stored in a database.

Script databases provide the basic dump/load operations, through the dump() and load() methods. A dumped and re-loaded script will re-create its description objects, and will execute its pending operations, if the environment (mesh files . . . ) is adequate. These basic operations are complemented by a search() method. For the search to be useful and efficient, the user has to declare a view, defining which parameters (out of possibly several hundred) are of interest for the current study. The <scri>.catalog() method is then called -using this view -at each dump() to update the database's catalog. The catalog() call may also be used for tagging the output data for the corresponding simulation, providing an authentic traceability (e.g. for plots).

Adequate locking allows the database to be shared in read/write mode between several processes, possibly on different machines, allowing natural parallelism. The default behaviour is to use separate databases for script definition (read-only) and for job execution metadata (read/write) for better efficiency.

The database keeps track of not yet started (NYS), running (RUN), and completed (CMP) state of computational jobs, which helps recovering from crashes, generally using a global <database>.clean() call (resetting all RUN jobs to NYS state) before restart. This partial restarting has been very efficient to reduce user stress, especially when running simulations with more jobs than computing nodes and (clock) execution times counted in days.

Network operations

Methods for the network class include a simple server/client (sockets) pair, the dump()/load() pair, and the popen() (get command output) and db_search() (find in database) commands. This functionality allows to access a script database through the network, which is useful when no shared filesystem is available and the underlying database is not networked, see Fig. 5.

Extensibility

Products

So-called "products" are additional (Python) software packages which couple with Python-elsA (and possibly with other products) through description classes. A developer may build a new product (based on the provided skeleton) and simply drop it in the Products directory. Communication between elsA and the added software is performed through an instance of this product-based description class, which contributes to the global context and may get to steer the simulation in lieu of the cfd solver, see section 9.

The algorithm associated with the product may be coded in Python (possibly referencing external packages with compiled libraries) and/or use elsA kernel functionality.

root and boot objects

If a description class declares a compute() method, an instance of this class may grab control of the simulation from the cfd algorithm, using the global context to gather all required data. This instance is then called the boot object.

Scripts define a compute() method -invoked in the (top-level root) script through the compute() function -which is an indirection to that of the current boot object; a script with a compute() statement will thus execute differently -without explicit tests -depending on the current boot object, or on the explicit <desc>.compute() call, e.g. (see 9. where # starts a comment, and compute() is redirected to spr1.compute() because spr1 is the lastcreated bootable object.

This logic provides for testing a complex coupling script at different levels with minimal modification; it can also be implemented as:

... slvrs = {0:cfd1, 1:dmd1, 2:spr1} slvr_lev = 1 # use dmd1 slvrs [slvr_lev].compute()

The coupling level may thus be specified as an integer value, without any test in the user script.

Lastly, the slvrs [slvr_lev].compute() call above may be replaced by set_boot_objt(<desc>); compute(), where the first statement may be seen as passing a token to <desc>, giving it specific rights. This token may be moved during the simulation, i.e. for collaborating coupling algorithms.

provide() method for blind creation

When several product-like description objects (e.g. prd1, prd2) use a common description object (e.g. slave), it may occur that it is built by one of them, which should be the first appearing in the script. If for example slave is built by prd1.compute(), built first, and then used by prd2, all is well. But if the boot object is switched from prd1 to prd2, slave will not be built and will miss to both prd1 and prd2, as prd1.compute() is not called anymore.

The solution we use, to avoid here an explicit test on the existence (with possible creation) of slave before each reference, is the use of the provide() method, which wraps the conditional creation, and may be "blindly" called to always return the (new or pre-existent) object.

target_lift class for target lift computations

The "target lift" functionality allows to replace a standard lifting-body computation, at fixed angleof-attack (aoa), with the computation of the list of aoas corresponding to the given list of lift values (within convergence bounds). This is performed by replacing the standard compute() call with one directed to a new <target_lift> boot object, as in: tcl1 = target_lift(name='tcl1') tcl1.attach(lift) alphas = compute ([0.05, .10, .15]) where lift is an <extractor> defining the computation of the body's lift and alphas is the aoa output for the specified lift coefficients. This was the first example of an extension to be finally coded as a product.

variator class for parametric studies

The variator class allows building script variations from a base version and a list of parameter perturbations, dumping them to a database. Later on this database will be spanned, meaning that all the database scripts will be loaded and pending operations, see 7.1, executed. This is performed in sub-directories of a user-chosen base directory, with all file paths automatically shifted as required.

Spanning thus provides the database with an iterator.

A step further, this iterator is made into a more general automaton: during spanning, a simulation may be restarted (chained) from a source simulation, chosen using a user-defined non-isotropic doe distance (in parameter space), possibly with additional rules for restricting the source/target pairing. When chaining simulations, the automaton may also add intermediate points (linearization) to the iteration list, to respect a user-specified maximal jump size in parametric space [START_REF] Lazareff | Towards autonomous discovery of stiff structures in CFD Design of Experiment space, from random-walk automaton steered by the "spiral" criterion[END_REF].

An external algorithm may also add arbitrary points to the list, see 9.3.

swarm class for operational efficiency

The swarm class provides an abstraction for a group of spanning simulations. For operational efficiency, automated load management on a computational node is provided either as a maximal count of swarm job instances or as a fraction of the node's power.

The values of the selected observable quantity, for all the simulations in a swarm, are returned as <valu_list> = <swarm>.compute(), as used for the spi algorithm, 9.3.

Design of Experiment studies

Studies in Design of Experiment (doe) space involve at least two levels: the basic automaton performing the space spanning, and the mathematical tools, applied both to each doe point and to the global space. These tools may be passive (using specified doe points in a given order), or they may use observable quantities to steer the spanning automaton, possibly creating new doe points on-thefly.

In 9.2 and 9.3 we will give two examples in the field of differentiable dynamical systems (the geometrical study of complex systems and their stability) [START_REF] Smale | Differentiable dynamical systems[END_REF] applied to cfd, first as a local study and then on a doe. Usually the system is defined by an equation like ẋ = v(x). Here however the operator of the system is unknown, and only accessible through cfd observable quantities at computed points of the doe, so that as a first step we have to address the problem of doe discovery, see 9.1, to ensure that the main features of the operator are accounted for. 9.1. doe spanning and discovery doe discovery is an extended parametric study, see 8.5, where the aim is to describe (find the main features of) the space inside a closed boundary in parametric space, with possible refinement of the initial set of doe points [START_REF] Lazareff | Towards autonomous discovery of stiff structures in CFD Design of Experiment space, from random-walk automaton steered by the "spiral" criterion[END_REF]. Continuation techniques (e.g. stabilization to cross doe areas with separated flow) may be needed, see 9.2. As a first approach, doe refinement may be manual, but in 9.3 we introduce an automatic refinement algorithm through the spi algorithm [START_REF] Chkifa | Highdimensional adaptive sparse polynomial interpolation and applications to parametric PDEs[END_REF], which greatly simplifies user interaction.

The observable quantity here may be the aerodynamic lift or drag, the spectral radius of the global (physical + numerical) operator, or any other quantity of interest.

Coupling with the sfd and dmd algorithms

Coupling between elsA, the sfd and dmd algorithms has been performed to provide stabilized cfd solutions, initially at a single doe point for the flow around a cylinder [START_REF] Cunha | Optimization of the Selective Frequency Damping parameters using model reduction[END_REF]. The sfd algorithm may be either part of the cfd solver or treated as a wrapper in the encapsulated version [START_REF] Jordi | Encapsulated formulation of the Selective Frequency Damping method[END_REF], with an sfd description class. The dmd algorithm is coded in Python, with a dmd description class. Some parameters of the cfd algorithm (numerics class attribute values) are dependent on the sfd and dmd algorithms through contextual rules.

This work has since been extended to a (Mach, Reynolds) doe using the variator class. Success is still dependent on the adequate adjustment of some parameters, at this time taken to be constant across the doe. For the time being, this aspect is fully dependent on user expertise. 9.3. Coupling with the sfd, dmd, and spi algorithms

The most complex application to date of the extensibility of elsA through the Python-elsA interface is the algorithm described above in 9.2, complemented by Sparse Polynomial Interpolation (spi) [START_REF] Chkifa | Highdimensional adaptive sparse polynomial interpolation and applications to parametric PDEs[END_REF] for doe discovery (to be published).

Here the spanning automaton is managed by the spi algorithm, starting with nodes only at the doe summits and progressively enriching the representation with inner points according to a Clenshaw-Curtis distribution.

The cfd results for the chosen observable quantity at each refinement level of the spi algorithm are computed as a swarm, see 8.6.

With a reasonable degree of convergence of the spi algorithm, we hope that this algorithm will lead to an adequate automatic discovery of the doe features.

Conclusion

The basic foundation of the Python-elsA interface, which has been used since the creation of the elsA software, has long been used for the target lift extension, see 8.4. Recently more complex extensions have been introduced for doe studies.

This descriptive interface and associated functionality provides a high level of abstraction for coupling mathematical algorithmic layers with the cfd solver, reducing the tedious part of user's work and augmenting efficiency in research and applications.

This approach, allowing for collaborative computing, seems to be well suited for projects coupling several simulation kernels.

Perspectives

A rule-based implementation of the currently kernel-side factory, see 2.2 would remove the potential fragility of the current one, where tests are sometimes nested for several levels. A rule only has to be written once, while inner tests may have to be repeated for each branch of the upper level(s). This would benefit to user-side checking by ensuring completeness and coherency of the rules with the actual solver implementation.

The more immediate new development will be stochastic analysis, using the Monte-Carlo method on the response surface of 9.3, introducing the first 4th-level layer algorithm above the elsA interface (5th-level above the cfd kernel). This paper is dedicated to my late colleague and friend Michel Gazaix, who died unexpectedly on August 8, 2016. He was the one, as software architect, who invited me into the early elsA project to design and build its user interface, and I am still indebted to him for this challenge.

Fig. 2 :

 2 Fig. 1: Contextual dag information flow, through influence and dependency.

Fig. 3 :

 3 Fig. 3: Global rules traversal (more than one attribute).

Fig. 4 :

 4 Fig. 4: The PyGelsA gui.

Fig. 5 :

 5 Fig. 5: Database and network use.

  3): cfd1 = cfdpb(name='cfd1') cfd1.set('sfd', 'active') ... dmd1 = dmd(name='dmd1') spr1 = sparse_poly(name='spr1') ... # cfd1.compute() # single-point SFD simulation # dmd1.compute() # single-point SFD/DMD simulation compute() # SFD/DMD/SPI coupling on DoE, using spr1

  . . . . . . . . . . . . . . . . 11 8.2 root and boot objects . . . . . . . . 11 8.3 provide() method for blind creation 11 8.4 target_lift class for target lift computations . . . . . . . . . . . . . 11 8.5 variator class for parametric studies 12 8.6 swarm class for operational efficiency 12 9 Design of Experiment studies 12 9.1 doe spanning and discovery . . . . . 12 9.2 Coupling with the sfd and dmd algorithms . . . . . . . . . . . . . . . . 12 9.3 Coupling with the sfd, dmd, and spi algorithms . . . . . . . . . . . . . . . 12 first through the Carnot institutes network contract referenced as n o 07 CARNOT 00801, and then as part of the ufo (Uncertainty For Optimization) project referenced as ANR-11-MONU-0008.

But cgns is not a user interface system, lacking even basic user-oriented checks

Unlike a cgns tree -managed in elsA through pycgnswhich large depth is especially apparent when it is accessed through the cgnsview graphical interface.

Contextual (influence/dependence) relations introduce a different graph than the above shallow tree; this second

'visclaw': {'sutherland': ['suth_const', ['suth_muref', 'suth_muref_fct'], 'suth_tref']}

Acknowledgments

This work has received partial financial support from the Agence Nationale de la Recherche (anr http://www.agence-nationalerecherche.fr/),


Jorane Saubesty
email: jorane.saubesty@blri.fr

Phases of medical consultation : multimodal analysis of transitions

Studies on interactions

 Interactions are structured [START_REF] Sacks | A simplest systematics for the organization of turn-taking for conversation[END_REF]  Interactions are contextual [START_REF] Robinson | Intervening with conversation analysis: The case of medicine[END_REF]  Interactions are multimodal [START_REF] Cosnier | Les interactions en milieu soignant[END_REF]  Speakers-listeners mutually influence each other [START_REF] Selting | Introducing interactional linguistics[END_REF] THEORETICAL FRAMEWORK CORPUS RESEARCH QUESTIONS 2.

ANALYSIS AND RESULTS

Opening

3.

Which modalities are involved in transitioning from one phase to another ? How do they participate to the transition ?

Sequential organisation Medical consultation is structured in phases [START_REF] Ten Have | Sequential structures and categorical implications in doctor-patient interaction: ethnomethodology and history[END_REF][START_REF]Communication in medical care: Interaction between primary care physicians and patients[END_REF]  The phases are : Opening, Taking history, Examination, Diagnosis, Treatment and Closure [START_REF] Traverso | Analyse de consultations médicales en présence d'un intermédiaire linguistique non professionnel[END_REF]  Previous study shows phases for breaking bad news are slightly different (see Analysis and Results 2.).

Transitions

 All the interlocutors participate to the transitions from on phase to another [START_REF] Robinson | Achieving activity transitions in physician-patient encounters[END_REF] One can refuse a transition to the next phase [START_REF] Mondada | Participants' online analysis and multimodal practices: projecting the end of the turn and the closing of the sequence[END_REF] Transitions are multimodal [START_REF] Robinson | Nonverbal communication and physician-patient interaction[END_REF] BIBLIOGRAPHY

  transition between the « breaking the news » phase and the one before (usually « exposing the situation » ---------------------------------1 h. 32 min. 24 s. video Scenario Doctors found the patient had an intestinal obstruction. They did a surgery to open the duodenum but while the patient was asleep some stomach liquids find their way to the lungs causing respiratory distress. The patient is now in intensive care emergency, unconscious. The doctor has to break the news to the patient's wife or son. More information  The corpus was made and belong to the Institut Paoli-Calmettes (Marseille, France)  The interactions are simulation of breaking bad news consultations  The interactions are part of a training to teach doctors how to beak bad news Doctor Pen and paper Patient's wife

Table 1 .

 1 Features occuring with trigger which marks the swift from one phase to the breaking the news phase, per videos -doctor production.

	Patient's relative
		Logical operator	Pause	Pause duration	Hand Gesture	Head movements	Gaze	Posture	Else
	IPC1	Par contre -however	no speech	/	none	none	toward interlocutor	no change	extra communicative gesture
	IPC2	Malheureusement -unfortunately	no speech	/	none	single nod	toward interlocutor	no change	extra communicative gesture
	IPC3 Mais -but	no speech	/	none	tilt	toward interlocutor	no change	extra communicative gesture
	IPC4	Malheureusement -unfortunately	no speech	/	none	none	not visible	no change	/
	IPC6	Malheureusement -unfortunately	no speech	/	none	none	toward interlocutor	no change	/
	IPC7	Par contre -however	no speech	/	none	none	toward interlocutor	no change	/

Table 1

 1

	Logical operator	occurences	used by	Starts … phases
	\	13	pat / med	4
	Donc -so	6	med	2
	Mais -but	7	pat / med	3
	et (puis) -and (then)	4	pat / med	2
	Voilà	4	pat / med	2
	Malheureusement -unfortunately	3	med	1
	bon là -well here	1	pat	2
	par contre -however	2	med	1
	Merci -thank you	1	pat
	Actuellement -currently	1	med
	ça va -fine	1	pat
	en plus -moreover	1	med
	en pratique -in practice	1	med
	parce qu'en plus -because moreover	1	med

. Features occuring with trigger which marks the swift from one phase to the breaking the news phase, per videos -patient's relative production.

CONCLUSION

In this study :  We wondered which modalities were used for the transition from one phase to another  We analysed the logical operator used to start the next phase and found that :

 Most of the phases starts with no operator  Most of the operators are used to start two or more phases  "malheureusement" (unfortunately) and "par contre" (however) are the only operators used several times but only to start one type of phase, the "breaking the news" one.  Regarding the previous results, we focused our analysis on transitions to the "breaking the news" phase and found that :

 Most of the doctors pause right before they produce the logical operator and do not gaze at their interlocutor  The only one doctor gazing at his/her interlocutor is also the only doctor pausing right after the logical operator  The patient's relatives are inactive during this transition, but gaze at their interlocutor


est destinée au dépôt



  Browsing, Sharing, Learning and Reviewing the Haine du théâtre Corpus through Insightful Island Bin Yang, Chiara Mainardi, Jean-Gabriel Ganascia To cite this version: Bin Yang, Chiara Mainardi, Jean-Gabriel Ganascia. Browsing, Sharing, Learning and Reviewing the Haine du théâtre Corpus through Insightful Island. Digital Humanities 2016, Jul 2016, Krakow, Poland. 2016. hal-01395330 In a participatory perspective, new tools are required to share the contents and results in the scientific community in general, and in the DH community in particular. Furthermore, the users of corpora are waiting for tools that help them to understand, to seek information and to memorize. In this poster, we show how to use Memory Island (MI) technique to help to create an insightful visualization for the Haine du théâtre (HdT) corpus. More generally, we discuss the design of systems based on the Memory Island technique for sharing, learning and reviewing the humanities and literary corpora. ABSTRACT  Memory Island Technique. -Inspired by the "Art of Memory"(method of "loci"). -Browsing, Sharing, Learning, Reviewing and Memorizing corpus and knowledge.  The Haine du théâtre Project. -It analyses theater debates in Europe about the virtues and vices of the theater in the 17th-& 18th-Century. Users are waiting for a tool (e.g. knowledge Map) to help them with their information seeking tasks. They want to improve their understanding and memorability with the corpus. The insightful island is one of the most promising tool. CONTEXT  Visualize the HdT corpus as an insightful Island.  Knowledge Island allows users to navigate through the corpus, based on the insights of experts from literature.  Access, detail information and search. Users can immediately understand the concepts, Navigating through the HdT Corpus with Map Interactive functions and Learning with Review function.  Review function provides the user a summary about his/her studied concept, prepared by the expert.  Visualizing his/her visiting and studying trace. Visualizing the Haine du théâtre Corpus as an Insightful Island CONCLUSION AND PERSPECTIVES o Design a visualization system for sharing, learning and reviewing the humanities and literary corpora based on the Memory Island technique. o This approach are already applied for the children's textbooks and other corpus, the encyclopedia of Philosophy, the ontologies, the biologic datasets, etc. o We envisage integrating more Natural Language Processing and Artificial Intelligence techniques. o We are planning to add more functions to this visualization systems. o Improve users' memorability. o Storytelling.