<?xml version="1.0" standalone="yes"?>
<Paper uid="P06-1118">
  <Title>Francis.Brunet-Manquat@imag.fr</Title>
  <Section position="4" start_page="937" end_page="939" type="metho">
    <SectionTitle>
2 Jibiki, The Papillon Dictionary
</SectionTitle>
    <Paragraph position="0"/>
    <Section position="1" start_page="937" end_page="937" type="sub_section">
      <SectionTitle>
Development Platform
2.1 Overview
</SectionTitle>
      <Paragraph position="0"> The Jibiki platform has been designed to support the collaborative development of multilingual dictionaries. This platform is used as the basis of the Papillon project web site6.</Paragraph>
      <Paragraph position="1"> Thisplatformoffersseveralservicestoitsusers: * access to many different dictionaries from a single easy to use query form, * advance search for particular dictionary entries through an advanced search form, * creation and edition of dictionary entries.</Paragraph>
      <Paragraph position="2"> What makes the Jibiki platform quite unique is the fact that it provides these services regardless of the dictionary structure. In other words it may be used by any dictionary builder to give access and collaboratively edit any dictionary, provided that the resulting dictionary will be freely accessible online.</Paragraph>
    </Section>
    <Section position="2" start_page="937" end_page="937" type="sub_section">
      <SectionTitle>
2.2 Jibiki Platform Architecture
</SectionTitle>
      <Paragraph position="0"> The Jibiki platform is a framework used to set up a web server dedicated to the collaborative development of multilingual dictionaries. All services provided by the platform are organised as classical 3-tier architectures with a presentation layer (in charge of the interface with users), a business layer (which provides the services per se) and a data layer (in charge of the storage of persistent data).</Paragraph>
      <Paragraph position="1"> In order to adapt the Jibiki platform to a new dictionary, the dictionary manager does not have</Paragraph>
    </Section>
    <Section position="3" start_page="937" end_page="938" type="sub_section">
      <SectionTitle>
3.1 Overview
</SectionTitle>
      <Paragraph position="0"> The objective of the LexALP project is to compare the specialised terminology of six different national legal systems and three supranational systems in four different languages, and to harmonise it, thus optimising communication between the Alpine states at supranational level. To achieve this objective, the terminology of the Alpine Convention is described and compared to the equivalent terms used in national legislation. The resulting terminology entries feed a specific term bank that will support the harmonisation work.</Paragraph>
      <Paragraph position="1"> As the project deals with legal terms, which refer to concepts that are proper of the considered national law or international convention, equivalence problems are the norm, given that concepts are not &amp;quot;stable&amp;quot; between the different national legislations. Standard terminology techniques for other fields can not be applied to the field of law, where the standardisation approach (Felber, 1987;  Felber, 1994) is not applicable. For this, we chose to use &amp;quot;acceptions&amp;quot; as they are defined in the Papillon dictionary (S'erasset, 1994) to represent the equivalence links between concepts of the different legal systems (Arntz, 1993).</Paragraph>
      <Paragraph position="2">  The example given in figure 2 shows a concept defined in the Alpine Convention. This concept has the same definition in the four languages of the Alpine Convention but is expressed by different denominations. The Alpine Convention also uses the terms &amp;quot;circulation intra-alpine&amp;quot; or &amp;quot;transport intra-alpin&amp;quot; which are identified as synonyms by the terminologist.</Paragraph>
      <Paragraph position="3"> This illustrates the first goal of the LexALP project. In different texts, the same concept may be realised by different terms in the same language. This may lead to inefficient communication. Hence, a single term has to be determined as part of a harmonised quadruplet of translation equivalents. The other denominations will be represented in the term bank as non-harmonised synonyms in order to direct drafting and translating within the Alpine Convention towards a more clear and consistent terminology use for interlingual and supranational communication.</Paragraph>
      <Paragraph position="4"> In this example, the lexicographers and jurists did not identify any existing concept in the different national laws that could be considered close enough to the concept analysed. This is coherent  withtheminutesfromtheFrenchNationalAssembly which clearly states that the term &amp;quot;trafic intra-alpin&amp;quot; (among others) should be clarified by a declaration to be added to the Alpine Convention.</Paragraph>
      <Paragraph position="5"> Figure 3 shows an analogous quadrilingual example where the Alpine Convention concept may be related to a legal term defined in the French laws. In this example the French term is distinguished from the Alpine Convention terms, because these concepts belong to different legal sys- null Alpine Convention with reference to its equivalent at French national level tems (and are not identically defined in them).</Paragraph>
      <Paragraph position="6"> Hence, the terminologists created distinct acceptions, one for each concept. These acceptions are related by a translation link.</Paragraph>
      <Paragraph position="7"> This illustrates the second goal of the project, whichistohelpwiththefinecomprehensionofthe Alpine Convention and with the detailed knowledge necessary to evaluate the implementation and implementability of the convention in the different legal systems.</Paragraph>
      <Paragraph position="8"> As a by-product of the project, one can see that there is an indirect relation between concepts from different national legal systems (by way of their respective relation to the concepts of the Alpine Convention). However, establishing these indirect relations is not one of the main objectives of the LexALP project and would require more direct contrastive analysis.</Paragraph>
    </Section>
    <Section position="4" start_page="938" end_page="939" type="sub_section">
      <SectionTitle>
3.2 Macro- and Micro- Structures
</SectionTitle>
      <Paragraph position="0"> The LexALP term bank consists in 5 volumes (forFrench,German,Italian,SloveneandEnglish) containing all term descriptions (grammatical information, definition, contexts etc.). The translation links are established through a central acception volume. Figure 2 and 3 show examples of terms extracted from the Alpine Convention, synonymy links in the French and Italian volumes, as well as inter-lingual relations by way of acceptions. null All language volumes share the same microstructure. This structure is stored in XML.</Paragraph>
      <Paragraph position="1"> Figure 4 shows the xml structure of the French term &amp;quot;trafic intra-alpin&amp;quot;, as defined in the Alpine Convention. The term entry is associated to a unique identifier used to establish relations between volume entries. Each term entry belongs to one (and only one) legal system. The example term belongs to the Alpine Convention legal  tems includes of course countries belonging to the Alpine Space (Austria, France, Germany, Italy, Slovenia and Switzerland9) but also international treaties or conventions. The entry also bears the information on its status (harmonised or rejected) and its process status (to be processed, provisionally processed or finalised).</Paragraph>
      <Paragraph position="2"> The term itself and its part of speech is also given, with the general domain to which the term belongs, along with some usage notes. In these usage notes, the attribute geographical-code allows for discrimination between terms defined in national (or federal) laws and terms defined in regional laws as in some of the countries involved legislative power is distributed at different levels. Then the term may be related to other terms.</Paragraph>
      <Paragraph position="3"> These relations may lead to simple strings of texts (as in the given example) or to autonomous term entries in the dictionary by the use of the termref attribute. The relation itself is specified in the relationToTerm attribute. The current schema allows for the representation of relations  Convention, however, their legal systems are not terminologically processed within LexALP.</Paragraph>
      <Paragraph position="4"> between concepts (synonymy, hyponymy and hyperonymy), as well as relations between graphies (variant, abbreviation, acronym, etc.).</Paragraph>
      <Paragraph position="5"> Then, a definition and a context may be given.</Paragraph>
      <Paragraph position="6"> Both should be extracted from legal texts, which must be identified in the source field.</Paragraph>
      <Paragraph position="7"> An interlingual acception (or axie) is a place holder for relations. Each interlingual acception may be linked to several term entries in the language volumes through termref elements and to other interlingual acceptions throughaxieref elements, as illustrated in figure 5.</Paragraph>
    </Section>
  </Section>
  <Section position="5" start_page="939" end_page="943" type="metho">
    <SectionTitle>
4 LexALP Information System
</SectionTitle>
    <Paragraph position="0"/>
    <Section position="1" start_page="939" end_page="940" type="sub_section">
      <SectionTitle>
4.1 Overview
</SectionTitle>
      <Paragraph position="0"> Building such a term bank can only be envisaged as a collaborative work involving terminologists, translators and legal experts from all the involved countries. Hence, the LexALP consortium has set up a centralised information system that is used to gather all textual and terminological data.</Paragraph>
      <Paragraph position="1"> This information system is organized in two main parts. The first one is dedicated to corpus management. It allows the users to upload legal texts that will serve to bootstrap the terminology work (by way of candidate term extraction) and to let terminologists find occurrences of the term they are working on, in order for them to provide definitions or contexts.</Paragraph>
      <Paragraph position="2"> The second part is dedicated to terminology work per se. It has been developed with the Jibiki platform described in section 2. In this section, we show the LexALP Information System functionality, along with the metadata required to implement it with Jibiki.</Paragraph>
    </Section>
    <Section position="2" start_page="940" end_page="941" type="sub_section">
      <SectionTitle>
4.2 Dictionary Browsing
</SectionTitle>
      <Paragraph position="0">  Thefirstmainserviceconsistsinbrowsingthecurrently developed dictionary. It consists in two different query interfaces (see figures 6 and 7) and a  In the provided examples, the user of the system specifies an entry (a term), or part of it, and a language in which the search is to be done. The expected behaviour may only be achieved if : * the system knows in which volume the search is to be performed, * the system knows where, in the volume entry, the headword is to be found, * the system is able to produce a presentation for the retrieved XML structures.</Paragraph>
      <Paragraph position="1"> However, as the Jibiki platform is entirely independent of the underlying dictionary structure  (which makes it highly adaptable), the expected result may only be achieved if additional metadata is added to the system.</Paragraph>
      <Paragraph position="2"> These pieces of information are to be found in the mandatory dictionary descriptor. It consists in a structure defined in the Dictionary Metadata Language (DML), as set of metadata structures and a specific XML namespace defined in (Mangeot, 2001).</Paragraph>
      <Paragraph position="3"> Figure 8 gives an excerpt of this descriptor. The metadata first identify the dictionary by giving it a name and a type. In this example the dictionary is a pivot dictionary (DML also defines monolingual and bilingual dictionary types). The descriptor also defines the set of source and target languages. Finally, the dictionary is defined as a set of volumes, each volume being described in another file. As the LexALP dictionary is a pivot dictionary, there should be a volume for the artificial language axi, which is the pivot volume. Figure 9 shows an excerpt of the description of the French volume of the LexALP dictionary. After specifying the name of the dictionary, the descriptor provides a set of cdm-elements. These elements are used to identify standard dictionary elements (that can be found in several dictionaries) in the specific dictionary structure. For instance, the descriptor tells the system that the headword of the dictionary (cdm-headword) is to be found by applying the specified xpath10 to the dictionary structure.</Paragraph>
      <Paragraph position="4"> With this set of metadata, the system knows that:  * requests on French should be directed to the LexALP fra volume, * the requested headword will be found in the text of the term element of the volume entry element, Hence, the system can easily perform a request and retrieve the desired XML entries. The only remaining step is to produce a presentation for the user, based on the retrieved entries. This is achieved by way of a xsl11 stylesheet. This stylesheetisspecifiedeitheronthedictionarylevel (for common presentations) or on the volume level (for volume specific presentation).</Paragraph>
      <Paragraph position="5"> In the given example, the dictionary administrator provided two presentations called LexALP (the default one, as shown in figure 10) and short-list, both of them defined in the dictionary descriptor.</Paragraph>
      <Paragraph position="6"> Thismechanism allowsfor thedefinition ofpresentation outputs in xhtml (for online browsing) or for presentation output in pdf (for dictionary export and print).</Paragraph>
    </Section>
    <Section position="3" start_page="941" end_page="943" type="sub_section">
      <SectionTitle>
4.3 Dictionary Edition
</SectionTitle>
      <Paragraph position="0"> The second main service provided by the Jibiki platform is to allow terminologists to collaboratively develop the envisaged dictionary. In this sense, Jibiki is quite unique as it federates, on the very same platform the construction and diffusion of a structured dictionary.</Paragraph>
      <Paragraph position="1"> As before, Jibiki may be used to edit any dictionary. Hence, it needs some metadata information in order to work: * thecompletedefinitionofthedictionaryentry structures by way of an XML schema, * a template describing an empty entry structure, null 11XSL is a standard way to transform an XML structure into another structure (XML or not).</Paragraph>
      <Paragraph position="2"> Figure 11: Basic flow chart of the editing service * a xhtml form used to edit a dictionary entry structure (which can be adapted from an automatically generated one).</Paragraph>
      <Paragraph position="3"> When this information is known, the Jibiki platform provides a specific web page to edit a dictionary entry structure. As shown in figure 11, the XML structure is projected into the given empty XHTML form. This form is served as a standard web page on the client browser. After manual editing, the resulting form is sent back to the Jibiki platform as CGI12 data. The Jibiki platform decodesthisdataandmodifiestheeditedXMLstruc- null ture accordingly. Then the process iterates as long as necessary. Figure 12 shows an example of such a dynamically created web page.</Paragraph>
      <Paragraph position="4"> After each update, the resulting XML structure is stored in the dictionary database. However, it is not available to other users until it is marked as finished by the contributor (by clicking on the save button). If the contributor leaves the web page without saving the entry, he will be able to retrieve it and finish his contribution later.</Paragraph>
      <Paragraph position="5">  At each step of the contribution (after each update) and at each step of dictionary editing (after each save), the previous state is saved and the contributor (or the dictionary administrator) is able to browse the history of changes and to revert the entry to a previous version.</Paragraph>
    </Section>
  </Section>
class="xml-element"></Paper>