[Nepomuk] Bangarang player media library

Evgeny Egorochkin phreedom.stdin at gmail.com
Mon Feb 1 23:51:47 CET 2010


В сообщении от Понедельник 01 февраля 2010 22:13:52 автор Sebastian Trueg 
написал:
> Jamboarder wrote:
> >> ... It is just that we try to keep data that can be extracted from files
> >> separate from the rest, i.e. have it in one graph which can easily be
> >> removed and recreated. That is what the Strigi indexer service does.
> >> ...
> >> Resource::setProperty overwrites any existing triple with
> >
> > that
> >
> >> subject/property pair.
> >
> > Ahh.  I think I see now... So if Bangarang creates the data in nepomuk
> > before Strigi does, Strigi may subsequently create a separate index graph
> > containing the same extractable data.  If Strigi creates it first then
> > Bangarang updates the existing data.
> 
> exactly. Although I don't see a very big problem with that atm.

This is a problem for metadata backup, migration and sharing tools. These need 
to know which data is generated by the user.

Say I have some xesam properties generated by bangarang in my database. I'll 
have to remove these by hand sometime soon and I'm lucky because I can easily 
identify these by ontology. If the changes were more subtle, I'd have troubles 
with upgrades, while file indexer-provided data is easily identifiable. Also, 
having 2 alternative implementations of essentially the same functionality 
sucks.

> >> The Strigi service does create the one graph which is
> >> marked as the index graph for that particular file[1]. This graph
> >> contains only data that can be recreated by re-indexing the file. So in
> >> theory Bangarang would need to add its own graph with data only
> >> extracted from the file. But then we need to sync that data. If we were
> >> to put it in the same graph that is used by Strigi then Strigi would
> >> delete that data again on update. Also not a perfect solution. But maybe
> >> better since media files almost never change....
> >
> > Perhaps another work-around could be for apps working with file resources
> > in nepomuk to always give Strigi a chance to create the nepomuk data
> > first.  Bangarang could ask Strigi to index any file it opens. After that
> > it can continue to work as it currrently does: Updating existing triples,
> > adding new triples for custom metadata (Strigi shouldn't delete these on
> > re-indexing right?)  Longer term we could work on the plugin issue for
> > extending strigi indexing capabilities.
> 
> The Strigi service already has a DBus interface for that. If it is not
> enough it should be easy to extend.

Not surprised, but it's you who can provide the necessary details ;)

> But to be honest: the way Bangarang does it atm is not at all bad.

I didn't say it's bad. But if Bangarang has to implement its own file indexing 
service, it means that something's broken on the nepomuk side. This is what 
I'm trying to address.

> The video meta data cannot be created by Strigi anyway.

I think it's a matter of days now.

> And as far as audio meta data is concerned taglib information is either 
similar to what Strigi extracts or better.

At this moment, the audio formats that libstreamanalyzer supports, are very 
detailed and as detailed as taglib can get. Taglib supports more formats than 
libstreamanalyzer.

-- 
Evgeny


More information about the Nepomuk mailing list