A-rule

From UNL Wiki
(Difference between revisions)
Jump to: navigation, search
(Generative and enumerative lexica)
(Generative and enumerative lexica)
Line 2: Line 2:
  
 
== Generative and enumerative lexica ==
 
== Generative and enumerative lexica ==
The repertoire of lexemes of a given language can be organized in two basic ways: 1) as a simple listing of all word forms, i.e., of all variants of the same lexeme ("die", "dies", "died", "dying", etc); or 2) as a list of base forms accompanied by morphological rules for generating their inflections ("die", +s, +d, etc). The first architecture, the "enumerative" one, states that a word form can be more accurately retrieved as a single atomic entity instead of a combination of several different morphemes. Its main advantages concern word matching (faster and more precise as there is no possibility of over-generation) and construction (it is easier and often less expensive to list the irregular forms instead of trying to define paradigms for them). Nevertheless, the latter architecture, i.e., the "generative" one, which relies on the principle that “the smaller the better”, is far much more common, as its main advantages concern access (the word retrieval process is supposed to be faster), storage (it requires a smaller amount of memory space) and maintenance (changes are automatically propagated to all instances of a given entry).  
+
The repertoire of lexemes of a given language can be organized in two basic ways: 1) as a simple listing of all word forms, i.e., of all variants of the same lexeme ("die", "dies", "died", "dying", etc); or 2) as a list of base forms accompanied by morphological rules for generating their inflections ("die", +s, +d, etc). The first architecture, the "enumerative" one, states that a word form can be more accurately retrieved as a single atomic entity instead of as a combination of several different morphemes. Its main advantages concern word matching (faster and more precise as there is no possibility of over-generation) and construction (it is easier and often less expensive to list the irregular forms instead of trying to define paradigms for them). Nevertheless, the latter architecture, i.e., the "generative" one, which relies on the principle that “the smaller the better”, is far much more common, as its main advantages concern access (the word retrieval process is supposed to be faster), storage (it requires a smaller amount of memory space) and maintenance (changes are automatically propagated to all instances of a given entry).  
  
 
The UNLarium is mainly a generative environment, in the sense that word forms are expected to be represented by their corresponding LRUs and base forms, along with rules for generating their possible inflections. These are the m-rules, to be provided either as LRU-specific (in case of irregular behaviour) or as inflectional paradigms (applying to several different LRUs).
 
The UNLarium is mainly a generative environment, in the sense that word forms are expected to be represented by their corresponding LRUs and base forms, along with rules for generating their possible inflections. These are the m-rules, to be provided either as LRU-specific (in case of irregular behaviour) or as inflectional paradigms (applying to several different LRUs).

Revision as of 12:09, 19 January 2010

M-rule is the formalism used for describing morphological behaviour in the UNLarium framework. It is used in inflectional paradigms, in inflectional rules, in semantic rules and in morphological settings.

Contents

Generative and enumerative lexica

The repertoire of lexemes of a given language can be organized in two basic ways: 1) as a simple listing of all word forms, i.e., of all variants of the same lexeme ("die", "dies", "died", "dying", etc); or 2) as a list of base forms accompanied by morphological rules for generating their inflections ("die", +s, +d, etc). The first architecture, the "enumerative" one, states that a word form can be more accurately retrieved as a single atomic entity instead of as a combination of several different morphemes. Its main advantages concern word matching (faster and more precise as there is no possibility of over-generation) and construction (it is easier and often less expensive to list the irregular forms instead of trying to define paradigms for them). Nevertheless, the latter architecture, i.e., the "generative" one, which relies on the principle that “the smaller the better”, is far much more common, as its main advantages concern access (the word retrieval process is supposed to be faster), storage (it requires a smaller amount of memory space) and maintenance (changes are automatically propagated to all instances of a given entry).

The UNLarium is mainly a generative environment, in the sense that word forms are expected to be represented by their corresponding LRUs and base forms, along with rules for generating their possible inflections. These are the m-rules, to be provided either as LRU-specific (in case of irregular behaviour) or as inflectional paradigms (applying to several different LRUs).

Types of m-rules

There are two types of m-rules:

  • simple m-rules involve a single action (such as prefixation, suffixation or infixation); and
  • complex m-rules involve more than one action (such as prefixation and sufixation, or two suffixations).

Simple m-rules

There are three types of simple m-rules:

  • left appending (prefixation), for adding/changing information at the beginning of a base form
  • right appending (suffixation), for adding/changing information at the end of a base form
  • replacement (infixation), for adding/changing information in the midlle of a base form

Syntax

The syntax for simple m-rules is the following:

left appending
 CONDITION := “ADDED” < “DELETED”;
right appending
 CONDITION := “DELETED” > “ADDED”;
replacement
 CONDITION := “DELETED” : “ADDED”;

Where:

  • CONDITION = tag (such as “PLR”, “FEM”, etc) or list of tags (“FEM&PLR”) that indicates when the rule should be applied
  • ADDED = the string to be added (between quotes);
  • DELETED = the string to be deleted (between quotes);

Examples

Left appending (prefixation) rules

RULE BEHAVIOR BEFORE AFTER
X:=”y”<”z”; if X replace the string “z” by the string “y” in the beginning of the string zabc yabc
X:=”y”<1; if X replace the first character of the string by “y” zabc yabc
X:=”y”<0; if X add the string “y” to the beginning of the string zabc yzabc
X:=”y”<; if X add the string “y” to the beginning of the string (idem previous) zabc yzabc
X:=”y”<<0; if X add the string “y” and a blank space to the beginning of the string zabc y zabc
X:=”y”<<; if X add the string “y” and a blank space to the beginning of the string (idem previous) zabc y zabc

Right appending (suffixation) rules

RULE BEHAVIOR BEFORE AFTER
X:=”z”>”y”; if X replace the string “z” by the string “y” in the end of the string abcz abcy
X:=1>”y”; if X replace the last character of the string by “y” abcz abcy
X:=0>”y”; if X add the string “y” to the end of the string abcz abczy
X:=>”y”; if X add the string “y” to the end of the string (idem previous) abcz abczy
X:=0>>”y”; if X add a blank space and the string “y” to the end of the string abcz abcz y
X:=>>”y”; if X add a blank space and the string “y” to the end of the string (idem previous) abcz abcz y

Replacement (infixation) rules

RULE BEHAVIOR BEFORE AFTER
X:=”y”; if X replace the whole by “y” X y
X:=”z”:”y”; if X replace the string “z” by “y” azbc aybc
X:=[2;3]:”y”; if X replace the second to the third character by “z” abcz ayz
X:=Y; replace the feature X by the feature Y X Y

Observations

In appending rules, the part to be deleted may be represented by the number of characters (without quotes)
PLR := “X”<””; = PLR := “X”<0; (ABC becomes XABC)
PLR:= “X”<”A”; = PLR:= “X”<1; (ABC becomes XBC)
PLR:= “XY”<”AB”; = PLR:= “XY”<2; (ABC becomes XYC)
PLR:=””>”X”; = PLR:= 0>”X”; (ABC becomes ABCX)
PLR:=”C”>”X”; = PLR:= 1>”X”; (ABC becomes ABX)
PLR:=”BC”>”XY”; = PLR:= 2>”XY”; (ABC becomes AXY)
In replacement rules, the part to be deleted may be omitted if the whole string is to be replaced
PLR:=”ABC”:”XYZ”; = PLR:=”XYZ” (ABC becomes XYZ)
In replacement rules, the part to be deleted may be represented by an interval of characters in the format [beginning-end]
PLR:=”B”:”X”; = PLR:=[2-3]:”X”; (ABC becomes XYZ)
The symbol “^” can be used for negation (“^MCL” means “not MCL”)
NOU&^MCL:=”x”:”y”; (If NOU and not MCL then replace “x” by “y”)
Rules will only be applied if all conditions are true
X:=”y”<”z”; ( “zabc” changes to “yabc”, but “abc” remains “abc”)
The replacement rule applies only once the same action
X:=”a”:”b”; ( “aaa” becomes “baa” and not “bbb”)
“<<” and “>>” add blank spaces
X:=”a”<<”b” (“bc” becomes “a bc” and not “abc”)

Common mistakes

  • nou:= ”y”<”z”; (WRONG: Tags are case sensitive)
  • NNN:= ”y”<”z”; (WRONG: NNN is not defined in the tagset)
  • NOUFEM:=”y”<”z”; (WRONG: Tags must be separated by “&”)
  • NOU,FEM:=”y”<”z”; (WRONG: Tags must be separated by “&”)
  • NOU & FEM:=”y”<”z”; (WRONG: There can be no blank spaces between tags)
  • X:=1<1; (WRONG: The left side must always be a string in a left appending rule)
  • X:=1>1; (WRONG: The right side must always be a string in a right appending rule)
  • X:=1; (WRONG: Replacement rules do not allow for numbers)
  • X:=1:1; (WRONG: Replacement rules do not allow for numbers)

Complex m-rules

Complex m-rules are formed from the combination of simple m-rules:

left appending + right appending (circumfixation)

(used, for instance, in circumfixation, i.e, to add a prefix and a suffix at the same time) CONDITION := “ADDED” < “DELETED”, “DELETED” > “ADDED”; Example: INC := “a”<0, 0>”ed”; (scatter > ascattered)

replacement rule + right appending 

(used, for instance, for inflecting English irregular verbs) CONDITION := “DELETED”:”ADDED”, “DELETED”>”ADDED”; Example: PAS := “ea”:”o”, 0>”en”; (break > broken)

left appending + left appending

Observations

In complex inflectional rules:

Actions must be conjoined through ","
Each action is applied only once (i.e, rules are not exhaustive)
PLR:=0>”s”; (AAA > AAAS, and not AAASSSSSSSSS...)
CON := "A" : "E" ; (AAA > EAA, and not EEE)
Actions are applied from left to right (i.e., rules are not commutative)
PLR := "s" > "ses", "y" > "ies"; (kiss > kisses, city > cities)
PLR := "y" > "ies", "s" > "ses"; (kiss > kises, city>cities>citieses)

Formal syntax

M-rules comply with the following syntax:

<M-RULE>           ::= <CONDITION> “:=” <ACTION> [, <ACTION>]* “;”
<CONDITION>        ::= <ATAG>[“&”[“^”]<ATAG>]*
<ATAG>             ::= {one of the tags defined in the UNDLF Tagset}
<ACTION>           ::= <LEFT APPENDING> | <RIGHT APPENDING> | <REPLACEMENT>
<LEFT APPENDING>   ::= <ADDED>	 {“<” | “<<”} 	[ <DELETED> ]
<RIGHT APPENDING>  ::= [ <DELETED> ]	 {“>” | “>>”} 	<ADDED>
<REPLACEMENT>      ::= [ <STRING> ":" ] <ADDED> | "[" <INTEGER> "-" <INTEGER> "]" ":"  <ADDED>
<ADDED>            ::= <STRING> 
<DELETED>          ::= <STRING> | <INTEGER>  
<STRING>           ::= “ “ “ [a..Z]+ “ “ “
<INTEGER>          ::= [0..9]+

where

<a> = a is a non-terminal symbol
“a“ = a is a constant
[a] = a can be omitted
a | b = a or b
{ a | b } = either a or b
a* = a can be repeated 0 or more times
a+ = a can be repeated 1 or more times

Software