[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]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic