KDE 4.1 PyKDE API Reference
nepomuk Module
The Nepomuk Meta Data Library
Overview | hacking "Using" | examples "Examples" | page_ontology "Desktop Ontologies" | nepomuk-rcgen "Resource Generator"
This is the KDE Meta Data library (not to confuse with KFileMetaData).
- Warning:
- The Nepomuk API may be subject to change before the release of KDE 4.1. Using these classes in applications that are part of the KDE core packages is no problem at all; API changes will be merged in quickly. However, if you intend to use this API in external applications please be aware that your application might stop working with KDE 4.1. Changes to the API will be announced on the kde-core mailing list.
The General Idea
Three types of meta data can be identified:
- Meta data that is stored with the data itself and is available at all times. This includes id3 tags, the number of pages in a pdf document, or even the size of a file or the subject of an email.
- Meta data that is created by the user manually like annotations or tags that are assigned to files, emails, or whatever resources.
- Meta data that can be gathered automatically by applications such as the source of a downloaded file or the email an attachment was saved from or the original when copying a file locally.
Type 1 is already handled in many implementations. KDE itself includes the KMetaFileInfo classes that allow extracting this kind of meta information from files and the Strigi system even creates a searchable index of this information.
Nepomuk is intended for meta data of type 2 and 3. It provides an easy way to create and read meta data for arbitrary resources (this includes for example files or emails, but also contacts or maybe even a paragraph in a pdf file).
The simplest type of meta data that can be handled with Nepomuk is a comment. It is a simple string associated with a resource (a file for example). This comment is created by the user using an application that is based on Nepomuk.
Nepomuk's core is designed to allow arbitrary types of meta data, i.e. any resource can be related with any other resource or value by simply naming the relation and providing the value. The power of Nepomuk, however, lies in that it provides a class for each type of resource. Each of these classes provide convenience methods to allow a simple handling of the meta data. These classes are automatically generated from a description of types and properties, i.e. an ontology (see page_ontology).
Nepomuk is resource based. Thus, working with Nepomuk is always done with instances representing a certain resource. This resource has a list of properties. Properties are named and have a certain type. The type can either be another resource (compare a file that was an attachment from an email) or a literal (this means for example a string, or an integer; the comment mentioned earlier would be a string literal). Each property can either have a cardinality of 1 (again a file can only be saved from one email) or greater than 1 (i.e. infinite, like one file can have arbitrary many associated comments). See hacking on how Nepomuk handles literals and cardinalities greater than 1.
Further Reading
- page_ontology - hacking - examples - nepomuk-rcgen
- Author(s):
- Sebastian Trueg <trueg@kde.org>
- Maintainer(s):
- Sebastian Trueg <trueg@kde.org>
- License(s):
- LGPLv2
Namespaces
| G | N | Nepomuk.Types |
| global | Nepomuk |
