NEPOMUK File Ontology

This document arose from the work of the Task-Force ontologies within the NEPOMUK project. This document is a DRAFT made available by the Nepomuk Consortium for discussion only. This document is a work in progress and may be updated, replaced, or rendered obsolete by other documents at any time.

This document is a part in a set of seven documents, which together comprise the complete specification of the Nepomuk Information Element Ontology Framework. These are: NIE, NFO, NCO, NMO, NCAL, NEXIF, NID3.

• Added
  • nfo:Placemark
  • nfo:PlacemarkContainer
  • nfo:containsPlacemark

Introduction

Nepomuk File Ontology (NFO) is one of the fundamental parts of NIE. It deals with files and other desktop resources. Files are understood as sequences of bytes stored in a Filesystem or on a Network. It provides subclasses both of a DataObject and an InformationElement. A basic hierarchy of FileDataObject subclasses is provided. It includes a 'normal' FileDataObject, that usually resides on a typical filesystem, but also allows for other kinds of files - those embedded in, or attached to other data items, as well as deleted and stored in a trash folder. This hierarchy is by no means complete. More complete taxonomies, that either add additional FileDataObject subclasses or extend ones provided in this ontology may appear in future.

FileDataObject

The cornerstone of the NFO is the FileDataObject class. It represents files - finite sequences of bytes available from some durable storage medium. This definition explicitly exludes streams (which are potentially infinite) but includes web documents and other resources resolvable via a URL. As mentioned before there are various types of files. They are reflected in the hierarchy of subclasses of the File class. This hierarchy is expected to grow when users add new types of files relevant to their work.

Folders and Compressed files

Each file on a hard disk is usually contained within a folder or a directory (the naming depends on the Operating System). They are represented by the Folder class. The containment relation can be expressed with the belongsToContainer property. Note that a Folder is an interpretation. It may be applied to a FileDataObject (representing a folder on a disk), but it can also be applied to an ArchiveItem (representing a folder inside an archive), or to a MailboxDataObject (representing a mail folder on an IMAP server).

Compressed Files are expressed with an Archive class. It is also an interpretation that may be applied to any piece of data. An important thing to note is that Nepomuk strives for data integration. It shouldn't make much difference if a file is within a normal folder or within an archive. That's why no special case is made for the fileUrl property for files in compressed archives. In both cases a file should be accessible with a URL. In case of stand-alone files this is simple. Unfortunately there are no standards defining the way to construct URL's for files inside compressed archives. We encourage applications to use conventions established by the Apache Virtual File System project. For cases when no URL can be constructed for a file (e.g. a picture inside an archive attached to an event in an outlook calendar) the entire containment tree needs to be examined to find ways for accessing a file.

Remote Resources

NFO includes basic vocabulary to describe remote resources. Its notion of a FileDataObject is universal. The fileUrl property can just as well be set to a http:// address. To facilitate processing a RemoteDataObject class has been introduced. Its purpose is to have a 'semantic' way of expressing the fact that an instance of a FileDataObject class actually refers to a remote resource. Otherwise the applications would have to check manually if the url begins with http://.

Examples

Example files that show how to use the expressive power of the ontology will be published here in near future.