The Nepomuk Meta Data Library

Overview | Using | Examples | Desktop Ontologies | Resource Generator

This is the KDE Meta Data library (not to confuse with KFileMetaData). It consists of the following parts:

• The main resource handling centered around Nepomuk::Resource
• The handling of ontologies via classes in the Nepomuk::Types namespace
• The desktop Nepomuk::Query API
• The Facet API
• Several utility methods and classes

The General Idea

Three types of meta data can be identified:

1. 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.
2. Meta data that is created by the user manually like annotations or tags that are assigned to files, emails, or whatever resources.
3. 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 The Desktop Ontologies).

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 Using Nepomuk on how Nepomuk handles literals and cardinalities greater than 1.

Further Reading

• The Desktop Ontologies
• Using Nepomuk
• Nepomuk Examples
• The Nepomuk Resource Generator
• The Nepomuk techbase tutorials

Author(s):

Sebastian Trueg <trueg.nosp@m.@kde.nosp@m..org>

Maintainer(s):

Sebastian Trueg <trueg.nosp@m.@kde.nosp@m..org>

License(s):

LGPLv2