NIE - Nepomuk Information Element Ontology

Namespace: http://www.semanticdesktop.org/ontologies/2007/01/19/nie# (Version 0.9.0)

Authors:

Antoni Mylka

DFKI

Leo Sauermann

DFKI

Michael Sintek

DFKI

Ludger van Elst

DFKI

Maintainers:

Antoni Mylka

DFKI

Contributors:

Evgeny Egorochkin

KDE

Abstract

The Nepomuk Information Element Framework provides unified vocabulary for describing native resources available on the desktop. NIE itself contains of classes and properties that comprise the core part of the framework.

Table of Contents

Classes Overview
Properties Overview
Ontology Visualization
Introduction
Background
Overview of the Nepomuk ontology architecture
Basic design decisions
Use NEPOMUK Representational Language
Make NIE useful for the Semantic Desktop
Don't go beyond the intended scope of NIE
Allow for easy migration and conform to the standards
High-level overview of the NIE Framework
Data Objects
Information Elements
Data Sources
Guidelines for extending NIE
References
NIE Vocabulary Summary
Description of Classes
Description of Properties

Classes Overview

nie:DataObject - A unit of data that is created, annotated and processed on the user desktop. It ...
nie:DataSource - A superclass for all entities from which DataObjects can be extracted. Each enti...
nie:InformationElement - A unit of content the user works with. This is a superclass for all interpretati...

Properties Overview

nie:byteSize - The overall size of the data object in bytes. That means the space taken by the ...
nie:characterSet - Characterset in which the content of the InformationElement was created. Example...
nie:comment - A user comment about an InformationElement.
nie:contentCreated - The date of the content creation. This may not necessarily be equal to the date ...
nie:contentLastModified - The date of the last modification of the original content (not its corresponding...
nie:contentModified - The date of a modification of the original content (not its corresponding DataOb...
nie:contentSize - The size of the content. This property can be used whenever the size of the cont...
nie:copyright - Content copyright
nie:coreGraph (deprecated) - Connects the data object with the graph that contains information about it. Depr...
nie:created - Date of creation of the DataObject. Note that this date refers to the creation o...
nie:dataSource - Marks the provenance of a DataObject, what source does a data object come from.
nie:depends - Dependency relation. A piece of content depends on another piece of data in orde...
nie:description - A textual description of the resource. This property may be used for any metadat...
nie:disclaimer - A disclaimer
nie:generator - Software used to "generate" the contents. E.g. a word processor name.
nie:generatorOption - A common superproperty for all settings used by the generating software. This ma...
nie:hasLogicalPart - Generic property used to express 'logical' containment relationships between Inf...
nie:hasPart - Generic property used to express 'physical' containment relationships between Da...
nie:htmlContent - The HTML content of an information element. This property can be used to store t...
nie:identifier - An unambiguous reference to the InformationElement within a given context. Recom...
nie:informationElementDate - A point or period of time associated with an event in the lifecycle of an Inform...
nie:interpretedAs - Links the DataObject with the InformationElement it is interpreted as.
nie:isLogicalPartOf - Generic property used to express 'logical' containment relationships between Dat...
nie:isPartOf - Generic property used to express containment relationships between DataObjects. ...
nie:isStoredAs - Links the information element with the DataObject it is stored in.
nie:keyword - Adapted DublinCore: The topic of the content of the resource, as keyword. No sen...
nie:language - Language the InformationElement is expressed in. This property applies to the da...
nie:lastModified - Last modification date of the DataObject. Note that this date refers to the modi...
nie:lastRefreshed - Date when information about this data object was retrieved (for the first time) ...
nie:legal - A common superproperty for all properties that point at legal information about ...
nie:license - Terms and intellectual property rights licensing conditions.
nie:licenseType - The type of the license. Possible values for this field may include "GPL", "BSD"...
nie:links - A linking relation. A piece of content links/mentions a piece of data
nie:mimeType - The mime type of the resource, if available. Example: "text/plain". See http://w...
nie:modified - Date the DataObject was changed in any way. Note that this date refers to the m...
nie:plainTextContent - Plain-text representation of the content of a InformationElement with all markup...
nie:relatedTo - A common superproperty for all relations between a piece of content and other pi...
nie:rootElementOf - DataObjects extracted from a single data source are organized into a containment...
nie:subject - An overall topic of the content of a InformationElement
nie:title - Name given to an InformationElement
nie:url - URL of a DataObject. It points to the location of the object. A typial usage is ...
nie:version - The current version of the given data object. Exact semantics is unspecified at ...

Ontology Visualization

Figure 13. 


Introduction

Since the dawn of the Semantic Web much effort has been exercised to bring its power to the desktop. One of the most important parts of this aim is to leverage existing information sources and make them accessible to 'semantic' systems. This information is contained within various structures maintained by the operating system and a multitude of existing 'legacy' applications. These structures include files, messages, documents, pictures, calendar entries and contacts in addressbooks. Ludger van Elst coined the term `native structures' to describe them and 'native resources' for the pieces of information they contain.

A successful Semantic Desktop system cannot deny the existence of native structures. Dealing with them is an issue that needs to be tackled on every attempt to realize the Semantic Desktop vision. What follows is an account of the approach adopted within the NEPOMUK Social Semantic Desktop project, followed by the specification of the NEPOMUK Information Element Framework (NIE), vocabulary developed to express native structures in RDF.

Note that the abbreviation NIE may refer to the NIE Framework as a whole or to the NIE Ontology - the core part of the framework. In most cases the former meaning is used, unless explicitly stated otherwise.

Background

The problem is a difficult one given the multitude of applications and data formats. Previous semantic desktop projects (e.g. Haystack or Gnowsis) had to develop their solutions. Some attempts at standardization have been made (Adobe XMP or Freedesktop.org XESAM) but a definite standard hasn't emerged yet.

Apart from large metadata description frameworks there exists a considerable number of smaller single-purpose ontologies aimed at specific types of resources (e.g. ICALor VCARD). A broad array of utilities has been developed for extracting RDF metadata from desktop sources (see RDFizers website, for an overview).

Various problems have been identified with those ontologies. They are expressed in many languages, often aren't as detailed as one would like, sometimes contain outright bugs. NEPOMUK Information Element Framework is an attempt to build upon that experience, to provide unified vocabulary to describe typical native resources that may be of interest to the user. These resources are intended to serve as raw data for other semantic applications. They can be browsed, searched, annotated and linked with each other. It is hoped that this framework will help to achieve the critical mass of raw RDF data that will ignite rapid development of applications which will bring actual value to the user and make everyday work easier and more productive.

Overview of the Nepomuk ontology architecture

In order to justify the design decisions that were made when creating NIE, a short introduction on the ontology architecture of NEPOMUK is necessary. It can be conceptually divided in two tiers.

The lower one is the data tier. It stores the native data extracted from various data sources on the desktop. These include filesystems, mailboxes, calendars, and addressbooks. They are usually maintained by external applications, that are not part of NEPOMUK by themselves. The user still uses Kontact or MS Outlook for contacts and events, OpenOffice or Word for writing documents etc. The upper ontology layer is composed of concepts and instances that make up the Personal Information Model. They represent more abstract entities.

Native resources are extracted, converted to RDF and made available for Semantic Web software agents. An approach is to store converted RDF in a repository, making it queryable. Another approach is to adapt datasources dynamically, using virtual RDF graphs but in general, extraction and storing RDF in a queryable index is the common approach, also used by the other desktop search engines.

Data represented in NIE has three roles. First, NIE data is intended to be generated by an extraction process. Second, RDF-based systems can create NIE structures natively, without building on existing applications. Third, data expressed in NIE can be imported back to native applications. The ontology is therefore a mediator between semantic and native applications.

These roles explain some of the design decisions outlined below. They are a direct result of the following assumptions about the NEPOMUK architecture:

  • The 'PIMO' layer can much more easily work with native resources if they are expressed in a single language (see Use NEPOMUK Representational Language), using limited vocabulary (see Unification of ontologies), where similar entities are always expressed in the same way with the same vocabulary elements (see Integration of ontologies).

  • The task of dealing with dynamic nature of the native resources can be more easily tackled when it is divided into two subtasks :

    • synchronizing the 'real-life' with the data repository, that doesn't contain abstract concepts

    • synchronizing the data repository with the abstract concepts in the personal information model

    These subtasks can be assigned to different components that only need limited knowledge to perform them and can thus be much simpler.

The authors of this document believe that these assumptions would also hold for other semantic desktop systems.

Basic design decisions

Requirements stated above led to certain guidelines for the ontology design. The following sections contain a brief outline of them. This is by no means a sound and complete set of axioms that are always correct, but a set of factors that were taken into account. They are given in their perceived order of importance. Developers of ontologies that will extend NIE to describe new kinds of data are strongly encouraged to be consistent with them.

Use NEPOMUK Representational Language

NIE is expressed in the NEPOMUK Representational Language as defined in the recently published specification ([NRLSPEC]). This means, that whenever some existing ontologies are to be reused, they need to be adapted to NRL. Author's experience suggests that such an adaptation would usually entail following steps:

  1. Remove language constructs that are not present in RDFS. Some of them have their NRL equivalents (like FunctionalProperty or TransitiveProperty in OWL or Protege ontologies). Others don't (e.g. OWL unions or Protege overriding properties). If a construct has a NRL equivalent - it may be substituted. If not, then the information may be expressed in the, rdfs:comment or in the documentation.

  2. Create a new namespace for the new ontology, to distinguish between the original one and the new representation in NRL.

  3. Let all properties have concrete domains and ranges. Bring the ontology to a state where the data that conforms to it doesn't need to have any untyped nodes.

  4. Provide links with the original ontology (e.g. via rdfs:subClassOf or rdfs:subPropertyOf relationships) if possible.

  5. Examine the ontology for possibilities of alignment with existing NIE ontologies, in accordance with the Integration of ontologies guidelines.

This decision is fundamental in its nature. It could be interpreted as being against the spirit of reuse, pervasive in the Semantic Web community. It brings many benefits though. They include:

  1. Easier consistency checking. There are differences between semantics of various ontology languages. Some of them don't specify any constraints. (e.g. RDF/S domains and ranges aren't interpreted as constraints that have to be met, but as rules that entail facts. [RDFSEMANTICS]) Apart from that many well-established ontologies (like Dublin Core [DCSPEC], Kanzaki EXIF [EXIFRDF] or important parts of ICAL [ICALRDF] don't have the domains and ranges specified at all, so there is nothing to check.

  2. Simpler inference. An inferencer would have to reason over data that uses vocabulary from many ontologies in many languages.

  3. Explicit connections between ontologies. The application developer would need to be aware of the fact that an instance of a class from one ontology, might also be annotated with properties from some other ontology. This is important information, that is not expressed in the ontology itself.

  4. Unified ontology universe. Since the Personal Information Model would definitely be expressed in NRL - leaving the raw data described in its 'original' vocabulary would split the 'NEPOMUK universe' into two parts - one consistent, well checked, where inference is efficient and well-implemented - the part in NRL, and the chaotic, unchecked part in all possible languages.

  5. Easier data integration. Algorithms would need to have knowledge of multiple languages and differences in their semantics. Using single language removes this burden and paves the way for further benefits - described in the next section.

Make NIE useful for the Semantic Desktop

The main goal of the Semantic Desktop is to aid the user in his/her everyday tasks. In order to achieve this goal - the user wants to have a uniform view of all his/her data, where application boundaries are not important. This requirement is a very important one. It implies that wherever data with similar 'meaning' is stored or processed - it needs to be described using the same vocabulary. Having multiple disparate vocabularies for dealing with similar entities would make the task of data integration much more difficult. In the previous section we mentioned that differences between representational languages are to be avoided. Here we fortify that claim by saying that overlap between multiple ontologies in the same domain is also unadvisable.

This statement has two practical consequences. They are outlined below.

Unification of ontologies

In domains where there are many competing 'de facto standard' ontologies - for NIE either one of them is chosen (and adapted - see [NRLSPEC]) or both are merged into a third one, with incosistencies resolved. It is definitely not the purpose of NEPOMUK to deny existence of publicly available ontologies. NEPOMUK wants to provide a platform that would simplify the development of semantically-enabled applications. To achieve this goal NEPOMUK aims to alleviate the burden of learning and supporting multiple vocabularies.

If the user needs to integrate data expressed in the vocabulary of some other ontology into the NEPOMUK knowledge base it needs to be transformed into NRL and aligned with other NEPOMUK ontologies. This will enable NEPOMUK applications to process it easily. Maintaining a single import/export utility is much less costly than having all applications support all vocabularies. In a domain where many applications need to work with many vocabularies, there is an entire matrix of combinations that need to be supported. A unified approach encouraged by NEPOMUK aims to reduce this complexity from quadratic to linear.

NEPOMUK doesn't aim to substitute existing data with their RDF counterparts. The complexity of existing and future data formats makes round-trip 1 to 1 transformation between RDF and the native format nearly impossible. There were attempts at creating vocabularies that would express all complexities of a non-rdf data format. (e.g. [ICALRDF], or [VCARDRDF]). Even if they succeeded in achieving high level of conformance, they didn't explore real benefits of RDF, like common datatypes and URI references. Ontologies that resulted from these attempts have deficiencies that inhibit their usefullness within social semantic desktop context.

Integration of ontologies

Tight integration between ontologies is needed. Some data formats contain references to entities that fall beyond their intended scope, but are nevertheless important. Examples might include references to contacts in emails (to, from, cc, bcc fields), calendar events (attendee, rsvp) or text documents (author, reviewer). These references are mostly incomplete. (a 'to' field in an email usually contains only the address, sometimes a name). Nevertheless it is better for these occurences to be described as instances of classes from a specialized ontology (even though these instances might hardly contain more that one or two fields) than leave them as plain string values.

Having such incomplete instances facilitates ontology alignment. It is comparatively easy to create and algorithm that browses all instances of a given class and implements some similarity measure to detect duplicates in order to link them with a unique instance of some higher-level concept. If those instances were expressed with plain strings, the problem would become more difficult.

Don't go beyond the intended scope of NIE

NIE contains concepts that are directly related to native resources available on a local desktop or in the network. These are mostly files or can be mapped to parts of files. (like calendar entries are parts of a calendar file, contacts are part of an addressbook file etc.) It doesn't contain abstract concepts that don't have their direct representations as sequences of bytes (like 'Person', 'Project', 'Publication', 'Job' etc.) These are delegated to other ontologies. It is the task of appropriate tools to map between the 'raw' data and those 'high-level' concepts.

Allow for easy migration and conform to the standards

The most immediate goal of NIE is to replace ontologies currently used by Aperture, Beagle++ and Strigi. That's why NIE is designed with easy migration in mind, wherever it didn't clash with above objectives. Moreover existing standards are to be observed. This means widespread norms, usually issued by official standardization bodies like World Wide Web Consortium (W3C Recommendations), Internet Engineering Task Force (RFC Documents), International Organization for Standardization etc. Specific attention is given to the standardization effort undertaken by the open source community in the XESAM Project (eXtEnsible Search And Metadata Specification).

High-level overview of the NIE Framework

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

Data Objects

nie:DataObject represent physical entities that contain data. They are extracted from filesystems, archives, contact lists, mailboxes etc. The representation itself is usually not interesting to the user. In order for a piece of data to be actually understood, it needs to be interpreted as an appropriate type of an InformationElement. Such an interpretation makes it possible to inspect the content of a nie:DataObject correctly, and possibly divide it into parts - new nie:DataObject which can have their own interpretations. This process is iterative and continues as long as needed.

All resources on the desktop are basically related to each other with two most fundamental types of relations: interpretation and containment.

nie:DataObject represents a native entity the user works with. The usage of the term 'native' is important. It means that a nie:DataObject can usually be directly mapped to a sequence of bytes. Examples include a file, a set of files or a part of a file. The granularity depends on the user. nie:DataObject is atomic in the sense, that in order to distinguish any more data objects within, it has to be interpreted first.

The detailed list of nie:DataObject subclasses is subject to extension. It is envisioned that future applications will define their own nie:DataObject subclasses in their own ontologies. The NEPOMUK Information Element Ontology defines only the most generic properties deemed applicable to all nie:DataObject. More specific information is to be expressed using vocabularies extending NIE.

Information Elements

nie:InformationElement is a piece of information stored within a data object. Content-specific properties are defined as properties of an nie:InformationElement. It is separate from the nie:DataObject in order to make the interpretation independent of the representation. Research has shown that this flexibility is necessary to create a framework flexible enough to accomodate for the complexity of data structures present on the desktop. For example let's consider a mailbox. It is usually stored in a file (this is expressed as a FileDataObject interpreted as a Mailbox). An IMAP mailbox though is stored on a remote server, but from the interpretation point of view it doesn't differ from a file mailbox (in NIE this is expressed as a RemoteHostAddress interpreted as a Mailbox). Another representation may be a software service available through some interprocess communication mechanism (as is the case of the Outlook mailbox available via a COM interface). In NIE this is expressed as a SoftwareService interpreted as a mailbox). We have three completely different representations (file, remote host, software service) with an identical interpretation (Mailbox).

For a more thorough example see figure below. We see an in-file mailbox, containing an email, which contains an attachment. Notice that entities appearing on the right side can also appear at different levels. Apart from the already mentioned mailbox, there are other possibilities. A partition may be interpreted as a filesystem, but also a file containing an image of a DVD can be interpreted as a filesystem. A nmo:MailboxDataObject can be interpreted as a nmo:Message, but an .eml file too. The same applies to nco:Contact. We may have a single .vcf file containing a single VCARD, which is interpreted as a nco:Contact, but an email nfo:Attachment, or a nfo:RemoteDataObject may have the same interpretation.

This approach gives a uniform overview of data regardless of how it's represented.

Data Sources

nie:DataObject instances don't just come out of thin air. They are usually extracted from some data source. These are represented by instances of a nie:DataSource class. Each instance represents a native application or system, that manages information. A nie:DataSource instance aggregates information required by the data extraction component to gain access to the source. In the case of a nfo:Filesystem, this may be a path, for a nmo:Mailbox this may be the hostname, login and password etc.

Various subclasses of a nie:DataSource are envisioned. They may include filesystems data sources, calendar data sources, website data sources etc. The exact choice of types and properties is considered specific to a particular rdf extraction application. Data extraction applications are encouraged to provide their own data source ontologies. Such an ontology should contain data source types supported by the application coupled with properties necessary to gain access to them.

It is important to notice that certain entities (such as a mailbox or a filesystem) may appear both as a DataSource and as an InformationElement. They should not be confused though. They are completely different classes with completely different meaning. DataSource is an entity for which an rdf extraction framework of choice has an adapter for. DataObjects are extracted from it, either automatically when they appear (with some kind of monitoring process) or manually at the wish of the user.

The choice of subclasses of a DataSource depends specifically on the capabilities of the chosen rdf extraction framework. Some frameworks prefer to use an integrated approach (like the 'personal information space' from Beagle) where the Desktop is treated as a whole, and no specific data sources are distinguished. Other (like Aperture), work with a specific set of data source types (e.g. FilesystemDataSource, IMAPDataSource, IcalDataSource etc.). In the Aperture example a Filesystem instance is extracted from a FilesystemDataSource, just as all files.

The provenance of a DataObject is represented by the nie:dataSource property. In many usage scenarios it is important to keep track of the provenance of each data object. This information is useful for a number of reasons.

  • It augments the value of the information contained within the object itself.

  • It could be used to open a resource in it's native application for editing.

  • If a user wishes to remove a data source from the system, or stop monitoring it, the dataSource property can be used to identify resources that have been extracted from this data source, so that they can also be removed.

Note that this approach itself allows for an arbitrary hierarchy of data objects. It makes the structure of the extracted data independent of the capabilities of a particular extraction framework. It can be used by all-encompassing semantic desktop systems, as well as smaller libraries specialized in a single type of data source. The former would probably begin with some high-level concept such as nfo:HardDiskPartition or a nfo:SoftwareItem interpreted as an nfo:OperatingSystem and build a containment tree to the very bottom. The latter could begin their work somewhere in the middle (e.g. an mbox file crawler) and proceed as deep as they like.

Guidelines for extending NIE

As said before, The NIE Ontology is intended to serve as a foundation for a broad framework. Extensions are to be added to accomodate for various types of DataObjects and InformationElements. Each extension is a separate ontology, housed within a separate namespace. It should accept the assumptions outlined in section Basic design decisions- be expressed in NRL and try not to extend beyond native desktop resources. A NIE extension can define its own types of Data entities (subclasses of nie:DataObject) and their interpretations (subclasses of nie:InformationElement) or simply augment vocabulary provided elsewhere. The developers are encouraged to reuse classes and properties already defined in NIE (as stated Integration of ontologies) or provide specializations for them (subclasses and subproperties).

References

[NRLSPEC]

NEPOMUK Representational Language (NRL) Vocabulary Specification., NEPOMUK Task-Force Ontologies, http://www.semanticdesktop.org/ontologies/nrl

[RDFSEMANTICS]

RDF Semantics, Patrick Hayes, W3C Recommendation http://www.w3.org/TR/rdf-mt/

[DCSPEC]

Dublin core metadata element set, version 1.1, DCMI Recommendation http://www.dublincore.org/documents/dces/

[ICALRDF]

Rdf calendar - an application of the resource description framework to icalendar data, Dan Connolly and Libby Miller, W3C Interest Group Note 29 September 2005 http://www.w3.org/TR/rdfcal/

[VCARDRDF]

Representing vcard objects in rdf/xml, Renato Ianella, W3C Note 22 February 2001 http://www.w3.org/TR/vcard-rdf

[EXIFRDF]

Exif data description vocabulary, Masahide Kanzaki http://www.kanzaki.com/ns/exif

NIE Vocabulary Summary

Description of Classes

nie:DataObject

LabelDataObject
DescriptionA unit of data that is created, annotated and processed on the user desktop. It represents a native structure the user works with. The usage of the term 'native' is important. It means that a DataObject can be directly mapped to a data structure maintained by a native application. This may be a file, a set of files or a part of a file. The granularity depends on the user. This class is not intended to be instantiated by itself. Use more specific subclasses.
Super-classes 
Sub-classesncal:Attachment, nfo:RemoteDataObject, nfo:RemotePortAddress (direct), nfo:FileDataObject (direct), ndo:TorrentedFile, ncal:CalendarDataObject (direct), nco:ContactListDataObject (direct), nfo:WebDataObject (direct), nfo:SoftwareItem (direct), nfo:Attachment, nfo:DeletedResource, nmo:MailboxDataObject (direct), nfo:MediaStream (direct), nfo:EmbeddedFileDataObject, nfo:SoftwareService (direct), nfo:LocalFileDataObject, nfo:ArchiveItem, nfo:HardDiskPartition (direct), ndo:P2PFile
In domain ofnfo:belongsToContainer, nie:interpretedAs, nie:byteSize, nie:coreGraph, nie:lastModified, nie:url, nie:created, nie:lastRefreshed, nie:dataSource, nie:isPartOf, nie:modified, ndo:copiedFrom
In range ofnfo:bookmarks, nco:sound, nco:key, ndo:copiedFrom, nco:photo, nie:links, nie:depends, nie:hasPart, nfo:hasMediaStream, nie:relatedTo, nie:isStoredAs, nco:logo
Mentioned inData Sources, High-level overview of the NIE Framework, Information Elements, Guidelines for extending NIE, Data Objects, File Downloads

nie:DataSource

LabelDataSource
DescriptionA superclass for all entities from which DataObjects can be extracted. Each entity represents a native application or some other system that manages information that may be of interest to the user of the Semantic Desktop. Subclasses may include FileSystems, Mailboxes, Calendars, websites etc. The exact choice of subclasses and their properties is considered application-specific. Each data extraction application is supposed to provide it's own DataSource ontology. Such an ontology should contain supported data source types coupled with properties necessary for the application to gain access to the data sources. (paths, urls, passwords etc...)
Super-classes 
Sub-classes 
In domain of 
In range ofnie:dataSource, nie:rootElementOf
Mentioned inData Sources

nie:InformationElement

LabelInformationElement
DescriptionA unit of content the user works with. This is a superclass for all interpretations of a DataObject.
Super-classes 
Sub-classesnfo:MindMap, nfo:BookmarkFolder (direct), nfo:Software (direct), nfo:Media (direct), nfo:TextDocument, nmm:Movie, nmo:MimeEntity (direct), nfo:Icon, nfo:Audio, nco:ContactGroup (direct), nfo:Website (direct), ncal:Freebusy (direct), nfo:HtmlDocument, nfo:Image, nfo:Spreadsheet, ncal:Alarm (direct), nfo:DataContainer (direct), nmo:Message (direct), nfo:MediaList (direct), nexif:Photo, nfo:Filesystem, nfo:Video, nfo:Cursor, nmm:TVSeries (direct), ncal:Journal (direct), nfo:Document (direct), nfo:RasterImage, nfo:Trash, nfo:Font (direct), nfo:Visual, ncal:Calendar (direct), nco:OrganizationContact, nfo:SourceCode, ncal:Todo (direct), nfo:PaginatedTextDocument, nmm:MusicPiece, nco:ContactList (direct), nfo:Archive, nmm:TVShow, nmo:IMMessage, ncal:Event (direct), nmo:Email, nmm:MusicAlbum, nfo:Folder, nco:Contact (direct), ndo:Torrent (direct), nfo:FilesystemImage, nfo:OperatingSystem, ncal:Timezone (direct), nco:PersonContact, nfo:Executable (direct), nmo:Mailbox (direct), nfo:Bookmark (direct), nfo:PlainTextDocument, nfo:Presentation, nfo:Application, nfo:VectorImage
In domain ofnco:publisher, nie:links, nie:title, nco:creator, nie:relatedTo, nie:language, nie:isLogicalPartOf, nie:version, nie:informationElementDate, nie:identifier, nie:isStoredAs, nie:characterSet, nie:contentSize, nie:contentLastModified, nie:rootElementOf, nie:htmlContent, nie:contentModified, nie:generator, nie:hasPart, nie:keyword, nco:contributor, nie:contentCreated, nie:hasLogicalPart, nie:legal, nie:generatorOption, nfo:encryptionStatus, nie:subject, nie:mimeType, nie:plainTextContent, nie:comment, nie:description
In range ofnuao:targettedResource, ndo:referrer, nie:interpretedAs, nie:isLogicalPartOf, nie:hasLogicalPart, pimo:referencingOccurrence, nie:isPartOf, pimo:groundingOccurrence
Mentioned inInformation Elements, Guidelines for extending NIE, High-level overview of the NIE Framework

Description of Properties

nie:byteSize

LabelbyteSize
DescriptionThe overall size of the data object in bytes. That means the space taken by the DataObject in its container, and not the size of the content that is of interest to the user. For cases where the content size is different (e.g. in compressed files the content is larger, in messages the content excludes headings and is smaller) use more specific properties, not necessarily subproperties of this one.
Domainnie:DataObject
Rangexsd:integer
Maximum Cardinality1
Super-properties 
Sub-propertiesnfo:fileSize (direct)

nie:characterSet

LabelcharacterSet
DescriptionCharacterset in which the content of the InformationElement was created. Example: ISO-8859-1, UTF-8. One of the registered character sets at http://www.iana.org/assignments/character-sets. This characterSet is used to interpret any textual parts of the content. If more than one characterSet is used within one data object, use more specific properties.
Domainnie:InformationElement
Rangexsd:string
Maximum Cardinality1
Super-properties 
Sub-properties 

nie:comment

Labelcomment
DescriptionA user comment about an InformationElement.
Domainnie:InformationElement
Rangexsd:string
Cardinalitynone
Super-properties 
Sub-propertiesncal:comment (direct)

nie:contentCreated

LabelcontentCreated
DescriptionThe date of the content creation. This may not necessarily be equal to the date when the DataObject (i.e. the physical representation) itself was created. Compare with nie:created property.
Domainnie:InformationElement
Rangexsd:dateTime
Maximum Cardinality1
Super-propertiesnao:created (direct), nao:modified, nie:contentModified (direct), nie:informationElementDate (direct), nao:annotation
Sub-propertiesnmo:sentDate (direct)

nie:contentLastModified

LabelcontentLastModified
DescriptionThe date of the last modification of the original content (not its corresponding DataObject or local copy). Compare with nie:lastModified.
Domainnie:InformationElement
Rangexsd:dateTime
Maximum Cardinality1
Super-propertiesnao:lastModified (direct), nao:modified, nie:contentModified (direct), nie:informationElementDate (direct), nao:annotation
Sub-properties 

nie:contentModified

Labelmodified
DescriptionThe date of a modification of the original content (not its corresponding DataObject or local copy). Compare with nie:modified.
Domainnie:InformationElement
Rangexsd:dateTime
Cardinalitynone
Super-properties 
Sub-propertiesnie:contentCreated (direct), nie:contentLastModified (direct), nmo:sentDate
Mentioned inBasic Usage

nie:contentSize

LabelcontentSize
DescriptionThe size of the content. This property can be used whenever the size of the content of an InformationElement differs from the size of the DataObject. (e.g. because of compression, encoding, encryption or any other representation issues). The contentSize in expressed in bytes.
Domainnie:InformationElement
Rangexsd:integer
Maximum Cardinality1
Super-properties 
Sub-properties 

nie:copyright

Labelcopyright
DescriptionContent copyright
Domain 
Rangexsd:string
Cardinalitynone
Super-propertiesnie:legal (direct)
Sub-propertiesnexif:copyright (direct)

nie:coreGraph (deprecated)

LabelcoreGraph
DescriptionConnects the data object with the graph that contains information about it. Deprecated in favor of a more generic nao:isDataGraphFor.
Domainnie:DataObject
Rangenrl:InstanceBase
Cardinalitynone
Super-properties 
Sub-properties 

nie:created

Labelcreated
DescriptionDate of creation of the DataObject. Note that this date refers to the creation of the DataObject itself (i.e. the physical representation). Compare with nie:contentCreated.
Domainnie:DataObject
Rangexsd:dateTime
Maximum Cardinality1
Super-propertiesnao:modified, nie:modified (direct), nao:created (direct), nao:annotation
Sub-propertiesnfo:fileCreated (direct), ncal:created (direct)

nie:dataSource

LabeldataSource
DescriptionMarks the provenance of a DataObject, what source does a data object come from.
Domainnie:DataObject
Rangenie:DataSource
Minimum Cardinality1
Super-properties 
Sub-properties 
Mentioned inData Sources

nie:depends

Labeldepends
DescriptionDependency relation. A piece of content depends on another piece of data in order to be properly understood/used/interpreted.
Domain 
Rangenie:DataObject
Cardinalitynone
Super-propertiesnie:relatedTo (direct)
Sub-properties 

nie:description

Labeldescription
DescriptionA textual description of the resource. This property may be used for any metadata fields that provide some meta-information or comment about a resource in the form of a passage of text. This property is not to be confused with nie:plainTextContent. Use more specific subproperties wherever possible.
Domainnie:InformationElement
Rangexsd:string
Cardinalitynone
Super-propertiesnao:annotation, nao:description (direct)
Sub-propertiesnmm:synopsis (direct), nco:note (direct), ncal:description (direct)

nie:disclaimer

Labeldisclaimer
DescriptionA disclaimer
Domain 
Rangexsd:string
Cardinalitynone
Super-propertiesnie:legal (direct)
Sub-properties 

nie:generator

Labelgenerator
DescriptionSoftware used to "generate" the contents. E.g. a word processor name.
Domainnie:InformationElement
Rangexsd:string
Cardinalitynone
Super-properties 
Sub-propertiesncal:prodid (direct)

nie:generatorOption

LabelgeneratorOption
DescriptionA common superproperty for all settings used by the generating software. This may include compression settings, algorithms, autosave, interlaced/non-interlaced etc. Note that this property has no range specified and therefore should not be used directly. Always use more specific properties.
Domainnie:InformationElement
Range 
Cardinalitynone
Super-properties 
Sub-propertiesncal:version (direct)

nie:hasLogicalPart

LabelhasLogicalPart
DescriptionGeneric property used to express 'logical' containment relationships between InformationElements. NIE extensions are encouraged to provide more specific subproperties of this one. It is advisable for actual instances of InformationElement to use those specific subproperties. Note the difference between 'physical' containment (hasPart) and logical containment (hasLogicalPart)
Domainnie:InformationElement
Rangenie:InformationElement
Cardinalitynone
Super-properties 
Sub-propertiesnfo:containsBookmarkFolder (direct), nfo:containsBookmark (direct)
Inverse Propertynie:isLogicalPartOf

nie:hasPart

LabelhasPart
DescriptionGeneric property used to express 'physical' containment relationships between DataObjects. NIE extensions are encouraged to provide more specific subproperties of this one. It is advisable for actual instances of DataObjects to use those specific subproperties. Note to the developers: Please be aware of the distinction between containment relation and provenance. The hasPart relation models physical containment, an InformationElement (a nmo:Message) can have a 'physical' part (an nfo:Attachment). Also, please note the difference between physical containment (hasPart) and logical containment (hasLogicalPart) the former has more strict meaning. They may occur independently of each other.
Domainnie:InformationElement
Rangenie:DataObject
Cardinalitynone
Super-propertiesnie:relatedTo (direct)
Sub-propertiesnco:containsContact (direct), nco:sound (direct), nco:key (direct), ncal:hasAlarm (direct), nco:photo (direct), nmo:hasAttachment (direct), ncal:attach (direct), ncal:component (direct), nfo:hasMediaStream (direct), nco:logo (direct)
Inverse Propertynie:isPartOf

nie:htmlContent

Labelhtml content
DescriptionThe HTML content of an information element. This property can be used to store text including formatting in a generic fashion.
Domainnie:InformationElement
Rangexsd:string
Maximum Cardinality1
Super-properties 
Sub-propertiesnmo:htmlMessageContent (direct)

nie:identifier

Labelidentifier
DescriptionAn unambiguous reference to the InformationElement within a given context. Recommended best practice is to identify the resource by means of a string conforming to a formal identification system.
Domainnie:InformationElement
Rangexsd:string
Cardinalitynone
Super-propertiesnao:identifier (direct)
Sub-propertiesnmm:musicBrainzAlbumID (direct), nmm:musicCDIdentifier (direct), nmm:internationalStandardRecordingCode (direct), ncal:uid (direct), nmm:musicBrainzTrackID (direct), nexif:imageUniqueID (direct), nfo:uuid (direct), nmo:messageId (direct), nco:contactUID (direct)

nie:informationElementDate

LabelinformationElementDate
DescriptionA point or period of time associated with an event in the lifecycle of an Information Element. A common superproperty for all date-related properties of InformationElements in the NIE Framework.
Domainnie:InformationElement
Rangexsd:dateTime
Cardinalitynone
Super-properties 
Sub-propertiesnie:contentCreated (direct), nie:contentLastModified (direct), nmm:releaseDate (direct), nmo:sentDate

nie:interpretedAs

LabelinterpretedAs
DescriptionLinks the DataObject with the InformationElement it is interpreted as.
Domainnie:DataObject
Rangenie:InformationElement
Cardinalitynone
Super-properties 
Sub-properties 
Inverse Propertynie:isStoredAs

nie:isLogicalPartOf

LabelisLogicalPartOf
DescriptionGeneric property used to express 'logical' containment relationships between DataObjects. NIE extensions are encouraged to provide more specific subproperties of this one. It is advisable for actual instances of InformationElement to use those specific subproperties. Note the difference between 'physical' containment (isPartOf) and logical containment (isLogicalPartOf)
Domainnie:InformationElement
Rangenie:InformationElement
Cardinalitynone
Super-properties 
Sub-propertiesnmm:musicAlbum (direct)
Inverse Propertynie:hasLogicalPart

nie:isPartOf

LabelisPartOf
DescriptionGeneric property used to express containment relationships between DataObjects. NIE extensions are encouraged to provide more specific subproperties of this one. It is advisable for actual instances of DataObjects to use those specific subproperties. Note to the developers: Please be aware of the distinction between containment relation and provenance. The isPartOf relation models physical containment, a nie:DataObject (e.g. an nfo:Attachment) is a 'physical' part of an nie:InformationElement (a nmo:Message). Also, please note the difference between physical containment (isPartOf) and logical containment (isLogicalPartOf) the former has more strict meaning. They may occur independently of each other.
Domainnie:DataObject
Rangenie:InformationElement
Cardinalitynone
Super-properties 
Sub-propertiesnfo:belongsToContainer (direct)
Inverse Propertynie:hasPart

nie:isStoredAs

LabelisStoredAs
DescriptionLinks the information element with the DataObject it is stored in.
Domainnie:InformationElement
Rangenie:DataObject
Cardinalitynone
Super-properties 
Sub-properties 
Inverse Propertynie:interpretedAs

nie:keyword

Labelkeyword
DescriptionAdapted DublinCore: The topic of the content of the resource, as keyword. No sentences here. Recommended best practice is to select a value from a controlled vocabulary or formal classification scheme.
Domainnie:InformationElement
Rangexsd:string
Cardinalitynone
Super-properties 
Sub-properties 

nie:language

Labellanguage
DescriptionLanguage the InformationElement is expressed in. This property applies to the data object in its entirety. If the data object is divisible into parts expressed in multiple languages - more specific properties should be used. Users are encouraged to use the two-letter code specified in the RFC 3066
Domainnie:InformationElement
Rangexsd:string
Maximum Cardinality1
Super-properties 
Sub-properties 

nie:lastModified

LabellastModified
DescriptionLast modification date of the DataObject. Note that this date refers to the modification of the DataObject itself (i.e. the physical representation). Compare with nie:contentLastModified.
Domainnie:DataObject
Rangexsd:dateTime
Maximum Cardinality1
Super-propertiesnao:lastModified (direct), nao:modified, nie:modified (direct), nao:annotation
Sub-propertiesnfo:fileLastModified (direct), nexif:dateTime (direct)

nie:lastRefreshed

LabellastRefreshed
DescriptionDate when information about this data object was retrieved (for the first time) or last refreshed from the data source. This property is important for metadata extraction applications that don't receive any notifications of changes in the data source and have to poll it regularly. This may lead to information becoming out of date. In these cases this property may be used to determine the age of data, which is an important element of it's dependability.
Domainnie:DataObject
Rangexsd:dateTime
Maximum Cardinality1
Super-properties 
Sub-properties 

nie:legal

Labellegal
DescriptionA common superproperty for all properties that point at legal information about an Information Element
Domainnie:InformationElement
Rangexsd:string
Cardinalitynone
Super-properties 
Sub-propertiesnexif:copyright, nie:disclaimer (direct), nie:copyright (direct), nie:license (direct), nie:licenseType (direct)

nie:license

Labellicense
DescriptionTerms and intellectual property rights licensing conditions.
Domain 
Rangexsd:string
Cardinalitynone
Super-propertiesnie:legal (direct)
Sub-properties 

nie:licenseType

LabellicenseType
DescriptionThe type of the license. Possible values for this field may include "GPL", "BSD", "Creative Commons" etc.
Domain 
Rangexsd:string
Cardinalitynone
Super-propertiesnie:legal (direct)
Sub-properties 

nie:links

Labellinks
DescriptionA linking relation. A piece of content links/mentions a piece of data
Domainnie:InformationElement
Rangenie:DataObject
Cardinalitynone
Super-propertiesnie:relatedTo (direct)
Sub-propertiesnfo:bookmarks (direct)

nie:mimeType

LabelmimeType
DescriptionThe mime type of the resource, if available. Example: "text/plain". See http://www.iana.org/assignments/media-types/. This property applies to data objects that can be described with one mime type. In cases where the object as a whole has one mime type, while it's parts have other mime types, or there is no mime type that can be applied to the object as a whole, but some parts of the content have mime types - use more specific properties.
Domainnie:InformationElement
Rangexsd:string
Maximum Cardinality1
Super-properties 
Sub-propertiesnmo:contentMimeType (direct)

nie:modified

Labelmodified
DescriptionDate the DataObject was changed in any way. Note that this date refers to the modification of the DataObject itself (i.e. the physical representation). Compare with nie:contentModified.
Domainnie:DataObject
Rangexsd:dateTime
Cardinalitynone
Super-properties 
Sub-propertiesnfo:fileCreated, nfo:fileLastModified, nexif:dateTime, nie:created (direct), nie:lastModified (direct), ncal:created
Mentioned inBasic Usage

nie:plainTextContent

LabelplainTextContent
DescriptionPlain-text representation of the content of a InformationElement with all markup removed. The main purpose of this property is full-text indexing and search. Its exact content is considered application-specific. The user can make no assumptions about what is and what is not contained within. Applications should use more specific properties wherever possible.
Domainnie:InformationElement
Rangexsd:string
Maximum Cardinality1
Super-properties 
Sub-propertiesnmo:plainTextMessageContent (direct)

nie:relatedTo

LabelrelatedTo
DescriptionA common superproperty for all relations between a piece of content and other pieces of data (which may be interpreted as other pieces of content).
Domainnie:InformationElement
Rangenie:DataObject
Cardinalitynone
Super-properties 
Sub-propertiesnmo:hasAttachment, nie:links (direct), nco:containsContact, ncal:component, nco:key, ncal:hasAlarm, nco:photo, nfo:bookmarks, nie:hasPart (direct), ncal:attach, nco:sound, nie:depends (direct), nfo:hasMediaStream, nco:logo

nie:rootElementOf

LabelrootElementOf
DescriptionDataObjects extracted from a single data source are organized into a containment tree. This property links the root of that tree with the datasource it has been extracted from
Domainnie:InformationElement
Rangenie:DataSource
Cardinalitynone
Super-properties 
Sub-properties 

nie:subject

Labelsubject
DescriptionAn overall topic of the content of a InformationElement
Domainnie:InformationElement
Rangexsd:string
Cardinalitynone
Super-properties 
Sub-propertiesnmo:messageSubject (direct)

nie:title

Labeltitle
DescriptionName given to an InformationElement
Domainnie:InformationElement
Rangexsd:string
Maximum Cardinality1
Super-propertiesnao:prefLabel (direct)
Sub-propertiesnco:fullname (direct), nexif:imageDescription (direct)

nie:url

Labelurl
DescriptionURL of a DataObject. It points to the location of the object. A typial usage is FileDataObject. In cases where creating a simple file:// or http:// URL for a file is difficult (e.g. for files inside compressed archives) the applications are encouraged to use conventions defined by Apache Commons VFS Project at http://jakarta.apache.org/ commons/ vfs/ filesystems.html.
Domainnie:DataObject
Rangerdfs:Resource
Maximum Cardinality1
Super-properties 
Sub-propertiesnfo:fileUrl (direct)
Mentioned inRemote Resources

nie:version

Labelversion
DescriptionThe current version of the given data object. Exact semantics is unspecified at this level. Use more specific subproperties if needed.
Domainnie:InformationElement
Rangexsd:string
Cardinalitynone
Super-properties 
Sub-properties