Apertium-recursive/Formalism
A proposal for a recursive transfer rule formalism.
Contents
Basic Rule Syntax
Rules consist of a node type, a weight (optional?), a pattern, and an output.
NP -> 2: @det @adj @n {3 _2 2 _1 1} ;
- Could support -> and → —Firespeaker (talk) 17:41, 29 May 2019 (CEST)
This gathers an det node, a adj node, and an n node and produces an NP node. Once all rules have been applied, the nodes they have gathered will be output according to their patterns. In this case in the order n adj det (the 3rd, the 2nd, the 1st).
The weight of a parse is the sum (?) of all the rules involved in producing it and the parse with the lowest weight is output. There should probably be an additional factor of how many unconsolidated pieces a parse has so we prefer more complete parses (that is, "NP cnj NP" as 3 separate nodes has a lower weight than the consolidated version, but we want the consolidated one).
Multiple rules which produce the same node type can be joined with pipes:
NP -> 1: @det @n {2 _1 1} |
2: @num @n {1 _1 2} ;
- Comments
- When you say "output" do you mean immediately? or do you mean the AST will be built with that order in mind? - Francis Tyers (talk) 05:48, 13 March 2019 (CET)
- It uses the patterns to build the tree bottom-up and then when that's done it applies the output sections top-down (that way the verb phrase can set case on the noun phrase which can then set case on the noun). Popcorndude (talk) 14:59, 13 March 2019 (CET)
- I guess the weights should also be lexicalised, but a priori rule weights are probably also a good idea(?) - Francis Tyers (talk) 05:48, 13 March 2019 (CET)
- Would something like this be a reasonable way of lexicalising the weights? (from the ambiguous rules example) Popcorndude (talk) 19:17, 14 March 2019 (CET)
de_nn1 = memoría ;
de_nn2 = traducción ;
de_nsn1 = hermana madre ;
DE-S -> @det.pos @n {1 2} ;
de_nofn1 = constitución guerra ;
NP -> 1: $de_nn1@n de@pr $de_nn2@n {3 1} |
1: $de_nsn1@n de@pr DE-S {3 's@gen 1} |
1: $de_nofn1@n de@pr @num {1 2 3} |
3: @n de@pr @n {1 2 3} ;
- Why isn't it
@det @adj @netc. (per below)? —Firespeaker (talk) 05:53, 13 March 2019 (CET)- Because I changed it partway through writing this page and forgot to fix this part. Popcorndude (talk) 14:59, 13 March 2019 (CET)
Attribute Lists
A list of attributes can be defined like this:
gender = m f GD ; number = sg pl ND ;
Lexical Units
Lexical units are matched like this:
potato@n.sg ! matches "potato" with tags <n> and <sg>, possibly with others @n ! matches any noun
Any of these literals can be replaced with an attribute category using $
number = sg pl ; potato@n.$number ! matches potato<n><sg> and potato<n><pl> vegetable = potato carrot radish ; $vegetable@n.sg ! matches potato<n><sg>, carrot<n><sg>, and radish<n><sg>
The tags and attributes are neither ordered nor exhaustive.
potato@n.sg ! This matches all of the following: ! potato<n><sg> ! potato<n><m><sg> ! potato<sg><n> ! potato<sg><imp><n><o3pl>
Lexical Unit Output
The following rules specify how to output tags for particular parts of speech:
n: _.gender.number ; ! output: lemma<n><[gender]><[number]> prn.pers: _.person.number ; ! output: lemma<prn><pers><[person]><[number]> det.dem: _.<sp> ; ! output: lemma<det><def><sp>
Where _ represents the set of tags that were matched in choosing this rule, and everything else is the name of a category. Literal tags can be inserted using angle brackets.
Blanks
Blanks between lexical units are handled analogously to the chunking system. A _ in the output inserts a blank and _n inserts the blank originally after node n. If two nodes do not have a blank between them, they will be output as conjoined.
If an input needs to distinguish between conjoined and non-conjoined lexical units, that can be done with + and _. Ordinarily, the parser will ignore the difference.
@n @v ! matches "^a<n>$ ^b<v>$" or "^a<n>+b<v>$" @n _ @v ! matches only "^a<n>$ ^b<v>$" @n + @v ! matches only "^a<n>+b<v>$"
On an input like "^a<n>+b<v>$", _1 should probably be equivalent to _, but I'm not completely certain of this.
Variables
A node can have variables attached to it. Lexical units have variables corresponding to any attribute categories that match their tags.
NP.number.case.gender -> @adj.$number @n.$number.$gender {2(case=$case) 1(case=$case)} ;
This rule specifies that NP has 3 variables associated with it. The NP will initially have a value for $number which will be the number marking of the adjective and noun (which must match) and for $gender, which will be the gender tag of the noun. $case will initially be empty. If the value of $case is set by some other rule further up the tree, then the case tag will be set on both lexical units in the output phase, otherwise they will keep their default marking.
Values can also be transferred between nodes in the output phase:
VP -> NP @v {2(number=1.number, gender=1.gender) _1 1(case=nom)} ;
This makes the verb agree with the subject in number and gender and sets the subject's case to <nom>.
The 3 possible assignments are "attr=literal", "attr=index.attr", and "attr=$var".
Similar patterns can be used if the output is a literal lexical unit with agreement:
el@det.def.[1.gender].sg el@det.def.$gender.sg
If a rule needs to specify which side of the translation a value comes from, that can be done like so:
1.number/sl ! the $number of the source language 1.number/tl ! the $number of the target language 1.number/an ! the $number of the anaphora
By default all values are copied to parent nodes, so /sl will work on things other than lexical units. For comparisons and output, the anaphora value will be used if it exists, otherwise the target value if it exists, otherwise the source value if it exists, otherwise the empty string.
Variable passing can also specify particular side, if necessary.
NP.gender -> @n.$gender/tl @adj {2 _1 1} ;
! this will copy only the target value of $gender from @n to NP
Conditionals
Rule application can be further restricted with conditional statements:
NP -> @n @adj (1.gender/sl = 2.gender/sl, 1.number = 2.number) {2 _1 1} ;
! match a noun and an adjective, but only if they have the same number marking
! and the source language gender is the same
Output Conditionals
If the output of a rule is conditioned on what happens further up the tree, rather than just on the input, conditionals can be added to the output statements:
mood = ind opt nec inf ;
VP.mood.person.number -> @v.$person.$number NP.acc {should@vaux _ 1(mood=inf) _1 2} ($mood = opt)
{could@vaux _ 1(mood=inf) _1 2} ($mood = nec)
{1 _1 2} ; ! no conditional, so functions as an elsewhere case
An elsewhere case is required, since otherwise there might be no output.
Attribute Maps
This would be a way to convert certain sets of tags, either between two languages that have different sets of tenses, or between something like object agreement and number marking. (The following syntax is entirely provisional.)
object_agr = o1sg o1pl o2sg o2pl o3sg o3pl ;
number = sg pl ;
person = p1 p2 p3 ;
object_agr > person.number: o1sg p1.sg, o1pl p1.pl, o2sg p2.sg, o2pl p2.pl, o3sg p3.sg, o3pl p3.pl ;
VP -> @v NP {2(object_agr=1.object_agr) _1 1} ;
In this example, if the verb had <o2sg>, the noun would get object_agr=o2sg, person=p2, number=sg, with the first two tags probably being discarded on output.
tense = farpst nearpst pst prs fut nonpst ; tense > tense: farpst pst, nearpst pst, prs nonpst, fut nonpst ;
In this example, no explicit assignment needs to take place and the 4 tenses of the source language (farpst, nearpst, prs, fut) would be automatically converted to the 2 of the target language (pst, nonpst).
Converting from 4 to 3 with something like
tense > tense: farpst pst, nearpst pst ;
should also work, the unchanged tags not needing to be explicitly mentioned.
Interpolation
Parsing clitics, such as User_talk:Popcorndude/Recursive_Transfer#Serbo-Croatian_clitics can be done using multiple output units
vbser n -> @n @vbser {2} {1} ;
NP -> @n @det {2 _1 1} ;
! should be able to handle "noun clitic determiner"
Outputting them, however, is more difficult. My current idea is to do something like this:
NP -> @det @n {2 _1 1};
VP -> NP @vbser {(_1 2)>1};
Where (_1 2)>1 means "put the space between the elements and element 2 after the first word of element 1". The corresponding syntax for a right-aligned clitic would be 1<(2 _1). New lexical units could also be put in the parentheses (even if there's only one thing being inserted, the parentheses should, I think, be mandatory for clarity).
I'm not sure whether this will cover all cases, but it should at least cover a lot of them.
