# Ontology Visualization

# Introduction

The meaning of the term annotation is highly contextual. Depending on the context, anything or nothing can be considered as annotation within a data set (or named graph). On the social semantic desktop, the average user is frequently seen creating representations of objects on their desktop, while the more experienced user is also frequently creating representations of concepts and their relationships. Sharing and creating relationships between all these resources across multiple desktops is what makes a user's desktop social and semantic. Within this context, we consider annotation to be anything that goes further than creating resources and defining their elementary relationships. A user can create an instance of a 'Person', and provide values for all the elementary properties that an instance of 'Person' can have. The user can then go one step ahead and annotate the resources with more information, of a textual (e.g. custom human-readable descriptions) or non-textual (e.g. links to related resources) nature. In a typical scenario there may be a number of domain-centric properties for the classes 'Person' (e.g. name, address, knows etc.) and 'Document' (e.g. author, title etc.). Via vocabulary in the annotation ontology the user can provide personalized, user-friendly labels and descriptions for a resource, as well as other things like tags and ratings. Generic relationships may exist between resources across multiple domains, and making these relationships explicit would be of great benefit for the user. For example, a user wants to state that a 'Document' is about some instance of 'Person'. This relationship is too general to be applied at the domain ontology level, since such a relationship may exist between other concepts in other domains e.g. between 'Conference' and 'Technology'. Vocabulary that is able to express these generic relationships are therefore provided by the annotation ontology. Although this information is optional and does not reflect the elementary nature of a 'Document', it contributes to improved data unification and eases user search.

We model annotation via properties, rather than classes, since we believe that annotation is a relationship and not a concept. This was also the idea for the rdfs:label and rdfs:comment properties in the RDFS vocabulary, which we consider as textual annotation. These properties are in fact included in our specifications, especially since in the context of this ontology and that of the social semantic desktop they have a slightly different meaning. Generic annotation is represented at its highest level with the abstract nao:annotation property. Although it is not meant to be used, it is the superproperty of many other annotation properties in this ontology. Vocabulary for generic annotation is introduced in .

Graph Metadata is also a form of annotation, where instead of annotating general resources, one annotates Named Graphs. Therefore graph metadata properties can be modelled under the general annotation property , where the resource being annotated is a graph role (instance of ) and the annotations are provided via the graph metadata properties. The major difference is that while generic annotation can be stored within any graph the user is working with (e.g. the graph where the annotated resource is defined), metadata about a graph should always be stored outside that graph, in a separate special named graph that is aptly represented in by . Graph Metadata Vocabulary is introduced in .

# Generic Annotation Vocabulary

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

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

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 the figure below.

Basic annotation properties

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.

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

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:hasSymbol

  A resource can be annotated with an instance of via subproperties of this abstract property, and .

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

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, . Although this property is not applied any form of restriction, all its subproperties, including , are meant to be inverse functional.

nao:Symbol

  This class represents a symbol, which can be an icon or an image for example, that is used to annotate a resource. Resources can be annotated with a standard graphical symbol via the subproperties of , and . Any such graphical symbol that is in this way used to annotate a resource automatically becomes an instance of this class.

nao:Tag

  This class is useful for modelling conventional tagging practices. The user can tag resources in conventional ways, automatically creating an instance of this tag, which is then related to the annotated resource via the . For more on tagging as annotation see .

nao:Party

  Annotations are provided by an individual or a group of individuals. Some annotations are contained in a separate named graph whose role is to provide annotations about another named graph (e.g. graph metadata for a graph, See ). In such cases it is useful to state the contributor(s) for the set of annotations. This class is provided to represent a party who created such a set of annotations, where a party can be either one individual or a group of individuals (e.g. an organization). Once a user or an group provides these annotations, they automatically become an instance of this class.

## 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 . An overview of these properties is illustrated in . The specifications for this vocabulary are given below.

Figure 2. Basic annotation properties

nao:isRelated

  This property defines a symmetric relation between any two resources. A subproperty of , 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.

nao:hasTopic

  A subproperty of , 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

  This property is also a subproperty of and is the inverse property of . 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.

nao:hasTag

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

nao:isTagFor

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

nao:prefLabel

  This property is one of two provided by this ontology to handle custom user labels. Alternative labels can be provided via . 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.

nao:altLabel

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

nao:pluralPrefLabel

  This property supplements 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.

nao:prefSymbol

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

nao:altSymbol

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

nao:description

  A subproperty of rdfs:comment, the purpose of this property is similar to and . However this property is also a subproperty of . 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.

nao:personalIdentifier

  This property should be used to provide alternative values that identify a resource alongside the default URI. A subproperty of the abstract , 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.

nao:numericRating

  This property extends , 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.

nao:creator

  Via this property the creator/s of a resource can be specified graph. The creator can be a an individual or a group as represented by an instance of the class.

nao:contributor

  This property refers to additional contributors for a resource and is otherwise similar to .

nao:modified

  Represents the modification date/time [xsd:dateTime] for a resource. More of an abstract class, its subproperties and prove to be more useful.

nao:created

  Via this property the creation date/time for a resource can be defined. A subproperty of nao:modified, the expected value is of type [xsd:dateTime] and a typical value is of the form "2007-08-15T23:59:55.329Z". The maximum cardinality for this property is set to 1.

nao:lastModified

  This property defines the date/time when a resource was most recently modified. It is a subproperty of . The maximum cardinality for this property is also set to 1.

nao:score

  This property refers to an authorative score for an item (resource), valued between [0, 1]. A score is a weight of a resource compared to all other resources, and it is computed via a mathematical combination of score parameters e.g. nao:numericRating, nao:lastModified as well external parameters. For this purpose, parameters that go into the score need to be marked as being sub-properties of . Allowed values for this property are of the [xsd:float] datatype.

nao:scoreParameter

  Multiple score parameters (e.g. nao:numericRating, nao:lastModified) can be input to a mathematical algorithm that computes an overall for a resource. The score parameters in question need to be defined as a subproperty of this property - thus effectively is a marker property. Ranking algorithms will compute the values of multiple subproperties of scoreParameter and then compute the based on a mathematical combination of score parameters. The allowed range is a float number. The exact algorithm is open to implementations. Allowed values for this property are of the [xsd:float] datatype.

nao:FreeDesktopIcon

  This class represents a desktop icon as defined in the FreeDesktop Icon Naming standard and it is a subclass of . is a required property referring to the name of the icon.

nao:iconName

  Values of this property contain the FreeDesktop standard icon name (literal) as defined in the FreeDesktop Naming Specification. The use of the property is required for every instance of since its minimum cardinality is set to 1.

nao:hasSubResource

  This property defines a super-sub relationship between two instances of rdfs:Resource - whereby one resource can be treated as dependent on another. Thus if a resource is deleted or removed from a system, all its subresources can also be automatically removed, unless they have other superresources still existant on the system. This property is the inverse property of . This property is transitive in nature.

nao:hasSuperResource

  This property is the inverse of nao:hasSubResource. It defines a dependency relationship between two resources such that, when the superresource is removed from a system, the defined subresources should also be removed unless they are also subresources of other remaining superresources. This property is transitive in nature.

## 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. shows how can be used as a special case of the relation given in . The unique default name given by the user when creating a tag is defined by . Other custom names for the tag can be defined using while a custom user description can be provided via nao:description. A custom default icon or image can be attached to the tag via , making the icon in question an instance of . 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 . An automatic inverse relationship is created to link the new tag with the resource via .

Figure 3. Modelling conventional tagging

## Generic Annotation Example

A person wants to annotate a file of type image/photo on their personal desktop. The photo depicts a friend, Claudia, drinking coffee in the SAP offices. The user states that the photo 'is related' (via nao:isRelated - a symmetric property) to the following resources:

- [1] a resource representing Claudia on the user's desktop (ex:Claudia)

- [2] a resource representing the organisation SAP on the user's desktop (ex:SAP)

Furthermore, the user states that the photo 'is about' (via nao:hasTopic) the following resources:

- [3] a concept from a Work ontology defining a colleague at work (work:Colleague)

- [4] a concept from a Work ontology defining a working office (work:Office)

[5] The user defines a custom personal identifier for the photo, 'ClaudiaOffice20070815'.

[6] Finally, the user also tags the photo with an instance of nao:Tag they create:

- [7],[8] The user labels the new tag 'Work', with the alternative labels 'SAP' and 'WorkPlace'.

- [9],[10] The user also selects an icon for the new tag that they find on their desktop, and creates a custom description for the new tag.

The resulting statements are generated and stored within a named graph 'ex:i1'. Apart from the obvious statements, note the following automatically generated statements

- [11] Since nao:hasTag has the inverse property nao:isTagFor, the newly generated tag is also related to the tagged resource via this inverse property.

- [12] The icon used as a symbol for the tag (ex:WorkIcon) is now also an instance of nao:Symbol.

- Since nao:isRelated is symmetric the resources related to the photo via this property (ex:SAP and ex:Claudia) are themselves defined as related to the photo.

    ex:i1 {
    [1]  ex:DSCF001 nao:isRelated ex:Claudia ,
    [2]                           ex:SAP ;
    [3]                nao:hasTopic work:Colleague ,
    [4]                             work:Office ;
    [5]                nao:personalIdentifier "ClaudiaOffice20070815" ;
    [6]                nao:hasTag ex:Work .

    	 ex:Work a nao:Tag ;
    [7]          nao:prefLabel "Work" ;
    [8]          nao:altLabel "WorkPlace" ,
    						  "SAP" ;
    [9]          nao:hasSymbol ex:WorkIcon ;
    [10]         nao:description "Represents all about my work, workplace, workmates etc" ;
    [11]         nao:isTagFor ex:DSCF001 .

    [12] ex:WorkIcon a nao:Symbol .

    [13] ex:SAP nao:isRelated ex:DSCF001 .

    [14] ex:Claudia nao:isRelated ex:DSCF001 . }

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

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

Generic annotation vocabulary given in this ontology is also applicable to named graphs (which are in fact special cases of a resource). In particular, , , and 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 .

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 (), and not just ontologies. The majority of graph metadata properties thus have as their domain. Other properties apply specifically to (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 [] role, also shown in and linked to their respective graphs via []. 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 [].

## 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 and are listed here, since their common superclass is . 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 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

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.

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.

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.

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.

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

## Document Graph Metadata

A special class in the NRL specifications, [], 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 , applies only to instances of such graphs.

Figure 6. Graph Metadata for Graphs encoded in documents

nao:serializationLanguage

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

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

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

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

OMV Report

  Ontology Metadata Vocabulary for the Semantic. Web. Jens Hartmann (University of Karlsruhe), Raul Palma (Universidad Politecnica de Madrid) and Elena Paslaru Bontas (Free University of Berlin). http://ontoware.org/projects/omv/