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
