Nepomuk collection plans

[Daniel Winter]

Hello,

I had a talk with Sebastian Trüg today about some issues with the Nepomuk 
collection. "very slow filtering" mainly

We come to the conclusion that introducing artists, albums and track resources 
in Nepomuk would be the best solution. In the longterm that would be the best 
anyway. 

To explain: 

At the moment Amarok uses the data from strigi. So the resources in Nepomuk 
are files.  (their resource uri is the path in the filesystem).  

So every song is a file.  When i need a list of all artists fpr example I query 
then distinct for all artists from all files.  That is quite slow and really 
slow when I need to filter. For example only all artists which have "foo" in 
their name. That takes about 10 seconds on my pc.

Every data is linked directly to files.  But in the real word it is different. 
For example a cover is a attribute of the album and not the file. Or the 
release year is often an attribute of the album not the files.

So the plan is to create resource types for artists, albums and tracks in 
Nepomuk. 

The tracks would then link to the files which represents them. In theory a 
track could even have two files linked to it (one in high and one in low 
quality (for mobile player) for example) .  Albums link to tracks, and Artists 
links to albums or tracks. 

That looks more clean and allows faster querys. And is more extensible in the 
long term.

There are also problems with that though.  Someone has to create this artist, 
album, track resources out of the data from strigi and also to keep them in 
sync.

For that I will write a nepomukservice which will do just that. So basically 
it makes sure that the information of all mediadata ( i think it should 
support video too) is always there in Nepomuk in a good structered way, 
accessible in an easy way to media players or tagging applications and so on. 

That would also mean to create or adapt an ontology for the data.

Hopefully that service will then get into kdebase as part of nepomuk. 


What does that mean for Amarok?

The nepomuk collection will be easier to do.  

But it also means I will work on Nepomuk the next time. I will make the 
changes to the Nepomuk collection to use the new data structures and services 
after that (new query-service for example). (and use Amarok to test it)

That probably also means the nepomuk collection will not be ready at the end 
of the summer of code. And  as this service will not be in KDE before 4.2, 
nepomuk collection can not be used with 4.1. My plan is it to include it with 
the first Amarok 2 release after KDE 4.2.

But I believe strigis indexer is not yet ready in KDE 4.1 anyway. 

I hope you agree with that plan.