Hello, I put my proposal into GSoC page, you can look at it at: https://google-melange.appspot.com/gsoc/proposal/review/google/gsoc2013/lukiasz/14001# (it's public, everyone can see it).
I'll be very thankful if you comment it at GSoC page or at previous Google Documents link. It's important to me ;) Cheers, Lukasz 2013/4/21 Łukasz Olender <[email protected]> > Hi again, > > I made a document with my idea description. I need your help - could you > read it and give me some tips and tell me what's your opinion? Here's link: > https://docs.google.com/document/d/1occ2LPLS9dJoBqgxIz9O2T3mo6L6xWT4t1Z0L0fFp4U/edit?usp=sharing > > @Vishesh - will you be my mentor with this project if I get into? > > Best regards, > > Lukasz > > > 2013/4/19 Łukasz Olender <[email protected]> > >> Hi, >> >> My name is Lukasz, I'm from Poland and I'd like to take part in GSoC this >> year. I'm pretty impressed by a quality of code and the way KDE development >> works. You're doing a great job and I want to work with you! :) >> >> To the point. I want to rewrite current query parser. Now, I'm having >> good time thinking about it and I wonder whether using of Bison + Flex is >> desirable to generate parser. In whole KDE, Bison is used in several >> subprojects, I think it might me the best choice if we consider future >> maintenance and code readability. >> >> Few weeks ago, I made a patch which optimizes regexp cache mechanism in >> Nepomuk. Some pattern recognition is involved and whole code looks pretty >> complicated and might be hard to understand at first glance. On the other >> hand, code prepared to use with Bison and Flex looks more clear and I >> believe we should go that way. What is your opinion? >> >> To achieve goal ( >> http://community.kde.org/GSoC/2013/Ideas#Project:_A_.22real.22_query_parser_and_Query_Builder_Widget), >> we will need two parsers. One for checking and parsing completed query to >> SPARQL request and another for checking correctness in not finished query. >> If not finished query is correct, it will be compiled to more general >> request (for example, query ending with "hastag:" will be compiled to >> something like "get all tags considering earlier part of query"). I'll try >> to show you how I imagine process of parsing single query. >> >> First, all query extensions (localized words like "music", "yesterday", >> date and time), will be mapped in traditional way, by just replacing >> strings in query. >> >> Second, query will be checked by parser which will show whether it is >> already completed or not. If it's not, but it's, let's say, semi-completed, >> a mechanism will provide a avaliable list of keywords. For example a >> semi-completed query may be "hastag:" and provided autocomplete list will >> contain all of available tags. If query is more specific, autocomplete will >> also include it. >> >> Lastly, finished query will be parsed and compiled into SPARQL request. >> Existing parsing errors might be shown to user as suggestions and... that's >> all :) The most difficult part of this task will probably be grammar >> creation and optimization of autocomplete mechanism to provide fast and not >> much cpu-consuming hints. >> >> You have much more deep knowledge and experience in the use of Nepomuk, >> could you tell me what is your opinion? Or maybe for some reason, some >> parts of my idea may not work as expected? I realize this description is >> very general, I'd be very happy to write it in more details :) >> >> Have a nice day, >> >> Lukasz >> > >
_______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
