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