--===============1136606046==
Content-Type: multipart/alternative; 
	boundary="----=_Part_20985_11250014.1206008821579"

------=_Part_20985_11250014.1206008821579
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

First draft here
http://www.bahasara.org/raw-attachment/wiki/Papers/application_gsoc.pdf

Please comment. It is still WIP.
Do you think I should move something from extra functionality to core
functionality?



On Thu, Mar 20, 2008 at 3:37 AM, Jordi Polo <mumismo@gmail.com> wrote:

>
> 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.
>
> I will rewrite all this in a more concrete gsoc style proposal and send it
> to the ML tomorrow.
>
>
>
> > > translate  -> feed runners and get their results (the user select or
> > launch
> > > the top ranking)
> > >
> > > :translate -> The command is parser and only the "translate" service
> > runner
> >
> > other things that can help:
> >
> > * relevancy ranking. any runner which recognizes its keywords (e.g.
> > "starting
> > with translate" for a translation runner) should up the relevancy of the
> > rturn
> >
> > * if done in coordination with another application, that application can
> > hint
> > which runner to favour (not neccessarily limit to, but at least favour),
> > which you already mentioned above.
> >
>
>
> I see two choices here:
> - 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.
> - 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.
>
> 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.
>
> --
>
> Jordi Polo Carres
> NLP laboratory - NAIST
> http://www.bahasara.org
>



-- 
Jordi Polo Carres
NLP laboratory - NAIST
http://www.bahasara.org

------=_Part_20985_11250014.1206008821579
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

<br>First draft here<br><a href="http://www.bahasara.org/raw-attachment/wiki/Papers/application_gsoc.pdf">http://www.bahasara.org/raw-attachment/wiki/Papers/application_gsoc.pdf</a><br><br>Please comment. It is still WIP.<br>
Do you think I should move something from extra functionality to core functionality?<br><br><br><br><div class="gmail_quote">On Thu, Mar 20, 2008 at 3:37 AM, Jordi Polo &lt;<a href="mailto:mumismo@gmail.com">mumismo@gmail.com</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><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"><div class="Ih2E3d"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><br>
&gt; translate &nbsp;-&gt; feed runners and get their results (the user select or launch<br>
&gt; the top ranking)<br>
&gt;<br>
&gt; :translate -&gt; The command is parser and only the &quot;translate&quot; service runner<br>
<br>
</div>other things that can help:<br>
<br>
* relevancy ranking. any runner which recognizes its keywords (e.g. &quot;starting<br>
with translate&quot; 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></div></blockquote></div><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 &quot;proxy&quot; 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.&nbsp; <br></div></div><font color="#888888"><br>--</font><div><div></div><div class="Wj3C7c">
<br>Jordi Polo Carres<br>NLP laboratory - NAIST<br><a href="http://www.bahasara.org/" target="_blank">http://www.bahasara.org</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Jordi Polo Carres<br>NLP laboratory - NAIST<br><a href="http://www.bahasara.org">http://www.bahasara.org</a><br>

------=_Part_20985_11250014.1206008821579--

--===============1136606046==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Panel-devel mailing list
Panel-devel@kde.org
https://mail.kde.org/mailman/listinfo/panel-devel

--===============1136606046==--