Hi - I went ahead and did some more Freebase noun work, along the lines that Will suggested.
Summary: the general-purpose Freebase noun now does essentially what Will wanted -- it supports narrowing by type, and can also suggest types "on the fly." As with the original version, you can try it out by adding the "about" command you'll find here: http://graynorton.com/ubiquity/freebase-nouns.html A few notes on usage: * In most cases, you can just start typing the full or partial name of whatever it is you're interested in, e.g. "about washington" * If you're not seeing the results you expect and you think that narrowing by type will help, you can refine by appending type info in one of a few relatively natural ways, e.g., "about washington the president," "about washington, tennis player," "about washington - us state" * Prepending type info also works, in case you know in advance that you'll need to narrow by type, e.g. "about person: washington," "about the college washington" * If you need type suggestions, starting with the type and then pausing ("about person") will often work pretty well, but some of the suggestions may not be types. You can restrict suggestions to types by appending a colon ("about person:"). Ultimately, I think Freebase is more interesting (in the Ubiquity context) as a mechanism for defining *specific* noun types, and there are a few examples (which take just a couple of lines to define) in the feed above. But working on the general Freebase noun has been interesting, too, as it has gotten me thinking quite a bit about command-parsing and Ubiquity's NL support in general. As promised on last week's planning call, I'll try to compile some of those thoughts in an email to this list shortly. For those few who might be interested, here are some additional notes and observations arising from my experience working on the general-purpose Freebase noun: I started with a quick-and-dirty pairing of a "Freebase type" noun to Will's Freebase search command. This was indeed quick, but the results weren't terribly humane (to speak the Mozilla Labs language). Besides the unfortunate splitting of the "suggestions" across the suggestion and preview panes that I called out before, there were a couple of issues I hadn't anticipated: * Given the way the Ubiquity parser works, I needed to make the type a named modifier to separate it from the direct object (the search term). For example, rather than "freebase actor clooney," the user would have had to say something like "freebase type actor clooney" or "freebase clooney type actor." Pretty ugly. * It appears that the parser also can't handle multiple-word values for a modifier if the noun-type associated with that modifier returns suggestions asynchronously. The command "about clooney type film actor" actually ended up being parsed as { direct_object: "clooney actor", type: "film" }. (This one seems like a clear bug, or perhaps a design limitation -- I haven't checked Trac yet.) The net result was pretty much unusable. But then I got to thinking again about Will's original suggestion, which I had initially dismissed as not doable because of parser limitations. This time it occurred to me that the type and the search term might best be considered a single noun phrase, so why not let the Ubiquity parser pass the entire phrase to the noun-type, leaving the noun-type to parse out the type and the search term? So, that's the path I took: * At first I thought there might not be much to do, since it turns out that the Freebase Search service is actually pretty good at cases like Will's examples, where a type name is prepended to some search text. Without any modifications to the old noun-type, commands like "about actor clooney," "about film braveheart," and "about language huaorani" all yielded the desired results. * However, the results weren't always great (e.g., "about person washington" didn't return George in the first 5 results, despite the fact that an explicit Freebase search for "washington" of type "person" puts him first). Also, pausing partway through to get type suggestions (e.g., after typing "about film") didn't work quite right, because many of the suggestions returned were not in fact types. * To address the occasional poor-results problem, I decided it would be worthwhile to support some "natural" (to varying degrees) ways for users to explicitly separate the type from the search term. So, the noun type now handles a number of punctuation- and article-based methods of differentiation: "washington the person", "the film actor clooney" (which actually required some gymnastics to get right, given the ambiguous boundary between type and term), "chris reeve, actor", "location: madeline", etc.; and some more verbose constructions, like "a person named rain". * To address the type-suggestion issue, I settled on a solution that's only semi-natural, and would need to be learned. If you provide a potential type name, add a colon (as in the "location: ..." example above) and then pause, the suggestions that come back will be restricted to Freebase types. You can select one, hit Tab to complete or refine, then continue typing the search text. Enough for now. :-) There's plenty more interesting stuff to do in the area of dynamic (data-driven) noun types, I think, and I'd be happy to discuss/compare notes with anyone else who is inclined to keep moving in this direction. - Gray On Sat, Nov 8, 2008 at 12:39 PM, Gray Norton <[EMAIL PROTECTED]> wrote: > Hi, guys - > > Fernando, container verbs are certainly interesting, but unless I'm missing > something I don't think they'll enable quite the use case that Will is > talking about. If I understand correctly, a version of what he wants > could be done with a "normal" (non-container) command, and another version > needs something besides a container. > > Will, although I removed it before putting my script on the server, I had a > "Freebase type" noun that I was aiming to use very much as you describe. The > noun could be re-added with a couple lines of code, and then it would likely > be easy to pair that with a slightly modified version of your Freebase > search command, resulting in a type-constrained Freebase search. > > However, that's still not quite what I wanted, because it would effectively > split the "suggesting" functionality into two parts: the suggestion of type > would happen at the noun level (within the command-suggestion "pane"), > whereas the suggestion of individual entities/topics would happen inside the > preview pane. Not bad, but it would be great if all of the suggesting could > happen within the command-suggestion area, leaving the preview free for > actually displaying whatever information the user is after. In order for > this to work, though, the Ubiquity parser would need to allow for one > argument of a command to be dependent on the value of another argument; and > on top of that I think the parser would also need to support a more > sophisticated scoring mechanism to allow the best type/entity pairings to > bubble to the top of the command suggestions. > > In any case, when I have a few minutes (probably tomorrow or Monday) I'll > take a whack at mating a "Freebase type" noun to your Freebase search > command (unless you want to try it first). > > And thanks for the link to the discussion of the mql_output param to the > Feebase search service...I didn't know about that, but it looks very useful! > > - Gray > > On Sat, Nov 8, 2008 at 10:22 AM, Fernando Takai < > [EMAIL PROTECTED]> wrote: > >> Will, >> >> What you want is a cointainer verb [1]. I did some tests about it, but we >> need to do some changes on the Ubiquity core first. >> Take a look here [2] to see what i'm trying to do (i don't know if its >> going to work...) >> >> [1] http://labs.toolness.com/trac/ticket/134 >> [2] http://gist.github.com/21109 >> >> On Sat, Nov 8, 2008 at 3:37 PM, Will Moffat <[EMAIL PROTECTED]>wrote: >> >>> >>> Hi Gray, >>> >>> Cool command! >>> >>> I'd love to see a completely flexible two stage Freebase search >>> command where you first choose a type and then an instance. >>> >>> Example (step 1): >>> >>> "about" type-name where type-name is "person", "film", "city" or any >>> of the thousands of types in Freebase [1] >>> >>> Examples (step 2) >>> "about film braveheart" >>> "about actor clooney" >>> "about language huaorani" >>> >>> Also note that you can use the Freebase API to search other sites by >>> demanding another site's key. See the discussion at [2] >>> If anybody needs help constructing Freebase queries then post on the >>> Freebase Developer mailing list. >>> >>> regards, >>> --Will >>> (Freebase.com hacker) >>> >>> [1] http://www.freebase.com/view/type/type >>> [2] http://markmail.org/message/svjtdzwqkz6enjep >>> >>> >>> >>> >> >> >> -- >> Fernando "Takai" >> http://flickr.com/photos/supeertakai >> http://fernandotakai.wordpress.com >> http://fernandotakai.jaiku.com >> >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "ubiquity-firefox" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/ubiquity-firefox?hl=en -~----------~----~----~----~------~----~------~--~---
