<div dir="ltr"><br><div class="gmail_extra">Hey Sebastian<br><br>Nice to hear from you<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 9, 2013 at 5:57 PM, Sebastian Trüg <span dir="ltr"><<a href="mailto:trueg@kde.org" target="_blank">trueg@kde.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Virtuoso actually has support for indexing plug-ins. I did not look into this in depth yet but it would even be possible to plug in an external index like clucene and use it from within the query engine.<br>
</blockquote><div><br></div><div>That would be nice, but I'm scared it is going to be a lot of effort. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br>
This, however, is a bit more involved. As a first step it might be worthwhile to look into the improvements that could be achieved by simply customizing the full text index in a way that<br>
1. allows to query all relevant fields in one statement<br>
2. still keep context information<br></blockquote><div><br></div><div>Could you elaborate? I'm not sure what you mean by either of those.<br><br></div><div>By (1) do you mean that we don't use expressions such as ?r ?p ?o. and instead specify the property? Cause we could do rdfs:label instead like you used to in literalterm.cpp, but this bug [1] is blocking it.<br>
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I will, however, have to research this further to know the extend of work required to get to that point. Might be rather simple, might be harder.<br>
<br></blockquote><div>I don't have much time. I need to fix full text searching by 4.11 and 4.11 has it's freeze in about a month.<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

Cheers,<br>
Sebastian<div><div class="h5"><br></div></div></blockquote><div><br>[1] <a href="https://sourceforge.net/tracker/?func=detail&aid=3591024&group_id=161622&atid=820574">https://sourceforge.net/tracker/?func=detail&aid=3591024&group_id=161622&atid=820574</a><br>
 <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="h5">
<br>
On 05/04/2013 03:40 PM, Christian Mollekopf wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="h5">
On Saturday 04 May 2013 18.49:05 Vishesh Handa wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hey guys<br>
<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I was thinking of moving all the plain text related to a file into the<br>
nie:plainTextContent of the resource. So in the case of music we would have<br>
-<br>
<br>
<res> nie:plainTextContent "title artist album whatevereElse" .<br>
<br>
for the case of files, we would append the file name, and any other plain<br>
text that we want searched just in the nie:plainTextConent. So a search for<br>
any combination of text will just have to search through the plain text<br>
content.<br>
<br>
Opinions?<br>
</blockquote>
<br>
Hey Vishesh,<br>
<br>
I think that's a good idea. We're also already using it that way to be able to<br>
search through emails with markup in the email feeder, and I see no reason why<br>
we can't extend that to other resource types (after all the property is<br>
exactly for this purpose).<br>
So that means, in the future all feeders should push all information which<br>
should be matched by full text searching to nie:plainTextContent, right?<br>
<br>
The alternative would of course be to use a separate dedicated fulltext index,<br>
which may have better performance, some more features (tokenizer, stemming<br>
etc.), but would obviously complicate the setup again (fulltext query => i.e.<br>
filter by type in nepomuk => retrieve akonadi item). So not necessarily the way<br>
to go, but I wanted to bring it on the table anyways as it's IMO not<br>
conflicting with what nepomuk provides (the semantic analysis), and could<br>
result in better results (performance and feature wise) than letting virtuoso<br>
doing all the work.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
We can easily do this for the 4.11 release cause we already need everyone<br>
to re-index everything cause of the migration.<br>
</blockquote>
<br>
Cool.<br>
<br>
Cheers,<br>
Christian<br></div></div><div class="im">
______________________________<u></u>_________________<br>
Nepomuk mailing list<br>
<a href="mailto:Nepomuk@kde.org" target="_blank">Nepomuk@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/nepomuk" target="_blank">https://mail.kde.org/mailman/<u></u>listinfo/nepomuk</a><br>
<br>
</div></blockquote><div class=""><div class="h5">
______________________________<u></u>_________________<br>
Nepomuk mailing list<br>
<a href="mailto:Nepomuk@kde.org" target="_blank">Nepomuk@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/nepomuk" target="_blank">https://mail.kde.org/mailman/<u></u>listinfo/nepomuk</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><span style="color:rgb(192,192,192)">Vishesh Handa</span><br>
</div></div>