Provided by: mmorph_2.3.4.2-15_amd64 bug

NAME

       mmorph - MULTEXT morphology tool formalism syntax

DESCRIPTION

       A  mmorph  morphology description file is divided into declaration sections.  Each section
       starts by a section header (`@ Alphabets', `@ Attributes', etc.)  followed by  a  sequence
       of  declarations.   Each  declaration  starts by a name, followed by a colon (`:') and the
       definition associated to the name.  Here is a brief description of each section:

@ Alphabets

       In this section the lexical and surface alphabet are declared.  All symbols  forming  each
       alphabet  has  to  be listed.  Symbols may appear in both the lexical and surface alphabet
       definition in which case it is considered a bi-level symbol, otherwise  it  is  a  lexical
       only  or  surface  only symbol.  Symbols are usually letters (eg.  a, b, c) , but may also
       consist of longer names (beta, schwa).  Symbol names consisting of one  special  character
       (`:' or `(') may be specified by enclosing them in double quotes (`:' or `(').
       Example:

              Lexical  :  a b c d e f g h i j k l m n o p q r s t u v w x y z "-" "." "," "?" "!"
                     "\"" "'" ":" ";" "(" ")" strong_e

              Surface : a b c d e f g h i j k l m n o p q r s t u v w x y z "-" "." ","  "?"  "!"
                     "\"" "'" ":" ";" "(" ")" " "

       In  this  example,  the symbol strong_e is lexical only, the symbol " " (space) is surface
       only.  All the other symbols are bi-level.

       All the strings appearing in the rest of the grammar will be made exclusively  of  symbols
       declared in this section.

@ Attributes

       In  this  section, the name of attributes (sometimes called features) and their associated
       value set.  At most 32 different values may be declared for an attribute.
       Examples:

              Gender : feminine masculine neuter
              Number : singular plural
              Person : 1st 2nd 3rd
              Transitive : yes no
              Inflection : base intermediate final

       In the current version of the  implementation  value  sets  of  different  attributes  are
       incompatible,  even  if  they are defined identically.  To overcome this restriction, in a
       future version this section will be  split  into  two:   declaration  of  value  sets  and
       declaration of attributes.

@ Types

       In  this  section, the different types of feature structures are declared.  The attributes
       allowed for each type are listed.  Attributes that are only used within the scope  of  the
       tool  and  have  no  meaning outside can be listed after a bar (`|').  The values of these
       local attributes ar not stored in the database or written  on  the  final  output  of  the
       program.
       Examples:

              Noun : Gender Number
              Verb : Tense Person Gender Number Transitive | Inflection

Typed feature structures

       Typed  feature  structures  are  used  in  the  grammar  and  spelling  rules.   It is the
       specification of a type and  the  value  of  some  associated  attributes.   The  list  of
       attribute specifications is enclosed in square brackets (`[' and `]').
       Example:

              Noun[ Gender=feminine Number=singular ]

       It  is possible to specify a set of values for an attribute by listing the possible valuse
       separated with a bar (`|'), or the complement of a  set  (with  respect  to  all  possible
       values of that attribute) indicated with `!=' instead of `='.
       Example:   Assuming  the  declaration  of Gender as above, the following two typed feature
       structures are equivalent

              Noun[ Gender=masculine|neuter ]
              Noun[ Gender!=feminine ]

@ Grammar

       This section contains the rules that specify the structure of words.  It has  the  general
       shape  of  a  context  free  grammar over typed feature structures.  There are three basic
       types of rules:  binary, goal and affixes.

       Binary rules specify the result of the concatenation of two elements. This is written as:

              Rule_name : Lhs <- Rhs1 Rhs2

       where Lhs is called the left hand side, and Rhs1 and Rhs2 the first and second part of the
       right hand side.  Lhs, Rhs1 and Rhs2 are specified as typed feature structures.
       Example:

              Rule_1  : Noun[ Gender=feminine Number=singular ]
                      <- Noun[ Gender=feminine Number=singular ]
                         NounSuffix[ Gender=feminine ]

       Variables can be used to indicate that some attributes have the same value.  A variable is
       a name starting with a dollar (`$').
       Example:

              Rule_2  : Noun[ Gender=$A Number=$number ]
                      <- Noun[ Gender=$A Number=$number ]
                         NounSuffix[ Gender=$A ]

       If needed, both a variable and a value specification can be given for an  attribute  (only
       once per attribute):
       Example:

              Rule_3  : Noun[ Gender=$A Number=$number ]
                      <- Noun[ Gender=$A Number=$number ]
                         NounSuffix[ Gender=$A=masculine|neuter ]

       Affix  rules  define  basic  elements  of  the  concatenations  specified  by binary rules
       (together with lexical entries, see the section @ Lexicon below).  An affix rule  consists
       of lexical string associated to a typed feature structure.
       Examples:

              Plural_s : "s" NounSuffix[ Number=plural ]
              Feminine_e : "e" NounSuffix[ Gender=feminine ]
              ing : "ing" VerbSuffix[ Tense=present_participle ]

       Goal  rules  specify the valid results constructed by the grammar.  They consist of just a
       typed feature structure.
       Examples:

              Goal_1  : Noun[]
              Goal_2  : Verb[ inflection=final ]

       In addition to these three basic rule types, there are prefix or  suffix  composite  rules
       and unary rules.  A unary rule consist of a left hand side and a right hand side.
       Example:

              Rule_4  : Noun[ gender=$G number=plural ]
                      <- Noun[ gender=$G number=singular invariant=yes]

       Prefix and suffix composite rules have the same shape as binary rules except that one part
       of the right hand side is an affix (i.e. has an associated string).
       Examples:

              Append_e   : Noun[ Gender=feminine Number=$number ]
                      <- Noun[ Gender=feminine Number=$number ]
                         "e" NounSuffix[ Gender=feminine ]

              anti    : Noun[ Gender=$gender Number=$number ]
                      <- "anti" NounPrefix[]
                         Noun[ Gender=$gender Number=$number ]

@ Classes

       This optional section contains the definition of symbol classes. Each class is defined  as
       a  set  of symbols, or other classes. If the class contains only bi-level elements it is a
       bi-level class, otherwise it is a lexical or surface class.
       Examples:

              Dental : d t
              Vowel : a e i o u
              Vowel_y : Vowel y
              Consonant: b c d f g h j k l m n p q r s t v w x z

@ Pairs

       This optional section contains the definition of pair disjunctions.  Each  disjunction  is
       defined  as  a  set  of pairs.  Explicit pairs specify a sequence of surface symbols and a
       sequence of zero or one lexical symbol,  one  of  them  possibly  empty.   A  sequence  is
       enclosed  between  angle brackets `<' and `>'.  The empty sequence is indicated with `<>'.
       In the current implementation only the surface part of a pair can be a  sequence  of  more
       than  one  element.   The special symbol `?' stands for the class of all possible symbols,
       including the morpheme and word boundary.
       Examples:

              s_x_z_1 : s/s x/x z/z
              VowelPair1: a/a e/e i/i o/o u/u
              VowelPair2: Vowel/Vowel
              ie.y: <i e>/y
              Delete_e: <>/e
              Insert_d: d/<>
              Surface_Vowel: Vowel/?
              Lexical_s:  ?/s

              DoubleConsonant: <b b>/b <d d>/d <f f>/f <g g>/g <k k>/k  <m m>/m  <p p>/p  <s s>/s
                     <t t>/t <v v>/v <z z>/z

       Note  that  VowelPair1 and VowelPair2 don't specify the same thing: VowelPair2 would match
       a/o but VowelPair1 would not.

       Implicit pairs are specified by the name of a bi-level symbol or a bi-level class.
       Examples:  the following s_x_z_2 and VowelPair3 are equivalent to the  above  s_x_z_1  and
       VowelPair2 (assuming that s, x, z and Vowel are bi-level symbols and classes).

              s_x_z_2 : s x z
              VowelPair3 : Vowel

       In  a pair disjunction all lexical parts should be disjoint. This means you cannot specify
       for the same pair disjunction a/a and o/a or a/a and Vowel/Vowel.

       In a future version this section will be split in two:  simple pair disjunctions and  pair
       sequences.

@ Spelling

       In  this  section are declared the two level spelling rules.  A spelling rule consist of a
       kind indicator followed by a left context a focus and a right context.  The kind indicator
       is  `=>'  if  the  rule is optional, `<=>' if it is obligatory and `<=' if it is a surface
       coercion rule.  The contexts may be empty.  The focus  is  surrounded  by  two  `-'.   The
       contexts and the focus consist of a sequence of pairs or pair disjunctions declared in the
       `@ Pairs section.  A morpheme boundary is indicated by a `+' or a `*', a word boundary  is
       indicated by a `~'.
       Examples:

              Sibilant_s: <=> s_x_z_1 * - e/<> - s
              Gemination: <=>
                      Consonant Vowel - DoubleConsonant - * Vowel
              i_y_optionnel: => a - i/y - * ?/e

       Constraints  may be specified in the form of a list of typed feature structures.  They are
       affix-driven:  the rule is  licensed  if  at  least  one  of  them  subsumes  the  closest
       corresponding  affix.   The  morpheme  boundary  indicated by a star (`*') will be used to
       determine which affix it is.  If there is no such indication, then the affix  adjacent  to
       the  morpheme  where the first character of the focus occurs is used.  In case there is no
       affix, the typed feature structure of the lexical stem is used.
       Example:

              Sibilant_s: <=>
                  s_x_z_1 * - e/<> - s NounSuffix[ Number=plural ]

@ Lexicon

       This section is optional and can also be repeated.  This section  lists  all  the  lexical
       entries  of  the morphological description.  Unlike the other sections, definitions do not
       have a name.  A definition consist of a typed feature  strucure  followed  by  a  list  of
       lexical  stems  that  share that feature structure.  A lexical stem consists of the string
       used in the concatenation specified by the grammar rules followed by `=' and  a  reference
       string.   The  reference  string  can  be  anything  and  usually  is used to indicate the
       canonical form of the word or an identifier of an external database entry.
       Examples:
              Noun[ Number=singular ] "table" = "table" "chair" = "chair"
              Verb[ Transitive=yes|no Inflection=base ] "bow" = "bow1"
              Noun[ Number=singular ] "bow" = "bow2"

       If the stem string and  the  reference  strings  are  identical,  only  one  needs  to  be
       specified.
       Example:

              Noun[ Number=singular ] "table" "chair"

FORMAL SYNTAX

       The  formal  syntax  description  below  is  in  Backus  Naur  Form  (BNF).  The following
       conventions apply:

       <id>      is a non-terminal symbol (within angle brackets).
       ID        is a token (terminal symbol, all uppercase).
       <id>?     means zero or one occurrence of <id> (i.e. <id> is optional).
       <id>*     is zero or more occurrences of <id>.
       <id>+     is one or more occurrences of <id>.
       ::=       separates a non-terminal symbol and its expansion.
       |         indicates an alternative expansion.
       ;         starts a comment (not part of the definition).

       The start symbol corresponding to a complete description is named <Start>.   Symbols  that
       parse but do nothing are marked with `; not operational'.

       <Start>           ::= <AlphabetDecl> <AttDecl> <TypeDecl> <GramDecl>
                             <ClassDecl>? <PairDecl>? <SpellDecl>? <LexDecl>*

       <AlphabetDecl>    ::= ALPHABETS <LexicalDef> <SurfaceDef>

       <LexicalDef>      ::= <LexicalName> COLON <LexicalSymbol>+

       <SurfaceDef>      ::= <SurfaceName> COLON <SurfaceSymbol>+

       <LexicalSymbol>   ::= <LexicalSymbolName>    ; lexical only
                         |   <BiLevelSymbolName>    ; both lexical and surface

       <SurfaceSymbol>   ::= <SurfaceSymbolName>    ; surface only
                         |   <BiLevelSymbolName>    ; both lexical and surface

       <AttDecl>         ::= ATTRIBUTES <AttDef>+

       <AttDef>          ::= <AttName> COLON <ValName>+

       <TypeDecl>        ::= TYPES <TypeDef>+

       <TypeDef>         ::= <TypeName> COLON <AttName>+ <NoProjAtt>?

       <NoProjAtt>       ::= BAR <AttName>+

       <LexDecl>         ::= LEXICON <LexDef>+

       <LexDef>          ::= <Tfs> <Lexical>+

       <Lexical>         ::= LEXICALSTRING <BaseForm>?

       <BaseForm>        ::= EQUAL LEXICALSTRING

       <Tfs>             ::= <TypeName> <AttSpec>?

       <VarTfs>          ::= <TypeName> <VarAttSpec>?

       <AttSpec>         ::= LBRA <AttVal>* RBRA

       <VarAttSpec>      ::= LBRA <VarAttVal>* RBRA

       <AttVal>          ::= <AttName> <ValSpec>

       <VarAttVal>       ::= <AttName> <VarValSpec>

       <ValSpec>         ::= EQUAL <ValSet>
                         |   NOTEQUAL <ValSet>

       <VarValSpec>      ::= <ValSpec>
                         |   EQUAL DOLLAR <VarName>
                         |   EQUAL DOLLAR <VarName> <ValSpec>

       <ValSet>          ::= <ValName> <ValSetRest>*

       <ValSetRest>      ::= BAR <ValName>

       <GramDecl>        ::= GRAMMAR <Rule>+

       <RuleDef>         ::= <RuleName> COLON <RuleBody>

       <RuleBody>        ::= <VarTfs> LARROW <Rhs>
                         |   <Tfs>    ; goal rule
                         |   LEXICALSTRING <Tfs>    ; lexical affix

       <Rhs>             ::= <VarTfs>    ; unary rule
                         |   <VarTfs> <VarTfs>    ; binary rule
                         |   LEXICALSTRING <Tfs> <VarTfs>   ; prefix rule
                         |   <VarTfs> <Tfs> LEXICALSTRING    ; suffix rule

       <ClassDecl>       ::= CLASSES<ClassDef>+

       <ClassDef>        ::= <LexicalClassName> COLON <LexicalClass>+
                         |   <SurfaceClassName> COLON <SurfaceClass>+
                         |   <BiLevelClassName> COLON <BiLevelClass>+

       <LexicalClass>    ::= <LexicalSymbol>
                         |   <LexicalClassName>
                         |   <BiLevelClassName>

       <SurfaceClass>    ::= <SurfaceSymbol>
                         |   <SurfaceClassName>
                         |   <BiLevelClassName>

       <BiLevelClass>    ::= <BiLevelSymbolName>
                         |   <BiLevelClassName>

       <PairDecl>        ::= PAIRS <PairDef>+

       <PairDef>         ::= <PairName> COLON <PairDef>+

       <PairDef>         ::= <PairName> COLON <Pair>+

       <Pair>            ::= <SurfaceSequence> SLASH <LexicalSequence>
                         |   <PairName>
                         |   <BiLevelClassName>
                         |   <BiLevelSymbolName>

       SurfaceSequence   ::= LANGLE <SurfaceSymbol>* RANGLE
                         |   SURFACESTRING
                         |   <SurfaceClass>
                         |   ANY

       LexicalSequence   ::= LANGLE <LexicalSymbol>* RANGLE
                         |   LEXICALSTRING
                         |   <LexicalClass>
                         |   ANY

       <SpellDecl>       ::= SPELLING <SpellDef>+

       <SpellDef>        ::= <SpellName> COLON <Arrow> <LeftContext> <Focus>
                                 <RightContext> <Constraint>*

       <LeftContext>     ::= <Pattern>*

       <RightContext>    ::= <Pattern>*

       <Focus>           ::= CONTEXTBOUNDARY <Pattern>+ CONTEXTBOUNDARY

       <Pattern>         ::= <Pair>
                         |   MORPHEMEBOUNDARY
                         |   WORDBOUNDARY
                         |   CONCATBOUNDARY

       <Constraint>      ::= <Tfs>

       <Arrow>           ::= RARROW
                         |   BIARROW
                         |   COERCEARROW

       <AttName>           ::= NAME
       <BiLevelClassName>  ::= NAME
       <BiLevelSymbolName> ::= NAME  | SYMBOLSTRING
       <LexicalClassName>  ::= NAME
       <LexicalName>       ::= NAME
       <LexicalSymbolName> ::= NAME  | SYMBOLSTRING
       <PairName>          ::= NAME
       <RuleName>          ::= NAME
       <SpellName>         ::= NAME
       <SurfaceClassName>  ::= NAME
       <SurfaceName>       ::= NAME
       <SurfaceSymbolName> ::= NAME  | SYMBOLSTRING
       <TypeName>          ::= NAME
       <ValName>           ::= NAME
       <VarName>           ::= NAME

   Simple tokens
       Simple  tokens  of  the  BNF  above  are  defined  as  follow:  The token name on the left
       correspond to the literal character or characters on the right:

       ANY                 ?
       BAR                 |
       BIARROW             <=>
       COERCEARROW         <=
       COLON               :
       CONCATBOUNDARY      *
       CONTEXTBOUNDARY     -
       DOLLAR              $
       EQUAL               =
       LANGLE              <
       LARROW              <-
       LBRA                ]
       MORPHEMEBOUNDARY    +
       NOTEQUAL            !=
       RARROW              =>
       RANGLE              <
       RBRA                [
       SLASH               /
       WORDBOUNDARY        ~

       ALPHABETS           @Alphabets
       ATTRIBUTES          @Attributes
       CLASSES             @Classes
       GRAMMAR             @Grammar
       LEXICON             @Lexicon
       PAIRS               @Pairs
       SPELLING            @Spelling
       TYPES               @Types

       In the section header tokens above, spaces may separate the `@' from the reserved word.

   Complex tokens
       NAME
              is any sequence of letter, digit, underline (`_'), period (`.')
              Examples:
              category
              33
              Rule_9
              __2__
              Proper.Noun

       LEXICALSTRING
              is a string of lexical symbols

       SURFACESTRING
              is a string of surface symbols

       SYMBOLSTRING
              is a string of just just one character (used only in alphabet declaration).

       A string consist of zero or  more  characters  within  double  quotes  (`"').   Characters
       preceded  by  a  backslash  (`\')  are  escaped  (the  usual C escaping convention apply).
       Symbols that have a name longer than one character are represented  using  a  SGML  entity
       like notation: `&symbolname;'.  The maximum number of symbols in a string is 127.
       Examples:

              "table"
              ","
              ""
              "double quote is \" and backslash is \\"
              "&strong_e;"
              "escape like in C : \t is ASCII tab"
              "escape with octal code: \011 is ASCII tab"

       Tokens can be separated by one or many blanks or comments.
       A blank separator is space, tab or newline.
       A  comment  starts  with  a  semicolon  and  finishes at the next newline (except when the
       semicolon occurs in a string.

       Inclusion of files can be specified with the usual `#include' directive:
       Example:
              #include "verb.entries"

       will splice in the content of the file verb.entries at  the  point  where  this  directive
       occurs.

       The  `#'  should  be the first character on the line.  Tabs or spaces may separate `#' and
       `include'.  The file name must be quoted.  Only tabs or spaces may occur on  the  rest  of
       the line.  Inclusion can be nested up to 10 levels.

SEE ALSO

       mmorph(1).

       G.  Russell  and  D.  Petitpierre,  MMORPH  - The Multext Morphology Program, Version 2.3,
              October 1995, MULTEXT deliverable report for task 2.3.1.

AUTHOR

       Dominique Petitpierre, ISSCO, <petitp@divsun.unige.ch>

COMMENTS

       The parser for the morphology description formalims above was written using yacc  (1)  and
       flex  (1).   Flex was written by Vern Paxson, <vern@ee.lbl.gov>, and is distributed in the
       framework of the GNU project under the condition of the GNU General Public License

                                    Version 2.3, October 1995                           MMORPH(5)