No subject
Sat Apr 12 01:08:48 CEST 2008
be possible use it or its ontologies for the type field of the information
the runners work with. IMHO and in the ignorance of the few things I`ve read
about Nepomuk, it seems a the best approach.
--
Jordi Polo Carres
NLP laboratory - NAIST
http://www.bahasara.org
------=_Part_27106_4475299.1208016514781
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
<br><br><div class="gmail_quote">2008/4/12 Aaron J. Seigo <<a href="mailto:aseigo at kde.org" target="_blank">aseigo at kde.org</a>>:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>On Friday 11 April 2008, Jordi Polo wrote:<br>
> Also, we need extended type information. To put an example, I`ve modified<br>
> (locally) the bookmark runner to also read the bookmarks of krdc and<br>
> konsole. So extra information should be added in the match as for konsole<br>
> bookmarks we surely are interested in konsole --workdir bookmark or browse<br>
> it with dolphin.<br>
<br>
</div>patch?<br>
</blockquote><div><br> Unfortunately I am traveling this weekend and don`t have my computer here, I`ll send it on monday.<br><br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br>
> Aaron suggested some kind of hintting and delaying of hinted runners IIRC.<br>
> That may be a solution that preserve current interfaz but I`d like you to<br>
> consider further changes and get some discussion on the topic now that you<br>
> are meeting.<br>
<br>
</div>could you provide some API examples of wht you are thinking about?<br>
<font color="#888888"></font></blockquote><div><br>What I`d suggest is:<br><br>1 - Runners will have a defineType along with the current match and exec methods. <br><br>2- The current type enum of SearchContext will be extended, possibly with types from the ontologies of Nepomuk (it seems possible and very attractive but have to be sure). The type also will need extended information. For instance, we got a directory type. But it we need as extended information where the type came from. The ranking of the matches may vary depending on if the directory was found in the bookmarks of konsole or konqueror. <br>
<br>3.- In fact, the previous point can be encapsulated in a new class with type and data information. SearchContext will have a list of these classes. Similar to current SearchMatch.<br><br>4.- As the user inputs text, each runner`s defineType will be called. Some runners will have not need to define further. If the runner define or use a command, it will add it to the list (saying that the user input has the type command). So any command not defined by active and installed runner will not be available. Each runner will add guesses and the extended information to the list of types of SearchContext. <br>
<br>5.- Even when defineType will be called for each runner, I am wondering if it would be a good idea let the runners specify what types they are interested in so match will be only be called when that types are in the list. That will be useful for the future RunnerManagerGUI I guess. Also matches can be ordered by type. For instance commands come first, unknown type runners` matches come last.<br>
</div></div><br> Summary: new method for runners and extended type info. An intermediate step to get the type and distribute the accurate information to the runners. <br><br>For instance, the bookmark runner will have empty match and exec. As now it will search the user input in the bookmarks and find the corresponding URL. But it will do it in the defineType method, adding the URL and "konqueror as the program the info came from" as information to the list of types. The location runners and others will know how to manage that kind of information and will not bother parsing.<br>
<br>So in practice, there will be runners with empty defineType, runners with empty match and exec and runners that define both. <br><br>From monday I`ll take a further look to Nepomuk to dictanimate if it would be possible use it or its ontologies for the type field of the information the runners work with. IMHO and in the ignorance of the few things I`ve read about Nepomuk, it seems a the best approach.<br>
<br clear="all"><br><br>-- <br>Jordi Polo Carres<br>NLP laboratory - NAIST<br><a href="http://www.bahasara.org" target="_blank">http://www.bahasara.org</a><br>
------=_Part_27106_4475299.1208016514781--
More information about the Panel-devel
mailing list