Bug 225533 - Digikam does not read metadata from Nepomuk
Summary: Digikam does not read metadata from Nepomuk
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Database-Baloo (show other bugs)
Version: 1.1.0
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-04 19:12 UTC by Petr Zmek
Modified: 2017-07-19 13:57 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In: 1.3.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Zmek 2010-02-04 19:12:09 UTC
Version:            (using KDE 4.4.0)
OS:                Linux
Installed from:    Fedora RPMs

After enabling reading/writing metadata to Nepomuk in Digikam settings and restarting KDE Digikam can send information to nepomuk (I can see in Dolphin tags, ratings and comments made in Digikam), but can not read changed or new metadata made in Dolphin, neither after restarting application.

I have not allowed writting metadata to exif.

Digikam 1.1.0 using KDE4.4 RC3 on Fedora12 64bit.
Comment 1 Mahendra Tallur 2010-03-05 15:42:05 UTC
I can confirm this behaviour here (Archlinux + KDE SC 4.4.1).
Comment 2 Marcel Wiesweg 2010-03-06 14:45:39 UTC
I have been contacted by Sebastian Trueg a few weeks ago, Nepomuk ontologies have changed. Maybe digikam is reading the old one and Dolphin writes to the new one. I need to have a look at this.
Comment 3 Marcel Wiesweg 2010-04-02 14:58:23 UTC
SVN commit 1110223 by mwiesweg:

Use NIE/NFO namespace instead of Xesam.
Please complain if it does not build with KDE4.3.
Need to test if bug is fixed.

CCBUG: 225533

 M  +4 -0      digikam/CMakeLists.txt  
 M  +12 -10    utilities/nepomuk/digikamnepomukservice.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1110223
Comment 4 caulier.gilles 2010-04-02 18:56:23 UTC
Marcel,

with this commit, i can see this error now :

-- Configuring done
CMake Error in digikam/digikam/CMakeLists.txt:
  Cannot find source file "nie.trig".  Tried extensions .c .C .c++ .cc .cpp
  .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx


CMake Error in digikam/digikam/CMakeLists.txt:
  Cannot find source file "nfo.trig".  Tried extensions .c .C .c++ .cc .cpp
  .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx


-- Generating done
-- Build files have been written to: /mnt/data/devel/SVN/trunk/graphics
make: *** [cmake_check_build_system] Erreur 1

Gilles
Comment 5 Marcel Wiesweg 2010-04-02 22:38:50 UTC
Which KDE version? Do you have the shared ontologies installed?
/usr/share/ontology/nie/nie.trig
I'm not quite sure from which version on they are required by kdelibs.
Comment 6 caulier.gilles 2010-04-03 12:06:59 UTC
KDE 4.3.2, from Mandriva 2010.0

/usr/share/ontology/ dir do not exist there.

Gilles
Comment 7 Marcel Wiesweg 2010-04-03 16:38:34 UTC
SVN commit 1110532 by mwiesweg:

For Nepomuk support, require KDE 4.4 and shared-desktop-ontologies (which
are required by kdebase-4.4 anyway)

CCBUG: 225533

 M  +19 -6     CMakeLists.txt  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1110532
Comment 8 Marcel Wiesweg 2010-04-30 19:39:34 UTC
SVN commit 1119858 by mwiesweg:

- fix two bugs introduced by the silent semantic API changes in Nepomuk:
  With the switch from file:// to nepomuk://res URIs, we must not pass FileDataObject
  as the second parameter to Nepomuk::Resource, if we want to retrieve the nepomuk: URI.
  When removing a tag property, we must pass the resourceURI of the tag, not the
  Resource object itself.
- use TagsCache, remove own caching
- Fix reading of db parameters, as changed recently for MySQL port

 M  +29 -78    digikamnepomukservice.cpp  
 M  +0 -3      digikamnepomukservice.h
Comment 9 Marcel Wiesweg 2010-04-30 19:44:44 UTC
I have just successfully tested synchronization of tags and rating in both directions. There have been indeed three or four independent problems, and KDE4.4 is required for Nepomuk support now.

There is one possible problem left: Originally, Nepomuk used file:// URLs for files, since 4.4 it uses nepomuk://res/ URLs with a UUID. The digikam service continued to use file:// URLs and continued to add these to the database, because the API changed silently and semantically underneath.
Now you may still have these entries in your db, the effects of which are unknown to me. I deleted my Nepomuk storage first...
But in any case, handling this migration is well out of digikam's scope, it's up to Nepomuk and libnepomuk.