The Nepomuk development is split across many different repositories across KDE. The page attempts to list out most of the known Nepomuk code, and its development location. The list has been split according to importance.
These are the official repositories which the core Nepomuk team focuses on.
NepomukCore, which is the main repository for Nepomuk development, was released with KDE 4.9. It is a combination of both the Nepomuk libraries present in kdelibs, and certain run time components present in kde-runtime.
All Nepomuk enabled applications must depend on NepomukCore. It utilizes the Nepomuk2 namespace.
For a brief introduction on kioslaves, please read this.
Nepomuk currently consists of 3 kio-slaves - nepomuk, nepomuksearch, and timeline. Out of these 3, nepomuksearch and timeline are the most visible. The nepomuk kioslave is an internal kioslave which redirects to the nepomuksearch kioslave.
Nepomuk consists of 2 main user visible components. The Nepomuk KCM and the controller, which is uses to pause/resume indexing. The plan is to eventually move these out of kde-runtime, but that will probably only happen with KDE Frameworks 5.
Nepomuk provides some simple widgets which are use across various applications. The most notable ones are the tagging, and rating widgets. This code is fairly old and needs to be ported to Nepomuk2.
Current repository which shouldn't be used kdelibs/nepomuk/ui. It should ideally be moved to a separate repository called nepomuk-ui-widgets. This is a blocker for porting Dolphin, PIM and Gwenview to Nepomuk2.
Nepomuk consists of a development tool called 'nepomukshell' which can be used to browse the Nepomuk database, and to run SPARQL queries.
Soprano provides a Qt based wrapper over virtuoso, and additional serializing and parsing features which are used to load the ontologies. It follows an independent release schedule.
The Strigi project provides libraries to extract metadata from file. The project is divided into 5 sub-proejcts. Nepomuk only requires libstreams and libstreamanalyzer.
The overall development of Strigi has been stagnant for a couple of years now. However there are no viable alternatives present. And the cost of moving would be risking stability.
Strigi requires a lot of work where all the file formats can be listed, and the compatibility for every file can be checked.
From KDE/4.7, Nepomuk has started enforcing the ontologies - Either the data follows the ontologies or it is rejected. Since this move many bugs and inconsistencies have come to light. Unfortunately, while earlier they were just an minor inconvenience to the user, now those files are not indexed.