[Nepomuk] Query parser - idea.

[Łukasz Olender]

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 <lukiasz at gmail.com>

> 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 <lukiasz at gmail.com>
>
>> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20130424/0a991458/attachment.html>