NEPOMUK Information Element Ontology

Task-Force Ontologies 02.09.2008
Latest Version:
http://www.semanticdesktop.org/ontologies/2007/01/19/nie
This Version:
This file refers to the Revision 1.0 of NIE. Minor changes may be implemented in future revisions. With each new revision, the documentation and all serializations of the ontology will be updated. The URI identifying this version (but not the namespace) is http://www.semanticdesktop.org/ontologies/2007/01/19/nie/v1.0/
Authors:
Antoni Mylka, DFKI, antoni.mylka@dfki.de
Leo Sauermann, DFKI, leo.sauermann@dfki.de
Michael Sintek, DFKI, michael.sintek@dfki.de
Ludger van Elst, DFKI, elst@dfki.uni-kl.de
Editor:
Antoni Mylka, DFKI, antoni.mylka@dfki.de
Contributors:
Evgeny 'phreedom' Egorochkin, KDE Strigi Developer, stexx@mail.ru
Christiaan Fluit, Aduna, christiaan.fluit@aduna-software.com
Ontology:
XML/RDFS Serialization: NIE (Data Graph Only)
XML/RDFS Serialization: NIE (Metadata Graph Only)
TriG Serialization: NIE (Graph Set)

Abstract

The NEPOMUK Information Element Framework is an attempt to provide unified vocabulary for describing native resources available on the desktop. This document presents the high-level overview of the entire framework, its motivations and design decisions, as well as classes and properties that comprise the core part of the framework - the NEPOMUK Information Element Ontology itself.

Status of this document

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.

Contents

1. Introduction
2. Background
3. Overview of the NEPOMUK ontology architecture
4. Basic design decisions
4.1 Use NEPOMUK Representational Language
4.2 Make NIE usefull for the Semantic Desktop
4.2.1 Unification of ontologies
4.2.2 Integration of ontologies
4.3 Don't go beyond the intended scope of NIE
4.4 Allow for easy migration and conform to the standards
5. High-level overview of the entire NIE Framework
6. Description of the NIE Ontology
6.1 Data Objects
6.2 Information Elements
6.3 Data Sources
7. Guidelines for extending NIE
8. Examples

1. 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.

2. 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. ICAL or 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.

The open source community has recently started a widespread standardization activity under the name of XESAM Project. It gathers together developers from many important desktop search projects like Strigi, Gnome Beagle, Gnome Tracker, Pinot and Recol. The NEPOMUK project has been involved in this effort. NIE has benefitted much from the insight of XESAM developers (most notably Evgeny Egorochkin). Even though the ontologies themselves are kept separate, due to certain differences in requirements, NIE strived to maximize interoperability with XESAM and provide direct equivalents of XESAM classes an properties wherever possible.

3. 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.

NEPOMUK Universe

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 authors of this document believe that these assumptions would also hold for other semantic desktop systems.

4. 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.

4.1 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 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.

4.2 Make NIE usefull 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.

4.2.1 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 sec. 4.1) 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.

4.2.2 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.

4.3 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.

4.4 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).

5. High-level overview of the NIE Framework

High-Level Overview

6. Description of the NIE Ontology

The core of the NEPOMUK Information Element Ontology and the entire NIE Framework revolves around the concepts of DataObject and 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.

6.1 DataObjects

DataObjects 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 DataObject correctly, and possibly divide it into parts - new DataObjects 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.

Interpretation/Containment

DataObject represents a native entity the user works with. The usage of the term 'native' is important. It means that a 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. 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 DataObject subclasses is subject to extension. It is envisioned that future applications will define their own DataObject subclasses in their own ontologies. The NEPOMUK Information Element Ontology defines only the most generic properties deemed applicable to all DataObjects. More specific information is to be expressed using vocabularies extending NIE.

6.2 Information Elements

InformationElement is a piece of information stored within a data object. Content-specific properties are defined as properties of an InformationElement. It is separate from the 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 MailboxDataObject can be interpreted as a Message, but an .eml file too. The same applies to Contacts. We may have a single .vcf file containing a single VCARD, which is interpreted as a Contact, but an email Attachment, or a RemoteDataObject may have the same interpretation.

Mail Attachment Example

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

6.3 Data Sources

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 DataSource class. Each instance represents a native application or system, that manages information. A DataSource instance aggregates information required by the data extraction component to gain access to the source. In the case of a Filesystem, this may be a path, for a Mailbox this may be the hostname, login and password etc.

Various subclasses of a 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 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.

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 HardDiskPartition or a SoftwareItem interpreted as an 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.

7. 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 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 DataObject) and their interpretations (subclasses of InformationElement) or simply augment vocabulary provided elsewhere. The developers are encouraged to reuse classes and properties already defined in NIE (as stated above) or provide specializations for them (subclasses and subproperties).

8. Examples

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

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

Ontology Classes Description

DataObject

Superclasses rdfs:Resource
Subclasses nfo:ArchiveItem, ncal:Attachment, nfo:Attachment, ncal:CalendarDataObject, nco:ContactListDataObject, nfo:DeletedResource, nfo:EmbeddedFileDataObject, nfo:FileDataObject, nfo:HardDiskPartition, nmo:MailboxDataObject, nfo:MediaStream, nfo:RemoteDataObject, nfo:RemotePortAddress, nfo:SoftwareItem, nfo:SoftwareService
In domain of: nfo:belongsToContainer, nie:byteSize, nie:created, nie:dataSource, nie:interpretedAs, nie:isPartOf, nie:lastRefreshed
In range of: nid3:attachedPicture, nfo:bookmarks, nie:depends, nid3:generalEncapsulatedObject, nfo:hasMediaStream, nie:hasPart, nie:isStoredAs, nco:key, nie:links, nco:logo, nco:photo, nie:relatedTo, nco:sound
Description A 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.

DataSource

Superclasses rdfs:Resource
Subclasses --
In domain of: --
In range of: nie:dataSource, nie:rootElementOf
Description A 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...)

InformationElement

Superclasses rdfs:Resource
Subclasses ncal:Alarm, nfo:Application, nfo:Archive, nfo:Audio, nfo:Bookmark, nfo:BookmarkFolder, ncal:Calendar, nco:Contact, nco:ContactGroup, nco:ContactList, nfo:Cursor, nfo:DataContainer, nfo:Document, nmo:Email, ncal:Event, nfo:Executable, nfo:Filesystem, nfo:FilesystemImage, nfo:Folder, nfo:Font, ncal:Freebusy, nfo:HtmlDocument, nid3:ID3Audio, nmo:IMMessage, nfo:Icon, nfo:Image, ncal:Journal, nmo:Mailbox, nfo:Media, nfo:MediaList, nmo:Message, nmo:MimeEntity, nfo:MindMap, nfo:OperatingSystem, nco:OrganizationContact, nfo:PaginatedTextDocument, nco:PersonContact, nexif:Photo, nfo:PlainTextDocument, nfo:Presentation, nfo:RasterImage, nfo:Software, nfo:SourceCode, nfo:Spreadsheet, nfo:TextDocument, ncal:Timezone, ncal:Todo, nfo:Trash, nfo:VectorImage, nfo:Video, nfo:Visual, nfo:Website
In domain of: nie:characterSet, nie:comment, nie:contentCreated, nie:contentLastModified, nie:contentSize, nco:contributor, nco:creator, nie:description, nie:generator, nie:generatorOption, nie:hasLogicalPart, nie:hasPart, nie:identifier, nie:informationElementDate, nie:isLogicalPartOf, nie:isStoredAs, nie:keyword, nie:language, nie:legal, nie:links, nie:mimeType, nie:plainTextContent, nco:publisher, nie:relatedTo, nie:rootElementOf, nie:subject, nie:title, nie:version
In range of: pimo:groundingOccurrence, nie:hasLogicalPart, nie:interpretedAs, nie:isLogicalPartOf, nie:isPartOf, pimo:referencingOccurrence
Description A unit of content the user works with. This is a superclass for all interpretations of a DataObject.

Ontology Properties Description

byteSize

Type rdf:Property, rdfs:Resource
Domain nie:DataObject
Range xsd:integer
Maximal cardinality 1
Superproperties --
Subproperties nfo:fileSize
Description The overall size of the data object in bytes. That means the WHOLE data object and ONLY the data object, not 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.

characterSet

Type rdf:Property, rdfs:Resource
Domain nie:InformationElement
Range xsd:string
Superproperties --
Subproperties --
Description Characterset 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.

comment

Type rdf:Property, rdfs:Resource
Domain nie:InformationElement
Range xsd:string
Superproperties --
Subproperties --
Description A user comment about an InformationElement.

contentCreated

Type rdf:Property, rdfs:Resource
Domain nie:InformationElement
Range xsd:dateTime
Maximal cardinality 1
Superproperties dc:date, nie:informationElementDate
Subproperties nid3:date, nmo:sentDate
Description The 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.

contentLastModified

Type rdf:Property, rdfs:Resource
Domain nie:InformationElement
Range xsd:dateTime
Maximal cardinality 1
Superproperties dc:date, nie:informationElementDate
Subproperties --
Description The date of the last modification of the content.

contentSize

Type rdf:Property, rdfs:Resource
Domain nie:InformationElement
Range xsd:integer
Superproperties --
Subproperties --
Description The 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.

copyright

Type rdf:Property, rdfs:Resource
Domain --
Range xsd:string
Superproperties dcterms:accessRights, nie:legal, dc:rights
Subproperties --
Description Content copyright

created

Type rdf:Property, rdfs:Resource
Domain nie:DataObject
Range xsd:dateTime
Superproperties dcterms:created, dc:date
Subproperties ncal:created, nfo:fileCreated
Description Date 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.

dataSource

Type rdf:Property, rdfs:Resource
Domain nie:DataObject
Range nie:DataSource
Minimal cardinality 1
Superproperties dc:source
Subproperties --
Description Marks the provenance of a DataObject, what source does a data object come from.

depends

Type rdf:Property, rdfs:Resource
Domain --
Range nie:DataObject
Superproperties nie:relatedTo, dc:relation
Subproperties --
Description Dependency relation. A piece of content depends on another piece of data in order to be properly understood/used/interpreted.

description

Type rdf:Property, rdfs:Resource
Domain nie:InformationElement
Range xsd:string
Superproperties dc:description
Subproperties ncal:description, nco:note
Description A 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.

disclaimer

Type rdf:Property, rdfs:Resource
Domain --
Range xsd:string
Superproperties nie:legal, dc:rights
Subproperties --
Description A disclaimer

generator

Type rdf:Property, rdfs:Resource
Domain nie:InformationElement
Range xsd:string
Superproperties --
Subproperties ncal:prodid
Description Software used to "generate" the contents. E.g. a word processor name.

generatorOption

Type rdf:Property, rdfs:Resource
Domain nie:InformationElement
Range --
Superproperties --
Subproperties ncal:version
Description A 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.

hasLogicalPart

Type rdf:Property, rdfs:Resource
Domain nie:InformationElement
Range nie:InformationElement
Inverse property nie:isLogicalPartOf
Superproperties dcterms:hasPart, dc:relation
Subproperties nfo:containsBookmark, nfo:containsBookmarkFolder
Description Generic 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)

hasPart

Type rdf:Property, rdfs:Resource
Domain nie:InformationElement
Range nie:DataObject
Inverse property nie:isPartOf
Superproperties dcterms:hasPart, nie:relatedTo, dc:relation
Subproperties ncal:attach, nid3:attachedPicture, ncal:component, nco:containsContact, nid3:generalEncapsulatedObject, ncal:hasAlarm, nmo:hasAttachment, nfo:hasMediaStream, nco:key, nco:logo, nco:photo, nco:sound
Description Generic 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.

identifier

Type rdf:Property, rdfs:Resource
Domain nie:InformationElement
Range xsd:string
Superproperties nao:identifier, dc:identifier
Subproperties nco:contactUID, nexif:imageUniqueID, nmo:messageId, ncal:uid, nid3:uniqueFileIdentifier
Description An 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.

informationElementDate

Type rdf:Property, rdfs:Resource
Domain nie:InformationElement
Range xsd:dateTime
Superproperties dc:date
Subproperties nie:contentCreated, nie:contentLastModified, nid3:date, nmo:sentDate
Description A 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.

interpretedAs

Type rdf:Property, rdfs:Resource
Domain nie:DataObject
Range nie:InformationElement
Inverse property nie:isStoredAs
Superproperties --
Subproperties --
Description Links the DataObject with the InformationElement it is interpreted as.

isLogicalPartOf

Type rdf:Property, rdfs:Resource
Domain nie:InformationElement
Range nie:InformationElement
Inverse property nie:hasLogicalPart
Superproperties dcterms:isPartOf, dc:relation
Subproperties --
Description Generic 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)

isPartOf

Type rdf:Property, rdfs:Resource
Domain nie:DataObject
Range nie:InformationElement
Inverse property nie:hasPart
Superproperties dcterms:isPartOf, dc:relation
Subproperties nfo:belongsToContainer
Description Generic 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.

isStoredAs

Type rdf:Property, rdfs:Resource
Domain nie:InformationElement
Range nie:DataObject
Inverse property nie:interpretedAs
Superproperties --
Subproperties --
Description Links the information element with the DataObject it is stored in.

keyword

Type rdf:Property, rdfs:Resource
Domain nie:InformationElement
Range xsd:string
Superproperties --
Subproperties --
Description Adapted 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.

language

Type rdf:Property, rdfs:Resource
Domain nie:InformationElement
Range xsd:string
Superproperties dc:language
Subproperties nid3:language
Description Language 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

lastRefreshed

Type rdf:Property, rdfs:Resource
Domain nie:DataObject
Range xsd:dateTime
Maximal cardinality 1
Superproperties dc:date
Subproperties --
Description Date 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.

legal

Type rdf:Property, rdfs:Resource
Domain nie:InformationElement
Range xsd:string
Superproperties dc:rights
Subproperties nie:copyright, nie:disclaimer, nie:license, nie:licenseType
Description A common superproperty for all properties that point at legal information about an Information Element

license

Type rdf:Property, rdfs:Resource
Domain --
Range xsd:string
Superproperties nie:legal, dcterms:license, dc:rights
Subproperties --
Description Terms and intellectual property rights licensing conditions.

licenseType

Type rdf:Property, rdfs:Resource
Domain --
Range xsd:string
Superproperties nie:legal, dc:rights
Subproperties --
Description The type of the license. Possible values for this field may include "GPL", "BSD", "Creative Commons" etc.

links

Type rdf:Property, rdfs:Resource
Domain nie:InformationElement
Range nie:DataObject
Superproperties nie:relatedTo, dc:relation
Subproperties nfo:bookmarks
Description A linking relation. A piece of content links/mentions a piece of data

mimeType

Type rdf:Property, rdfs:Resource
Domain nie:InformationElement
Range xsd:string
Superproperties --
Subproperties nmo:contentMimeType
Description The 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.

plainTextContent

Type rdf:Property, rdfs:Resource
Domain nie:InformationElement
Range xsd:string
Superproperties --
Subproperties nmo:plainTextMessageContent, nid3:unsynchronizedTextContent
Description Plain-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.

relatedTo

Type rdf:Property, rdfs:Resource
Domain nie:InformationElement
Range nie:DataObject
Superproperties dc:relation
Subproperties ncal:attach, nid3:attachedPicture, nfo:bookmarks, ncal:component, nco:containsContact, nie:depends, nid3:generalEncapsulatedObject, ncal:hasAlarm, nmo:hasAttachment, nfo:hasMediaStream, nie:hasPart, nco:key, nie:links, nco:logo, nco:photo, nco:sound
Description A common superproperty for all relations between a piece of content and other pieces of data (which may be interpreted as other pieces of content).

rootElementOf

Type rdf:Property, rdfs:Resource
Domain nie:InformationElement
Range nie:DataSource
Superproperties --
Subproperties --
Description DataObjects 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

subject

Type rdf:Property, rdfs:Resource
Domain nie:InformationElement
Range xsd:string
Superproperties dc:subject
Subproperties nmo:messageSubject
Description An overall topic of the content of a InformationElement

title

Type rdf:Property, rdfs:Resource
Domain nie:InformationElement
Range xsd:string
Superproperties dc:title
Subproperties nexif:imageDescription, nid3:title
Description Name given to an InformationElement

version

Type rdf:Property, rdfs:Resource
Domain nie:InformationElement
Range xsd:string
Superproperties dcterms:hasVersion
Subproperties --
Description The current version of the given data object. Exact semantics is unspecified at this level. Use more specific subproperties if needed.