This week I implemented a new way to customize and extend Ubiquity commands: CmdUtils.CreateAlias.

The use case for and importance of CreateAlias

CreateAlias lets you easily create a special-case alias of another, more generic verb. Ubiquity comes bundled with useful verbs like translate and search which can be used for a number of different uses based on their arguments. In some cases, and in some languages, though, typing out translate to English or search with Google is unnatural, though, as there is a more succinct and direct way to make that request. For example, in English one could say “anglicize” or “google”, respectively, for the verbs and arguments above. Indeed, in order to support both search with Google and google, Ubiquity traditionally has implemented two different verbs, search and google, which duplicate functionality and code.

CreateAlias lets us create such natural aliases without repeating ourselves. We can easily create an anglicize verb which, in one word, does the work of translate to English, or google which is semantically equivalent to search with Google.

These sorts of aliases become particularly important in our perpetual quest to internationalize Ubiquity. One discussion that came up early on on our Ubiquity-i18n list is the fact that not all languages have the verb “Google”: in many languages it is necessary to explicitly say “search with Google”. Moreover, other languages may have other domain-specific verbs which English doesn’t have either. Maybe some language has a special verb for “email with Hotmail” or “map Denmark”. Who knows? With CreateAlias we can easily enable such localizations based on the more generic commands bundled with Ubiquity.

Creating an alias

CreateAlias was designed to be incredibly simple to use. Here’s an example that will be bundled (but not installed by default) in Ubiquity:

CmdUtils.CreateAlias({
  names: ["anglicize"],
  verb: "translate",
  givenArgs: { goal: "English" }
});

As you see, this syntax is incredibly straightforward. There are two required properties, names, an array of names for the alias, and verb, a reference to the target verb that this alias should use.¹

The alias can also have a givenArgs property which is a hash of pre-specified arguments with their semantic roles. Because translate takes three arguments (an object text, a goal language, and a source language) but we have pre-specified a goal in the givenArgs, the new anglicize command will only take two arguments: the object text and a source language. Of course, if you specify no givenArgs, you’ll get a simple synonym without having access to the original verb’s code.

As you see, the preview of this command is simply the preview of the translate verb. Its preview and execution is just as if you had entered translate こんにちは to English.

Just like other commands created with CreateCommand, the object specifying the alias can also have properties like help, description, author information, and so on. I used the icon property to add a Union Jack to it so that it was easily identifiable.

Bonus: using CmdUtils.previewCommand and CmdUtils.executeCommand

On the road to implementing CreateAlias, I also implemented the CmdUtils.previewCommand and CmdUtils.executeCommand functions. The majority of this code comes from previous work by Louis-Rémi Babé, though I adapted it to the modern Ubiquity system. Using previewCommand and executeCommand you can take advantage of the preview or execute functionality of another command. In the new alias-commands feed I included a command called germanize which essentially is a straightforward analogy to anglicize, seen above, but using these functions within a CreateCommand. While CreateAlias is much more straightforward for simple aliases, for more complex subcommands where you would like to adapt another verb’s execution or preview, or only take one of those but re-implement the other part, previewCommand and executeCommand are the way to go.

Related posts:

1. Ubiquity Localization: What’s New, What’s Next
2. Rolling out the Roles
3. Localizing Commands for Ubiquity 0.5

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

It’s time for one more installment of Nountype Quirks, where I review and tweak Ubiquity’s built-in nountypes. For an introduction to this effort, please read Judging Noun Types and my updates from Day 1 and Day 2.

Today I ended up spending most of the day attempting to implement (but not yet completing) major improvements to the geolocation-related nountypes whose plans I lay out here.

Note: this blog post includes a number of graphs using HTML/CSS formatting. If you are reading this article through a feed reader or planet, I invite you to read it on my site.

noun_type_geolocation

noun_type_geolocation is the nountype used by the weather command for its location argument in input like “weather near Chicago”. The neat feature of noun_type_geolocation is that it has a smart default value which uses Firefox’s geolocation system to give you your current location by default, so I can enter “weather” and get the suggestion “weather near Broomfield, Colorado” (not completely correct, but close enough for the weather). Otherwise, however, noun_type_geolocation does not do too hot… for any input you give it, it’ll just accept it with a score of 0.3, much like noun_arb_text. We could do better.

One issue with this noun_type_geolocation is a conceptual one. Is this nountype supposed to accept only municipalities? Countries? Or should it accept landmarks or addresses as well? Part of the issue is that it’s only used by one built-in command in Ubiquity now, weather. But to be called a general “geolocation” nountype, its output should not be specific to weather’s usage, which is to throw the result at the Weather Underground API.

I propose that we change this to be something like noun_type_geo_town and also make similar nountypes like noun_type_geo_country, noun_type_geo_region, going all the way down to noun_type_address (which already exists—see below). All of the nountypes in this family could use a geocoding API such as Google’s or Yahoo’s. Their data properties could include all of this geocoded geographic data (in English) and also the latitude/longitude coordinate data.

The weather command could then accept noun_type_geo_town but, as some municipalities are not in Weather Underground or, for some countries, it is only as granular as administrative districts, we could just display the results of the geocoding API but then give Weather Underground the geocoded latitude/longitude data.

noun_type_async_address

noun_type_async_address attempts to do exactly what I’ve laid out above for the most granular level: that of geolocations with data all the way down to the street level. This is the nountype which is used for the built-in map command and uses the Yahoo geocoding service to accomplish this. Let’s see what kinds of results it returns:

input	suggestion
mitcho	mitcho	0.5
grenada	grenada	0.9
jono	jono	0.9
mountain view	mountain view	0.9

Let’s lay out some immediate quirks:

1. All scores are either 0.5 or 0.9. In general, if the Yahoo API returns some geocoded interpretation, it gets 0.9, but otherwise it accepts everything with 0.5.
2. The results that came back from the Yahoo service doesn’t add any useful information like the country or administrative region. Even the case stays lowercase.
3. Since when is Jono a location!? I’ll get back to this later.

For starters, the Yahoo! Maps API terms of service dictate that we can’t use its geocoding service if we’re not also displaying Yahoo maps, so I rewrote it using the Google API which also had the advantage of offering JSON output.

One quirk of the Google Geocoding API, though, is that all of the resulting municipality names are only in English. Try for example queries for Wien or 東京 (Tokyo). Since we want our suggestions to only add information to our input, not replace the input entirely (and especially not in another language), we’ll then only take results which have the input as an initial substring. On the other hand, if none of the results have the input as a proper prefix of the return value, we will take the geocoding information from the first result but with the original input as the display text. Such results will have a markedly lower score.¹

As this is the address nountype, we’ll penalize results which do not have detailed information such as street address or town-level information. All of this is very easy to judge as every result from the API has a geocoding accuracy value.

The best laid plans of mice and men…

I spent a good few hours this afternoon and evening attempting to implement this new family of nountypes, including this new nountype_geo_address, but also nountype_geo_subregion, nountype_geo_region, and nountype_geo_country. Some of the quirks of the weather and map commands, however, have prevented me from completely replacing the legacy noun_type_address and noun_type_geolocation described above. I hope to continue this work again soon and actually make this transition, ideally before 0.5.2.

Look forward to one (or maybe two?) more episode(s) of Nountype Quirks where I hope to definitively explain, analyze, and tweak matchScore, the scoring algorithm which underlies the majority of the nountypes in Ubiquity. As always, I look forward to your comments and feedback.

Bonus: Where’s Jono?

It turns out that noun_type_async_address was recognizing “Jono” as an address because Jono is actually a location afterall! Not only that, but Jono is in Japan!!

You clearly can’t take Japan out of Jono, but it turns out you can’t take Jono out of Japan either.

Related posts:

1. Nountype Quirks: Day 2
2. Nountype Quirks: Day 1
3. Judging Noun Types

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

Today I’m continuing the process of reviewing and tweaking all of the nountypes built-in to Ubiquity. For a more respectable introduction to this endeavor, please read my blog post from a couple days ago, Judging Noun Types and my status update from yesterday, Nountype Quirks: Day 1.

Note: this blog post includes a number of graphs using HTML/CSS formatting. If you are reading this article through a feed reader or planet, I invite you to read it on my site.

noun_type_twitter_user

Let’s begin again by considering the suggestions and scores that a variety of different inputs to this nountype return and see what quirks we find.

To test this nountype, I made sure I had logged into Twitter once with the login mitchoyoshitaka.

input	suggestion
mitcho	mitchoyoshitaka	0.85
	mitcho	0.5
mitchoyoshi	mitchoyoshitaka	0.94
	mitcho	0.5
test	test	0.5
テスト	none
hello world	none
@test	none

As nountypes go, this is looking pretty good. For usernames which look like logins we’ve saved before, we’re using matchScore to get decent differential scores.¹ It’s even ruling out impossible twitter username strings, according to Twitter’s own restriction:

One possible improvement we could make is to let @ strings be accepted. I went ahead and made this improvement. The initial @ will be stripped off and then will be checked as normal, but the final score will receive a slight boost using an nth root formula. The twitter command was also updated to deal with inputs with and without the initial @.

input	suggestion
mitcho	mitchoyoshitaka	0.85
	mitcho	0.5
@mitcho	@mitchoyoshitaka	0.88
	@mitcho	0.57
test	test	0.5
@test	@test	0.57

Although the noun_type_twitter_user nountype is currently most used by the built-in twitter command to specify the user’s username, in theory it could also be used for example in a command which pulls up another user’s tweets. With that in mind, perhaps in the future we could check the browser history and/or bookmarks for entries of the form http://twitter.com/... and suggest those as well (trac #846).

noun_type_number

input	suggestion
text	none
0.5	0.5	1
0.5.1	none

This nountype has an incredibly simple job and does it with ease. I’m going to leave it alone.

noun_type_date and noun_type_time

noun_type_date and noun_type_time both use the magical Date.parse method to parse date- and time-like strings. Let’s first take a look at some of its suggestions:

input	date suggestion	time suggestion
June 8th 5pm	2009-06-08	05:00 PM	1
5pm	2009-07-30	05:00 PM	1
5	2009-07-05	12:00 AM	1
June 8th	2009-06-08	12:00 AM	1
today	2009-07-30	12:00 AM	1
now	2009-07-30	02:40 PM	1
5pm is a good time	none	none

The quirks in these outputs can be summed up into these two factors:

1. There is no differential scoring at all.
2. Both nountypes parse the input with Date.parse and then just spit out the date or time components of the result. Thus time-only inputs get the default date and date-only inputs get the default time with equal scores.

I just rewrote both nountypes and also added a new noun_type_date_time. Here are some of the features of the new implementation:

1. If the input only contains digits and spaces, it is marked down.
2. With the exception of the outputs ‘today’ and ‘now’, if the resulting Date object’s date is today, its date suggestion is scored lower; equivalently for time being the default value, “12:00 AM”.
3. Scores (with the exception of ‘today’ and ‘now’) which are shorter than the output string get a slight penalty. This factor reflects the intuition that a longer output than input means some generic information was added and thus there is less confidence in the output.

Here’s what some of the inputs give now:

input	suggestion
June 8th 5pm	date: 2009-06-08	0.7
	time: 05:00 PM	0.7
	date_time: 2009-06-08 05:00 PM	0.86
5pm	date: 2009-07-30	0.27
	time: 05:00 PM	0.81
	date_time: 2009-07-30 05:00 PM	0.49
5	date: 2009-07-05	0.53
	time: 12:00 AM	0.19
	date_time: 2009-07-05 12:00 AM	0.34
June 8th	date: 2009-06-08	0.95
	time: 12:00 AM	0.35
	date_time: 2009-06-08 12:00 AM	0.58
today	date: 2009-07-30	1
	time: 12:00 AM	0.45
	date_time: 2009-06-08 12:00 AM	0.7
now	date: 2009-07-30	0.7
	time: 12:00 AM	1
	date_time: 2009-06-08 04:34 PM	1

In addition, looking to the future we’d like to make nountypes localizable as well, and these two nountypes in particular will surely require some good thinking and planning to make localizable.

noun_type_email and noun_type_contact

noun_type_email and noun_type_contact are two closely related nountypes. noun_type_email simply validates email address-looking strings, while noun_type_contact will return the noun_type_email suggestions and additionally return contacts from GMail if available.

The first thing to note is that I’ve often found the GMail contact lookup to be finicky in my own use. Reading through the code, I discovered the solution: GMail must either be open in a tab or you must use the “stay signed in” option and close the GMail tab.² With this mystery solved, and some code cleanup done to this contact fetching, let’s take a look at some example suggestions: (suggestions overlapping with noun_type_email are not listed here)

input	suggestion
aza@m	aza@mozilla.com	0.42
jono	jdicarlo@mozilla.com	0.28
jdicarlo	jdicarlo@mozilla.com	0.19

In general, we see that these scores all look pretty poor. In particular, though, note that the “jono” input yielded a higher score for the same suggestion than “jdicarlo”, even though “jdicarlo” is longer and thus, intuitively, has more informational content and should maybe do better. Digging into the code I realized why this is. It was computing the scores by comparing “jono” and “jdicarlo” not simply to “Jono DiCarlo” and “jdicarlo@mozilla.com” respectively, but to the combined string “Jono DiCarlo <jdicarlo@mozilla.com>”. Now with this change in place, both the email address and name are analyzed individually and, due to the way nountype detection works in Parser 2, no duplicates are returned. Here are the updated results:

input	suggestion
jono	jdicarlo@mozilla.com	0.83
jdicarlo	jdicarlo@mozilla.com	0.85

That’s much better!

Now let’s consider the suggestions from noun_type_email. Here are what they originally looked like:

input	suggestion
bpung	none
bpung@m	bpung@m	1
bpung@mozilla.com	bpung@mozilla.com	1

noun_type_email is based on a very robust regular expression for RFC 2822. Unfortunately this means that it completely rules out strings such as “bpung” which could be a proper prefix of an email address—something that I’ve advocated for avoiding before (see footnote 2 of Judging Noun Types). Moreover, due to a quirk of how nountypes based on regular expressions are scored, all results are given the score of 1.

I just committed a change so that this behavior is improved. The new version accepts strings which match the username part of the email address spec sans @ and domain, but with a great score penalty.³ Moreover, domains which do not have a final label (the top level domain) with more than one letter (unless it’s an IP address) or do not have any periods (.) in the domain will be penalized as well. Here’s what the same inputs produce now:

input	suggestion
bpung	bpung	0.3
bpung@m	bpung@m	0.8
bpung@mozilla.com	bpung@mozilla.com	1

Same time, same channel

I hope this post sheds light on the many changes I made together as well as the underlying thought process. If you don’t agree with any particular fix or analysis, please comment! I’ll be back again tomorrow with another installment of Nountype Quirks. Stay tuned!

Related posts:

1. Nountype Quirks: Day 3: Geo Day
2. Nountype Quirks: Day 1
3. Judging Noun Types

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

Today I began the process of going through all of the nountypes built-in to Ubiquity using the principles and criteria I laid out yesterday—a task I’ve had in planning for a while now. As I explained yesterday, improved suggestions and scoring from the built-in nountypes could directly translate to better and smarter suggestions, resulting in a better experience for all users. Here I’ll document some of the nountype quirks I’ve discovered so far and what remedy has been implemented or is planned.

Note: this blog post includes a number of graphs using HTML/CSS formatting. If you are reading this article through a feed reader or planet, I invite you to read it on my site.

noun_type_percentage

Here’s what a few different inputs originally returned:

input	suggestion
20	20%	1
20%	20%	1
0.2	20%	1
0.2%	20%	1
20.0	2000%	1
2 hens in the garden	2%	1

Let me highlight a couple obvious quirks:

1. In certain cases, where the numerical expression includes a decimal and is less than one, it is interpreted as a proportional, rather than percent, value, e.g. “0.2” → “20%”. “0.2%” is not even an option. This is the case even when explicitly adding a % sign.
2. All suggestions, including those where the numeral was extracted from a long string of text (e.g. “2 hens in the garden”), get the same score of 1.

I just committed a fix so noun_type_percentage now…

1. Counts the number of characters in the input which match [\d.%] and caps the score by (number of acceptable characters)/(length of input).
2. Strings which do not include “%” get a 10% penalty.
3. In the case of decimals less than 1 without a % sign, the proportion interpretation is also suggested (e.g. “0.2” → “20%”) in addition to the original suggestion (“0.2%”), but with a slight penalty.

Here is what they now return:

input	suggestion
20	20%	0.9
20%	20%	1
0.2	0.2%	0.9
	20%	0.81
0.2%	0.2%	1
20.0	20%	0.9
2 hens in the garden	2%	0.05

noun_type_tag

Here’s what a few different inputs originally returned. Keep in mind that currently in this test profile, the preexisting tags are “animal”, “help”, “test”, and “ubiquity”.

input	suggestion
animal	animal	0.3
mineral	mineral	0.3
anim	animal	0.7
	anim	0.3
help, test, ubiq	help,test,ubiquity	0.7
	help,test,ubiq	0.3
google, yahoo, ubiq	google,yahoo,ubiquity	0.7
	google,yahoo,ubiq	0.3
google, , yahoo	google,yahoo	0.3

Here are a few of noun_type_tag’s quirks:

1. There are only two scores ever given out: 0.3 and 0.7.
2. Only the last tag in the list and whether it exists or not is taken into account.
3. When the last tag is incomplete, the completion is suggested with a higher score, but if the last tag is exactly equal to an existing tag, it gets the lower score.

Ideally, we want noun_type_tag to look at each of the tags given to it, with higher scores for when there are more preexisting tags and fewer new ones. Keep in mind, though, that we only have to suggest the completion of the very last tag as that may be one where the user hasn’t completed typing yet… for earlier tags, we can assume (safely or not) that the user placed the comma where they meant to. We can’t teach Ubiquity to read minds, after all.¹

With this in mind, I just made a change to noun_type_tag which aims to follow these principles. The basic idea is that we start with a base score of 0.3 but then raise it via nth root for every tag in the sequence which is preexisting. Here’s what the same inputs return now. Recall that the preexisting tags are “animal”, “help”, “test”, and “ubiquity”.

input	suggestion
animal	animal	0.55
mineral	mineral	0.3
anim	animal	0.55
	anim	0.3
help, test, ubiq	help,test,ubiquity	0.86
	help,test,ubiq	0.74
google, yahoo, ubiq	google,yahoo,ubiquity	0.55
	google,yahoo,ubiq	0.3
google, , yahoo	google,yahoo	0.3

noun_type_awesomebar

input	suggestion
moz	http://www.mozilla.com/	0.8
	https://wiki.mozilla.org/Labs/Ubiquity/ Parser_2_API_Conversion_Tutorial	0.8
	http://en-us.start3.mozilla.com/ firefox?client=firefox-a&rls= org.mozilla:en-US:official	0.8
	http://en-us.www.mozilla.com/en-US/firefox/about/	0.8

There are a couple quirks here:

1. All suggestions are returned with the same scores.
2. The nountype returns the URL of the entry as the HTML-formatted result and the title as the text-formatted result, which clearly does not make sense. However, it’s not clear to me whether the title, URL, or some combination of both is what we should be returning as the suggestion text presented to the user.²

I just rewrote noun_type_awesomebar to actually do some differential scoring. This new version also presents the URL or title depending on whichever had a better match using the matchScore function.³

input	suggestion
moz	www.mozilla.com	0.7
	https://wiki.mozilla.org/Labs/Ubiquity/ Parser_2_API_Conversion_Tutorial	0.63
	http://en-us.start3.mozilla.com/ firefox?client=firefox-a&rls= org.mozilla:en-US:official	0.61
	http://en-us.www.mozilla.com/en-US/firefox/about/	0.6

noun_type_url

The purpose of noun_type_url’s suggest function is two-fold: first, to accept strings which may look like a URL and, second, to suggest URL’s from the history just like noun_type_url, but only based on URL matches and not title matches.⁴ Here are a few sample inputs:

input	suggestion
moz	http://www.mozilla.com/	0.9
	http://moz	0.5
	https://wiki.mozilla.org/Labs/Ubiquity/ Parser_2_API_Conversion_Tutorial	0.9
	http://en-us.start3.mozilla.com/ firefox?client=firefox-a&rls= org.mozilla:en-US:official	0.9
	http://en-us.www.mozilla.com/en-US/firefox/about/	0.9
test	http://test	0.5
http://	http://	0.5
http:	http:	0.5
http	http	0.5
_test	http://_test	0.5
hello world!	http://hello world!	0.5

Oh, where to begin!? Here are some initial quirks… it’s possible that you could think of more!

1. There is no differential scoring… only 0.9 for suggestions from history and 0.5 for URL-like strings.
2. A number of invalid domain names are being accepted and turned into suggestions (“hello world!”, “_test”, etc.).
3. It’s trying to be smart by suggesting “http://” as a default URI scheme but doing so even for prefixes (initial substrings) of the word “http” itself.

With these thoughts in mind, I just took a first stab at improving this situation. Here are some features of the new implementation:

1. History entries are scored in the same way as in noun_type_awesomebar, using matchScore.
2. URLs without an explicit URI scheme (like “http://”) get a 10% penalty.
3. “http://” is only suggested if one of a long list of common URI schemes are not detected.
4. It repairs schemes which are missing a slash or two, suggesting for example “http:hello.com” → “http://hello.com”.
5. It actually uses Firefox’s own IDNService to check if the domain name is a valid internationalized domain name. If it’s an IDN as opposed to LDH (“letters, digits, and hyphens”), it gets a 10% penalty. If it’s not even a valid IDN, it is ruled out (see last two example inputs below).
6. There are also penalties for only being a domain name with no path and for the domain not having any periods (.) in it.

Here is what our suggestions now look like:

input	suggestion
moz	http://www.mozilla.com/	0.6
	http://moz	0.65
	https://wiki.mozilla.org/Labs/Ubiquity/ Parser_2_API_Conversion_Tutorial	0.63
	http://en-us.start3.mozilla.com/ firefox?client=firefox-a&rls= org.mozilla:en-US:official	0.61
	http://en-us.www.mozilla.com/en-US/firefox/about/	0.6
test	http://test	0.65
http://	http://	1
	shttp://	0.75
http:	http://	0.9
	shttp://	0.7
http	http://	0.72
	https://	0.71
	shttp://	0.68
	http://http	0.65
_test	none
hello world!	none

See you tomorrow~

Alright, enough nountype wrangling for one day. I’ll be back again tomorrow for another installment.

Related posts:

1. Nountype Quirks: Day 3: Geo Day
2. Nountype Quirks: Day 2
3. Localizing Commands for Ubiquity 0.5

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

Different arguments are classified into different kinds of nouns in Ubiquity using noun types.¹ For example, a string like “Spanish” could be construed as a language, while “14.3” should not be. These kinds of relations are then used by the parser to introduce, for example, language-related verbs (like translate) using the former argument, and number-related verbs (like zoom or calculate) based on the latter. Ubiquity nountypes aren’t exclusive—a single string can count as valid for a number of different nountypes and in particular the “arbitrary text” nountype (noun_arb_text) will always accept any string given.

In addition to the various built-in nountypes, Ubiquity lets command authors write their own nountypes as well.

The functions of a noun type

Nountypes have two functions: the first is accepting and suggesting suggestions and the second is scoring.

Accepting and suggesting

Nountypes don’t just have to accept the exact string they were given—they can also return suggestions which are based on that input. For example, the noun_type_language can take the input “span” and return “Spanish.” A nountype can return multiple suggestions which may or may not include the trivial suggestion, i.e. the original input as is. If there is no way that that input could possibly be part of an accepted value, it should return no suggestions, i.e. [].²

Scoring

Ubiquity 0.5 with Parser 2 introduced the notion of a nountype suggestion score. For example, two different nountypes can accept the same input, but with different scores. Scores range from 0 to 1 where 1 is a perfect or exact suggestion and 0.1 or so is a very very improbable suggestion.³ These scores are used in the scoring of parses. Because verbs specify certain nountypes for each of their arguments, the scores that individual nountypes return for each argument are a crucial component of the scoring algorithm and can even determine whether a parse is returned or not.

With this in mind, you may be tempted to make your nountype return a score of 1 on any input so your verb will show up in the suggestions highly. While this would work, it will only act to make your verb annoying and a poor Ubiquity citizen. Appropriate scores must be given to noun suggestions, with higher values reflecting confidence and lower values reflecting imprecision. But how exactly do you figure out what’s an appropriate value?

Judging nountypes with the Nountype Tuner

The Nountype Tuner is a new tool I’ve been building to help both Ubiquity core developers and command authors to check their nountypes against others and to “tune” their behavior and scores. The nountype tuner will take your input and throw it against all of the nountypes referenced in your active verbs and display the suggestions returned with their scores. You can think of it as the Playpen’s little sister.

The Nountype Tuner can be found at chrome://ubiquity/content/tuner.html, though I am pretty sure it is broken in Ubiquity 0.5 and 0.5.1. It has been fixed now and I will make sure it’s in good shape for 0.5.2.

The heart and soul of the Nountype Tuner is this scale:

This scale tells you, in plain English, what different scores represent and correspond to, in two sets of vocabulary: “in terms of a guess” and “in terms of a match.” While still subjective, this scale helps developers just different input/output pairs and their scores. For example, “lian” → “http://lian” is given 0.5, so it’s an okay guess or a possible match… does that seem right to you? Or “lian” → “Italian” being between “okay” and “good.” Appropriate? We can look at such statements, decide how we feel about them, and tweak if necessary.

Good nountype scores have roots

CC-BY Aaron Escobar

…not that kind of root, but more like this kind of root… let me explain…

When comparing the scores that individual nountypes return for different inputs, we must compare those scores within the same nountype’s family of suggestions to see if higher scores truly correspond to higher confidence. For example, the language nountype should give the suggestion “French” for both the inputs “f” and “fren,” but the scores of these suggestions should be different—i.e. the score of “f” → “French” should be much lower than the score for “fren” → “French,” reflecting the additional informational value. We refer to this relation of the scores of successive prefixes of a single suggestion all returning that same suggestion as the score curve and in general it should be non-decreasing.⁴

One could say the most trivial score function then is the linear one. For a series of converging prefixes of the same suggestion (“Dutch”), under a linear approach we could naively let the score be (length of the input)/(length of the suggestion), as below:

This linear model is represented below by the black line.

The problem with the linear model is that earlier transitions (additional keystrokes) add more information than the later ones. Once we’ve entered “dutc,” after all, we would like to be pretty darn sure that we mean “Dutch,” so the score difference between “dutc” and “dutch” should be less than the score difference between, say, “d” and “du.” We want a score curve that looks more like the solid or dotted red lines above.

For this reason, I strongly advocate the incorporation of an nth-root in the score computation. Nth-rooted score functions over [0,1] have the feature that they are increasing but also that earlier transitions affect the score more than later ones, which is exactly what we’d like to see. (The solid red line above is x^1/2 and the dotted one is x^1/3.)⁵

Conclusion

Properly tuning both the built-in nountypes and custom nountypes is crucial to producing more accurate and relevant parse suggestions. I’ll be using the principles and criteria laid out above, combined with the new Nountype Tuner, to tune the built-in nountypes (trac #746) in the coming days in preparation for our 0.5.2 release. I invite you to use the Nountype Tuner in 0.5.2 to tune your custom nountypes as well.

Related posts:

1. Nountype Quirks: Day 1
2. Nountype Quirks: Day 2
3. Nountype Quirks: Day 3: Geo Day

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

In many romance languages, prepositions and articles often form portmanteau morphs, combining to form a single word.¹ Some examples include (French) à + le > au, de + le > du, (Catalan) a + el > al, de + les > dels, per + el > pel. Italian has a particularly productive system of portmanteau’ed prepositions and articles… I refer you to the contraction article on Wikipedia.

As I noted a couple weeks ago, however, some combinations do not form portmanteaus.²

French:

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

The problem with this is that if we use both à and au as delimiters, we may end up passing the definite article to the verb as part of the argument in some cases, but not in other cases.

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

The solution:

The solution is a new step in the Parser 2 process which normalizes the form of arguments. Each language’s parser can now optionally define a normalizeArgument() method which takes an argument and returns a list of normalized alternates. Normalized arguments are returned in the form of {prefix: '', newInput: '', suffix: ''}. For example, if you feed “la table” to the French normalizeArgument(), it ought to return

[{prefix: 'la ', newInput: 'table', suffix: ''}]

If there are no possible normalizations, normalizeArgument() should simply return []. Each alternative returned by normalizeArgument() is substituted into a copy of the possible parses just before nountype detection. The prefixes and suffixes are stored in the argument (as inactivePrefix and inactiveSuffix) so they can be incorporated into the suggestion display.

Here, for example, is how the inactive prefix “l’” is displayed in the parser demo. This way the user is told that the “l’” prefix is being ignored, and the nountype detection and verb action can act on the argument “English”.³ (In the future, of course, we could teach this nountype to accept the Catalan “anglès”.)

The easiest way to produce this output is to use the String.match() method. For example normalizeArgument() code, I refer you to the Catalan and French parser files.

I hope that this solution will help make Ubiquity with Parser 2 feel more natural for many romance languages.

Related posts:

1. Solving Another Romantic Problem: Weak Pronouns
2. Inside the Argument
3. Where’s The Verb?

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

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.

Ubiquity Parser 2: better noun-first suggestions and command localization from mitcho on Vimeo.

Testing Parser 2 requires the latest Ubiquity source, as explained here. If you find any problems or suggestions, please add a ticket to our trac with the keyword new-parser.

Here are some resources for those of you who would like to read more about different features touched on in this video:

• The design document for the new parser
• Writing commands with semantic roles and a proposed inventory of semantic roles
• Some thoughts on noun-first suggestions and Ubiquity in Japanese

In the near future we’ll also be writing up some documentation on how to take advantage of this new parser in your commands as well.

Related posts:

1. Ubiquity Parser: The Next Generation Demo
2. Adding Your Language to Ubiquity Parser 2
3. Ubiquity Commands by The Numbers

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

Every day on the way to work I walk by a fine establishment known as Yoshinoya (吉野家), Japan’s largest gyudon (牛丼) chain restaurant. For those of you whose lives have yet to be graced by gyudon, it’s a bowl of rice topped with beef and onions stewed in a sweet-savory soy-based sauce. Loving gyudon and being a cheapskate, I naturally noticed the recent 50 yen off gyudon promotion at Yoshinoya. The above photo is a photo of part of that sign.

Part of this sign, though, made me think about our new Ubiquity parser. In particular, it was the attachment ambiguity in the end date of the promotion. The text in the photo above literally is “April 15th (Wed.) 8PM until”. (Note that Japanese is a strongly head-final language, and that the “until” is a postposition.) There are two possible readings for this expression, as illustrated by the two composition trees below.

The first tree, on the left, represents the reading “until (April 15th 8PM)”, while the second represents two arguments: “on April 15th” and “until 8PM”. In other words, in the first reading, the promotion begins at some earlier date and extends until April 15th at 8PM while, in the second reading, the promotion is one day only, on April 15th, until 8pm. Such syntactic ambiguities are called “attachment ambiguities” in linguistics as it is an ambiguity of where different arguments “attach” in a tree representation.

This attachment ambiguity was possible because there was no clear marker on “April 15th,” which may have disambiguated it as “on April 15th”. In fact, in many languages this time position argument comes with no case marker or preposition, or it’s optional, making parsing for them difficult. If such a sentence is entered with spaces, the Ubiquity Parser: The Next Generation would try a parse where “8PM” is the “until” or goal argument and “April 15th” is an object argument, but it will only check its noun type, not put it in the correct semantic role (position). Perhaps this is something to think about in the future.

These types of situations will surely come up as we continue work on the Ubiquity parser, making it essential to look at different languages. Are there certain kinds of arguments in your language that do not have any word-external markers such as case or prepositions/postpositions?

Related posts:

1. User-Aided Disambiguation: a demo
2. Ubiquity in Firefox: Focus on Japanese
3. Talking Ubiquity in Japan: 拡張機能勉強会にて発表

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. Adding Your Language to Ubiquity Parser 2
3. Ubiquity Commands by The Numbers

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

As we look to move forward with incorporating the next generation parser into Ubiquity proper, it thus becomes important to take a look at the current command ecosystem to see how possibly disruptive this move will be. To this end last night I wrote a quick perl script to scrape the commands cached on the herd and get some quantitative answers to my questions.

(1577 different verbs were analyzed. None of these computations below are weighted by feed popularity.)

Q: Are there a lot of commands which use more than one argument?

A: The vast majority (>85%) of commands take one or no arguments, requiring no modifiers. Only those remaining 15% will require a switch to refer to different arguments by semantic role.

Q: Do many commands introduce custom noun types?

A: 147 different noun types (lumping anonymous inline objects as one type) were detected. The vast majority of all takes (direct object) arguments were of type noun_arb_text, although many modifiers arguments used custom noun types. The other standard (built-in) noun types are well represented as well, with noun_type_language coming in at second place. Here’s a chart with all the noun types which had more than one use.

Q: Are commands with modifiers using natural-language delimiters?

A: Most of the modifiers detected were English prepositions such as “from”, “to”, “as”, “with”, but other words were also seen such as “title”, “type”, “username”, and “message” and even a handful of commands with symbols such as “@”, “>”, or “#”.

Related posts:

1. Writing commands with semantic roles
2. Ubiquity Parser: The Next Generation Demo
3. Rolling out the Roles

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

A week or two ago while visiting California, Jono and I had a productive charrette, resulting in a new architecture proposal for the Ubiquity parser, as laid out in Ubiquity Parser: The Next Generation. The new architecture is designed to support (1) the use of overlord verbs, (2) writing verbs by semantic roles, and (3) better suggestions for verb-final languages and other argument-first contexts. I’m happy to say that I’ve spent some time putting a proof-of-concept together.

I’ve implemented the basic algorithm of this parser for left-branching languages (like English) and also implemented some fake English verbs, noun types, and semantic roles. This demo should give you a basic sense of how this parser will attempt to identify different types of arguments and check their noun types even without clearly knowing the verb. This should make the suggestion ranking much smarter, particularly for verb-final contexts. (For a good example, try from Tokyo to San Francisco.)

➔ Check out the Ubiquity next-gen parser demo

Clicking on the environment info will give you some information on the specific verbs, noun types, and roles implemented. You can also scroll through the current parse section to see the step by step derivation of how the suggested parses were constructed.

I’ll be flying about 15 hours in the next hour as I make my way back to Japan… hopefully I’ll make some more progress on the plane! I’ll look forward to your comments! For those of you interested in checking out the code yourself, you can find it on BitBucket.

Related posts:

1. This week on Ubiquity Parser: The Next Generation
2. Ubiquity Commands by The Numbers
3. Foxkeh demos Ubiquity Parser: The Next Generation

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

The inspiration for this idea came from Aza’s blog post “Solving the ‘it’ problem” which advocates for this type of quick feedback to the user in cases of ambiguity. Such a method would help both the user better understand what is being interpreted by the system, as well as offer an opportunity for the user to correct improper parses. I just tried mocking up such an input box using jQuery.

➔ Try the User-Aided Disambiguation Demo

If you have any bugfixes to submit or want to play around with your own copy, the demo code is up on BitBucket. ^^ Let me know what you think!

Related posts:

1. Ubiquity Parser: The Next Generation Demo
2. This week on Ubiquity Parser: The Next Generation
3. Scoring and Ranking Suggestions

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. Rolling out the 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.

今後多様な言語に対応した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. Ubiquity Parser: The Next Generation Demo
3. Ubiquity in Portuguese

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

I gathered some data from the fantastic World Atlas of Language Structures to put together a survey of many of the languages on the Internet. For each of the languages, I got the canonical word order and whether the language marks the role of its argument on the verb and/or the arguments themselves.

As you can see, there are a number of data points that are still missing. Please contribute information on the languages you speak! You can edit the spreadsheet on Google Docs. Thanks!

Related posts:

1. Three ways to argue over arguments
2. Ubiquity i18n: questions to ask
3. Adding Your Language to Ubiquity Parser 2

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. Contribute: how your language identifies its arguments
2. Writing commands with semantic roles
3. Ubiquity in Firefox: Focus on Japanese

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