• Added
  • nao:trustLevel
  • nao:directTrust
  • nao:networkTrust
  • nao:privacyLevel
  • nao:externalIdentifier
  • nao:endorsedBy
  • nao:favouritedBy
  • nao:hasDataGraph

• Abstract
• Status of this document
• Ontology Visualisation
• Change Log
• Contents
• 1. Introduction
• 2. Generic Annotation Vocabulary
  • 2.1. Basic Annotation
    • 2.1.1. nao:annotation
    • 2.1.2. rdfs:label
    • 2.1.3. rdfs:comment
    • 2.1.4. nao:hasSymbol
    • 2.1.5. nao:rating
    • 2.1.6. nao:identifier
    • 2.1.7. nao:Symbol
    • 2.1.8. nao:Tag
    • 2.1.9. nao:Party
  • 2.2. More Specific Annotation
    • 2.2.1. nao:isRelated
    • 2.2.2. nao:hasTopic
    • 2.2.3. nao:isTopicOf
    • 2.2.4. nao:hasTag
    • 2.2.5. nao:isTagFor
    • 2.2.6. nao:prefLabel
    • 2.2.7. nao:altLabel
    • 2.2.8. nao:pluralPrefLabel
    • 2.2.9. nao:prefSymbol
    • 2.2.10. nao:altSymbol
    • 2.2.11. nao:description
    • 2.2.12. nao:personalIdentifier
    • 2.2.13. nao:numericRating
    • 2.2.14. nao:creator
    • 2.2.15. nao:contributor
    • 2.2.16. nao:modified
    • 2.2.17. nao:created
    • 2.2.18. nao:lastModified
    • 2.2.19. nao:score
    • 2.2.20. nao:scoreParameter
    • 2.2.21. nao:FreeDesktopIcon
    • 2.2.22. nao:iconName
    • 2.2.23. nao:hasSubResource
    • 2.2.24. nao:hasSuperResource
  • 2.3. Tagging as Annotation
  • 2.4. Generic Annotation Example
• 3. Graph Metadata Vocabulary
  • 3.1 General Graph Metadata
    • 3.1.4. nao:hasDefaultNamespace
    • 3.1.5. nao:hasDefaultNamespaceAbbreviation
    • 3.1.6. nao:engineeringTool
    • 3.1.7. nao:version
    • 3.1.8. nao:status
  • 3.2. Document Graph Metadata
    • 3.3.1. nao:serializationLanguage
  • 3.3. Graph Metadata Example
• References
• Appendix A. NAO Vocabulary Summary
  • A1: Ontology Classes Description
  • A2: Ontology Properties Description

NAO Vocabulary Specification

This document presents the specifications for the NEPOMUK Annotation Ontology, a vocabulary for resource annotation that is based on the NEPOMUK Representational Language [NRL SPECIFICATION]. The ontology is available for general and individual use and is independent of the domain for which it was initially designed for, namely the [NEPOMUK Social Semantic Desktop] initiative. The NEPOMUK in the ontology name (NAO) has been retained only for historic purposes. 

The document is structured as follows. Section 1 provides an insight of what we consider to be annotation within the context of NRL and the social semantic desktop. Section 2 introduces vocabulary for generic annotation, i.e. general annotation of resources, with a particular emphasis on how conventional tagging can also be represented using this ontology. Section 3 introduces vocabulary that supports annotation for graphs, or graph metadata. Given the important role that named graphs have in NRL, annotation for graphs is also consideted part of this ontology. Finallya summary of all the NAO vocabulary elements is given in [ Appendix A].

1. Introduction

2. Generic Annotation Vocabulary

In this section we introduce vocabulary that serves generic annotation, i.e., vocabulary that models general, common relationships between things. Section 2.1 presents the basic annotation vocabulary. All other vocabulary in the annotation ontology will require or derive from these basic terms. Section 2.2 introduces richer annotation relationships that derive from the basic annotation properties presented in Section 2.1.  In Section 2.3 we discuss how we also model tagging as a form of annotation and finally in Section 2.4 we present a concise example of how the vocabulary presented in this section can be employed.

2.1. Basic Annotation

The most basic annotation property is nao:annotation, which simply defines a descriptive property for a resource. Given that an annotation's nature can be textual or non-textual (i.e. semantic annotation pointing to a resource), the range of this abstract high-level property is left undefined. Specific subproperties can have richer semantics (e.g. symmetric properties), but in order to abstract over all annotation properties, no such semantics are defined for nao:annotation. 

rdfs:label and rdfs:comment are also (indirectly) considered as part of our annotation ontology, as they provide textual annotations for a resource. Although we do not define them as being subproperties of nao:annotation, we also include them in these specifications, in order to define their meaning in the context of the social semantic desktop. 

These and other annotation properties and required classes are specified below. The annotation properties defined in this section are also illustrated in Fig.1.

Figure1. Basic annotation properties

2.1.1. nao:annotation

An abstract property representing a general annotation for a resource. Given its abstract nature and its undefined range, this property is not meant to be used directly.

2.1.2. rdfs:label

We consider this RDFS property as part of our annotation ontology, since it provides a textual annotation which relates a resource to a literal. In the context of the social semantic desktop this property provides technical labels for a resource, i.e, a non-user customizable label that is not meant to be seen by the user. User-customizable labels are possible via the use of our own sub-properties nao:prefLabel and nao:altLabel.

2.1.3. rdfs:comment

This RDFS property is also considered as part of our annotation ontology, since it provides a textual annotation which relates a resource to a literal. In the context of the social semantic desktop, this property provides technical descriptions for a resource. Non-technical, custom user descriptions can be provided  by our own subproperty, nao:description.

2.1.4. nao:hasSymbol

A resource can be annotated with an instance of nao:Symbol via subproperties of this abstract property, nao:prefSymbol and nao:altSymbol.

2.1.5. nao:rating

Users can rate a resource via subproperties of this property, which is not meant to be used directly. Specific subproperties can extend it and be used to rate resources, e.g. an audio file. The range of this property is undefined. Numeric ratings can be assigned via nao:numericRating (maximum cardinality 1). If other kinds of ratings are needed, this property can arbitrarily and easily extend be extended (e.g. with a property that has as range a class for which a number of instances can be enumerated).

2.1.6. nao:identifier

This property enables further types of identifiers for a resource, apart from its standard URI. The property itself is not meant to be directly used since it is an abstract property and does not have a defined range.  The annotation ontology provides a  subproperty for this property,  nao:personalIdentifier.  Although this property is not applied any form of restriction, all its subproperties, including nao:personalIdentifier, are meant to be inverse functional.

2.2. More Specific Annotation

The Annotation Ontology provides more specific vocabulary that extends the description power of the basic annotation vocabulary presented in the previous section.  Vocabulary in this category consists solely of properties which extend properties given in Section 2.1. An overview of these properties is illustrated in Fig.2. The specifications for this vocabulary are given below. 

Figure 2. More specific annotation properties

2.2.1. nao:isRelated

This property defines a symmetric relation between any two resources. A subproperty of nao:annotation, one can use this property to annotate a resource with pointers to related resources. For example, a blog entry for an event may be linked to an image of the same event via this property. In order for this property to be used legally, the relationship must be symmetric. 

2.2.2. nao:hasTopic

A subproperty of nao:isRelated, this property does not inherit its symmetric nature. It further defines the relationship given by its superproperty, stating that a resource is about some concept. Instead, this vocabulary provides an inverse property for this property, nao:isTopicOf.

2.2.3. nao:isTopicOf

This property is also a subproperty of nao:isRelated and is the inverse property of nao:hasTopic. It is used to create a relationship between two resources, where the subject resource is said to be the topic of the object. It is not a symmetric property.

2.2.4. nao:hasTag

Used to model conventional tagging practices, this property annotates a resource with a tag, represented by an instance of nao:Tag. For more on tagging as annotation see Section 2.3.

2.2.5. nao:isTagFor

This property is the inverse of nao:hasTag. It links an instance of nao:Tag to resources that are tagged with it. For more on tagging as annotation see Section 2.3.

2.2.6. nao:prefLabel

This property is one of two provided by this ontology to handle custom user labels. Alternative labels can be provided via nao:altLabel. Both properties are subproperties of rdfs:label and expect a literal as value. Given that the domain of this property is rdfs:Resource, it is not applied any cardinality restrictions. Where required, such properties can be defined by extending this property via appropriate subproperties. However, it is intended that at most one value per (natural) language is defined via this property and that at most one literal without any defined language exists. Other usages, although legal, are considered invalid NAO data and are strongly discouraged as they may generate errors.

2.2.7. nao:altLabel

Via this property a user can provide further custom labels for resources on their desktop, alongside the required, unique value given by nao:prefLabel. Both properties are subproperties of rdfs:label and expect a literal as value.

2.2.8. nao:pluralPrefLabel

This property supplements nao:prefLabel to provide plural forms for custom user resource labels. In particular it is useful to refer to multiple instances of a calss. It is also a subproperty of rdfs:label and expects a literal as value. No cardinality restrictions are imposed.

2.2.9. nao:prefSymbol

A subproperty of nao:hasSymbol, this property specifies a preferred symbol for resource annotation, given by an instance of nao:Symbol. Resources can be annotated with alternative symbols via nao:altSymbol.

2.2.10. nao:altSymbol

This property is used to annotate a resource with alternative symbols, given by instances of nao:Symbol, alongside the preferred symbol that is linked via nao:prefSymbol. It is a subproperty of nao:hasSymbol.

2.2.11. nao:description

A subproperty of rdfs:comment, the purpose of this property is similar to nao:prefLabel and nao:altLabel. However this property is also a subproperty of nao:annotation. Whereas in the context of the social semantic desktop the textual annotation provided via rdfs:comment is meant for technical users, the textual annotation here is aimed at average users and is meant to be used to define custom descriptions of resources on their desktop. The maximum cardinality is 1, and the property expects a literal value.

2.2.12. nao:personalIdentifier

This property should be used to provide alternative values that identify a resource alongside the default URI. A subproperty of the abstract nao:identifier, the range of this property is a literal. The property is inverse functional, which effectively means that personal identifiers for resources should be unique, and two resources cannot have the same personal identifier.

2.2.13. nao:numericRating

This property extends nao:rating, to restrict the range to an XSD float datatype. Values must be between '1' and '10' whereas a value of '0' is interpreted as not set. Furthermore, resources can only be given at most one numeric rating, thus the maximum cardinality is 1. 

2.2.14. nao:creator

2.2.18. nao:lastModified

2.3. Tagging as Annotation

Given tagging is a popular Web 2.0 concept which we want to adopt and retain in our semantic approach to data modelling, in this section we provide an example of how semantic tagging can be performed using our annotation ontology. Fig.3 shows how nao:Tag can be used as a special case of the nao:annotation relation given in Fig.2. The unique default name given by the user when creating a tag is defined by nao:prefLabel. Other custom names for the tag can be defined using nao:altLabel while a custom user description can be provided via nao:description. A custom default icon or image can be attached to the tag via nao:prefSymbol, making the icon in question an instance of nao:Symbol. This icon, like any other resource, can also be annotated. The newly created tag is then linked to the resource being tagged (or annotated) via nao:hasTag. An automatic inverse relationship is created to link the new tag with the resource via nao:isTagFor.

Figure 3. Modelling conventional tagging

2.4. Generic Annotation Example

3. Graph Metadata Vocabulary

In this section we provide the description and specifications for the subpart of the annotation ontology dealing with Graph Metadata. Graph metadata is a form of annotation where the subject of the annotations are named graphs, as specified in [NRL SPECIFICATION]. Given the important and central role that named graphs have in the NRL concept, this graph metadata, or graph annotation, vocabulary is considered to be part of the annotation ontology, and the properties are subproperties of nao:annotation. 

NRL already provides vocabulary that is used to define essential graph metadata [See Graph Roles Vocabulary], including graph role speficiation and whether the graph is a document graph (see Fig.4.), whether a graph is updatable or otherwise (via nrl:updatable) and specification of the declarative semantics for a graph (via nrl:hasSemantics).

Generic annotation vocabulary given in this ontology is also applicable to named graphs (which are in fact special cases of a resource). In particular, nao:creator, nao:contributor, nao:created and nao:lastModified are of special relevance when it comes to providing metadata for a named graph. The vocabulary provided in this section enables additional graph annotations to those provided by NRL and by the NAO generic annotation vocabulary. An example that makes full use of all the relevant vocabulary is given in Section 3.3.

In contrast to vocabularies like the Ontology Metadata Vocabulary [OMV REPORT], which was a major source of inspiration for this vocabulary, our vocabulary is applicable to all Graph Roles as defined in NRL (Fig.4.), and not just ontologies. The majority of graph metadata properties thus have nrl:Data as their domain. Other properties apply specifically to nrl:DocumentGraph (documents that encode named graphs).

Figure 4. Graph Roles Hierarchy

While generic annotation for a resource is usually stored within the graph where the resource is defined, metadata about a graph is stored outside that graph, in a separate but associated metadata graph. These special graphs are marked using the [nrl:GraphMetadata] role, also shown in Fig.4. and linked to their respective graphs via [nrl:graphMetadataFor]. The unique metadata graph that defines the non-subjective attributes (graph role, semantics, namespace,  etc) for a graph is instead linked to that graph via [nrl:coreGraphMetadataFor].

3.1 General Graph Metadata

The following vocabulary applies to all NRL Graph Roles. Although some of them  appear to be ontology-specific, properties which apply to e.g. both nrl:InstanceBase and nrl:Ontology are listed here, since their common superclass is nrl:Data. Given that graph metadata is considered to be a special case of annotation, most of the vocabulary consists of subproperties of nao:annotation. These properties are depicted in Fig.5. and described individually in the following subsections. Although the use of none of these properties is compulsory, their use is recommended as a best practice.

Figure 5. General Graph Metadata properties

3.1.4. nao:hasDefaultNamespace

This property explicitally defines the default namespace for a named graph. The value for this property should therefore be a valid URI ending with the '#' sign.

3.1.5. nao:hasDefaultNamespaceAbbreviation

A default namespace abbreviation for a named graph can be defined via the use of this property. This prevents a scenario where different random abbreviations are generated from different applications for the same graph.

3.1.6. nao:engineeringTool

Graphs that are generated via a specific graph engineering tool can make use of this property. The value is a string stating the name of the editing tool.

3.1.7. nao:version

This property specifies version information for the graph role and is particularly useful for tracking, comparing and merging data. Legal values for this property are of the [xsd:float] datatype. A graph can have at most one version, hence the maximum cardinality is 1.

3.1.8. nao:status

Tracking information for the contents of a graph can be specified via this property. Typical values, of type string, include "Stable", "Unstable" and "Testing". 

3.2. Document Graph Metadata

A special class in the NRL specifications,  [nrl:DocumentGraph], is defined to mark graphs that are completely represented within a document which can be accessed via a URL, which effectively also becomes the name of the graph. The following property, also shown in Fig.6., applies only to instances of such graphs.

Figure 6. Graph Metadata for Graphs encoded in documents

3.3.1. nao:serializationLanguage

This property states the graph serialization language for the document, e.g. XML/RDFS, RDFS/N3, TriG etc.

3.3. Graph Metadata Example

The following example demonstrates the use and best practice for the Graph Metadata Vocabulary given in this section.

[1] In this example we assume that a named graph with the role of an ontology exists and is given by ex:o1.
[2] Graph metadata for this ontology is provided by the metadata graph ex:o1_metadata. This graph consists of annotations for the ontology stored in graph ex:o1. These annotations are defined using the graph metadata vocabulary specified in this document.
[3],[4] The metadata graph includes first and foremost a description about itself, stating that it is indeed a named graph with a nrl:GraphMetadata role. It is further stated that this is the core graph metadata that defines the core properties for the graph ex:o1, via nrl:coreGraphMetadataFor.
[5] Metadata for the actual graph being described is then provided. This metadata includes the following:

• [6] The creator of the ontology is defined to be ex:SAP, with two separate contributors being ex:Dirk and ex:Claudia. This automatically generates the statement (usually not within this graph) that ex:SAP, ex:Dirk and ex:Claudia are annotators and therefore instances of nao:Party.
• [7] The ontology is defined to be 'Stable' at version 1.2. The last modified time is also represented.
• [8]  A static, standard namespace and namespace abbreviation are defined.
• [9] The graph is said to be non-updatable, meaning that if the ontology needs to be changed, a new version needs to be generated while leaving the original unchanged. See nrl:updatable.

[1] ex:o1 {          # Work Ontology provided in this named graph          } [2] ex:o1/metadata { [3]   ex:o1/metadata a nrl:GraphMetadata ; [4]                    nrl:coreGraphMetadataFor ex:o1 . }   [5]   ex:o1 a nrl:Ontology ; [6]         nao:creator ex:SAP ;             nao:contributor ex:Dirk ,                             ex:Claudia ; [7]         nao:version "1.2" ;             nao:lastModified "2007-08-15T23:59:55.329Z" .             nao:status "Stable" ; [8]         nao:hasNamespace "http://www.example.org/ontologies/work#" ;             nao:hasNamespaceAbbreviation "work" ; [9]         nrl:updatable "0" . }

References

[NRL SPECIFICATIONS]

NEPOMUK Representation Language (NRL) Vocabulary Specification.

NEPOMUK.,  Task-Force Ontologies.

http://www.semanticdesktop.org/ontologies/nrl.