[prev in list] [next in list] [prev in thread] [next in thread]
List: nepomuk
Subject: Re: [Nepomuk] Search Problems cause of annoying ontologies
From: Vishesh Handa <me () vhanda ! in>
Date: 2012-12-18 19:42:54
Message-ID: CAOPTMKAAi3ZuMUO3YUCXWdV48cNZ1OL6JWSMwJ2p4Vp8b4gdRA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Tue, Dec 18, 2012 at 9:30 PM, Sebastian Trüg <sebastian@trueg.de> wrote:
> Maybe one: use mailto: addresses for the EmailAddress resources and let
> Akonadi use those instead of the additional properties.
Can't. Virtuoso doesn't index resource uris in the full text index.
>
>
> On 12/18/2012 12:45 PM, Vishesh Handa wrote:
>
>> Hey everyone
>>
>> In Akonadi, they have a very common problem where they need to do a full
>> text search across a number of properties and find the associated contact.
>>
>> The properties are -
>> * nco:fullname
>> * nco:nameGiven
>> * nco:nameFamily
>> * nco:emailAddress
>>
>> The problem is obviously that a nco:PersonContact unfortunately cannot
>> have a nco:emailAddress. The EmailAddress must be a resource which then
>> has the property nco:emailAddress which contains the email.
>>
>> Theoretically this makes a lot of sense cause an EmailAddress is a
>> nco:ContactMedium. So one could write a query to iterate all the
>> possible ways to contact a query, and one would get the email id.
>>
>> Practically, this sucks. Cause the query requires an extra join + union
>> and gets slowed down significantly.
>>
>> select distinct ?r where {
>> {
>> ?r ?p ?o .
>> FILTER( ?p in (nco:nameGiven, nco:fullname, nco:nameFamily) ) .
>> ?o bif:contains "whatever" .
>> }
>> UNION
>> {
>> ?r nco:hasEmailAddress ?e .
>> ?e bif:contains "whatever" .
>> }
>>
>> This is a general problem all across Nepomuk where the ontologies (like
>> a db schema) are fully normalized, and hence require one extra traversal
>> to go to that object and get its property. In virtuoso this amounts to
>> an extra join.
>>
>> Another example is searching for a song given its album, name, and
>> artist's name. The query is horrible and takes over 18 seconds on my
>> system (yeah, we are horrible at our main job - searching).
>> Unfortunately, in this case we have a proper reason for splitting the
>> data. In the Akonadi case there isn't much of reason.
>>
>> My suggestion to fix the Akonadi problem is either relaxing the
>> condition for nco:emailAddress or double typing the nco:PersonContact
>> as an nco:EmailAddress. Both of which are very ugly.
>>
>> Does anyone else have a good solution?
>>
>> --
>> Vishesh Handa
>>
>>
>>
>> ______________________________**_________________
>> Nepomuk mailing list
>> Nepomuk@kde.org
>> https://mail.kde.org/mailman/**listinfo/nepomuk<https://mail.kde.org/mailman/listinfo/nepomuk>
>>
>> ______________________________**_________________
> Nepomuk mailing list
> Nepomuk@kde.org
> https://mail.kde.org/mailman/**listinfo/nepomuk<https://mail.kde.org/mailman/listinfo/nepomuk>
>
--
Vishesh Handa
[Attachment #5 (text/html)]
<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>
_______________________________________________
Nepomuk mailing list
Nepomuk@kde.org
https://mail.kde.org/mailman/listinfo/nepomuk
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic