[Nepomuk] Search Problems cause of annoying ontologies

[Sebastian Trüg]

Maybe one: use mailto: addresses for the EmailAddress resources and let 
Akonadi use those instead of the additional properties.

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
>