[Nepomuk] Search Problems cause of annoying ontologies

[Vishesh Handa]

On Tue, Dec 18, 2012 at 9:30 PM, Sebastian Trüg <sebastian at 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 at kde.org
>> https://mail.kde.org/mailman/**listinfo/nepomuk<https://mail.kde.org/mailman/listinfo/nepomuk>
>>
>>  ______________________________**_________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/**listinfo/nepomuk<https://mail.kde.org/mailman/listinfo/nepomuk>
>



-- 
Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20121219/fabbb5e4/attachment-0001.html>