[Kde-pim] Considerations for akonadi-nepomukfeeder update/rewrite

[Christian Mollekopf]

Since we will need to port the nepomukfeeders to the new DMS, and I rely  
on the feeders in MindMirror,
I'd like to discuss what we have to keep in mind during the rewrite.

First off, I think we can keep the structure of the feeder pretty much  
(codewise), we just replace all the manual soprano statements
with their equivalent in the SimpleResource api.
Currently the feeders create a new Context for every item, which is  
removed before every update. I'm not sure this is
still necessary with the new DMS, I reckon we can just create the  
resources once and then update their properties.
Vishesh or Sebastian should know how to do that properly.

Although we are currently not differentiating between the nie:dataobject  
and nie:informationelement classes (the created resource is basically  
both),
we only reflect the nie:informationelement part, which is probably still  
ok, as I can't think of a usecase for the dataobject part.
Also we could reflect the akonadi storage, or each specific akonadi-agent  
as a nie:datasource and link the created resources to it, which would make  
it again possible to see in nepomuk where the data comes from, and e.g. to  
remove all items which were created from the resource. This would also be  
a starting point for applications using nepomuk only, to display items  
 from a specific resource, allowing nepomuk to become effectively a wrapper  
of akonadi once the writeback from nepomuk is solved (which should be the  
long term goal IMHO).
Maybe some of you can think of a usecase, otherwise this wouldn't be  
needed atm.

Important is however that the feeder is the "owner" of this resource,  
meaning that it will also delete the resource again.
The applications should normally anyways work with the pimo:thing, and if  
they work with the nie:informationElement, they have to be aware that the
resource can vanish at any time.

For fulltext-indexing I propose that we set the nie:plainTextContent and  
nie:title properties on all resources.
Of course this will duplicate a lot of text, but here we set the text with  
all markup removed (at least nie:plainTextContent is especially for this  
usecase),
so fulltext search works also on richtext. It makes it also easy to create  
fulltext queries because one can only search for those two properties.

The last issue is, that the codepath which generates the resource should  
also be callable from userapplications (i.e. in an exported function).
If I e.g. create a new akonadi item, I wan't to tag it immediately after  
creation with the default tags. Since there is no guarantee that the
feeder already created a new resource for it, we might end up in situation  
where I created a different resource for the same item than the feeder.
So we need some  Nepomuk::SimpleResource getResource(Akonadi::Item);  
function, which returns us the resource, so we can get the Thing from it.
Actually I'm not sure if the SimpleResource api is better here as the  
Nepomuk::Resource api. (Vishesh, Sebastian?)

Summary:
-use SimpleResource api only
-nie:plaintextContent and nie:title for fulltext search
-function to get the resource from a userapplication.

Cheers,

Chris
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/