Design Patterns

Last modified by Lieke Verhelst on 2015/01/08 08:39

This page contains descriptions of design patterns for the CB-NL ontology. A design pattern is a piece of RDF code (in Turtle serialisation) that represents a particular part of the CB-NL.

The CB-NL ontology

The CB-NL ontology statements contain important metadata of the ontology such as information about the version, information about imports


      rdf:type owl:Ontology ;
      rdfs:comment "some comment..."@nl-nl ;
      owl:imports cbnltop: ;
      owl:versionInfo "CBNL model prototype 11/8/2014"@nl-nl .

URL references

Namespace prefixes are used to abbreviate URL references.  Instances in CB-NL, such as enumeration values, do not have a prefix.


@prefix cbnlcore:    <> .
@prefix cbnltop:     <> .

Lists and Values

Values that belong to a list are described as subclasses of the abstract class EnumerationValue.

      a       owl:Class ;
      rdfs:subClassOf cbnlcore:EnumerationValue .

Restricted lists are restricted via owl:OneOf:



owl:oneOf (<> 



                    <>) ;

The values themselves are individuals of these classes. CB-NL individuals are not saved in the same graph as the CB-NL ontology. They are stored in separate, per class graphs. 

example A: example instance of core:Status:

      rdf:type cbnlcore:Status ;
      rdfs:label "Concept"@nl-nl , "Draft"@en-gb ;
      dcterms:created "2014-8-11"^^xsd:date ;
      dcterms:creator <> ;
      dcterms:modified "2014-8-18"^^xsd:date ;
              <> ;
      skos:prefLabel "Draft"@en-gb , "Concept"@nl-nl .


example B, instance of dcterms:Agent :

      rdf:type dcterms:Agent ;
      rdfs:label "CBNL"@nl-nl ;
      dcterms:created "2014-8-11"^^xsd:date ;
      dcterms:creator <> ;
      dcterms:modified "2014-8-18"^^xsd:date ;
              <> ;
      skos:prefLabel "CBNL"@nl-nl .


CB-NL Concepts

CB-NL Concepts are classes that belong to a taxonomy tree. They must have the following qualifications:

a) Properties are associated with classes by means of a subclass construction with a restriction. In CB-NL these property constructions define the semantic difference between the superclass and subclass.


A Brug has the properties "application water" and "function overbruggen"

A VasteBrug is different from a Brug because it has the properties "appearance vast" and "application doorlaathoogte" that are discriminating it from Brug.

b) subclasses obtain properties from all of their superclasses

A VasteBrug has properties from Bridge : "application water" , "function overbruggen" and from itself "appearance vast" and "application doorlaathoogte"

c) because of b) sets of instances that are described by the subclass have properties from the superclasses above

A VasteBrug is a Thing that has "application water" , "function overbruggen" , "appearance vast" and "application doorlaathoogte" .

The rdfs:subClassOf owl:Restriction pattern (bold face) takes care of all the above. Must be defined per property:

      a       owl:Class ;
              [ a       owl:Restriction ;
                owl:onProperty core:hasApplication ;
                owl:someValuesFrom core:Water
              ] ;

This same pattern adds the following meaning to the class Brug: A Brug is anything that has one or more applications and at least one application is of type Water

This represents a discriminating statement that separates the subclass Brug from the superclass PhysicalObject.


Collections are used to group concepts. Collections are not inherited. They are bound to a Concept class via the dcterms:subject owl:AnnotationProperty


core:Brug  dcterms:subject <> ;

Created by Lieke Verhelst on 2014/09/18 09:33

This wiki is licensed under a Creative Commons 2.0 license
XWiki Enterprise 5.3 - Documentation