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

From Apertium
Jump to navigation Jump to search
Line 15: Line 15:
   
 
<!--which does which-->
 
<!--which does which-->
  +
  +
==Some preliminaries==
  +
  +
* Pattern:
  +
  +
* Action:
   
 
==Overview of a transfer file==
 
==Overview of a transfer file==
Line 51: Line 57:
 
</section-rules>
 
</section-rules>
 
</transfer>
 
</transfer>
 
</pre>
   
  +
I'll try and give a tag-by-tag account... the {{tag|transfer}} and {{tag|/transfer}} tags don't do anything. They just encapsulate the rest of the sections.
 
</pre>
 
   
 
==Practical examples==
 
==Practical examples==

Revision as of 17:27, 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

Some preliminaries

  • Pattern:
  • Action:

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>

I'll try and give a tag-by-tag account... the <transfer> and </transfer> tags don't do anything. They just encapsulate the rest of the sections.

Practical examples

Apertium 1

Otisla si tiho i bez pozdrava

She left quietly and without a word

Lexical transfer

Apertium 3

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

The minister of agriculture tricks the people, he says plant the green herb and there will be a miracle

Lexical transfer

Notes

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