В сообщении от Воскресенье 31 января 2010 19:12:32 автор Jamboarder написал: > Thanks much for the heads up Evgeny. > > > From: Evgeny Egorochkin > > I have uncovered another issue with Bangarang, It seems to have it's own > > media library scanner and metadata extractor which also marks song > > metadata as user- created, and not automatically generated. > > Bangarang doesn't really have an explicit media scanner function. It just > updates nepomuk whenever a file with extractable metadata is opened or > when a user updates metadata for a media resource.
This is what I meant. That it adds media metadata generated from tags on occasion. > It uses the methods > (setProperty, addType and setTypes) of Nepomuk::Resource to set/update > data. Am I using the api incorrectly? Not really incorectly. However, it conflicts with nepomuks file indexer which adds another copy of metadata extracted from tags. > > A much better solution would be to tell nepomuk which files to index and > > add any of you custom data extractors into libstreamanalyzer or at least > > refactor them as libstreamanalyzer plugins. > > Sounds good. That makes sense for metadata that is techinically extractable > from the file itself. This is what I'm talking about. > Since there's quite a lot of metadata that may or > may not be extractable there will still be a need for Bangarang to > maintain the in-context update of the nepomuk resource. You're handling user-generated metadata just fine. > At the moment, when updating nepomuk data, Bangarang doesn't distinguish between techinically extractable file metadata and non-extractable metadata. > Video > metadata is the prime example. The entirety of the the video metadata in > Bangarang right now is user created. I hope to add some support of video > file metadata formats in the 2.0 version. I like the idea of refactoring > the file metadata extractors as libstreamanalyser plugins, but I'll still > need to maintain functionality for in-context user-created metadata that > is not technically extractable. > > > You would get the same or better functionality, contribute to nepomuk and > > avoid lots of pitfalls like your custom extractors and file indexing > > service adding what essentially is 2 copies of the same data. > > That seems a little odd. Does that mean a duplicate triple for the same > resource is created when setProperty is called on an existing resource > property? Not at all. Ontology allows you to specify several performers/artists for media, which is fine, unless 2 different services create their own copy of performer metadata. > I can kinda see the reasoning for setting it to user-created but > it seams like it shouldn't duplicate it. Is there anyway for an app to > just update the automatically generated triples since, whether strigi or > Bangarang or any other app does it, the data is still automatically > generated from the file metadata. I think we need to add such an API call to nepomuk. > In the short term I'd like to sort out this duplicate issue as a potential > bugfix. We'd need Sebastian Trueg's input on how to handle this the best way. > Then, if it still makes sense, in the medium term (version 2.0) > I'd like to try for the libstreamanalyser solution. I think it will be easier for you as I'm planning a major media overhaul... so maybe it will take no effort on your part at all :) > > I can help you with strigi part, and I hope Sebastian can find a way to > > let Bangarang extend the media collection via some nepomuk API call. > > Thanks much Evgeny. A quick first thought is that since a > libstreamanalyser plugin would result in a split in the code path for > writing to nepomuk in Bangarang, to keep the user feedback consistent I'll > probably need some progress feedback. Does that already exist? I hope to have Sebastian's input on this too... > Also, probably a silly question but can the plugin be delivered at app install time? Or does it have to be delivered at strigi install time? You can add your plugins anytime. -- Evgeny _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
