You’ve seen the video. You speak another language. And you’re wondering, “how hard is it to add my language to Ubiquity with Parser 2?” The answer: not that hard. With a little bit of JavaScript and knowledge of and interest in your own language, you’ll be able to get at least rudimentary Ubiquity functionality in your language. Follow along in this step by step guide and please submit your (even incomplete) language files!

As Ubiquity Parser 2 evolves, there is a chance that this specification will change in the future. Keep abreast of such changes on the Ubiquity Planet and/or this blog (RSS).

Set up your environment

If you’re new to Ubiquity core development, you’ll want to first read the Ubiquity 0.1 Development Tutorial to learn how to get a live copy of the Ubiquity repository using Mercurial. Once you’ve set up your Firefox profile to use this development version, make sure to try changing the extensions.ubiquity.parserVersion value to 2 in about:config (as seen in this demo video) to verify that Parser 2 is working for you.

As you read along, you may find it beneficial to follow along in the languages currently included in Parser 2: English, Japanese, Portuguese, and Swedish (and the incomplete Chinese and French).

The structure of the language file

Each language in Parser 2 gets its own file which acts as a JavaScript module. You’ll need to look up the ISO 639-1 code for your language… Here we’ll use English (code en) as an example here and the JavaScript language file would then be called en.js and go in the /ubiquity/modules/parser/new/ directory of the repository.

Here is the basic template for a Ubiquity Parser 2 language file:

1
2
3
4
5
6
7
8
9
10
11
12

var EXPORTED_SYMBOLS = ["makeEnParser"];
 
if ((typeof window) == 'undefined') // kick it chrome style
  Components.utils.import("resource://ubiquity/modules/parser/new/parser.js");
 
function makeEnParser() {
  var en = new Parser('en');
 
...
 
  return en;
};

After lines 1-4 which set up the JavaScript module, everything else is wrapped in a factory function called makeLaParser (for Latin) or makeEnParser (for English, en) or makeFrParser (for French, fr), etc. This function initializes the new Parser object (line 7) with the appropriate language code, sets a bunch of parameters (elided above) and returns it. That’s it!

Now let’s walk through some of the parameters you must set to get your language working. For reference, the properties the language parser object is required to have are: branching, anaphora, and roles.

Identifying your branching parameter

  en.branching = 'right'; // or 'left'

One of the first things you’ll have to set for your parser is the branching parameter. Ubiquity Parser 2 uses the branching parameter to decide which direction to look for an argument after finding a delimiter or “role marker” (most often, these are prepositions or postpositions. For example, in English “from” is a delimiter for the goal role and its argument is on its right.

So “John” is a possible argument for the source role, but “Mary” should not be. Ubiquity can figure this out because English has the property en.branching = 'right'.

In Japanese, on the other hand, the argument of a delimiter like から (“from”) is found on the left of that delimiter, so en.branching = 'left'.

In general, if your language has prepositions, you should use .branching = 'right' and if your language has postpositions, you can use .branching = 'left'.

For more info:

• see branching on Wikipedia.

Defining your roles

  en.roles = [
    {role: 'goal', delimiter: 'to'},
    {role: 'source', delimiter: 'from'},
    {role: 'position', delimiter: 'at'},
    {role: 'position', delimiter: 'on'},
    {role: 'alias', delimiter: 'as'},
    {role: 'instrument', delimiter: 'using'},
    {role: 'instrument', delimiter: 'with'}
  ];

The second required property is the inventory of semantic roles and their corresponding delimiters. Each entry has a role from the inventory of semantic roles and a corresponding delimiter. Note that this mapping can be many-to-many, i.e., each role can have multiple possible delimiters and different roles can have shared delimiters. Try to make sure to cover all of the roles in the inventory of semantic roles.

For more info:

• Writing commands with semantic roles
• the proposed inventory of semantic roles
• Wikipedia entry on thematic relations

Entering your anaphora (“magic words”)

  en.anaphora = ["this", "that", "it", "selection", "him", "her", "them"];

The final required property is the anaphora property which takes a list of “magic words”. Currently there is no distinction between all the different deictic anaphora which might refer to different things.

Special cases

Some special language features can be handled by overriding the default behavior from Parser. Many of these features are still in the works, however, so we’d love to get your comments!

Languages with no spaces

If your language does not delimit arguments (or words, more generally) with spaces, there will be a need to write a custom wordBreaker() function and set usespaces = false and joindelimiter = ''. For an example, please take a look at the Japanese or Chinese.

Case marking languages

If you have a strongly case-marked language, you’ll have to write some rules to identify those different cases in wordBreaker() and then add some extra roles for these case markers, but for a number of languages the current design does not allow an elegant solution for parsing such arguments. Updates to this issue will be posted to this trac ticket.

In the mean time, however, if you could write a parser even with only the prepositions/postpositions in your language, that would be a great benefit in getting started in your language. UPDATE: a proposal on how to deal with strongly case-marked languages has been written here: In Case of Case….

Stripping articles

Some languages have some delimiters which combine with articles. For example, in French, the preposition “à” combines with the masculine definite article “le” but not “la”:

1. à + la = à la
2. à + le = au

You can add both “à” and “au” as delimiters of the goal role, but then you will get feminine arguments back with the determiner (e.g. “la table”) while masculine arguments would be parsed without a determiner (e.g. “chat”).

1. “à la table” = “to the table”
2. “au chat” = “to the cat”

One possible solution to this is to write a custom cleanArgument() method. After arguments have been parsed and placed in their appropriate roles, each argument text (say, “la table” or “chat”) are passed to cleanArgument(). You can simply write a cleanArgument() to strip off any “la ” at the beginning of the input and return it and both example inputs will get normalized arguments: “table” and “chat”, respectively. UPDATE: For more up-to-date information on how to deal with these types of articles, please see Solving a Romance Problem.

Test your parser

Now you can go into about:config and change extensions.ubiquity.language to be your language code and restart. All the verbs and nountypes at this point will remain the same as in the English version, but it should obey the argument structure (the word order and delimiters) of your language.¹ If you run into any trouble, feel free to ask for help on the Ubiquity i18n listhost or find me on the Ubiquity IRC channel (mitcho @ irc.mozilla.org#ubiquity). Of course, once you’re at a good stopping point, please contribute your language file to Ubiquity!

More to come…

At this point, you’ve only localized the argument structure of your language… additional work will be required to localize the nountypes and verb names, which is the subject of ongoing discussion… join the Google Group to get in on the discussion!

Related posts:

1. Ubiquity Parser: The Next Generation Demo
2. Rolling out the Roles
3. Foxkeh demos Ubiquity Parser: The Next Generation

Related posts brought to you by Yet Another Related Posts Plugin.

Something to consider…

As we rewrite these current commands to specify semantic roles instead of specific modifiers, it is important to distinguish between synonymous prepositions in English which actually map to different semantic roles. Here are two examples:

• with: English “with” can refer to one of two relations: “together-with” as in “share this with Jono” and “using-with” as in “share this with delicious” or “eat this with a fork.”
• in: “in”, similarly, can refer to two different relations: “location-in” as in “find mexican food in Tokyo” and “format-in” as in “search Moscow in Russian” or “save this page in PDF.”

A quick test for such cases is “would these markers translate to the same markers in a different language?” It’s easy to find a language where the two different “with”s and the two different “in”s are expressed using different words. With semantic roles in Parser TNG, it’s okay for multiple semantic roles to share the same delimiters/markers.

A proposed set of semantic roles

Here is a set of semantic roles which I would like to propose. Keep in mind that these roles should map to morphological features in languages, not necessarily to the type of content in the argument (which is why we also will keep the noun types).

• object: direct object (the default or unmarked argument)
• goal: the goal or end point of (metaphorical) movement or transition
  • example: in English, arguments marked by “to”, “into”, “toward”, etc.
• source: the source or starting point of (metaphorical) movement or transition¹
  • example: in English, arguments marked by “from”, “by”, etc.
• position: refers to a (metaphorical) location which defines the scope of an action, in contrast to goal and source.
  • example: in English, arguments marked by “in”, “at”, “near”, etc.
• instrument: a tool or intermediary to be used
  • example: in English, arguments marked by “using” or “with”, as in “bookmark this with delicious.”
• format: describes the intended or expected form of the result
  • example: in English, arguments marked by “in” as in “in PDF form” or “in German”
• alias: a name or reference to
  • example: in English, arguments marked by “as” as in “tag this as new” or “login to mail as aza.”

Note that all three locational roles, goal, source, and location may be used for both times and places as the morphological marking of temporal and spacial expressions are often conflated in language. The appropriate type of referent (time or space) can then be specified with the noun type.

As a quick sanity check of this proposal, here are all the standard feeds built into Ubiquity which have multiple arguments together with what semantic role is appropriate for each argument:

The only problematic standard command, then, is the share-on-delicious command which can take both tags and a title, both of which would most naturally correspond to the alias role. If you have a suggestion for how best to deal with this type of case, I’d love to hear your suggestions!

We’d love to get your feedback to this proposed set of semantic roles. How do you feel about the proposed set of semantic roles laid out here? In particular, if you have a command or can envision a command which would like to use a semantic role which does not fit any of these roles or would take multiple arguments of the same role, please let us know! ^^

Related posts:

1. Writing commands with semantic roles
2. Ubiquity Commands by The Numbers
3. Three ways to argue over arguments

Related posts brought to you by Yet Another Related Posts Plugin.

How Ubiquity identifies its arguments

Currently when writing a command in Ubiquity you must specify two properties for each argument: a modifier (the appropriate adposition—the direct object excluded) and the noun type. Here are some quick examples from the standard commands:

email:

• direct object (noun_arb_text)
• to (noun_type_contact)

translate:

• direct object (noun_arb_text)
• to (noun_type_language)
• from (noun_type_language)

This way of specifying arguments has a few shortcomings. First of all, it requires you to identify each type of argument by unique adposition, which does not support languages with case marking nor languages with sets of synonymous adpositions (e.g. French {à la, au, aux}). Second, as we saw in how your language identifies its arguments some languages don’t mark semantic roles on the arguments at all and the current system of specifying arguments is completely incompatible with these languages. Third, the current specification requires command authors to make localized versions of their commands, specifying the language-appropriate modifiers.

In a perfect world the last issue could be solved (at least for languages which mark semantic roles with adpositions) by a mapping of English prepositions to the target language adpositions. Indeed, for some adpositions in some languages this may be possible:

However, some English prepositions do not cleanly map to a particular adpositions. Take, for example, English “with.” This “with” may map to different markings in Chinese and Japanese depending on the sentence:

Note, however, that which set of markings “with” maps to is predictable, as there is a salient semantic difference. The first “with” could be referred to as together-with while the second is a using-with. With this distinction, we can easily predict which paradigm the “with” in “search with Google” should use, because these two “with” arguments represent two different semantic roles.

A proposal: identifying arguments by semantic role¹

Suppose commands could specify their arguments by referring to these semantic roles in lieu of adpositions as they currently do. This way, we would be able to automatically map commands into different languages. For example, you could write a new command called move with the following argument structure:

move:

• role_object (noun_arb_text)
• role_goal (noun_type_geolocation)
• role_source (noun_type_geolocation)

The English mapping of ” => role_object, ‘to’ => role_goal, ‘from’ => role_source could be used to parse the command

move truck from Tokyo to Paris

In addition, with the Japanese mapping of ‘が’ => role_object, ‘に’ => role_goal, ‘から’ => role_source, you could immediately use the command in Japanese as well:

東京からパリにトラックをmoveして

In essence, this proposal would let command authors get their commands localized for free, as long as they stick to a predefined set of semantic roles. For more complex commands and legacy commands, of course, commands could optionally specify particular English modifiers, but then Ubiquity would simply not attempt to localize those commands.

In addition, each language specific parser would determine how to identify its arguments. This would allow languages with case marking or no role marking on arguments at all to handle their own mapping of arguments to semantic roles and still use shared commands. Even parsers such as English would benefit by letting the parser deal with synonymous prepositions and possibly even argument structure alternations (such as English ditransitive alternations).

As a starting point, we could use argument types based on the list of semantic roles given in Fillmore (1971):

• Object: the entity that moves or changes or whose position or existence is in consideration
• Result: the entity that comes into existence as a result of the action
• Instrument: the stimulus or immediate physical cause of an event
• Source: the place from which something moves
• Goal: the place to which something moves
• Experiencer: the entity which receives or accepts or experiences or undergoes the effect of an action …

Comments welcome!

As command authors and Ubiquity users, how do you feel about this proposal? How might this affect, simplify, or complicate the localization of Ubiquity into your language? Thank you in advance! ^^

Related posts:

1. Three ways to argue over arguments
2. Contribute: how your language identifies its arguments
3. Ubiquity in Firefox: Focus on Japanese

Related posts brought to you by Yet Another Related Posts Plugin.

今後多様な言語に対応したFirefox内のUbiquityを検討していきますが、その中でも今日は日本語をとりあげます。後日日本語で同じ内容を投稿するつもりです。^^ 日本語でのコメントも大歓迎です！

What commands look like in Japanese

Japanese is not only just a verb-final language but it is strongly head-final, meaning it has postpositions instead of prepositions, direct objects come before verbs, and adjectives precede nouns. In terms of how it identifies its arguments, every argument has a postposition/case marker (called a particle in the Japanese literature) which marks its role in the sentence.

A couple common particles we’ll look at in this example include -を (-o) which marks the direct object (accusative case, you might say) and -に (-ni) which acts like English “to” (dative case). The example sentence we’ll look at today is:

(Note: ʔ is a glottal stop. ACC=accusative, DAT=dative, and IMP=imperative form.)

That final ください is often dropped in very casual speech and, as it adds no new information, we’ll assume today that the user will not enter it. Finally, Japanese doesn’t use spaces in their orthography, so the actual input would be “ケーキをブレアに送って”.

Mockup 1: Particle identification

One of the major hurdles in working with Japanese is that there are no spaces between the words. The natural first step is to split the sentence up into words, but this is a very difficult problem in NLP which big name research groups actively work on.

Fortunately, however, in “Solving the ‘It’ Problem” Aza suggests that, when we encounter ambiguity in our input, we can go ask the user. Great minds think alike, and computer scientist Jean E. Sammet suggested the same idea way back in 1953:

Using English [or any other natural language] definitely involves the requirement for the computer (or more accurately its programming system) to query the user about any possible ambiguity.

Parsing a sentence into words, in the limited context of Ubiquity, is really about identifying the particles which mark the end of each argument. Here’s a mockup of an application of the Sammet-Raskin Method to this problem:

Pros: This completely takes care of the word-breaking problem, with minimal arbitration from the user. The parser knows exactly what arguments it’s dealing with and the visual feedback means the user won’t be surprised by the parse.

Cons: Most of the particles/postpositions we’d have to deal with are a single character, so they may show up pretty often within words, in which case it would be quite annoying to have to press escape after each one.

An even smarter system, when wanting to mark a character as a particle, would first check to see that the argument (before the particle) is a valid argument type for that particle. If the check fails, it doesn’t have to bother with suggesting that character as a particle. This may cut down on the false positives.

Smart suggestions: what works, what doesn’t

One of the key suggestions in Aza’s mockups include a way to choose the prepositions while entering your arguments, based on the current verb.

For example, here, the translate command accepts a direct object, a to-object, and a from-object, so little to and from markers magically show up on the right side, making the appropriate prepositions (and by extension the appropriate arguments) discoverable. I think this line of thinking is a really good one, at least for English.

In a verb-final language, however, you enter the arguments first and then the verb, making this strategy of suggesting appropriate arguments impossible. Note that in the user-contributed spreadsheet of how languages identify their arguments we see that about a quarter of the languages we looked at are verb-final—that is, with Subject-Object-Verb canonical word order.

Instead of seeing this as a disadvantage, however, let’s see what verb-final order allows us to do.

Mockup 2: A different kind of suggestion

Not all verbs allow for every different kind of particle. For example, it doesn’t make sense to have a -に (-ni, “to” or dative) argument for a verb like 検索して (kensaku-shite, “search for”). In English we used this to suggest different types of arguments given a specific verb. In a verb-final language, we could do this backwards.

Pros: This makes verbs highly discoverable, given a certain argument structure. For example, if you enter a few arguments, like a direct object, a “to” argument, and a “from” argument, it’ll suggest verbs that will do something to an object from somewhere to somewhere else. This way, you can easily try out verbs you didn’t even know existed. It’ll only give you verbs appropriate for your arguments, reducing the chance of writing a an infelicitous command.

Cons: Without knowing what kinds of actions are available, it may be difficult to know what kinds of arguments to enter in the first place. If you have a specific verb or service you want to use it may be counterintuitive or downright tricky to start by guessing the right set of arguments.

In addition, from a technical point of view, this requires much of the prediction algorithms in English Ubiquity to run backwards. Ideally, there would be a closed (predetermined) class of particles and a predefined set of noun types. Verbs would not be able to define their own modifiers and noun classes as easily or freely as they can now.

Conclusion

The properties and challenges of Japanese grammar require that we not try to outright copy the English behavior but to think about what really makes sense in that language and that may be an important lesson as we move toward designing a localizable Ubiquity. Please post your questions and criticisms of this design or post your own mockups!

Related posts:

1. Three ways to argue over arguments
2. Contribute: how your language identifies its arguments
3. How natural should a natural interface be?

Related posts brought to you by Yet Another Related Posts Plugin.

When we execute a command in Ubiquity, in very simple terms, we’re hoping to do something (a verb) to some arguments (the nouns). Every sentence in every language uses some method to encode which arguments correspond to which roles of the verb. Here are a couple examples:

1
2

He sees Mary.
彼が Maryを 見る。 (Kare-ga Mary-o miru.)

As speakers of English, you can read sentence (1) above and know exactly who is doing the seeing and who is being seen and speakers of Japanese can get the same information from (2). How do different languages code for arguments in different roles? There are, broadly speaking, three different ways:

We’ll take a brief look today at these three different strategies, all of which a localizeable natural language interface will surely encounter.

Word order

In many languages, the position of the arguments relative to one another and to the verb determine the roles which each argument will play. Mandarin Chinese is a good example of such a language:

3
4

他 喜欢 Mary (Ta xihuan Mary)
Mary 喜欢 他 (Mary xihuan ta)

Here, sentence (3) says “he likes Mary” while sentence (4) says “Mary likes him”. Simply reversing the positions of “he/him” and “Mary” we’re able to flip the roles that they fill in the sentence: that of the person who does the liking and the person who is being liked. Now take a look at sentence (5) which means “John says ‘hello’ to Mary.”

5

John 告诉 Mary "你 好" (John gaosu Mary "ni hao")

We note here that, while in English we used a different strategy of marking one argument (we marked the “hello” argument with “to”), Chinese doesn’t mark either of the arguments. There is, however, a clearly defined order to the arguments, which you might encode this way:

say [who you're speaking to] [what you're saying]

If you swap the order of the two objects in this sentence, it becomes ungrammatical. (Note: the asterisk * here means the sentence is ungrammatical.)

5

* John 告诉 "你 好" Mary (John gaosu "ni hao" Mary)

Here, the word order dictates that “你好” must be “who you’re speaking to” and “Mary” must be “what you’re saying,” but that doesn’t make sense, so the sentence is ungrammatical.

Marking the arguments

Another possible strategy is to mark each argument (or some of the arguments) so that each argument’s role is clear. In many languages this is done with case marking. Take for example this Ancient Greek sentence with its English gloss on line (6). Here, NOM refers to nominative case and ACC refers to accusative case.¹

5
6

ho  didaskal-os  paideuei to  paidi-on  (SVO)
the teacher -NOM teaches  the boy  -ACC

This sentence means “the teacher instructs the boy.” While sentence (5) is in Subject-Verb-Object order, any of the six possible orderings of {subject, verb, object} are also grammatical and mean the same thing:²

7
8
9
10
11

ho didaskalos to paidion paideuei (SOV)
paideuei ho didaskalos to paidion (VSO)
paideuei to paidion ho didaskalos (VOS)
to paidion ho didaskalos paideuei (OSV)
to paidion paideuei ho didaskalos (OVS)

Many languages also use adpositions (prepositions and/or postpositions) to further clarify the role of an argument in addition to case (like English does) or in lieu of case marking altogether. The idea is the same, though: you want to clarify the roles of the arguments so you morphologically mark the arguments with their roles.

Marking the verb

Many languages mark the verb with some information about the argument in a certain role, so that we can properly identify the argument’s roles. This kind of phenomenon is called agreement.

The most common type of verbal agreement is subject agreement, where the verb is marked by a specific form depending on some features of the subject. Anyone who’s taken French 101 will recognize this verb conjugation paradigm:

With this paradigm, if you hear or see “suis” in a French sentence, you immediately know that “je” (I) must be the subject and if you see “sommes,” “nous” (we) is the subject, etc. Standard Average European languages tend to exhibit this sort of subject-verb agreement.

Features of the subject position aren’t the only thing that can be marked on the verb, though. Hungarian, for example, has a type of object agreement. Specifically, the verb marks whether the object is definite or not (in linguistics lingo, “the verb agrees with the object’s definiteness feature”).

12
13
14
15

John lát  egy almát.
John sees an  apple
John látja az  almát.
John sees  the apple

Notice that in sentence (12) (glossed in (13)) the verb for “see” is realized as “lát,” while in (14) it’s “látja.” A speaker can use that agreement to see whether the object is definite or not and thus limit the possible object arguments out of all the nouns in the sentence.

All of the above

Most languages do not use only one of these strategies, but a combination of them. English is a very good example. In a sentence like (12) below the main coding of grammatical roles seems to be word order alone. By reversing the word order into (13), we can effectively swap the argument’s roles.

12
13

John likes Mary.
Mary likes John.

However, this doesn’t work with pronominal arguments. Swapping the arguments in (14) yields (15) which is ungrammatical due to the case marking on the pronouns.

14
15

He likes her.
* Her likes he.

In addition, the verb in English must agree with the subject’s number (singular or plural):

16
17
18

John likes them.
* They likes John.
They like John.

In this way, English exhibits all three strategies: word order, case marking, and agreement, although often only word order is actively used to disambiguate the roles of arguments.

Question: What strategies are used by your language to mark the roles of different arguments?

Related posts:

1. 回収 vs. 収集 and Better Word Meanings Through Usage
2. Testing Google’s Language Detection
3. Gaba, Shame On You

Related posts brought to you by Yet Another Related Posts Plugin.