[prev in list] [next in list] [prev in thread] [next in thread] 

List:       nepomuk
Subject:    Re: [Nepomuk] Search Problems cause of annoying ontologies
From:       Sebastian_Trüg <trueg () kde ! org>
Date:       2013-01-03 9:47:10
Message-ID: 50E5539E.5050405 () kde ! org
[Download RAW message or body]

well, one hacky solution would be to introduce a new property which =

stores email addresses directly on the personcontact. This would be =

added automatically for every EmailAddress resource.

On 12/18/2012 08:30 PM, Vishesh Handa wrote:
>
>
>
> On Tue, Dec 18, 2012 at 9:30 PM, Sebastian Tr=FCg <sebastian@trueg.de
> <mailto: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 <mailto:Nepomuk@kde.org>
>         https://mail.kde.org/mailman/__listinfo/nepomuk
>         <https://mail.kde.org/mailman/listinfo/nepomuk>
>
>     _________________________________________________
>     Nepomuk mailing list
>     Nepomuk@kde.org <mailto:Nepomuk@kde.org>
>     https://mail.kde.org/mailman/__listinfo/nepomuk
>     <https://mail.kde.org/mailman/listinfo/nepomuk>
>
>
>
>
> --
> Vishesh Handa
>
>
>
> _______________________________________________
> Nepomuk mailing list
> Nepomuk@kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
>
_______________________________________________
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]