RDF and Ontologies in Nepomuk

All ontologies discussed here are installed with the kdelibs. Thus, they are always in the Nepomuk store. In addition their resource URIs can easily be accessed through the Soprano::Vocabulary namespace.

RDF describes a way of storing data. While "classical" databases are based on tables RDF data consists on triples and only triples. Each triple, called statement consists of

subject - predicate - object

The subject is a resource, the predicate is a relation, and the object is either another resource or a literal value.
A literal can be a string or an integer or a double or any other type defined by XML Schema (actually it is even possible to define custom literal types).
Thus RDF can represent statements such as "Mary - is mother of - Carl", or "Mary - was born on - 1970-02-23". These are statements about things, hence RDF is a good technology for metadata.

To reduce ambiguity, resources and relations need to be uniquely identified; in the example statement above, to identify a particular "Mary", and also to distinguish the family relationship from "Baghdad - is mother of - all battles".
Since RDF was born as a web technology all resources and relations are identified by a URI, Uniform Resource Identifier. (Hence they have a namespace often ending in a # and a name. Typically abbreviation such as foo:bar are used.) Thus, a dataset in RDF is basically a graph where resources are the nodes, predicates the links, and literals act as leaves.

RDF defines one important default property: rdf:type which allows to assign a type to a resource.

RDFS defines a set of resources and properties extending RDF. This extension basically allows to define ontologies. RDFS defines the two important classes rdfs:Resource and rdfs:Class which introduces the distinction between instances and types, as well as properties to define type hierarchies: rdfs:subClassOf and rdfs:subPropertyOf, and rdfs:domain and rdfs:range to specify details when defining properties.

This allows to create new classes and properties much like in object oriented programming. For example:

A simple example of how to define an ontology in RDFS (using the Turtle language). The last two important predicates in RDFS are rdfs:label and rdfs:comment which define human readable names and comments for any resource.

NRL was developed in Nepomuk to further extend on RDFS. I will not go into detail and explain everything about NRL but keep to what is important with respect to KDE at the moment.

Most importantly NRL changes triples to quadruples where the fourth "parameter" is another resource defining the graph in which the statement is stored (may be empty which means to store in the "default graph"). This graph (or context as it is called in Soprano) is just another resource which groups a set of statements and allows to "attach" information to this set. NRL defines a set of graph types of which two are important here: nrl:InstanceBase and nrl:Ontology. The first one defines graphs that contain instances and the second one, well you guessed it, defines graphs that contain types and predicates.

NAO already defines resource types and properties you already encountered in KDE: nao:Tag or nao:rating. But it also defines nao:created which is a property that assigns an xls:dateTime literal to a resource, in our case a graph. This way we store information about when a piece of information was inserted into the Nepomuk repository.

Xesam is an ontology that has been developed in regards to desktop file indexing tools such as Strigi. It tries to define classes/types and properties for most of the metadata that occurs in files on the desktop. Simple examples include id3 tags or image size or even email data such as sender or recipient.
File Metadata indexed by Strigi on the KDE desktop is stored in the Nepomuk repository using Xesam classes and properties.

Other/Custom Ontologies

The ontologies mentioned here form the basis of the data in Nepomuk bu they cannot describe every aspect necessary. If you want to store your own data in Nepomuk and link it with other information it is recommended to follow the following process:

Check if the standard ontologies provide the classes and properties you need (or some of them)