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:

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

The following requirements have not been satisfied:

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

The following requirement has been retracted:

This specification provides some recommendations as to the use of some RDF/S elements or constructs [Recommendations for and against the use of RDF/S elements]. 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 Handling Multiple Models: NRL 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].

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

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.

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:

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:

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 Handling Multiple Models: NRL Named Graph Extensions 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 nrl:FunctionalProperty 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 [Imposing Semantics on and Tailoring of Graphs: NRL Graph Views Extensions ]. 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. 

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 [Recommendations for and against the use of RDF/S 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 [Recommendations for and against the use of RDF/S elements]

As discussed earlier [RDF/S and NRL Compatibility] 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.

@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] :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 . }
			

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

It should be noted, that the recommendation given for the RDFS constraints in [rdfs:domain, rdfs:range] 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 ([nrl:TransitiveProperty] - [nrl:InverseFunctionalProperty) and properties ([nrl:cardinality] - [nrl:inverseProperty]) provided in NRL as constraint extensions to RDF/S. 

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 [Graph Roles Vocabulary].

This section introduces classes and properties provided in NRL that deal with Graph Roles as described in the introduction of Handling Multiple Models: NRL Named Graph Extensions and depicted in Figure 3. 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.

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:

This example and the one that follows in [Graph Views Example] 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. 

[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 [nrl:Ontology] 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 [Handling Multiple Models: NRL Named Graph Extensions].

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

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 [Handling Multiple Models: NRL Named Graph Extensions].

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

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. Figure 4 depicts graph view support in NRL. As can be seen in the figure, views are themselves named graphs (subclass of nrl:Graph). 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 Figure 2) and so on.

Figure 5. 

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 Figure 4 these are represented by the intersection of [nrl:GraphView] 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 Figure 1, and one can quite easily draw a parallel between the two figures. One must note that the property [nrl:realizes] 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 [nrl:hasSemantics] property, semantic views also carry Procedural Semantics, since the semantics of these graphs are always realized and not simply assumed. 

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

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

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.