[Nepomuk] Search Problems cause of annoying ontologies
Sebastian Trüg
trueg at kde.org
Thu Jan 3 09:47:10 UTC 2013
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üg <sebastian at trueg.de
> <mailto: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 <mailto: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 <mailto:Nepomuk at kde.org>
> https://mail.kde.org/mailman/__listinfo/nepomuk
> <https://mail.kde.org/mailman/listinfo/nepomuk>
>
>
>
>
> --
> Vishesh Handa
>
>
>
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
>
More information about the Nepomuk
mailing list