[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: Re: GSoC: command and get obeyed ! + draft
From: "Jordi Polo" <mumismo () gmail ! com>
Date: 2008-03-20 10:27:01
Message-ID: a4162420803200327k65f8e267ica843b0271e8f9cc () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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
[Attachment #5 (text/html)]
<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 <<a href="mailto:mumismo@gmail.com">mumismo@gmail.com</a>> 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> > \
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></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 "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><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>
_______________________________________________
Panel-devel mailing list
Panel-devel@kde.org
https://mail.kde.org/mailman/listinfo/panel-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic