Difference between revisions of "A long introduction to transfer rules"

From Apertium
Jump to navigation Jump to search
Line 31: Line 31:
<def-attr n="some_feature_of_a_word">
<def-attr n="some_feature_of_a_word">
<attr-item tags="myfeature"/>
<attr-item tags="myfeature"/>
<attr-item tags="myotherfeature"/>
</def-attr>
</def-attr>
</section-def-attrs>
</section-def-attrs>
Line 42: Line 43:
</pattern>
</pattern>
<action>
<action>
<let><clip pos="1" side="tl" part="some_feature_of_a_word"/><lit-tag v="myotherfeature"/></let>
<out>
<out>
<lu><clip pos="1" side="tl" part="whole"/></lu>
<lu><clip pos="1" side="tl" part="whole"/></lu>

Revision as of 16:14, 30 September 2012

Writing transfer rules seems to be tricky. People generally understand the basic concepts, but they struggle with the formalism. We think the formalism isn't that bad. And compared to many other formalisms,[1] it's fairly straightforward. Maybe one of the reasons people struggle is that we mix declarative and procedural programming. Could be.

Some formalities

Before starting, it is important to give some idea of what we can't do, before explaining what we can. If you come at rule-learning expecting something else, then it's likely to be confusing.

  • There are no recursive rules. Rules match fixed-length patterns. There is no optionality at the level of words. There is no way of saying one-or-more, it's just one.
  • Apertium's rules are very tied to the Apertium stream format. If you don't understand the stream format, it will be a lot more difficult to understand the rules.
  • Rules contain both declarative parts and procedural parts. You can't just expect to say what you want or how you want to do it. You need to do both -- but in different places (but it's quite intuitive).
  • Patterns match only on the source side. Not on the target side.

Lexical transfer and structural transfer

Overview of a transfer file

It's hard to give a step-by-step overview of what a transfer file looks like because there is quite a lot of obligatory parts that need to go into even the most basic file. But, it's important to get a general view before we go into the details. Here is an example in which I'm deliberately not going to use linguistic names for the different parts, to try and avoid assumptions.

<?xml version="1.0" encoding="utf-8"?>
<transfer>
  <section-def-cats>
    <def-cat n="some_word_category">
      <cat-item tags="mytag.*"/>
    </def-cat>
  </section-def-cats>
  <section-def-attrs>
    <def-attr n="some_feature_of_a_word">
      <attr-item tags="myfeature"/>
      <attr-item tags="myotherfeature"/>
    </def-attr>
  </section-def-attrs>
  <section-def-vars>
    <def-var n="blank"/>
  </section-def-vars>  
  <section-rules>
    <rule>
      <pattern>
        <pattern-item n="some_word_category"/>
      </pattern>
      <action>
        <let><clip pos="1" side="tl" part="some_feature_of_a_word"/><lit-tag v="myotherfeature"/></let>
        <out>
          <lu><clip pos="1" side="tl" part="whole"/></lu>
        </out>
      </action>
    </rule>
  </section-rules>
</transfer>


Apertium 1

Otisla si tiho i bez pozdrava

Lexical transfer

Apertium 3

Resorni je ministar navlačio ljude, kaže sejte biljku zelenu i čudo će da bude

Lexical transfer

Notes

  1. e.g. Matxin, OpenLogos, ...