[Nepomuk] Search Problems cause of annoying ontologies

[Vishesh Handa]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20121218/1391ec4a/attachment.html>