<br>Unbelievable, in 3 or 4 iterations of emails we seem to agree if not 100% of the ideas, at least in most of the vision. <br><br>I will rewrite all this in a more concrete gsoc style proposal and send it to the ML tomorrow. <br>
<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
> translate -> feed runners and get their results (the user select or launch<br>
> the top ranking)<br>
><br>
> :translate -> The command is parser and only the "translate" service runner<br>
<br>
</div>other things that can help:<br>
<br>
* relevancy ranking. any runner which recognizes its keywords (e.g. "starting<br>
with translate" for a translation runner) should up the relevancy of the<br>
rturn<br>
<br>
* if done in coordination with another application, that application can hint<br>
which runner to favour (not neccessarily limit to, but at least favour),<br>
which you already mentioned above.<br>
<div class="Ih2E3d"></div></blockquote><div><br><br>I see two choices here:<br>- Let the runners do the parsing job. Adding keywords to the runners, get apps hinting and let the best win. May be more dynamic but you may not get what you want and surely more difficult to implement.<br>
- Let a "proxy" do the parsing job. Mapping keywords to runners. Configure what syntax goes to what runner and let only one activate. All the language parsing in one place, more reliable results (the user defines how the language works), learning can be implemented here though.<br>
<br>At a first glance both choices may have advantages and drawbacks. But being 3.30 am here now, my first glance is all but reliable. <br></div></div><br>--<br>Jordi Polo Carres<br>NLP laboratory - NAIST<br><a href="http://www.bahasara.org/" target="_blank">http://www.bahasara.org</a><br>