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

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 [nrl:ViewSpecification] 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 view is generated upon are still intact and they have not been modified by any of the operations. 

1.1 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 restrictions]
• Properties must support cardinality requirements. [See nrl:cardinalty, nrl:minCardinalty and nrl:maxCardinality]
• Representation of ontology models. [See graph role nrl:Ontology]
• Ontology imports must be possible. Ontology management must be provided. [See named graph property [nrl:imports]
• Support for Quads/Named Graphs to record provenance. [See Named Graph Extensions]

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 2.3.3]

1.2 RDF/S and NRL Compatibility

This specification provides some recommendations as to the use of some RDF/S elements or constructs [2.3]. 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 Named Graph Extensions], 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].

1.3 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

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

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

1.6 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 [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 [1.2] in the case of NRL.

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

1.7 NRL and Closed World Vs. Open World Assumptions

2.3. Recommendations for and against the use of RDF/S elements

As discussed earlier [Section 1.2] 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.

2.3.1 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 . }

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

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

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

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

2.4. 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 type constraints). 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 [Table 1]. 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		nrl:cardinality		nrl:TransitiveProperty
rdfs:range		nrl:minCardinality		nrl:SymmetricProperty
		nrl:maxCardinality		nrl:AsymmetricProperty
				nrl:ReflexiveProperty
				nrl:inverseProperty
				nrl:FunctionalProperty
				nrl:InverseFunctionalProperty

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 [nrl:FunctionalProperty] 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 [nrl:InverseFunctionalProperty] 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 [nrl:TransitiveProperty].

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

2.4.2. 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 [5.1.4.]. This class is similar to [owl:SymmetricProperty].

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

2.4.4. 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 [nrl:SymmetricProperty].

[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 [nrl:AsymmetricProperty].

[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 the topic Publications has as topic the folder 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 . }

2.4.5. 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 [3.1.13]. This class is similar to [owl:FunctionalProperty].

2.4.6. 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 [nrl:inverseProperty]. 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 [nrl:FunctionalProperty].

[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 [nrl:InverseFunctionalProperty].

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

2.4.7. 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].

2.4.8. 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].

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

2.4.10. 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 [nrl:inverseProperty]. 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 . }

3. 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 [RDF Specification - CONCEPTS] 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 work described 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 1.7) 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.

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 [nrl:DefaultGraph]. 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, (n₁, g₁), (n₂, g₂), . . ., (n_n, g_n) } 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, [nrl:GraphMetadata] is used to mark such metadata graphs.

General graph vocabulary is defined in [Section 3.1] while [Section 3.2] is dedicated entirely to graph roles. Figure 3 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 3.1.2]. 

Figure 3: NRL Named Graph class hierarchy

3.1. 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 [3.2.].

3.1.1. 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 [3.2] are subclasses of this element [See Figure 3]. 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].

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

3.1.3. 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 [nrl:Graph]. This property is the inverse of [nrl:superGraphOf]. 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]. 

3.1.4. 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 [nrl:subGraphOf]. 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 [nrl:imports] is a subproperty of this property.

3.1.5. nrl: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 Figure 3. 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 [nrl:Ontology] is defined as equivalent to graph g' having role [nrl:Schema], then it can be said that graph g' has a role of [nrl:Ontology]. However not all graphs can be defined to be equivalent.  For example, graph g₁ having role [nrl:InstanecBase] cannot be defined as equivalent to graph g₂  if this graph has the role [nrl:Schema].

3.1.6. nrl:imports

3.1.7. nrl:DefaultGraph

3.2. Graph Roles Vocabulary 

3.2.1. nrl:Data

3.2.6. nrl:Configuration

3.2.8. nrl:graphMetadataFor

3.2.9. nrl:coreGraphMetadataFor

3.2.10. nrl:Semantics

3.2.12. nrl:semanticsDefinedBy

3.2.13. nrl:semanticsLabel

3. Named Graph Example

:G {Triple Set}

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

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

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

4.1. Views Core Vocabulary

4.1.1. nrl:GraphView

4.1.2. nrl:viewOn

4.1.3. nrl:hasSpecification

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

4.2. Views Specification Vocabulary

4.2.1. nrl:ViewSpecification

4.2.2. nrl:realizes

4.2.3. nrl:RuleViewSpecification

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

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

4.2.6. nrl:ExternalViewSpecification

4.2.7. nrl:externalRealizer

4.3 Graph Views Example

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

6. NRL Semantics

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