Tracker Ontology Reference Manual: Nepomuk Information Element (NIE): Top classes in the ontology. Almost everything else is subclass of these.

## Nepomuk Information Element (NIE): Top classes in the ontology. Almost everything else is subclass of these.

Authors:
  - Ludger van Elst, DFKI, <elst@dfki.uni-kl.de>
  - Michael Sintek, DFKI, <michael.sintek@dfki.de>
  - Leo Sauermann, DFKI, <leo.sauermann@dfki.de>
  - Antoni Mylka, DFKI, <antoni.mylka@dfki.de>
Editors:
  - Antoni Mylka, DFKI, <antoni.mylka@dfki.de>
Contributors:
  - Christiaan Fluit, Aduna, <christiaan.fluit@aduna-software.com>
  - Evgeny 'phreedom' Egorochkin, KDE Strigi Developer, <stexx@mail.ru>
Upstream:

  Upstream version

ChangeLog:

  Tracker changes

Copyright:

  © 2007 DFKI © 2009 Nokia. The ontologies are made available under the terms of NEPOMUK software license (FIXME verify)

## Overview

### Introduction

The core of the NEPOMUK Information Element Ontology and the entire Ontology Framework revolves around the concepts of DataObject and InformationElement. They express the representation and content of a piece of data. Their specialized subclasses (defined in the other ontologies) can be used to classify a wide array of desktop resources and express them in RDF.

nie:DataObject class represents a bunch of bytes somwhere (local or remote), the physical entity that contain data. The meaning (intepretation) of that entity, the information for the user contained in those bytes (e.g. a music file, a picture) is represented on the nie:InformationElement side of the ontology.

Both sides are linked using the property nie:interpretedAs (and its reverse nie:isStoredAs), indicating the correspondence between the physical element and its interpretation. There is also a property to link nie:InformationElements, representing the logical containment between them (like a picture and its album).

#### Common properties

Given that the classes defined in this ontology are the superclasses for almost everything in the Nepomuk set of ontologies, the properties defined here will be inherited for a lot of classes. It is worth to comment few of them with special relevance:

nie:title | Title or name or short text describing the item
nie:description | More verbose comment about the element
nie:language | To specify the language of the item.
nie:plainTextContent | Just the raw content of the file, if it makes sense as text.
nie:generator | Software/Agent that set/produced the information.
nie:usageCounter | Count number of accesses to the information. It can be an indicator of relevance for advanced searches

#### Dates and timestamps representations

There are few important dates for the life-cycle of a resource. These dates are properties of the nie:InformationElement class, and inherited for its subclasses:

nie:informationElementDate | This is an ''abstract'' property that act as superproperty of the other dates. Don't use it directly.
nie:contentLastModified | Modification time of a resource. Usually the mtime of a local file, or information from the server for online resources.
nie:contentCreated | Creation time of the content. If the contents is created by an application, the same application should set the value of this property. Note that this property can be undefined for resources in the filesystem because the creation time is not available in the most common filesystem formats.
nie:contentAccessed | For resources coming from the filesystem, this is the usual access time to the file. For other kind of resources (online or virtual), the application accessing it should update its value.
nie:lastRefreshed | .

### URIs and full representation of a file

One of the most common resources in a desktop is a file. Given the split between Data Objects and Information Elements, some times it is not clear how a real file is represented into Nepomuk. Here are some indications:

1. Every file (local or remote) should generate one DataObject instance and an InformationElement instance.
2. Even when Data Objects and Information Elements are completely different things, for efficency reasons in Tracker we use the same URI for both of them.
3. The URI will be an autogenerated ID, and the real location of the item (e.g. ''file://path/to/file.mp3'') is a property of the Data Object
4. Every DataObject must have the property nie:url, that points to the location of the resource, and should be used by any program that wants to access it.
5. There is a deprecated property in the ontology: nie:isStoredAs . We discourage its use in the code: in the best case it is a loopback to the nie:url value, but in general it can contain any value or not be set at all.

Here comes an example, for the image file /home/user/a.jpeg:

    <urn:uuid:10293801928301293> a nmm:Photo, nfo:FileDataObject ;
    	# Properties as nmm:Photo
    	 nfo:width 49 ;
    	 nfo:height 36 ;
    	nmm:flash <nmm:flash-off>;
    	nmm:whiteBalance <nmm:white-balance-automatic> ;
    	nfo:equipment [ a nfo:Equipment ; nfo:make 'Nokia'; nfo:model 'N900'; nfo:equipmentSoftware 'Tracknon' ] ;

    	# Properties from nfo:FileDataObject
    	nfo:fileSize 12341234 ;

    	# Mandatory for any nfo:DataObject
    	nie:url <file:///home/ivan/test/CC-test-big.png> .

Figure 1. Graphical Overview

Notation defined in this page

### Related information

This explanation is just a brief extract from the original Nepomuk NIE Ontology web page.