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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://mail.kde.org/mailman/__listinfo/nepomuk
<https://mail.kde.org/mailman/listinfo/nepomuk>
_________________________________________________
Nepomuk mailing list
[email protected] <mailto:[email protected]>
https://mail.kde.org/mailman/__listinfo/nepomuk
<https://mail.kde.org/mailman/listinfo/nepomuk>
--
Vishesh Handa
_______________________________________________
Nepomuk mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/nepomuk
_______________________________________________
Nepomuk mailing list
[email protected]
https://mail.kde.org/mailman/listinfo/nepomuk
