Design Patterns

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

example:

cbnlcore:
      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.

example:

@prefix cbnlcore:    <http://ont.cbnl.org/cb/def/> .
@prefix cbnltop:     <http://ont.cbnl.org/top/def/> .

Lists and Values

example A: example instance of core:Status:

<http://ont.cbnl.org/cb/id/status/Draft>
      rdf:type cbnlcore:Status ;
      rdfs:label "Concept"@nl-nl , "Draft"@en-gb ;
      dcterms:created "2014-8-11"^^xsd:date ;
      dcterms:creator <http://ont.cbnl.org/cb/id/agent/CBNL> ;
      dcterms:modified "2014-8-18"^^xsd:date ;
      dcterms:rightsHolder
              <http://ont.cbnl.org/cb/id/agent/CBNL> ;
      skos:prefLabel "Draft"@en-gb , "Concept"@nl-nl .

       .
     

example B, instance of dcterms:Agent :

<http://ont.cbnl.org/cb/id/agent/CBNL>
      rdf:type dcterms:Agent ;
      rdfs:label "CBNL"@nl-nl ;
      dcterms:created "2014-8-11"^^xsd:date ;
      dcterms:creator <http://ont.cbnl.org/cb/id/agent/CBNL> ;
      dcterms:modified "2014-8-18"^^xsd:date ;
      dcterms:rightsHolder
              <http://ont.cbnl.org/cb/id/agent/CBNL> ;
      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.

example:

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:

cbnlcore:Brug
      a       owl:Class ;
     rdfs:subClassOf
              [ 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

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

example:

core:Brug  dcterms:subject <http://ont.cbnl.org/cb/id/collection/Kunstwerk> ;