# Ontology Visualization

# Introduction

NRL is based on a number of key concepts, some of which are identical to concepts defined in earlier work. Other concepts are fundamentally the same to ones in existant work, but differ slightly in definition, while some concepts are a fresh approach to data representation. The key concepts are RDF triple, Named Graph and Graph Views and they are introduced in this section.

The basic concept is the RDF triple and the definition is fundamentally similar to the one given in [RDF Specification - CONCEPTS] where a triple consists of three components:

- a subject - in the form of a URI Reference
- a predicate - in the form of a URI Reference
- an object - in the form of either a URI Reference or a literal

where the predicate denotes the relationship between the subject and the object. The only difference is that in NRL it is not expected that a blank node manifests itself as either a subject or an object of a triple [See ].

An RDF Graph consists of a set of triples. The definition is similar to the one given in [RDF Specification - CONCEPTS]. A Named Graph is an RDF Graph identified by a name. In NRL, all RDF triples must be assigned to at least one named graph. Triples that are not, are automatically assigned to a special named graph, the []. Therefore, NRL data handling is usually defined in terms of named graphs rather than RDF triples. The formal definition for a named graph is the same as that given in [NAMED GRAPHS] but excludes the open-world assumption [See ]. Named graphs differ in content and purpose, and for this reason Graph Roles have been introduced, representing general roles like simple data, ontology, knowledge base, plus other less generic roles. Graph roles carry Declarative Semantics, which means that their semantics are implicit and have not necessarily been realized (in the form of inferred triples). A more elaborate definition, syntax specification and example section for named graphs is given in Named Graph Extensions [].

A named graph consists of the corresponding triple set as is, and retrieving RDF triples from a named graph, will simply return the enumerated triples in the set. However it is frequently required to work with graphs having realized semantics in the form of entailment triples, according to some declared semantics. Additionaly, it is sometimes required to work with more abstract, simplified forms of a graph. In general, it is useful to work with various interpretations of a named graph in different situations. However, in order to preserve the integrity and consistency of named graphs, an original named graph should be independent of its interpretations. To model this, one can define arbitrary views which realize different interpretations for an established named graph. We call these interpretations Graph Views and they are formally defined in Graph Views Extensions []. Graph views are themselves named graphs, so it is possible for a view to be applied on top of another graph view. View Specifications define how a view is to be computed and they can refer either to a set of rules in some rule language, or to an external application. Some view specifications realize the Procedural Semantics of a graph, and the result is a Semantic View, having both declarative and procedural semantics. Conceptually, a graph gcan be given a semantics by applying a semantic realizing view v,which is linked to some semantic specifications. Practically, if the semantics specifications are those for NRL, and these state that some of the applied semantics are transitive (e.g. rdfs:subClass) this would imply that vwill be the extension of g with the inferred triples generated by performing the transitive closure.

The following figure presents the important aspects of the NRL language, including the key concepts just described and their relationships. The diagram is partitioned in the (abstract) syntax on which it is defined (right), and the formal semantics (left) to which it is linked to. The NRL domain is depicted by the grey shaded part. Notice that NRL is not limited to the syntax partition, since it includes NRL formal semantics defined in []. The NRL syntax is composed of a base langugage and a schema language. The base language refers to the specification of the key concepts in the language, including named graphs, graph roles and graph views while the schema language (NRL Schema) provides the means to define schemas (especially information models and ontologies). The semantics partition mainly distinguishes between abstract declarative semantics, and realized procedural semantics.

Figure 1: Overview of NRL - Abstract Syntax, Concepts and Semantics

The syntax schema consists of the NRL Schema, which is based on an extended RDFS (RDFS'). The syntax base presents the key concepts of NRL as a set abstraction. Named graphs, consisting of RDF Triples, are the most general set (red) since both graph roles and graph views are special kinds of named graphs. Graph Roles (yellow) are tied to declarative semantics that they assume (e.g. an ontology using elements from RDF/S). Graph Views (green) are tied to view specifications which execute the view's realization. The intersection between graph roles and graph views refers to semantic views. These special views realize the declarative semantics of the graph role they are interpreting (e.g. by extending an ontology that uses rdfs:subClassOf by its transitive closure as defined in RDF/S Semantics). Thus, as shown on the left hand side of the figure, semantic view specifications carry the realized procedural semantics for a view, which are linked to the abstract declarative semantics of a language.

shows how the theoritical basis of NRL can be applied in practice to handle RDF data. Data handling includes creation, merging, interpretation and presentation of RDF data. It presents the dataflow for some typical NRL data and how the various concepts introduced earlier can be effectively used to model RDF data and use it in different scenarios in a sound but intuitive way. The example sections for the Named Graph extensions [] and the Graph Views extensions [] present examples that model the dataflow in this figure in TriG syntax [TRIG]. TriG is a straight-forward extension of Turtle [TURTLE]. Turtle itself is an extension of N-Triples [N-TRIPLES] which carefully takes the most useful and appropriate things added from Notation3 [NOTATION3] while keeping it in the RDF model. TriG is a plain text format created for serializing NGs and RDF Datasets.

The dataflow is based on four existing named graphs, two having the role of [] (ontologies O1 and O2) and the other two that of [] (instance bases I1 and I2). A new named graph, O, is also defined as having the role of [] and by using the property [] it is defined as being the supergraph of both O1 and O2. This constitutes an ontology merge for O1 and O2 into O. Similarly, a new named graph, KB, is defined to have the role of [] and is defined as the supergraph of O, I1 and I2. Therefore, KB consists of all RDF triples in O1, O2, I1 and I2.

Figure 2: NRL Dataflow diagram

An RDF programmer would like to work with an extension of KB that includes also the realized semantics that KB is implicitly carrying. To generate this extension, or view, the RDF programmer can define an instance of [] that computes and returns the procedural semantics for KB. The view specification uses a rule language of choice that provides a number of rules, one of which computes the transitive closure of rdfs:subClassOf, as defined in the RDFS semantics, for a set of RDF triples. Executing the chosen rules over the triples in KB result in a semantic view RDFS(KB) consisting of the RDF triples in KB plus the generated entailment triples.

Next, the RDF programmer needs to present some of this extended data to an average user in a simplified way. In particular, the user would at some point like to see the class hierarchy present in RDFS(KB). The RDF programmer can create external view specifications, in the form of applications which take a named graph as input (a set of RDF triples), and return the desired RDF triples as output. In this case, an external view specification, E1, is created and designed to select and return the triples defining the class hierarchy within an input named graph. The view generated by this application, E1(RDFS(KB)), which is basically another named graph, is the data required for presentation to the user. It is worth to note, that at this stage, all the seven named graphs that this last viewis generated upon are still intact and they have not been modified by any of the operations.

## Requirements

In this section we specify the original identified requirements for a Representational Language (excluding requirements that are domain-dependent) and whether their fulfillment was successful or otherwise.

The following requirements have been satisfied:

- Tool support for inferencing, interpretation, manipulation and storage.
- NRL should allow for validation of ontologies.
- Basic subClassOf, type, and inverseProperty inference has to be computable efficiently.
- Domain and Range properties must be adhered to and verified. [See domain and range usage ]
- Properties must support cardinality requirements. [See , and ]
- Representation of ontology models. [See graph role ]
- Ontology imports must be possible. Ontology management must be provided. [See named graph property []
- Support for Quads/Named Graphs to record provenance. [See ]

The following requirements are no longer in the scope of the NRL but in that of lower-level ontologies:

- The language must differentiate between concepts and web-resources. [See nrl:Thing and nrl:ResourceManifestation]
- Meta-modeling needs to be supported. [See nrl:NRLClass and nrl:NRLProperty]
- Support for alternative labels (thesauri helpers) alongside labels is required. [See alternative labels property nrl:altLabel
- n-ary relations should be supported. [See nrl:relationProperty]
- It must provide some basic semantic relations. [See nrl:partOf, nrl:hasTopic and nrl:relationProperty]
- Typing on reifications and contexts.

The following requirements have not been satisfied:

- Support for imprecise/fuzzy/probabilistic representations.

Note: The fulfillment of this requirement will be postponed until a non-imprecise version of NRL is stable.

The following requirement has been retracted:

- Typing on container contents. Containers are to be avoided altogether. [See Recommendation

## RDF/S and NRL Compatibility

This specification provides some recommendations as to the use of some RDF/S elements or constructs []. It must be noted that if these recommendations are not followed, this still results in legal RDF/S data and therefore legal NRL data. However this does not imply that such data would be valid NRL data. Although such data would conform to the RDF/S specifications, correct manipulation of invalid NRL data is not guaranteed if the recommendations are not followed. This also applies to RDF/S data that is imported in an NRL context (e.g. RDF/S data imported on one's semantic desktop). In a more technical sense, legal NRL would be processed without generating errors, but only valid NRL would be processed without generating warnings.

Since NRL is based on the Named Graph paradigm [See ], NRL data cannot be directly represented with plain RDF/S since NG's are an extension on top of RDF/S. Therefore NRL with named graphs is not backward compatible to RDF/S. It is compatible however with Named Graphs as specified in [SPARQL-QUERY].

## Naming

The URI for the NRL Vocabulary is http://www.semanticdesktop.org/ontologies/yyyy/mm/dd/nrl# subject to the date of the latest stable version.

The URI for an element in the vocabulary is constructed by appending a fragment identifier to the above URI. A fragment identifier for a class always starts with an uppercase letter while in the case of properties it starts with a lowercase letter. In the case of class identifiers consisting of multiple words, the leading character of each word will be an uppercase letter. In case of property identifiers consisting of multiple words, the leading character of each word will be an uppercase letter, except for the first word which as specified should be in lowercase.

Examples

http://www.semanticdesktop.org/ontology/yyyy/mm/dd/nrl#Class http://www.semanticdesktop.org/ontology/yyyy/mm/dd/nrl#ExampleClass http://www.semanticdesktop.org/ontology/yyyy/mm/dd/nrl#property http://www.semanticdesktop.org/ontology/yyyy/mm/dd/nrl#exampleProperty

## Persistence

The NRL Vocabulary specification defined here and any previous or later versions, plus the NRL ontology itself [http://www.semanticdesktop.org/ontology/yyyy/mm/dd/nrl#] will be provided as persistent resources.

## Social Semantic Desktop Ontologies

Ontologies are structured in various layers or levels, with the rationale that those at higher levels are more stable and thus change less often than those at lower levels. Usually, one distinguishes representational ontologies, upper-level ontologies, mid-level ontologies, and domain ontologies.

The NRL is a representational ontology and although it is domain independent it was designed to fulfil requirement for the NEPOMUK Social Semantic Desktop initiative. Representational ontologies define the vocabulary with which other ontologies are represented. Other examples of such representational ontologies are RDF/S and OWL. The relationship of a representational ontology to other ontologies is quite different from the relationship between the other ontologies themselves. While upper-level ontologies generalize mid-level ontologies, which in turn generalize domain ontologies, all these ontologies can be seen as instances of the representational ontology.

The specification of various other ontologies is in the pipeline for the Social Semantic Desktop project. In particular, the following (upper-level) ontologies are being discussed:

- Information Element Ontology [NIE] - to handle physical resource (e.g. documents, web pages, files etc.)
- Annotation Ontology [NAO] - to handle general annotation (e.g. Data annotation, Linking abstract to physical resources) as well as graph annotation (e.g. Data authorship. etc.)
- Personal Information Modelling Ontology [PIMO] - to model things and relationships on the user's desktop.

## External Ontology Synchronisation

The ontologies resulting from the Social Semantic Desktop project are partly inspired by existing elements in external ontologies. As a result some elements are very similar to elements in existing languages like OWL [OWL Overview] and [OMV Documentation]. Also, some RDF/S elements do not fulfil the requirements for the project's ontologies and therefore problems arise from these two scenarios. When requiring elements that already exist in some other standard ontology, but do not exactly conform to our requirements, there are the following three outlined options:

1. Re-define semantics for use within NEPOMUK ontologies.

   This creates major problem when it comes to heterogeneity issues. One cannot redefine an element if it already has a defined semantics, because when encountering such an element, it would not be possible to decide in which context to interpret it. Restrictions are a more subtle form of redefinition. In this case, any restrictions placed on the use of existing elements will result in the possibility of having Legal but Invalid data in the NEPOMUK ontologies context. See further discussions in [] in the case of NRL.

2. Re-create new elements with required semantics and ignore the existing ones.

   This goes against the idea of ontologies and the Semantic Web in general, that is, to have a shared conceptualisation, promote the re-use of ontologies and discourage the re-creation of data.

3. Re-create new elements with required semantics and provide a mapping between them and the existing elements.

   This option is a variant of the previous option, where although new elements are re-created, the relation between the new and the existent elements is modelled using mappings. Examples of these mappings are subclass, hyponym, meronym. Although in this case, new elements satisfying the requirements are created, the existent elements are not ignored and therefore the shared conceptualisation ideology is respected. In the NEPOMUK ontologies, option three is the standard best practice when existent elements with different semantics are required. When requiring restriction on the use of elements, option one is sufficient since it does not violate the predefined semantics. However in this case the statement in [] should be noted. The mapping constructs required for option three will be defined over time and therefore, although theoritically the agreed-upon option is three, in practice option two is currently being implemented.

## NRL and Closed World Vs. Open World Assumptions

The open-world assumption (OWA) presumes that its knowledge of the world is incomplete and that this lack of knowledge does not imply falsity. On the other hand, the closed-world assumption (CWA) presumes that what is not currently known to be true, is false. Whereas the OWA states that everything that is not known is undefined, the CWA implies that everything we don't know is false.

This assumption has a big impact on direct and indirect knowledge generated through RDF data. This difference is demonstrated through the following example which is based on and TriG [TRIG]. We will consider the implications of importing the given three graphs g1, g2 and g3 into an external graph g.

    @prefix nrl: <http://www.semanticdesktop.org/ontology/yyyy/mm/dd/nrl#> .
    @prefix dom: <http://www.example.org/ontology/domainOntology#> .
    @prefix ex: <http://www.example.org/vocabulary#> .
    @prefix ex2: <http://www.example.org/vocabulary#> .
    @prefix : <http://www.example.org/vocabulary#> .
    [1] :g1 {
        dom:Person rdf:type rdfs:Class .
        dom:Man rdf:type rdfs:Class ;
                rdfs:subClassOf dom:Person .
        dom:Woman rdf:type rdfs:Class ;
                 rdf:subClassOf dom:Person .
        dom:hasFather rdf:type rdf:Property ,
                                nrl:FunctionalProperty ;
                       rdfs:domain rdf:Person ;
                       rdfs:range rdf:Man . }
    [2] :g2 {
        ex:Peter rdf:type dom:Man .
        ex:Jill rdf:type dom:Person ;
                 dom:hasFather ex:Peter . }
    [3] :g3 {
        ex2:Jack rdf:type dom:Man .
        ex:Jill dom:hasFather ex2:Jack . }

[1] The first graph consists of an ontology and presents three classes and a property. The classes are dom:Person and its two subclasses dom:Woman and dom:Man. The property dom:hasFather is a applicable to class dom:Person and taking as values instances of dom:Man.

[2] The second named graph is an instance base consisting of two instances, Peter as a dom:Man and Jill as a dom:Person. In addition, the dom:hasFather relation between Jill and Peter says that Peter is Jill's father. Question: Is Jill a dom:Woman?

OWA: Unknown - It is only known that Jill is a dom:Person. OWA cannot determine whether the statement is true or false. CWA: No - Jill is nowhere defined to be a dom:Woman. Therefore the statement is false.

Question: Is Peter a dom:Person?

OWA: Yes - Peter is a dom:Man, and this is a subclass of dom:Person.

CWA: Yes - Peter is a dom:Man, and this is a subclass of dom:Person.

[3] The third graph is also an instance base and presents another instance, Jack as a dom:Man. The same Jill defined in graph two, is said to have Jack as her father.

Since dom:hasFather is a functional property, Jill can have only one person related to her by that property.

OWA: It results that Jack and Peter are the same person. This statement is implicitly added to the data.

CWA: There is conflicting data in g2 and g3. An error is generated. The RDF language itself assumes an open-world and so does the definition for Named Graphs in [NAMED GRAPHS]. There is a difference of opinion on what approach is best for handling RDF data. While OWA is more flexible, and more likely to generate new statements based on ones that already exist in the models, its non-monotonic nature hinders computability and largely increases the complexity of RDF data. On the other hand, while CWA is much more prone to generate errors, it is totally deterministic and one can always compute whether any statement under the assumption is true or false.

Although it is sometimes more realistic to apply OWA, the correctness of this approach is not guaranteed. In the given example, it might makes sense to leave the possibility open for the statement Jill is a woman to be true. However it might not make sense to assume that the fact Jack is Peter is intentional. Under CWA, the truth of the statements is subject to explicitally stating them.

For this reason, NRL does not assume an Open World View and although NRL imposes no semantics on basic graphs, NRL semantics are CWA. Semantics are imposed on graphs through Graph Views and Semantic Views as introduced in []. Therefore Open World Views can be realized as well by applying an OWA view to a named graph. On the Semantic Desktop in particular we assume closed-world semantics as it focuses mainly on personal data. While most people find it difficult to understand the logical meaning and potential inferences statements of the open-world assumption, the closed-world assumption is easier to understand for an average desktop user.

# Representing Domain Knowledge: RDF(S) and NRL Extensions to RDF(S)

The NRL Vocabulary is an application of the [Resource Description Framework] (RDF) and the associated [RDF Schema] (RDFS). The NRL vocabulary therefore implicitly includes elements from the RDF/RDFS vocabularies. Consequently the specifications for RDF [RDF Specification] and RDFS should be regarded as part of this specification document. However, the NRL vocabulary defines some on the use of RDF/RDFS elements. When using RDF/S constructs within the NRL context, these recommendations need to be respected if the generated data is to be valid NRL data (see discussion in [] regarding valid and legal NRL). In practice this means that when RDF/S constructs are used together with NRL elements (or any of their instances) one should strictly abide by the RDF/S specifications and any recommendations stated in this document.

The rest of Section 2 is divided as follows. Summary tables of the imported RDF/RDFS elements are provided, followed by specifications of any restrictions or recommendations placed when importing into NRL.

## Resource Description Framework (RDF) Elements

The following are the elements defined in RDF and implicitly forming part of the NRL. Their summary tables are categorized into Classes, Properties and other elements. The class summary table states the class name and the class’s parent class. The property summary table states the property name and the applicable domain and range. The other elements table states the element name and the element type. The tables also denote whether the elements have been imported as is, or if extensions or restrictions apply when used in the NEPOMUK context. These extensions and restrictions are specified in []

### Classes

Class | Superclass | Notes
rdf:Property | rdfs:Resource | No
rdf:Statement | rdfs:Resource | No
rdf:XMLLiteral* | rdfs:Literal | No
rdf:Bag | rdfs:Container | Yes
rdf:Seq | rdfs:Container | Yes
rdf:Alt | rdfs:Container | Yes
rdf:List | rdfs:Resource | No

*rdf:XMLLiteral is also an instance of rdfs:Datatype (see )

### Properties

Property | Domain | Range | Notes
rdf:type | rdfs:Resource | rdfs:Class | No
rdf:subject | rdf:Statement | rdfs:Resource | No
rdf:predicate | rdf:Statement | rdfs:Resource | No
rdf:object | rdf:Statement | rdfs:Resource | No
rdf:value | rdfs:Resource | rdfs:Resource | No
rdf:first | rdf:List | rdfs:Resource | No
rdf:rest | rdf:List | rdf:List | No

### Other Vocabulary

Name | Type | Notes
rdf:nil | rdfs:List | No
rdf:XMLLiteral | rdfs:Datatype | No

## RDF Schema (RDFS) Elements

The following are the elements defined in RDFS and implicitly forming part of the NRL. Their summary tables are categorized into Classes and Properties. The class summary table states the class name and the class’s parent class. The property summary table states the property name and the applicable domain and range. The tables also denote whether the elements have been imported as is, or if extensions apply when used in the NRL context. These extensions are specified in []

### Classes

Class | Superclass | Notes
rdfs:Resource | rdfs:Resource | No
rdfs:Class | rdfs:Resource | No
rdfs:Datatype | rdfs:Class | No
rdfs:Container | rdfs:Resource | Yes
rdfs:Literal | rdfs:Resource | No
rdfs:ContainerMembershipProperty | rdf:Property | Yes

### Properties

Property | Domain | Range | Notes
rdfs:domain | rdf:Property | rdfs:Class | Yes
rdfs:range | rdf:Property | rdfs:Class | Yes
rdfs:subClassOf | rdfs:Class | rdfs:Class | No
rdfs:subPropertyOf | rdf:Property | rdf:Property | No
rdfs:member | rdfs:Resource | rdfs:Resource | Yes
rdfs:isDefinedBy* | rdfs:Resource | rdfs:Resource | Yes
rdfs:label | rdfs:Resource | rdfs:Literal | No
rdfs:comment | rdfs:Resource | rdfs:Literal | No
rdfs:seeAlso | rdfs:Resource | rdfs:Resource | No

*rdfs:isDefinedBy is a sub property of rdfs:seeAlso

## Recommendations for and against the use of RDF/S elements

As discussed earlier [] although any legal RDF is also legal NRL, it is not necessarily valid NRL. In order for NRL to be valid, these recommendations must be strictly adhered to.

### rdfs:domain, rdfs:range

The fact that NRL does not assume open-world has an impact on the way some constructs should be used. This is especially true for the rdfs:domain and the rdfs:range elements. In an open-world scenario, when using a property to relate two resources, one is implicitly casting the type of those resources to the types specified in the property’s domain and range definition. In other words the use of a property evokes additional implicit statements about the types of the objects being related, even if these types are different than the types that have been predefined for the objects, if at all. In a closed-world scenario as on the semantic desktop this is not possible since in order to relate two resources, their types must fit the expected domain and range in the first place. This also means that untyped resources cannot be related. Failure to do so will generate legal yet invalid NRL data on the semantic desktop. This recommendation has a major bearing on the validity of logical inference mechanisms in place within NRL and therefore must be strictly adhered to.

Recommendation:The domain and range constraints for properties must be strictly adhered to. Untyped resources cannot be related through a property, since the types of the related resources must explicitly satisfy the constraints set by rdfs:domain and rdfs:range given NRL is not OWA.

Examples In these examples and the ones that follow throughout the document, we use the example namespace for user-generated data http://mydesktop.org/mydesktop#. The example namespace abbreviation can be defined as follows. To improve the readability of examples, the user namespace abbreviation is sometimes excluded. In these cases, the elements are given in italics.

    @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
    @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
    @prefix nrl: <http://www.semanticdesktop.org/ontology/yyyy/mm/dd/nrl#> .
    @prefix voc: <http://www.semanticdesktop.org/ontology/desktop#> .
    ...
    @prefix desktop: <http://mydesktop.org/mydesktop#>
    ...

[1] Within the Ontology Desktop the property voc:depicts is assigned a domain of voc:ImageFile and a range of voc:Person.

[2] desktop:Myself is defined as an instance of voc:Person.

[3] desktop:MyFriend is defined as an instance of voc:Friend.

[4] desktop:PassportPhoto is defined as an instance of voc:ImageFile. It is related to desktop:Myself through the voc:depicts property. This is valid usage of the rdfs:domain and rdfs:range as defined in [1] and is valid NRL data, since the types of both resources being related have been stated and they fit the domain and range constraints.

[5] desktop:Friend20060613 is defined as an instance of voc:ImageFile. It is related to desktop:MyFriend through the voc:depicts property. It is nowhere stated that the class voc:Friend is a subclass of voc:Person. This is legal, but not valid usage of the rdfs:domain and rdfs:range as defined in [1]. Given the closed-world assumption, it cannot be determined whether the statement 'desktop:MyFriend is voc:Person' is true. Note that if voc:Friend was defined as a subclass of voc:Person, the statement would become true and therefore the NRL data would be both legal and valid.

    [1] :o1 {
    			...
    			voc:depicts rdf:type rdf:Property ;
    			rdf:domain voc:ImageFile ;
    			rdf:range voc:Person . }
        :ib1 {
    			...
    			[2] desktop:Myself rdf:type voc:Person .
    			[3] desktop:MyFriend rdf:type voc:Friend .
    			[4] desktop:PassportPhoto rdf:type voc:ImageFile;
    						voc:depicts desktop:Myself .
    			[5] desktop:Friend20060613 rdf:type voc:ImageFile ;
    						voc:depicts desktop:MyFriend . }

### Blank Nodes

The use of blank nodes in conjunction with NRL elements and their instances is strongly discouraged. Blank nodes are semantically difficult to handle and as a result it is difficult to implement them correctly.

Recommendation: The use of blank nodes is strongly discouraged. Data containing blank nodes is legal but not valid NRL data.

### Collections and Containers

Container classes are deprecated because the semantics of containers are not clear and they are also difficult to handle. The sole use of either containers or collections is sufficient to model grouped resources. Since the semantics of collections are clearer, the use of containers is discouraged in favour of collections.

1. rdf:Bag is a container class whose use is discouraged.
2. rdf:Alt is a container class whose use is discouraged.
3. rdf:Seq is a container class whose use is discouraged.
4. rdfs:Container is the superclass of rdf:Bag, rdf:Alt and rdf:Seq, and is not applicable to any other RDF/S or NRL element.
5. rdfs:ContainerMembershipProperty is used to indicate the membership of rdf:Bag, rdf:Alt and rdf:Seq, and is not applicable to any other RDF/S or NRL element.
6. rdfs:member is a super property of the container membership properties, and is not applicable to any other RDF/S or NRL element.

Recommendation: The use elements numbered [1] through [6] is strongly discouraged.

Although the use of container classes and properties is discouraged, resources can still be grouped using [RDFS Collections] constructs.

1. rdf:List is a class that can be used to build descriptions of collections. A collection typically is composed of one or more lists.
2. rdf:first is a property that relates a list to its first element.
3. rdf:rest is a property that relates a list to the rest of the elements excluding the first element. The rest of the elements are in the form of another list.
4. rdf:nil is a property that can be used to create an empty list. This is usually the last list in a collection.

Recommendation: The combined use of elements numbered [1] through [4] is encouraged as an alternative to container elements

### rdfs:isDefinedBy

The semantics of this element is unclear and therefore it is discouraged. The definition vaguely allows the use of this property to relate any two resources.

Recommendation: The use of rdfs:isDefinedBy is strongly discouraged. Data containing statements using this property is legal but not valid NRL data.

### Reification

The named graphs paradigm provides all the functionality required to be able to state things about other statements. Consequently, the idea of reification within the NRL context is redundant.

Recommendation:The use of reification is strongly discouraged.

## Constraint Extensions

This section presents extensions used to make statements about constraints on the use of properties in NRL data. These extensions provide further functionalities to the basic constraints provided by RDFS, namely [rdfs:domain] and [rdfs:range]. The latter two constraints place a limitation on the class type of the resources that a property can relate (class typeconstraints).The NRL constraint extensions in turn place a limitation on the amount of values that a property can take (range cardinality constraints) and on actual pairs of resources that the property should or should not, through inference, relate (resource relation constraints). These three categories are summarized in []. Similarly to RDFS, NRL provides a mechanism for describing these constraints, but does not say whether or how an application must process the constraint information. In particular, in the Social Semantic Desktop scenario, different applications will use the constraints in different ways. NRL Validators will be expected to check for errors, interactive editors to suggest legal values, and reasoners to perform inference and inconsistency checks.

Class Type Constraints | Range Cardinality Constraints | Resource Relation Constraints
rdfs:domain |  |
rdfs:range |  |
Table 1: NRL Constraints

It should be noted, that the recommendation given for the RDFS constraints in [] is extended to the NRL constraint extensions. Given a possible closed-world view, in order to generate valid NRL data a user (human or machine) should check, prior to using a property, whether the resources are indeed valid candidates which satisfy the constraints.

The following are the classes ([] - [) and properties ([] - []) provided in NRL as constraint extensions to RDF/S.

nrl:TransitiveProperty

  Properties may be defined to be transitive. If a transitive property relates resource X to resource Y as well as Y to resource Z, then it follows that the property also relates X to Z. Semantic views can realize these declarative semantics by generating entailment triples. This class is similar to [owl:TransitiveProperty].

  Note: Transitive properties and their superproperties should not be assigned a maximum cardinality restriction of one. This would contradict the fact that the resource X described above can be transitively related to both Y and Z.

  Note: Transitive properties should not be defined as [] properties. If a transitive functional property relates X to Y, then X cannot be related to other resources by that same property. Thus transitivity cannot hold.

  Note: Transitive properties should not be defined as [] properties. If a transitive inverse functional property relates X to Y, then Y cannot be related to other resources by that same property. Thus transitivity cannot hold.

  Example

  [1] voc:containsFolder is defined as an instance of rdf:Property, applicable to instances of voc:Folder and taking instances of voc:Folder as a values. voc:containsFolder is also defined to be an instance of []

  [2] desktop:MyPapers is defined to be an instance of class voc:Folder. Another voc:Folder, desktop:PublishedPapers is related to desktop:MyPapers by the transitive property voc:containsFolder.

  [3] desktop:PublishedPapers is defined to be an instance of class voc:Folder. Another voc:Folder, desktop:ShortPapers is related to desktop:PublishedPapers by the transitive property voc:containsFolder.

  Since containsFolder is a transitive property, a reasoner can easily deduce that since MyPapers - containsFolder - PublishedPapers and PublishedPapers - containsFolder - ShortPapers, then MyPapers - containsFolder - ShortPapers as well.

      :o1 {
      		...
      		voc:containsFolder rdf:type rdf:Property ;
      		rdf:domain voc:Folder ;
      		rdf:range voc:Folder ;
      		[1] rdf:type nrl:TransitiveProperty . }

      :ib1 {
      		...
      		desktop:MyPapers rdf:type voc:Folder ;
      		[2] 	voc:containsFolder desktop:PublishedPapers .
      		[3] desktop:PublishedPapers rdf:type voc:Folder ;
      				voc:containsFolder desktop:ShortPapers . }

nrl:SymmetricProperty

  Properties can be defined to be symmetric. If a symmetric property relates resource X to resource Y, then it follows that Y is related to X by the same property. Examples follow []. This class is similar to [owl:SymmetricProperty].

nrl:AsymmetricProperty

  Properties can also be defined to be asymmetric. Then if asymmetric property relates X to Y, then Y cannot be related to X by the same property.

nrl:ReflexiveProperty

  Properties can be defined to be reflexive. This would restrict the use of this property to relate a resource to itself. Hence, reflexive properties can only relate resource X to itself.

  Examples

  [1] voc:relatedTopic is defined as an instance of rdf:Property, applicable to instances of voc:Folder and taking instances of voc:Folder as values. relatedTopic is defined to be an instance of [].

  [2] voc:hasTopic is defined as an instance of rdf:Property, applicable to instances of voc:Folder and taking instances of voc:Topic as values. hasTopic is defined to be an instance of [].

  [3] desktop:Publications is defined to be an instance of class voc:Topic. Another voc:Topic, desktop:Research is defined to be a voc:relatedTopic of desktop:Publications.

  Since relatedTopic is a symmetric property, it can be inferred that Publications is a relatedTopic of Research.

  [4] desktop:PublishedPapers is defined to be an instance of class voc:Folder. desktop:PublishedPapers is also stated to have topic desktop:Publications. Since hasTopic is an asymmetric property, a reasoner would know that it is not possible to say that thetopic Publications has as topic thefolder PublishedPapers.

      :o1 {
      		..
      		voc:relatedTopic rdf:type rdf:Property ;
      			rdf:domain voc:Topic ;
      			rdf:range voc:Topic ;
      		[1] rdf:type nrl:SymmetricProperty .
      		voc:hasTopic rdf:type rdf:Property ;
      			rdf:domain voc:Folder ;
      			rdf:range voc:Topic ;
      		[2] rdf:type nrl:AsymmetricProperty . }
      :ib1 {
      		...
      		[3] desktop:Publications rdf:type voc:Topic ;
      			voc:relatedTopic desktop:Research .
      		[4] desktop:PublishedPapers rdf:type voc:Folder ;
      		voc:hasTopic desktop:Publications . }

nrl:FunctionalProperty

  Properties can be defined to be functional. This translates into the property having a minimum cardinality of zero and a maximum cardinality of one for each unique resource that is applied as its domain. Therefore, if a functional property relates resource X to resource Y, then it means that X cannot be forward related to other resources by that same property. In simpler words, the value of such a property for resource X, if stated, is unique. Example follows []. This class is similar to [owl:FunctionalProperty].

nrl:InverseFunctionalProperty

  A property can also be defined to be inverse functional. Such a property implies that the inverse of the property is functional. This does not automatically mean that an inverse property of the property in question is actually defined using []. This translates into the property having a minimum cardinality of zero and a maximum cardinality of one for each unique resource that is applied as its range. Therefore, if such a property relates resource X to resource Y, then it means that Y cannot be backward related to other resources using that same property. In other words, if Y is defined as the property value for one resource, then it cannot be defined as the property value for another resource. This class is similar to [owl:InverseFunctionalProperty].

  Examples

  [1] voc:user is defined as an instance of rdf:Property, applicable to instances of voc:Desktop and taking instances of voc:Person as a values. desktop:user is defined to be an instance of [].

  [2] voc:email is defined as an instance of rdf:Property, applicable to instances of voc:Person and taking string datatypes as values. voc:email is defined to be an instance of [.

  [3] desktop:MyPersonalDesktop is defined to be an instance of class voc:Desktop. It is related to Person desktop:MyUserName by the property voc:user. Since user is a functional property, it can be concluded that this instance of Desktop has only that unique particular instance of Person as user. No other instances of Person can be defined as the user of this Desktop. Under the closed-world assumption this would generate warning over conflicting data.

  [4] desktop:MyUserName is defined to be an instance of class voc:Person with a voc:email value of user.name@host.com. Since email is an inverse functional property, it follows that user.name@host.com cannot belong to other instances of Person. Doing so might result in conflicting data due to NRL's closed-world assumption.

      :o1 {
      		...
      		voc:user rdf:type rdf:Property ;
      			rdf:domain voc:Desktop ;
      			rdf:range voc:Person ;
      		[1] rdf:type nrl:FunctionalProperty .
      		voc:email rdf:type rdf:Property ;
      			rdf:domain voc:Person ;
      			rdf:range <http://www.w3.org/2001/XMLSchema#string> ;
      		[2] rdf:type nrl:InverseFunctionalProperty . }
      :ib1 {
      		...
      		[3] desktop:MyPersonalDesktop rdf:type voc:Desktop ;
      				voc:user desktop:MyUsername .
      		[4] desktop:MyUserName rdf:type voc:Person ;
      				voc:email "user.name@host.com" . }

nrl:cardinality

  This property is a cardinality restriction property. It can be applied to instances of rdf:Property to specify a constraint on the number n of values that the property can have for each unique resource that is applied as its domain. The value allowed for this property is a nonNegativeInteger data value from the XML Schema datatypes. This states that instances of the restricted property must have exactly n semantically distinct values. In order to correctly use the NRL vocabulary, this restriction must be always strictly respected. This property is similar to [owl:cardinality].

nrl:minCardinality

  This property is a cardinality restriction property. It can be applied to instances of rdf:Property to specify a constraint on the minimum number n of values that the property can have for each unique resource it is applied as its domain. The value allowed for this property is a nonNegativeInteger data value from the XML Schema datatypes. This states that instances of the restricted property must have at least n (n or more) semantically distinct values. In particular, properties with a minimum cardinality of one must have at least one value to be semantically valid. Properties whose minimum cardinality constraint is not defined have a default minimum cardinality of zero. In order to correctly use the NRL vocabulary, this restriction must be always strictly respected. This property is similar to the Protégé minimum cardinality property constraints and to [owl:minCardinality].

nrl:maxCardinality

  This property is a cardinality restriction property. It can be applied to instances of rdf:Property to specify a constraint on the maximum number n of values that the property can have for each unique resource it is applied as its domain. The value allowed for this property is a nonNegativeInteger data value from the XML Schema datatypes. This states that instances of the restricted property must have at most n (n or less) semantically distinct values. In particular, a property with a maximum cardinality of zero would be of no use since it should never contain any values. Properties whose maximum cardinality constraint is not defined have a default infinite maximum cardinality. In order to correctly use the NRL vocabulary, this restriction must be always strictly respected. This property is similar to the Protégé maximum cardinality property constraints and to [owl:maxCardinality].

  Examples

  The property desktop:contactEmail is defined as being applicable to voc:ContactPerson and to have a value of voc:EmailAddress. Furthermore a restriction is placed on the minimum cardinality of the values for this property [1]. The minimum number of values for this property is one. This means, that all ContactPerson instances must be assigned at least one EmailAddress.

      :o1 {
      		...
      		voc:contactEmail rdf:type rdf:Property ;
      			rdf:domain voc:ContactPerson ;
      			rdf:range voc:EmailAddress ;
      			[1] nrl:minCardinality "1" . }

  This second example demonstrates the combinatorial use of cardinality constraints on properties. The property voc:firstName is defined as being applicable to voc:ContactPerson and to have a string datatype value. Two restrictions are placed on the minimum [2] and maximum [3] cardinality of the values for this property [2]. The value for both restrictions is set to one. This means, that all ContactPerson instances must be assigned exactly one firstName.

      :o1 {
      		...
      		voc:firstName rdf:type rdf:Property ;
      			rdf:domain voc:ContactPerson ;
      			rdf:range <http://www.w3.org/2001/XMLSchema#string> ;
      		[2] nrl:minCardinality "1" ;
      		[3] nrl:maxCardinality "1" . }

nrl:inverseProperty

  Properties are mainly distinguished by their domain and range. Some properties are the exact inverse of each others, where the range and domain of property A are the domain and range of property B respectively. In order to provide efficient reasoning and query handling, the NRL requires that such inverse functionality of two properties is explicitly stated using the []. Stating that a new property B is the inverse property of predefined property A is equivalent to stating that the range of A is the domain of B and the domain of A is the range of B. This will help enable the logical inference of some implicit statements from other explicit statements. If property A and property B are defined to be inverse properties, stating that resource X is related by property A to resource Y will evoke the statement that resource Y is related by property B to resource X. This property is comparable to Protégé’s inverse property and [owl:inverseOf].

  Example

  [1] voc:hasFile is defined as an instance of rdf:Property, applicable to instances of voc:Folder and taking instances of voc:File as a values.

  [3] voc:inFolder is likewise defined as an instance of rdf:Property, applicable to instances of voc:File and taking instances of voc:Folder as values. The domain of voc:hasFile is equivalent to the range of voc:inFolder, while the range of voc:hasFile is equivalent to the domain of voc:inFolder.

  [2,4] This implicit inverse relationship is explicitly stated in both properties.

      :o1 {
      		...
      	[1] voc:hasFile rdf:type rdf:Property ;
      			rdf:domain voc:Folder ;
      			rdf:range voc:File ;
      		[2] nrl:inverseProperty voc:inFolder .
      	[3] voc:inFolder rdf:type rdf:Property ;
      			rdf:domain voc:File ;
      			rdf:range voc:Folder ;
      		[4] nrl:inverseProperty voc:hasFile . }

# Handling Multiple Models: NRL Named Graph Extensions

In the Social Semantic Desktop domain we take a Named Graphs approach to semantic data. Named Graphs [NGs] are an extension on top of RDF, where every RDF Graph as defined in [] is identified by a name. NGs provide useful additional functionality on top of RDF, particulary with respect to metametadata (data about metadata), provenance and data (in)equivalence issues. This approach is based on the workdescribed in [NAMED GRAPHS] excluding the open-world assumption described there. However, one should note that our definitions for a closed-world and open-world assumption (See Section ) differ slightly from the ones given in [NAMED GRAPHS]. As previously stated NRL does not assume an open-world scenario and although it imposes no semantics per se to the graphs the NRL Semantics are based on a closed-world assumption.

A named graph is a pair (n,g), where n is a unique URI reference denoting the assigned name for the graph g. Such a mappingfixes the graph g corresponding to n in a rigid, non-extensible way. The URI representing n can then be used from any location to refer to the corresponding set of triples belonging to the graph g. In other words, graph names, like namespaces, should be globally unique. A graph g' consistent with a different graph g named n cannot be assigned the same name n. Two different datasets asserting graphs g and g' having the same URI for a name contradict one another.

An RDF triple can exist in a named graph or outside any named graph. However, for consistency reasons, all triples must be assigned to some named graph. For this reason, NRL provides the special named graph []. Triples existing outside any named graph automatically form part of this default graph. This ensures backward compatibility with triples that are not based on named graphs. This approach gives rise to the term RDF Dataset as defined in [SPARQL-QUERY]. An RDF dataset is composed of a default graph and an unlimited number of distinct named graphs. It is formally defined as the set {g, (n1, g1), (n2, g2), . . ., (nn, gn) } comprising of the default graph g and zero or more named graphs (n,g).

NRL distinguishes between Graphs and Graph Roles, in order to have orthogonal modeling primitives for defining graphs and for specifying their role. A graph role refers to the characteristics and content of a named graph (e.g. simple data, an ontology, a knowledge base, etc.) and how the data is intented to be handled. The NEPOMUK Annotation Ontology (Refer to the NAO) includes vocabulary for providing metadata about graph roles. Graph metadata will be attached to these roles rather than to the graphs themselves, because in practice it makes more sense to describe an ontology or a knowledge base rather than an anonymous graph. Roles are more stable than the graphs they represent, and while the graph for a particular role might change constantly, evolution of the role itself is less frequent. An instantiation of a role represents a specific type of graph and the corresponding triple set data. One can contain graph metadata outside or inside the graph being described. Storing graph metadata within the graph itself implies that the graph metadata is also describing itself, which is not something one will always want to have. Therefore its more suitable to keep graph metadata separate from its respective graph, and therefore outside the graph. This means to either contain the metadata in the default graph, or in a dedicated named graph. Since having graph metadata about every existing named graph in the default graph is not practical, it is more suitable to have the graph metadata in separate named graphs. That is, any metadata about a named graph g will be contained within a separate metadata graph gm dedicated for g. A special graph role, [] is used to mark such metadata graphs.

General graph vocabulary is defined in [] while [] is dedicated entirely to graph roles. depicts the class hierearchy supporting NGs in NRL. Graph Roles(yellow) are defined as a subclass of the abstract role superclass nrl:Data, itself being defined as a subclass of the general Graph representation (red). A special Graph specialization (blue) is used as a marker class for Graphs that are represented and identified by a document URL [See ].

Figure 3: NRL Named Graph class hierarchy

## Graph Core Vocabulary

This section specifies the core named graph vocabulary. This consists of top-level named graph elements which represent general graphs. Vocabulary for representation of specific graph roles is described in section [].

nrl:Graph

  This class represents a named graph. An instance of this class will represent a named graph as described in the introduction of this section, where the name of the instance coincides with the name of the graph. It should be noted that all graph role classes described in [] are subclasses of this element [See ]. As such, there will generally be instances of specific graph roles rather than this more generic graph representation. This class is similar to [rdfg:Graph].

nrl:DocumentGraph

  This is a marker class that names graphs via the URL of their containing document. A graph that is completely represented by such a document can be defined to be an instance of this class, whereby the document URL will become the name of that graph.

nrl:subGraphOf

  Graphs can consist of subparts of other more general Graphs. In other terms, a set of triples may form a specific part of a more general set of triples. This property can be used to model such a relationship between two instances of []. This property is the inverse of []. When a graph g is defined to be a subgraph of another graph g', the latter is understood to be the supergraph of g. This property is similar to [rdfg:subGraphOf].

nrl:superGraphOf

  This property can be used to state that one graph subsumes another graph. A supergraph will then consist of one or more subgraphs. This property is the inverse of []. When a graph g' is defined to be a supergraph of another graph g, the latter is understood to be a supgraph of g'. The property [] is a subproperty of this property.

nrl:equivalentGraph

  A set of triples can undergo duplication at a number of separate locations. This property can effectively be used to state that a graph that manifests itself at more than one location under different names is in fact equivalent. Equivalent graphs are simultaneously the subgraph and supergraph of each other. This property is similar to [rdfg:equivalentGraph].

  Note: The term equivalentGraph is subject to the role of the graphs being related. Hence for two graphs to be defined equivalent, they must either have the same role, or be a superrole or subrole of each other as depicted in . When a graph g having a role R is defined to be equivalent to a graph g' having a superrole R', then g' is understood to have the more specific role R. For example, if graph g having role [] is defined as equivalent to graph g' having role [], then it can be said that graph g'has a role of []. However not all graphs can be defined to be equivalent. For example, graph g1having role [] cannot be defined as equivalent to graph g2 if this graph has the role [].

nrl:imports

  This special subproperty of [] models graph imports and can be used to state that an existing named graph g' should be considered as part of graph g. This is akin to saying that g' is a subgraph of g or inversely that g is a supergraph of g'. This property can be used to model graph role data imports. Importing a graph into another means that all the former graph’s data, and semantics, will implicitly form part of the latter. Such modelling is transitive. If graph g is imported into graph g', and g' is imported into graph g'', then g'' also includes the data represented byg. Two graphs g and g' are equivalent if they import each other. When applied to the [] role this property can be used to model ontology imports and in this case this property is similar to [owl:imports]. An incompatibility problem may arise when importing graphs with incompatible semantics to the current graph, or combining multiple graphs with different semantics into a new supergraph.. This incompatibility may however be resolved via semantic views which rectify this problem by aligning the different semantics of the graphs.

nrl:DefaultGraph

  Although triples can exist inside a named graph or outside any named graph, for consistency reasons all triples are required to form part of some named graph. This default graph instance is provided by NRL to serve this requirement. All triples existing outside any named graph (e.g. external triples unaware of NRL's named graph approach), will be assigned to this default graph. The DefaultGraph is disjoint from all other existing named graphs and it is given by the intersection of the complements of all other existing named graphs in the RDF triple space.

## Graph Roles Vocabulary

This section introduces classes and properties provided in NRL that deal with Graph Roles as described in the introduction of and depicted in . This vocabulary is closely tied with the Graph Metadata Vocabulary provided in [NAO]. In fact they can also be considered as graph metadata vocabulary, since the elements are in practice used within graph metadata definitions. However, due to their essential nature they are core NRL elements.

nrl:Data

  This is an abstract class representing all graph roles. All graphs are assigned one of the roles represented by this abstract superclass. It is itself a subclass of [] alongside [] and [].

nrl:Schema

  A schema represents a conceptualisation model. This class is used as a role for a graph that represents data in the form of a schema. It is defined as a subclass of [], and therefore also a subclass of []; and it is a superclass of [].

nrl:InstanceBase

  A graph may represent instances of classes defined using some schema (or ontology) that is represented by another separate graph. This class provides the representation for such graphs. An instance base is a subclass of [], and therefore also a subclass of [].

nrl:Ontology

  An ontology is a more expressive type of schema describing more complex models which may include rule-based knowledge in addition to a relational characterisation. This class represents such a role for a Graph and it can also serve the purpose of an ontology header within RDF/S documents as provided by [owl:Ontology]. This class is a subclass of [] and therefore also a subclass of [] and [].

nrl:KnowledgeBase

  A graph can represent a schema (or ontology) together with a number of instantiations of elements in the same schema (or ontology). Such a graph has a similar role to an instance base with the major difference that it also represents the schema (or ontology) providing the constructs used to define the instances. Therefore this role can be seen as a subset of the intersection of the [] and [] roles, and is in fact defined as a subclass of both these roles.

nrl:Configuration

  Technical configuration data that is irrelevant to general semantic web data can also be represented within a graph, through this role. Other additional roles serving different purposes might be added in the future. This class is a subclass of [].

nrl:GraphMetadata

  This role is useful to mark graphs whose sole purpose is to store metadata about some specific graph. Data about a graph, or Graph Metadata, is thus stored in a corresponding graph that has this role.

nrl:graphMetadataFor

  This property binds a metadata graph to the graph being described. A metadata graph must point to the named graph being described therefore the minimum cardinality is set to 1. Given that in some cases a single metadata graph can provide metadata for multiple graphs, the maximum cardinality is undefined.

nrl:coreGraphMetadataFor

  Although a graph can have multiple metadata graphs that describe it, there can only be one unique core metadata graph which defines the graph's important core properties, e.g. whether it is updatable or otherwise and other important metadata vocabulary. This property identifies such a core metadata graph and points to the graph it describes. It is a subproperty of .

  Note: Sometimes the inverse link (from the subject named graph to its core metadata graph) might be of practical use. However, in order to avoid redundancy in the language, this direction has not been included in NRL. For a more efficient access to a graph's metadata, specific applications might want to establish this direction when loading graphs.

nrl:Semantics

  The declarative semantics for a graph role can be specified by referring to instances of this class. Such an instance will consist of an identifier to a location where the formal semantics of the schema or language used are specified.

nrl:hasSemantics

  Graph roles do not automatically have any semantics, but these can be specified through this property (declarative semantics) with respect to an instance of the special class []. The semantics of a graph role can also be realized (procedural semantics) by instantiating a graph view with a semantic specification over the role (See and ). However this property has a declarative rather than a procedural role.

  Note:A graph role with (virtual) declarative semantics should never be assumed to also carry (realized) procedural semantics.

nrl:semanticsDefinedBy

  This property links instances of the [] class to a URL for a document that defines the formal, non-machine-readable semantics that the instance is representing.

nrl:semanticsLabel

  This trivial property assigns a string label to instances of the [] class, in order to more easily identify and refer to different semantics.

nrl:updatable

  A graph role is stated as being updatable (1) or static (0). A static graph prevents any modifications - any modified versions of the graph must be created as a separate graph. A non-static graph's dataset can be directly modified.

## Named Graph Example

The following example demonstrates the use of NG extensions and is based on TriG [TRIG] as introduced in the introduction of this document. A simple graph in TriG named G (where g is a URI) is syntactically denoted by:

:G {Triple Set}

This example and the one that follows in [] model the dataflow represented in . This example demonstrates how one can make use of the named graph paradigm and the syntax for named graphs presented in this section.

[1] The example starts by defining the required namespaces.

[2-7] Metadata about six different graphs is represented within four metadata graphs.

[3] The metadata graph describing graph ex:o1 given in [8] states that ex:o1 is an ontology (graph with role ontology). [4] ex:o1 is defined to have the declarative semantics defined by the instance RDFS.

[5] RDFS is an instance of nrl:Semantics. It is labelled 'RDF/S' and its semantics are said to be defined by 'http://www.w3.org/TR/rdf-schema#'.

[6] ex:o1_metadata itself is marked as being graph metadata.

[7] ex:o2_metadata says that ex:o2 is graph equivalent to http://www.domain.com/o2.rdfs.

[8] ex:o2_metadata states also that ex:o is an ontology represented by the union of graphs ex:o1 and ex:o2. ex:o is now a supergraph of ex:o1 and ex:o2 (or http://www.domain.com/o2.rdfs). Inversely the named graphs are subgraphs of ex:o.

[9] ex:ib1_metadata states that ex:ib1 is an instance base defined in [9].

[10] ex:kb1_metadata states that ex:kb1 is a knowledge base graph represented by the union of graphs ex:o, ex:ib1 andhttp://www.anotherdomain.com/ib2.rdfs. Alternatively, through the definition of ex:o [5], one can say that ex:kb1 is represented by the union of graphs ex:o1, ex:o2 (orhttp://www.domain.com/o2.rdfs), ex:ib1 and http://www.anotherdomain.com/ib2.rdfs, where the latter graphs are all subgraphs of ex:kb1.

[12] The representation for graph ex:o1 (an ontology) is composed of the definition of a class ex:Person, a class ex:DesktopUser which is also a subclass of ex:Person, and a symmetric property ex:knows which relates instances of ex:Person to other instansces of ex:Person.

[12] The representation for graph ex:ib1 (an instance base) is composed of the definition of an instance of ex:DesktopUser called ex:User1, and two instances of ex:Person called ex:Contact1 and ex:Contact2. ex:Contact1 'knows' ex:Contact2 and ex:User1 while ex:Contact2 'knows' ex:User1. However since ex:knows is a symmetric property, all three instances of ex:Person (or its subclass ex:DesktopUser) 'know' each other.

    [1]  @prefix nrl: <http://www.semanticdesktop.org/ontology/yyyy/mm/dd/nrl#> .
    	 @prefix ex: <http://www.example.org/vocabulary#> .

    [2]  ex:o1_metadata {
    		[3] ex:o1 a nrl:Ontology ;
    		[4] nrl:hasSemantics ex:RDFS .
    		[5] ex:RDFS a nrl:Semantics ;
    				nrl:semanticsDefinedBy "http://www.w3.org/TR/rdf-schema#" ;
    				nrl:semanticsLabel "RDF/S" .
    		[6] ex:o1_metadata rdf:type nrl:GraphMetadata . }

    	 ex:o2_metadata {
    		[7] ex:o2 rdf:type nrl:Ontology ;
    			nrl:equivalentGraph <http://www.domain.com/o2.rdfs> .
    			[8] ex:o rdf:type nrl:Ontology ;
    			nrl:imports ex:o1 ,
    						ex:o2 .
    			ex:o2_metadata rdf:type nrl:GraphMetadata . }

    [9]  ex:ib1_metdata {
    			ex:ib1 rdf:type nrl:InstanceBase .
    			ex:ib1_metadata rdf:type nrl:GraphMetadata . }

    [10] ex:kb1_metadata {
    			ex:kb1 rdf:type nrl:KnowledgeBase ;
    			nrl:imports ex:o ,
    						ex:ib1 ,
    						<http://www.anotherdomain.com/ib2.rdfs> .
    			ex:kb1_metadata rdf:type nrl:GraphMetadata . }

    [11] ex:o1 {
    			ex:Person rdf:type rdfs:Class .
    			ex:DesktopUser rdf:type rdfs:Class ;
    				rdfs:subClassOf ex:Person .
    			ex:knows rdf:type rdf:Property ,
    							  nrl:SymmetricProperty ;
    				rdfs:domain ex:Person ;
    				rdfs:range ex:Person . }

    [12] ex:ib1 {
    			ex:User1 rdf:type ex:DesktopUser .
    			ex:Contact1 rdf:type ex:Person ;
    				ex:knows ex:User1 ,
    						 ex:Contact1 .
    				ex:Contact2 rdf:type ex:Person ;
    					ex:knows ex:User1 . }

The RDF/S Ontology accesible at http://www.domain.com/o2.rdfs and serialized as RDF/XML is given and described as follows.

[1] Required namespaces are defined.

[2] The [] class can be used to define some (ontology) graph metadata about the graph represented by this RDF/S document. Here it states that this is a document graph having the role of an ontology.

Note: Although this is allowed it is not considered best practice, since in this way, given that we state that XML/RDFS files can only encode one graph at a time, one is effectively providing graph metadata within the graph itself. This goes against our notion of keeping metadata about a graph separate from the graph itself, as discussed in [].

[3] A class Desktop is defined.

[4] A property user is defined as relating instances of Desktop to instances of http://www.example.org/vocabulary#DesktopUser defined in ex:g1 in the example above.

    [1] <rdf:RDF
    		xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    		xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
    		xmlns:nrl="http://www.semanticdesktop.org/ontology/yyyy/mm/dd/nrl#">
    		xmlns="http://www.domain.com/o2#">

    		[2] <nrl:Ontology rdf:about="">
    			<rdf:type rdfs:resource="nrl#DocumentGraph"/>
    			<!--Other Graph Metadata--->
    			</nrl:Ontology>

    		[3] <rdfs:Class rdf:ID="Desktop"/>
    		[4] <rdf:Property rdf:ID="user">
    			<rdfs:domain rdf:resource="#Desktop"/>
    			<rdfs:range rdf:resource="http://www.example.org/vocabulary#DesktopUser/>
    			</rdf:Property>
        </rdf:RDF>

The following is the RDF/S instance base serialized as RDF/XML and accessible at http://www.anotherdomain.com/ib2.rdfs:

[1] Required namespaces are defined.

[2] Metadata about the instance base graph represented by this RDF/S document is defined through the use of [].

Note: Although this is allowed it is not considered best practice, since in this way, given that we state that XML/RDFS files can only encode one graph at a time, one is effectively providing graph metadata within the graph itself. This goes against our notion of keeping metadata about a graph separate from the graph itself, as discussed in [].

[3] DesktopA is defined as an instance of o2:Desktop and related to http://www.example.org/vocabulary#User1 through the o2:user property.

    [1] <rdf:RDF
    		xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    		xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
    		xmlns:nrl="http://www.semanticdesktop.org/ontology/yyyy/mm/dd/nrl#"
    		xmlns:o2="http://www.domain.com/o2#"
    		xmlns="http://www.anotherdomain.com/ib2#">

    		[2] <nrl:InstanceBase rdf:about="">
    			<rdf:type rdfs:resource="nrl#DocumentGraph"/>
    			<!--Other Graph Metadata--->
    			</nrl:InstanceBase>

    		[3] <o2:Desktop rdf:ID="DesktopA">
    				<o2:user http://www.example.org/vocabulary#User1>
    				</o2:Desktop>
        </rdf:RDF>

## Imposing Semantics on and Tailoring of Graphs: NRL Graph Views Extensions

A simple named graph consists only of the enumerated triples in the triple set associated with the name, and it does not inherently carry any form of semantics. However in many situations it is desirable to work with an extended or restricted interpretation of a simple syntax-only named graph. These interpretations can be realized by applying rules which enhance named graphs with entailment triples, or return a restricted form of the complete triple set. To preserve the integrity of a named graph, interpretations of a basic named graph should never replace the original. To model this functionality in an intuitive way, while still separating between an original named graph and any number of its interpretations, we introduce the concept of Graph Views.

Graph views, or simply views, are different interpretations for a particular named graph. Formally, a graph view is an executable specification of an input graph into a corresponding output graph. Informally, they can be seen as arbitrary wrappings for a named graph. depicts graph view support in NRL. As can be seen in the figure, views are themselves named graphs (subclass of ). Therefore it is possible to have a named graph that is itself a different interpretation, or view, of another named graph. This modelling can be applied recurrently, yielding a view of a view (or an interpretation of a named graph interpretation, as depicted in ) and so on.

Figure 4: Graph Views in NRL

Views are defined through View Specifications which can execute, via a set of rules in a rule language (e.g. a SPARQL query over a named graph), or via an external application (e.g. an application that performs and returns the transitive closure of rdfs:subClassOf), the View Realization for a particular view. As in the latter example, view realizations can also realize the implicit semantics of a graph according to some language or schema (e.g. RDFS, OWL, NRL etc.). We refer to such a view as a Semantic View and in these are represented by the intersection of [] and Graph Roles. Therefore a semantic view is an instance of graph view that also carries a particular graph role. Semantic views are also depicted in , and one can quite easily draw a parallel between the two figures. One must note that the property [] applies only to semantic views, since only such views realize an explicit form of semantics. One should also note that in contrast to graph roles which have only Declarative Semantics defined through the [] property, semantic views also carry Procedural Semantics, since the semantics of these graphs are always realized and not simply assumed.

### Views Core Vocabulary

This section presents the core vocabulary supporting views in NRL, consisting of the core attributes that apply to views. The following section is specifically dedicated to vocabulary concerning the specification of views.

nrl:GraphView

  This class represents a view over a named graph as introduced in this document, and is itself modeled as a subclass of a named graph. A view is realized through a view specification, defined by an instance of []. The view is linked its view specification through the [] property whereas the named graph that the view applies to is linked by []. An instance of this class will be a realized view over some named graph, and it will consist of the extended or restricted set of RDF triples present in the original named graph.

nrl:viewOn

  This property attaches a view realisation to the respective interpreted named graph by linking instances of [] to respective instances of []. In this way, it is always possible to determine which graph a view is interpreting. Thus both the theoritical and the practical separation between different interpretations of a named graph and the original named graph itself can be retained. As a result, it is always possible to retrieve an original named graph, independently of how many views have been applied over it.

nrl:hasSpecification

  Views are realized according to a given view specification. This property determines the specification for a view by linking instances of [] to instances of []. View specifications are defined through instances of []. This class, its subclasses, attributes and general characteristics are introduced and defined in the following section.

### Views Specification Vocabulary

This section presents the vocabulary supporting graph view specification. These specification are essentially the instructions to how a view is to be realized.

nrl:ViewSpecification

  This class represents a view specification. Every graph view requires an associated view specification. View specifications can take one of two forms, modeled as the two subclasses [] and []. The view specification defines the criteria for the realization of the view. In the case of semantic views, view specifications also state which semantics are realized through the [] property.

nrl:realizes

  This property applies only to subset of views introduced as semantic views (see introduction). It links a semantic view to the formal specifications of the semantics that it realizes. In effect this states that the view should carry the realized, procedural semantics according to the given semantics definition, and not simply the implicit declarative semantics. The overlap in and also in ) between graph roles and views refers to these semantic views which carry both procedural (through this property) and declarative (through []) semantics. This property should be distinguished from the [] property since this property has only a declarative role when it comes to specifying the semantics for a graph.

  Note:For NRL to be valid, all semantic views must carry both procedural and declarative semantics. That is, any view (which can manifest itself also as a graph role) that is linked to some semantics by [], should also be linked to the same semantics by []. This relationship between the two properties is not symmetric and it is perfectly valid for a graph role (that is not a view) to have only non-realized declarative semantics.

nrl:RuleViewSpecification

  This class represents one of the provided forms of view specifications. Views can be specified by referring to a rule language and a corresponding set of required rules within. The view is subsequently realized by executing those rules, generating the required output named graph. The rule language and the selected rules are specified through the [] and [] properties, presented below.

nrl:ruleLanguage

  This property links a rule view specification to the name of the rule language supporting the required rules. The rule language is identified via a string referring to the language name.

nrl:rule

  This property is used to provide the actual rules for a rule view specification, with respect to the selected rule language. The rules (or queries) are provided as a string.

nrl:ExternalViewSpecification

  The second type of view specification supported by NRL refers to an external application, service or program (external realizer) that automatically executes and returns the required view without the need to select any rule or language. The word 'external' refers to the fact that the actual view specification is not given by instances of this class, but is predefined within the external application. External view specifications need only specify the location of the external realizer through the following property.

nrl:externalRealizer

  External view specifications rely on external realizers to realize a particular view. An identifier for the external application, service or program is assigned to the view specification through this property in the form of a string.

### Graph Views Example

The following example is a continuation to that given in [] and it completes the dataflow diagram presented in the introduction []. It demonstrates how the provided syntax supporting graph views can be used effectively. The practical applicability of the introduced views is explained in more detail in the introduction of the document and [].

[1] ex:kb2_metadata states that a new graph with the role of knowledge base, ex:kb2, is a graph view over graph ex:kb1 defined in the example earlieraccording to a view specification ex:rvs.

[2] ex:rvs is the view specification required to realize ex:kb2. It is a rule view specification, and it requires executing two rules from the SPARQL language over the graph that ex:kb2 is interpreting, namely ex:kb1. The view is defined as a semantic realizing view, which semantics are given by ex:RDFSSemantics.

[3] ex:RDFSemantics refers to a document where the formal specification of the procedural semantics realized by the view are given. These semantics are identified by a label, RDFS.

[4] ex:kb3_metadata states that the graph ex:kb3 having role []is a graph view over ex:kb2 according to a view specification ex:evs.

[5] The view specification for ex:kb3 is defined to consist of an external view specification. This in practice means that no specification is given in the graph definition, but the virtual specification is assumed to be within the external application or service that realizes the view. In this case, GraphTaxonomyExtractor will return the required realized view as the graph ex:kb3.

    @prefix nrl: <http://www.semanticdesktop.org/ontology/yyyy/mm/dd/nrl#> .
    @prefix ex: <http://www.example.org/vocabulary#> .
    [1] ex:kb2_metadata {
    			ex:kb2 	rdf:type nrl:KnowledgeBase ,
    							nrl:GraphView ;
    					nrl:viewOn ex:kb1 ;
    					nrl:hasSpecification ex:rvs .
    		[2] ex:rvs 	rdf:type nrl:RuleViewSpecification ;
    					nrl:realizes ex:RDFSSemantics ;
    					nrl:ruleLanguage "SPARQL" ;
    					nrl:rule "CONSTRUCT {?s ?rdfs:subClassOf ?v} WHERE ..." ;
    					nrl:rule "CONSTRUCT {?s ?rdf:type ?v} WHERE ..." .
    		[3] ex:RDFSSemantics rdf:type nrl:Semantics ;
    			    nrl:semanticsDefinedBy "http://www.w3.org/TR/2004/REC-rdf-mt-20040210/ ;
    			    nrl:semanticsLabel "RDFS" . }
    [4] ex:kb3_metadata {
    			ex:kb3 rdf:type nrl:GraphView ,
    				   nrl:KnowledgeBase ;
    			nrl:viewOn ex:kb2 ;
    			nrl:hasSpecification ex:evs .
    		[5] ex:evs rdf:type nrl:ExternalViewSpecification ;
    				nrl:externalRealizer "GraphTaxonomyExtractor" . }

## Deprecated Elements

In general there are three criteria for excluding elements from NRL:

1. Elements with no clear formal semantics.
2. Elements whose complexity cannot be handled.
3. Elements that are NEPOMUK project-specific.
4. Elements that do not belong to the Representation Language layer but rather to lower ontology levels.
5. Elements that have become redundant after introduction of the NRL concepts.

The following is a list of elements which have been excluded from NRL. Some of these elements might be moved to other NEPOMUK ontologies, or removed completely. Given in the table are the reasons why they have been excluded from this ontology, alongside the resulting actions taken.

nrl:Thing | Description
| The superclass of all conceptual classes. See also [SKOS Concept] and [OWL Thing]
Reason
rdfs:Resource satisfies the requirements for a top Resource representation.
Action
Exclude.
nrl:ResourceManifestation | Description
| The superclass of all files or web resources. See also [RDFS Resource]
Reason
Distinction between abstract resource and information resource not required at this level.
Action
Move to upper-level (foundational) ontology.
nrl:Association | Description
| The superclass of n-ary relations. See also [Topic Maps Association]
Reason
Not required at this level.
Action
Move to upper-level (foundational) ontology.
nrl:AssociationRole | Description
| The superclass of relations for N-ary associations. See also [Topic Maps Association]
Reason
Not required at this level.
Action
Move to upper-level (foundational) ontology.
nrl:NRLClass | Description
| The NRL's own class to enable specific extensions.
Reason
No specific restrictions in this ontology requiring an extra class representation.
Action
Move to upper-level(foundational) ontology if required.
nrl:NRLProperty | Description
| The NRL's own property to enable specific extensions.
Reason
No specific restrictions in this ontology requiring an extra property representation.
Action
Move to upper-level(foundational) ontology if required.
nrl:DescribingProperty | Description
| This class defines a class instance to be descriptive rather than relational. Descriptive properties cannot have an inverse. See also [OWL DatatypeProperty]
Reason
Distinction between descriptive and relational properties not required at this level.
Action
Move to upper-level (foundational) ontology.
nrl:RelatingProperty | Description
| This class defines a class instance to be relational rather than descriptive. Only relational properties can have an inverse. See also [OWL ObjectProperty]
Reason
Distinction between descriptive and relational properties not required at this level.
Action
Move to upper-level (foundational) ontology.
nrl:hasNamespace | Description
| Specifies the standard namespace for an ontology with particular attention to the hash or slash problem.
Reason
Not required at this level.
Action
Move to Ontology Metadata Layer provided semantics are clear.
nrl:hasNamespaceAbbreviation | Description
| Provides a means to specify the standard abbreviation for an ontology's namespace.
Reason
Not required at this level.
Action
Move to Ontology Metadata Layer provided semantics are clear.
nrl:isDefinedBy | Description
| A standard for stating which ontology defines a ontology element, to enable more efficient queries.
Reason
Not required at this level.
Action
Move to Ontology Metadata Layer provided semantics are clear.
nrl:directType | Description
| Specifies that a type is a direct type and not a type resulting from transitivity.
Reason
Not required since the introduction of Graph Views.
Action
Unclear
nrl:directSubClass | Description
| Specifies a direct subclass of some class and not a subclass resulting from transitivity.
Reason
Not required since the introduction of Graph Views.
Action
Unclear
nrl:directSubProperty | Description
| Specifies a direct subproperty of some property and not a subproperty resulting from transitivity.
Reason
Not required since the introduction of Graph Views.
Action
Unclear
nrl:altLabel | Description
| The alternative labels for a resource. A thesauri requirement in conjunction with [rdfs:label]. See also [skos:altLabel]
Reason
This is an annotation property.
Action
Move to annotation ontology.
nrl:defaultValues | Description
| The default value/s for a property assigned to instances of a class. Comparable to Protégé's defaultValues slot attribute.
Reason
Not required at this level.
Action
Move to general view ontology.
nrl:hasPart | Description
| This defines a resource as having a subset resource.
Reason
No clear formal semantics.
Action
Exclude.
nrl:partOf | Description
| This defines a resource as being a subset of another.
Reason
No clear formal semantics.
Action
Exclude.
nrl:hasTopic | Description
| This states the topic of a resource. See also [SKOS isSubejctOf]
Reason
Not required at this level.
Action
Move to annotation ontology.
nrl:isTopicOf | Description
| This states the resource attributed to a topic. See also [SKOS isSubjectOf]
Reason
Not required at this level.
Action
Move to annotation ontology.
nrl:occurrence | Description
| This points to an instance of a specific resource. See also [Topic Maps Occurences] and [SKOS hasSubject]
Reason
No formal semantics.
Action
Exclude.
nrl:isOccurenceOf | Description
| This points to a resource classifying this and other similar instances. See also [Topic Maps Occurences] and [SKOS hasSubject]
Reason
No formal semantics.
Action
Exclude.

# NRL Semantics

Note: The Semantics of NRL will be formally specified at a later version of the language.

# References

[NAMED GRAPHS]

  Named Graphs, Provenance and Trust, J. J. Carroll, C. Bizer, P. Hayes and P. Stickler, Proceedings of WWW2005, May 2005, Japan.

  http://www.w3.org/2004/03/trix/.

[NOTATION3]

  A readable language for data on the Web. Tim Berners-Lee, Editor.

  http://www.w3.org/DesignIssues/Notation3.

[N-TRIPLES]

  N-Triples section in [RDF Specification - Tests]

[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/. [OWL Overview] OWL Web Ontology Language Overview.Deborah L. McGuinness and Frank van Harmelen, Editors, W3C Recommendation, 10 February 2004,

http://www.w3.org/TR/owl-features/.

[RDF]

  Resource Description Framework

[RDF Specification - PRIMER]

  RDF Primer, Frank Manola and Eric Miller, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-primer-20040210/.

[RDF Specification - SYNTAX]

  RDF/XML Syntax Specification, Dave Beckett, Editor, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/.

[RDF Specification - CONCEPTS]

  Resource Description Framework (RDF): Concepts and Abstract Syntax, Graham Klyne and Jeremy J. Carroll, Editors, W3C Recommendation, 10 February 2004,

  http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/.

[RDF Specification - SEMANTICS]

  RDF Semantics, Patrick Hayes, Editor, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-mt-20040210/.

[RDF Specification - MS]

  Resource Description Framework (RDF) Model and Syntax, W3C Recommendation, 22 February 1999

  http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/.

[RDF Specification - TESTS]

  RDF Test Cases, Jan Grant and Dave Beckett, Editors, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-testcases-20040210/.

[RDFS Specification]

  RDF Vocabulary Description Language 1.0: RDF Schema, Dan Brickley, R.V. Guga, Brian McBride, W3C Recommendation, 10 February 2004,

  http://www.w3.org/TR/2004/REC-rdf-primer-20040210/.

[SPARQL-QUERY]SPARQL Query Language for RDF, E. Prud'hommeaux, A. Seaborne, Editors. World Wide Web Consortium. 23 November 2005. Work in progress. This version is http://www.w3.org/TR/2005/WD-rdf-sparql-query-20051123/. http://www.w3.org/TR/rdf-sparql-query/.

[TRIG]TriG Syntax, Chris Bizer, Freie Universität Berlin extends Turtle to serialise [NAMED GRAPHS] http://sites.wiwiss.fu-berlin.de/suhl/bizer/TriG/

.

[TURTLE]

  Terse - RDF Triple language. Dave Beckett, Editor. 04 December 2004.

  http://www.dajobe.org/2004/01/turtle/.