<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Dec 18, 2012 at 9:30 PM, Sebastian Trüg <span dir="ltr"><<a href="mailto:sebastian@trueg.de" target="_blank">sebastian@trueg.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Maybe one: use mailto: addresses for the EmailAddress resources and let Akonadi use those instead of the additional properties.</blockquote>
<div><br></div><div>Can't. Virtuoso doesn't index resource uris in the full text index. <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<br>
<br>
On 12/18/2012 12:45 PM, Vishesh Handa wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
Hey everyone<br>
<br>
In Akonadi, they have a very common problem where they need to do a full<br>
text search across a number of properties and find the associated contact.<br>
<br>
The properties are -<br>
* nco:fullname<br>
* nco:nameGiven<br>
* nco:nameFamily<br>
* nco:emailAddress<br>
<br>
The problem is obviously that a nco:PersonContact unfortunately cannot<br>
have a nco:emailAddress. The EmailAddress must be a resource which then<br>
has the property nco:emailAddress which contains the email.<br>
<br>
Theoretically this makes a lot of sense cause an EmailAddress is a<br>
nco:ContactMedium. So one could write a query to iterate all the<br>
possible ways to contact a query, and one would get the email id.<br>
<br>
Practically, this sucks. Cause the query requires an extra join + union<br>
and gets slowed down significantly.<br>
<br>
select distinct ?r where {<br>
{<br>
    ?r ?p ?o .<br>
    FILTER( ?p in (nco:nameGiven, nco:fullname, nco:nameFamily)  ) .<br>
    ?o bif:contains "whatever" .<br>
}<br>
UNION<br>
{<br>
    ?r nco:hasEmailAddress ?e .<br>
    ?e bif:contains "whatever" .<br>
}<br>
<br>
This is a general problem all across Nepomuk where the ontologies (like<br>
a db schema) are fully normalized, and hence require one extra traversal<br>
to go to that object and get its property. In virtuoso this amounts to<br>
an extra join.<br>
<br>
Another example is searching for a song given its album, name, and<br>
artist's name. The query is horrible and takes over 18 seconds on my<br>
system (yeah, we are horrible at our main job - searching).<br>
Unfortunately, in this case we have a proper reason for splitting the<br>
data. In the Akonadi case there isn't much of reason.<br>
<br>
My suggestion to fix the Akonadi problem is either relaxing the<br>
condition for nco:emailAddress  or double typing the nco:PersonContact<br>
as an nco:EmailAddress. Both of which are very ugly.<br>
<br>
Does anyone else have a good solution?<br>
<br>
--<br>
Vishesh Handa<br>
<br>
<br>
<br></div></div>
______________________________<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>
</blockquote>
______________________________<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>
</blockquote></div><br><br clear="all"><br>-- <br><span style="color:rgb(192,192,192)">Vishesh Handa</span><br><br>
</div></div>