MULTEXT-East Morphosyntactic Specifications:
Towards Version 4⋆Tomaž Erjavec
Department for Knowldege TechnologiesJožef Stefan InstituteJamova cesta 39
SI-1000 Ljubljana, Slovenia
tomaz.erjavec@ijs.si

Abstract. The MULTEXT-East standardised and linked set of language resources covers
a large number of mainly Central and Eastern European languages and includes harmonisedmorphosyntactic resources consisting of the specifications, lexica and a parallel corpus. The
MULTEXT-East resources, currently at Version 3, are freely available for research use andhave been used in numerous studies connected to language technologies. In this paper weconcentrate on MULTEXT-East morphosyntactic specifications, which define the featuresthat describe word-level syntactic annotations, and explain their structure in Version 4,
currently work in progress. The V4 specifications are planned to cover at least 13 languages
and will be encoded in XML, according to the latest version of the Text Encoding Initiative
Guidelines, TEI P5. The new encoding enables more flexible language-particular encodings,
localisations of feature names and codes, easy generation of derived formats (HTML, tabular,
XML libraries), and simplifies the addition of new languages.

1

Introduction

The MULTEXT-East project, (Multilingual Text Tools and Corpora for Eastern and Central
European Languages) was a spin-oﬀ of the EU MULTEXT project [14]; MULTEXT-East ran
from ’95 to ’97 and developed standardised language resources for six CEE languages [3], as well
as for English, the ’hub’ language of the project. The main results of the project were lexical
resources and an annotated multilingual corpus, where the most important resource turned out tobe the parallel corpus — heavily annotated with structural and linguistic information — which
consists of Orwell’s novel “1984” in the English original and translations.
In addition to delivering resources, a focus of MULTEXT-East was also the adoption andpromotion of encoding standardisation. On the one hand, the morphosyntactic annotations andlexica were developed in the formalism used for six Western European languages in the MULTEXT
project, itself based on the EAGLES speciﬁcations [5]. On the other, all the corpus resources wereencoded in SGML, according to the Corpus Encoding Standard [12] and, later, in XML and TEI,
the Text Encoding Initiative Guidelines [19].
One of the objectives of MULTEXT-East has been to make its resources available to the wider
research community. The resources are distributed on the Web at http://nl.ĳs.si/ME/. A portionof the resources is freely available for download or browsing; for the rest, the user has to ﬁrst ﬁllout a Web-based agreement form restricting the use of resources for research. Apart from the data
itself, the distribution also contains extensive documentation.
After the completion of the EU MULTEXT-East project, a number of other projects havehelped to keep the MULTEXT-East resources up-to-date (e.g., migrating the corpus from SGML
to XML) and enabled us to add new languages. At the time of writing, the latest publicly released
resources are at Version 3 [7].
The MULTEXT-East resources have been instrumental in advancing the state-of-the-art inlanguage technologies in a number of areas, e.g., part-of-speech tagging [21], inductive learning of⋆

The study and preparation of these results have received funding from the EU 7FWP under grant
agreement 211938 MONDILEX.

2Tomaž Erjavec

lemmatisation rules [9], and word sense disambiguation [13], to mention just a few. The licensing
form has been submitted by over 100 organisations, mostly academia, but also industry.
The success of the resources is mostly due to the fact that they are freely available for researchand that they include basic building blocks for processing a signiﬁcant range of “novel” languages.
As the linguistic markup has also been manually validated and tested in practice, the resources canserve as a “gold standard” which enables other researchers to develop and test their approaches
to topics in the language processing. The resources also provide a model which languages lacking
basic linguistic resources, such as tagsets, lexica and annotated corpora can link-up to, taking awell-trodden path. This aspect of the resources was unexpected but highly rewarding; this steady
addition of new languages also gives impetus to continue working on their general improvement.
Since the release of Version 3 the resources have again been expanded and re-encoded, in
preparation for Version 4. New languages have been added and the morphosyntactic speciﬁcations
have been converted from the LATEX format to XML [8]. A portion of the resources has also been
additionally annotated, e.g., for WordNet word-sense disambiguated nouns [13] in the English“1984” and dependency syntactic structures for the Slovenian “1984” [4].
This paper is devoted to one part of the resources, namely the MULTEXT-East morphosyntactic speciﬁcations. The speciﬁcations are a document that provides the deﬁnition of the attributesand values used by the various languages for word-class syntactic annotation, i.e., they provide aformal grammar for the morphosyntactic properties of the languages covered. The MULTEXTEast speciﬁcations deﬁne 12 categories (parts-of-speech), and approx. 100 diﬀerent attributes with
500 values.
The morphosyntactic speciﬁcations also deﬁne the mapping between feature-structures andmorphosyntactic descriptions (MSDs), which are compact strings used in the morphosyntactic lexica and for corpus annotation. For example, they specify that MSD Ncms is equivalent
to the feature-structure consisting of the attribute-value pairs Category:Noun, Type:common,
Gender:masculine, Number:singular. The speciﬁcations furthermore determine which featurevalue combinations and MSDs are valid for particular languages. In addition to the formal parts
the speciﬁcations also contain commentary, bibliography, etc.
Originally, these speciﬁcations were released as a report of the MULTEXT-East project but
have been revised for both subsequent releases, and have become, if not a standard, then at least areference for comparison [11]. They currently cover thirteen languages; Table 1 gives an overview,and for each language also speciﬁes its language family, and which version of the MULTEXTEast resources it ﬁrst appeared or will appear in. Special mention deserve the languages whichstill have to make their debut in Version 4, namely Macedonian, Persian, and Russian, and, toan extent, Slovene. The development of the Macedonian speciﬁcation, lexicon and corpus started
in 2004, and the resources have already been used as the data for several experiments in tagger[22] and lemmatiser induction [15]. The Macedonian resources comprise the speciﬁcations, lexicon,
and corpus, which is, however, not yet morphosyntactically annotated. The development of Persian
resources also started in 2004, and they currently comprise the speciﬁcations and annotated corpus[17]. The Russian speciﬁcations [18] are the latest addition, although the (unannotated) corpus has
been available since Version 1. The Russian resources thus still lack a lexicon and annotated corpus,
although an automatically annotated corpus and tagging models are available independently at
http://corpus.leeds.ac.uk/mocky/.
Slovene has been a part of the MULTEXT-East resources from the start, however, in Version
4 we plan to signiﬁcantly revise the speciﬁcations and harmonise the lexicon and corpus withthem. The Slovene speciﬁcations have been extensively used for corpus annotation, esp. of the
Slovene reference corpora Fida and its successor FidaPLUS (http://www.ﬁdaplus.net/ ) and in thecourse of the years various shortcomings of the original proposal have come to light. A recent
Slovene project, JOS (Jezikoslovno označevanje slovenščine / Linguistic Annotation of Slovene,
http://nl.ĳs.si/jos/ ), devoted to corpus annotation has provided the means to revise the speciﬁcations, and use them as the basis to (semi)manually annotate two corpora of Slovene [10].
The development of these “JOS” speciﬁcations, has, to a large extent, also served as the testing
ground for the new MULTEXT-East speciﬁcations. In Version 4 we plan to incorporate the JOS
speciﬁcations into MULTEXT-East.

MULTEXT-East Morphosyntactic Specifications V43

Language Language
Addedfamilyin
name
EnglishGermanic
Version 1
Version 1
Romanian Romance
RussianEast Slavic
Version 4
Czech
West Slavic
Version 1
South West Slavic Version 1/4
SloveneResiandialect of Slovene Version 3
CroatianSouth West Slavic Version 3
SerbianSouth West Slavic Version 2
Macedonian South East Slavic Version 4
Bulgarian South East Slavic Version 1
PersianIndo-IranianVersion 4
EstonianFinno-Ugric
Version 1
Version 1
Hungarian Finno-Ugric
Table 1. Languages covered by the morphosyntactic specifications.

The rest of this paper is structured as follows: Section 2 details the XML format of the speciﬁcations, Section 3 discusses the associated XSLT stylesheets, Section 4 brieﬂy introduces the
MULTEXT-East lexica and annotated corpus, and Section 5 gives some conclusions and directions for further work.

2

The format of the specifications in V4

In this section we give some background in the area of standardisation of multilingual morphosyntactic speciﬁcations, and detail their structure and encoding for MULTEXT-East Version 4.
The concepts expressed in MULTEXT-East speciﬁcations go back to the EAGLES guidelines
from the early ’90. The EU project EAGLES, the Expert Advisory Group on Language Engineering
Standards, was instrumental for advancing the ﬁeld of standardisation of language resources in a
multilingual setting, and tackled corpora, spoken resources, lexica etc. as well as morphosyntactic
descriptions and their speciﬁcations [2, 6].
But while the EAGLES compared a large number of proposals and gave general recommendations for encoding morphosyntactic descriptions, it did not provide explicit common speciﬁcations
for a set of languages which could be mapped into morphosyntactic descriptions as used in lexica
and corpora. This did, however, happen in the EU MULTEXT project, where the format of thespeciﬁcations was concretised [1] for six EU languages (Italian, German, Spanish, French, Dutch,
and English). The complete morphosyntactic speciﬁcations of MULTEXT were written as a LATEX
document, where the common tables are plain ASCII in a strictly deﬁned format. The MULTEXT
proposal also divided the features it deﬁned into “general” and language speciﬁc ones. The ﬁrst
are taken to be used by most MULTEXT languages, while the second were those that were felt tobe needed to describe the speciﬁcs of particular languages and their pre-existing resources.
MULTEXT-East adopted the MULTEXT format, except that it re-deﬁned the language particular features to accommodate the radically diﬀerent, mainly inﬂectional properties of the MULTEXTEast languages, and substituted the MULTEXT languages with the MULTEXT-East ones. The
two proposals thus cannot be trivially combined, as they share only a subset of the attributes.
The complete MULTEXT-East morphosyntactic speciﬁcations consist of the following parts:
1. introductory matter: preface, background, organisation of the proposal, bibliography
2. common part: attribute-value tables for each category with notes
3. language particular parts for each language
The MULTEXT speciﬁcations, in particular, the attribute-value tables of the common part,should be interpreted as deﬁning feature-structures, a well-known linguistic representation formalism, where a feature-structure consists of a set of attribute-value pairs. The common tables4Tomaž Erjavec

thus correspond to the deﬁnition of attribute- value pairs (e.g., that there exists, for Nouns, anattribute Type, which can have the values common or proper), while an MSD corresponds to a
fully-speciﬁed feature-structure. But in MULTEXT there was no automatic way (piece of software)
provided for converting the MSDs to feature-structures or vice-versa, or for checking the consistency of the speciﬁcations. For this reason MULTEXT-East soon developed a (Perl) program„which could expand, on the basis of the common tables in the speciﬁcations, MSDs into a plain
text feature-structures or check the validity of an MSD for a given language.
Having the document formatted in LATEX and the formal parts written as ASCII tables had thevirtue of simplicity but was problematic for at least two reasons. As mentioned, ad hoc programs
were needed to validate MSDs against the speciﬁcations, or to internally validate the speciﬁcations. As the years passed, it was also becoming increasingly diﬃcult to add new languages in acontrolled fashion, due to the brittleness of the plain text format, and to the inter-dependencies
and redundancy between the tables. What was needed was a formal speciﬁcation for the tables
that would enable their validation, extension, rendering on the Web or paper, or conversions into
other formats.
2.1

Using the TEIThe Text Encoding Initiative http://http://www.tei-c.org/ is an international consortium, whose
primary function is to maintain the TEI Guidelines, which set out a vocabulary of elements usefulfor describing text for scholarly purposes. The Guidelines use XML encoding and are written as aset of XML schemas (element grammars) with accompanying documentation. In MULTEXT-East
V3 we used Version P4 for encoding of the corpora, while in V4 we use of the most recent publishedversion, TEI P5 [20].
The are a number of advantages of using TEI for encoding. TEI documents are written in
XML, which brings with it the possibility of validation of document structure, a wealth of supporting software and related standards. Of these, the most important is the XML transformation
language, XSLT, which allows writing scripts (stylesheets) that transform XML documents into
other, diﬀerently structured XML documents, or into HTML as well as, indirectly, into a printableversion in, say, PDF. The XSLT standard is nowadays generally supported, e.g., we ﬁnd it implemented in most Web browsers. The MULTEXT-East speciﬁcations come with a number of XSLTtransforms, which help in authoring or displaying the speciﬁcations; they are further discussed in
Section 3.
TEI is also general enough to encode the non-normative parts of the speciﬁcations, e.g., theintroductions, notes, references, etc. The TEI also provides, amongst other software, a sophisticatedset of XSLT stylesheets and associated components for converting TEI documents into HTML and
PDF. These stylesheets, developed by Sebastian Rahtz and freely available via the TEI homepage,
cover a large number of TEI elements, and also perform tasks such as generating the table ofcontents, splitting (large) TEI documents into several HTML ﬁles (while preserving cross-links),
giving each HTML a project deﬁned header and footer, etc.
Finally, the MULTEXT-East parallel and MSD annotated corpus was already encoded in
TEI; by encoding the speciﬁcations in TEI as well, this gives an easy way to directly integrate thecorpus with the speciﬁcations, leading to simple validation of the corpus annotations or conversion
between corpus MSDs and their feature-structure representations. This can be extremely useful for
querying the corpus, as it enables e.g., the selection of word tokens based on particular features.
For these reasons the V4 speciﬁcations are written in TEI P5, as one XML document (which
does not mean they have to be in one ﬁle), with the idea that this is the single document whichneeds to be maintained and to which new languages are added in a controlled fashion. The structure
should therefore be amenable to hand editing, minimally redundant, contain as much as possibleof structured commentary and references, with the formal parts having a transparent structure.
2.2

The common part of the specifications

This section gives more detail about the structure of the common part of the speciﬁcations in TEI.
The common part of the speciﬁcations contains:MULTEXT-East Morphosyntactic Specifications V4

5

1. A table giving all the languages of the speciﬁcation. For each language the table also gives its
language family, ISO 836 code, and a link to its description in the Ethnologue database.
2. A table giving the (part-of-speech) categories of MULTEXT-East (12) together with their oneletter codes. The derived HTML of the speciﬁcations (so called display version) additionallycontains the number of attributes deﬁned for each category and which languages distinguishthem.
3. For each category, the common table, deﬁning attributes and their values for the category. For
attribute they also specify its position in the MSD string, and for each attribute-value pair, aone letter code for the MSD string. For each such pair, the table also lists the languages thatthe attribute-value is valid for.
4. A table of all deﬁned attributes, with the categories they are deﬁned for, and their position in
the MSD string (in display version only, and automatically generated from the XML source).
5. A table of all deﬁned values, with the attribute/categories they are deﬁned for, their code in
the MSD string, and the languages that distinguish this attribute-value pair (in display version
only, and automatically generated from the XML source).
Figure 1 gives an example from the TEI source, while Figure 2 gives the display view; the latteris, on purpose, quite similar to the tables in MULTEXT-East V3. The master TEI is, however,more logically oriented: the ﬁrst row deﬁnes the category and gives the languages it is appropriate
for while the following rows each deﬁne an attribute, with the values given in a subordinate table.

2.3

The language particular specifications

The speciﬁcations contain, for each language, also a language particular part. These parts canhave a minimal structure, just giving the authors and repeating the common tables, but reduced
to the categories and attribute-value pairs that are in fact used by the language. They can also bequite complex and can contain some or all of the following divisions:– Introductory matter, e.g., language description; background of the language speciﬁcations;bibliography.
– Then, for each category:• The language particular table, which can be automatically derived form the common table,
but also modiﬁed from it, as will be further described below. Furthermore, the tables canalso contain localisation information, i.e., the names of the categories, attributes, theirvalues and codes in the particular language, in addition to English. This enables keeping
the feature-structures and MSDs either in English, or in the language in question.
• Notes on the category itself or on the attributes and values used.
• Combinations of attribute-values (feature co-occurrence restrictions), which in a regularexpression-like syntax limit the possible combinations of attribute-values. These restrictions can also contain examples of usage. It should be noted that these combinations have
not yet been operationalised, i.e., it is not possible to directly use them to validate MSDs.
• A list of lexical MSDs, which should contain all the valid MSDs for the category. This ispresent only in the display view and automatically extracted from the full MSD index.
– The MSD index, which should contain all the valid MSDs for the language. Each MSD canbe furthermore accompanied by explicatory information, i.e., its decomposition into featurevalues, examples of usage, and its translation. This index is the authority for the MSD set for
the language, and is valuable for MSD validation.
As an example of how a language particular table can look in Version 4, we give the JOS
table for Slovene Nouns in Figure 3. The table gives identical information as the (Slovene selected)
common tables, except that all information is also translated/localised to Slovene.

6Tomaž Erjavec<div type="section" id="msd:Q"><head>Particle (Q)</head><table n="mtems-cat"><head>Common specifications for Particle</head><row role="type"><cell role="position">0</cell><cell role="name">CATEGORY</cell><cell role="value">Particle</cell><cell role="code">Q</cell><cell role="lang">ro</cell><cell role="lang">sl</cell>...
</row><row role="attribute"><cell role="position">1</cell><cell role="name">Type</cell><cell role="status">common</cell><cell><table><row role="value"><cell role="name">negative</cell><cell role="code">z</cell><cell role="lang">ro</cell><cell role="lang">bg</cell><cell role="lang">hr</cell><cell role="lang">sr</cell></row><row role="value"><cell role="name">infinitive</cell><cell role="code">n</cell><cell role="lang">ro</cell></row><row role="value"><cell role="name">subjunctive</cell><cell role="code">s</cell><cell role="lang">ro</cell></row>...
</table></cell></row>...
</table>...
</div>
Fig. 1. Example of a MULTEXT-East common table: start of definition for Particle.

MULTEXT-East Morphosyntactic Specifications V4

7

Fig. 2. Example of a common tabels in HTML: Particle.

In MULTEXT and MULTEXT-East V3 the attribute-value deﬁnitions, together with MSD
mapping information (i.e., the attribute position and the attribute-value code) were simply copiedfrom the common tables. In MULTEXT-East V4 we take a more ﬂexible position, where a language
particular section can have a looser connection to the common tables — in fact, it could be acompletely diﬀerent speciﬁcation, matching to the MULTEXT-East common one only in form.
Of course, in this case any sensible mapping from the language particular speciﬁcation to thecommon MULTEXT-East ones become very diﬃcult, if not impossible. However, there do exist
sensible compromises between the trivial mapping of MULTEXT and MULTEXT-East V3 and acompletely unconstrained one.
The one we plan to adopt for the Slovene speciﬁcation in Version 4 is exempliﬁed by the
JOS speciﬁcation, where the tables will be aligned to the MULTEXT-East common ones in all
respects, except for the attribute positions. This means that the feature-structure set of bothwill be identical, but not the MSDs. The reason for this is that MULTEXT-East has to cater for
attributes of all languages, so language speciﬁc attributes (or those added to the speciﬁcations at alater date) wind up at the end of the string, leading to unwieldy MSDs, such as Gppspe--n-----d.
This MSD has a number of hyphens only in order to maintain the position mapping to features,
even though the attributes for some of these positions are never used for Slovene. With the freedom
to reorder attributes, an individual language can use much shorter and more intuitive MSDs.

3

XSLT stylesheets

An important part of the speciﬁcations are the associated XSLT stylesheets, which allow for varioustransformations over the speciﬁcations. The stylesheets are written in XLST V1.0 and documented
with XSLTdoc, http://www.pnp-software.com/XSLTdoc/. They take the speciﬁcations as input,
usually together with certain command line arguments, and produce either XML, HTML or text
output, depending on the stylesheet.
We provide three classes of transformations, the ﬁrst ones to help in adding a new language
to the speciﬁcations themselves, the second to transform the speciﬁcations into HTML, and thethird to transform or validate a list of MSDs.

8Tomaž Erjavec<div type="section" xml:id="msd.N"><head xml:lang="sl">Samostalnik</head><head xml:lang="en">Noun</head><table n="msd.cat" xml:id="msd.cat.N"><head xml:lang="sl">Tabela atributov in vrednosti za samostalnik</head><head xml:lang="en">Attribute-Value Table for Noun</head><row role="type"><cell role="position">0</cell><cell role="name" xml:lang="sl">samostalnik</cell><cell role="code" xml:lang="sl">S</cell><cell role="name" xml:lang="en">Noun</cell><cell role="code" xml:lang="en">N</cell></row><row role="attribute"><cell role="position">1</cell><cell role="name" xml:lang="sl">vrsta</cell><cell role="name" xml:lang="en">Type</cell><cell role="values"><table><row role="value"><cell role="name" xml:lang="sl">občno_ime</cell><cell role="code" xml:lang="sl">o</cell><cell role="name" xml:lang="en">common</cell><cell role="code" xml:lang="en">c</cell></row><row role="value"><cell role="name" xml:lang="sl">lastno_ime</cell><cell role="code" xml:lang="sl">l</cell><cell role="name" xml:lang="en">proper</cell><cell role="code" xml:lang="en">p</cell></row></table></cell></row>

Fig. 3. JOS morphosyntactic specifications: start of table for Noun.

3.1

Authoring

The two stylesheets belonging to this class are meant to assist in adding new languages to thespeciﬁcations, and are the following:
msd-split.xsl makes a template for a language particular section on the basis of the value given
to the -langs parameter, which should contain a space separated list of ISO language codes.
So, to make section for a new language X, which is similar to Y and Z, the stylesheet would
be run with -langs ’Y Z’ and would produce a section with the union of the attribute-values
for these two languages. These new language particular speciﬁcations are then corrected byhand.
msd-merge.xsl takes a language particular speciﬁcation, and tries to “insert” it into the common
speciﬁcations. This can mean simply adding the new language ﬂags to existing attribute-value
pairs, or adding new values or even new attributes to the common speciﬁcations.
3.2

Rendering

Displaying the stylesheets is currently only supported in HTML. This is done in two stages:
msd-spec2prn.xsl generates a “display-oriented” TEI document from the speciﬁcations. Thismeans making display-oriented tables and generating the indexes of attributes, values, andMSDs.
msd-prn2html.xsl is a driver ﬁle, which calls the standard TEI stylesheets. It takes as input thedisplay-oriented document and produces the HTML equivalent.
3.3

MSD conversion

The stylesheets in this class take a list of MSDs as a parameter, and, on the basis of the given
speciﬁcations typically convert them to some form of feature-structures. The speciﬁcations can

MULTEXT-East Morphosyntactic Specifications V4

9be either the MULTEXT-East common ones, or those for a particular language, depending onwhether the MSDs are the common or language particular ones.
msd-expand.xsl produces diﬀerent types of output, depending on the values of its “mode” parameter. It also takes parameters for input language (only MSDs valid for the language will
be accepted) and for output language (it can localised to a language, which, of course, mustbe supported by the speciﬁcations). The output is in plain text tabular format, with columns
that can be, depending on the value of mode, which is a space separated list of modes, thefollowing:check only checks the validity of the input MSDs, ﬂagging codes that are illegal for the
language — this mode does not combine with the other ones;
id identity transform (with possible localisation);collate collating sequence, with which it is possible to sort MSDs so that their order corresponds to the ordering of categories, attributes and their values in the speciﬁcations;brief expansion to values only, which the is the most compact feature-expanded format andis meant for short but still readable expansions of MSD; instead of binary values (yes/no),+/-Attribute is written;
verbose expansion to feature-structures (attribute=value pairs) for all attributes deﬁned forthe category of the MSD;
canonical expansion to feature-structures (attribute=value pairs) for all deﬁned attributes,
regardless of whether they are deﬁned for a particular category or not;msd-fslib.xsl transforms the MSD list into a XML/TEI feature and feature-structure libraries,
suitable for inclusion into MSD annotated and TEI encoded corpora.
The intention isn’t to run the above stylesheet whenever a transformation is needed but rather
to run them, once the speciﬁcations are ﬁnished, over the complete set of MSDs to produce
the tabular and XML ﬁles, which are then made available together with the speciﬁcations. To
enable simpler processing and to produce output ﬁles with useful combinations of expansions, anadditional Perl wrapper script is made available with the speciﬁcations.

4

Associated resources

Even though this paper is devoted to the morphosyntactic speciﬁcations, we also mention associated MULTEXT-East morphosyntactic resources, as without them, the speciﬁcations are not ofmuch use. In the ﬁrst instance this means the MULTEXT-East morphosyntactic lexicons, as it
the lexicons that should provide the complete set of MSDs for a language, as well as examples of
their usage. A second level resource are MSD annotated corpora, as this grounds the lexicon incontextualised examples of usage.
4.1

MULTEXT-East Lexicons

The MULTEXT-East morphosyntactic lexicons have a simple structure, where each lexical entry
is composed of three ﬁelds: (1) the word-form, which is the inﬂected form of the word, as it
appears in the text, modulo sentence-initial capitalisation; (2) the lemma, which is the base-formof the word; where the entry is itself the base-form, the lemma is typically given as the equal
sign; and (3) the MSD, i.e., the morphosyntactic description, which should be 1) valid according
to the speciﬁcations and 2) contained in the set of MSDs listed in the lexical list of the language
particular sections. It should be noted that this second criterion is to an extent circular, as it
will be the lexicon that ultimately determines the list of valid MSDs; in practice, the process ofconstructing the MSD list and lexicon therefore typically proceeds in a cyclic fashion. Optionally,
the lexicon can contain also contain (4) a column, giving the frequencies of the lexical entries ina corpus — for this, a MSD tagged and lemmatised corpus of the language must of course beavailable. Figure 4 gives some example entries from the Slovene lexicon.

10Tomaž Erjavec

alibi
alibi
alibijaalibijaalibijaalibijealibijem
alibijem
alibijema
alibijema

=
alibi
alibi
alibi
alibi
alibi
alibi
alibi
alibi
alibi

Ncmsn
Ncmsa--n
Ncmda
Ncmdn
Ncmsg
Ncmpa
Ncmpd
Ncmsi
Ncmdd
Ncmdi

Fig. 4. Example of a MULTEXT-East morphosyntactic lexicons: the start of the paradigm for the Slovene
masculine nominal lemma “alibi”.

It is usually not the case that MULTEXT-East lexicons are produced from scratch but rather
converted from some existing morphosyntactic lexica for a language. The MULTEXT-East lexica
up to Version 3 were constructed according to diﬀerent principles, but an ideal lexicon obeys thefollowing principles:
1. The lexicon should contain all the valid MSDs for the language, even if only single exemplars areprovided for particular MSDs. This criterion is in fact more strict than it seems, as languages
with a large number of MSDs (e.g., Slovene has almost 2,000) exhibit a Zipﬁan distribution,i.e., quite a large number of MSDs can be quite rare in practice.
2. The lexicon should, for the lemmas it contains, include their complete inﬂectional paradigms.
This is not always possible, as certain languages (e.g., agglutinating ones) can have “paradigms”
with over a million word-forms but is manageable for even highly inﬂecting languages. The
advantage is including the complete paradigms is that this makes the lexicon a very good
resource for machine learning of lemmatisers; additionally, it also makes it more likely to obey
the condition 1) above.
3. The lexicons should be of reasonable size (most current MULTEXT-East have around 15,000
lemmas), and, of course, the larger, the better. Ideally, the lemmas appearing in the lexicon
should be grounded in an annotated corpus of the language, and the entries accompanied bycorpus frequencies.
We do not here attempt to tackle the diﬃcult problem of conversion of existing lexica to
MULTEXT-East ones, but it should be noted that the mtems-expand.xsl in its check mode canbe of considerable help in validating the lexical MSDs.
4.2

Annotated corpus

A corpus, annotated with context disambiguated MSDs and lemmas, provides the ﬁnal piece of the“morphosyntactic triad”, as it contextually validates the speciﬁcations and lexicon, and provides
examples of actual usage of the MSDs and lexical items.
Corpora currently included in MULTEXT-East deliverables are all (translations of) the novel“1984” by G. Orwell. The complete novel has about 100.000 tokens, although this of course diﬀers
between the languages. The corpus is annotated with MSDs and lemmas, which makes it suitablefor MSD tagging and lemmatisation experiments. Because it was the ﬁrst such resource for manyof the languages involved the annotation had to proceed mostly manually. The corpus is, in Version
3, encoded in XML, according to the Text Encoding Initiative Guidelines P4 [19], but it is planned
to upgrade it to TEI P5 in Version 4. To exemplify the current structure, Figure 5 gives the startof the Slovene part of the corpus.
This parallel corpus also comes with separate alignment ﬁles, which contain, in V3, handvalidated pair-wise sentence alignments (not necessarily 1-1) between English and the translations.
For V4 we also plan to provide pair-wise alignments between all the languages, which have been
automatically induced from the alignments with English.

MULTEXT-East Morphosyntactic Specifications V4

11<text id="Osl." lang="sl"><body><div type="part" id="Osl.1"><div type="chapter" id="Osl.1.2"><p id="Osl.1.2.2"><s id="Osl.1.2.2.1"><w lemma="biti" ana="Vcps-sma">Bil</w><w lemma="biti" ana="Vcip3s--n">je</w><w lemma="jasen" ana="Afpmsnn">jasen</w><c>,</c><w lemma="mrzel" ana="Afpmsnn">mrzel</w><w lemma="aprilski" ana="Aopmsn">aprilski</w><w lemma="dan" ana="Ncmsn">dan</w>...
Fig. 5. Example of the annotation of the MULTEXT-East “1984” corpus: the start of the Slovene text
“Bil je jasen, mrzel aprilski dan” (It was a bright cold day in April ).

5

Conclusions

The paper presented the morphosyntactic speciﬁcations that will be part of the MULTEXT-East
resources Version 4. The speciﬁcations currently cover 13 languages, and are encoded in TEI
P5, with dedicated XSLT scripts to help with authoring the speciﬁcations for new languages,
convert them into feature-structures or into a display HTML encoding. As the speciﬁcations covera number of languages for which not many available and standardised resources exist, they canbe a valuable reference point, and, together with the accompanying lexica and corpora, can serve
as a “gold standard” dataset for language technology research and development, as well as forcomparative linguistic studies.
There are a number of possible directions for further work. The language particular parts ofthe speciﬁcations could be further formalised and operationalised, esp. the combinations sections,as this would help in validating the MSD set for new languages. The attributes and their values
could also be linked to other related attempts at standardisation of morphosyntactic features, inparticular the ontology for descriptive linguistics GOLD http://linguistics-ontology.org/gold.html
and the ISOcat Data Category Registry http://www.isocat.org/. There is also work to do in further
formalisation of the MSDs and their relation to feature-structures, e.g., in allowing MSDs to include
the metasymbols ’*’ or ’.’, i.e., having underspeciﬁed features in the MSD string.
Of course, we also hope that further languages will be added to the speciﬁcations. An obvious
extension in this direction would be to add the original MULTEXT languages. However, we would
encounter several problems: the speciﬁcations are incompatible outside the “common” features,
so a way would needed to resolve this inconsistency, and in a backward compatible manner. More
importantly, the associated resources, namely the lexicon and annotated corpus would have to be
produced as well, to give the speciﬁcations some grounding in data. This is a relatively lengthily
process, and it is unlikely that it could be carried out without dedicated international funding.
The situation is somewhat diﬀerent, and better, for other, non Western European languages,
where national eﬀorts are underway to produce components of Basic Linguistic Resource Toolkits
or BLARKs [16]; these can easily take the well-travelled route of developing MULTEXT-East
compatible resources. Hopefully such an expansion could take place in the MONDILEX project,
to include further Slavic languages into the speciﬁcations.
Finally, the most important aspect of the resources should be further encouraged, namely theiruse. Developing linguistic resources is not an end to itself, and they are worth only as much as
they are used. We have therefore tried to maintain their quality and standardise their structure,
to ensure that they can be interchanged and re-used for various purposes.

References[1] Bel, N., Calzolari, N., and Monachini (eds.), M. (1995). Common Speciﬁcations and Notation for Lexicon Encoding and Preliminary Proposal for the Tagsets. MULTEXT Deliverable
D1.6.1B, ILC, Pisa.
[2] Calzolari, N. and Monachini (eds.), M. (1996). Synopsis and Comparison of Morphosyntactic Phenomena Encoded in Lexicons and Corpora: A Common Proposal and Applications to European Languages. EAGLES Report EAG—CLWG—MORPHSYN/R, ILC, Pisa.
http://www.ilc.cnr.it/EAGLES96/morphsyn/.
[3] Dimitrova, L., Erjavec, T., Ide, N., Kaalep, H.-J., Petkevič, V., and Tuﬁș, D. (1998). MultextEast: Parallel and Comparable Corpora and Lexicons for Six Central and Eastern European
Languages. In COLING-ACL ’98, pages 315–319, Montréal, Québec, Canada. ACL.
[4] Džeroski, S., Erjavec, T., Ledinek, N., Pajas, P., Žabokrtsky, Z., and Žele, A. (2006). Towards
a Slovene Dependency Treebank. In Fifth International Conference on Language Resources and
Evaluation, LREC’06, Paris. ELRA.
[5] EAGLES (1996).
Expert Advisory Group on Language Engineering Standards.
http://www.ilc.pi.cnr.it/EAGLES/home.html.
[6] EAGLES (1996). Recommendations for the Morphosyntactic Annotation of Corpora. EAGLES
Report EAG–TCWG–MAC/R, ILC, Pisa. http://www.ilc.cnr.it/EAGLES96/annotate/.
[7] Erjavec, T. (2004). MULTEXT-East Version 3: Multilingual Morphosyntactic Speciﬁcations,
Lexicons and Corpora. In Fourth International Conference on Language Resources and Evaluation, LREC’04, pages 1535 – 1538, Paris. ELRA. http://nl.ĳs.si/et/Bib/LREC04/.
[8] Erjavec, T. (2006). MULTEXT-East Morphosyntactic Speciﬁcations and XML. In Slavcheva,
M., Simov, K., and Angelova, G., editors, Readings in multilinguality, pages 41–48. Bulgarian
Academy of Science, Soﬁa.
[9] Erjavec, T. and Džeroski, S. (2004). Machine Learning of Language Structure: Lemmatising
Unknown Slovene Words. Applied Artiﬁcial Intelligence, 18(1):17–41.
[10] Erjavec, T. and Krek, S. (2008). The JOS morphosyntactically tagged corpus of Slovene. In
Sixth International Conference on Language Resources and Evaluation, LREC’08, Paris. ELRA.
[11] Erjavec, T., Krstev, C., Petkevič, V., Simov, K., Tadić, M., and Vitas, D. (2003). The
MULTEXT-East Morphosyntactic Speciﬁcations for Slavic Languages. In Proceedings of the
EACL 2003 Workshop on Morphological Processing of Slavic Languages, pages 25–32. ACL.
[12] Ide, N. (1998). Corpus Encoding Standard: SGML guidelines for encoding linguistic corpora.
In First International Conference on Language Resources and Evaluation, LREC’98, pages 463–
470, Granada. ELRA. http://www.cs.vassar.edu/CES/.
[13] Ide, N., Erjavec, T., and Tuﬁș, D. (2002). Sense Discrimination with Parallel Corpora. In
Workshop on Word Sense Disambiguation: Recent Successes and Future Directions, pages 54–60,
Philadelphia. ACL.
[14] Ide, N. and Véronis, J. (1994). Multext (multilingual tools and corpora). In Proceedings ofthe 15th International Conference on Computational Linguistics, pages 90–96, Kyoto. ACL.
[15] Ivanovska, A., Zdravkova, K., Erjavec, T., and Džeroski, S. (2006). Learning Rules for Morphological Analysis and Synthesis of Macedonian Nouns, Adjectives and Verbs. In Proceedingsof 5th Slovenian and 1st international Language Technologies Conference, Jožef Stefan Institute,
Ljubljana.
[16] Maegaard, B., Krauwer, S., Choukri, K., and Jorgensen, L. D. (2006). The BLARK concept and BLARK for Arabic. In Fifth International Conference on Language Resources and
Evaluation, LREC’06, Paris. ELRA.
[17] QasemiZadeh, B. and Rahimi, S. (2006). Persian in MULTEXT-East Framework. In FinTAL
2006: 5th International Conference on Natural Language Processing, pages 541–551, Turku,
Finland.
[18] Sharoﬀ, S., Kopotev, M., Erjavec, T., Feldman, A., and Divjak, D. (2008). Designing andevaluating a Russian tagset. In Sixth International Conference on Language Resources and
Evaluation, LREC’08, Paris. ELRA.

MULTEXT-East Morphosyntactic Specifications V4

13[19] Sperberg-McQueen, C. M. and Burnard, L., editors (2002). Guidelines for Electronic Text
Encoding and Interchange, The XML Version of the TEI Guidelines. The TEI Consortium.
[20] TEI Consortium, editor (2007). TEI P5: Guidelines for Electronic Text Encoding and Interchange.
[21] Tuﬁș, D. (1999). Tiered Tagging and Combined Language Model Classiﬁers. In Jelinek, F.
and Noth, E., editors, Text, Speech and Dialogue, number 1692 in Lecture Notes in Artiﬁcial
Intelligence, pages 28–33, Berlin. Springer-Verlag.
[22] Vojnovski, V., Džeroski, S., and Erjavec, T. (2005). Learning PoS Tagging from a Tagged
Macedonian Text Corpus. In Proceedings of the 8th International Conference Information Society, IS 2005, Jožef Stefan Institute, Ljubljana.