Modelling Guide (MG) for Linked Data (LD)

with Concept Modelling Ontology (CMO)

Version 4. February 2015

Editors: Michel Böhms (TNO), Peter Bonsma (RDF), Bruno Fies (CSTB)

Contents

1.Introduction

2.Design & Implementation Principles

3.Definitions

4.Modelling Guidelines

4.1 Profile 1

4.2 Profile 2

Appendix A: CMO

1.Introduction

This document is a Modelling Guide (MG) for the development/definition of ontologies, sometimes also referred to as “object libraries”. These ontologies are making use of a predefined“Concept Modelling Ontology”(CMO) generic upper ontology containing key modelling constructs for product modelling in general that are not yet part of the standard languages we use (OWL2, RDFS, RDF).

This deliverable focusses on “Modelling”, not “Mapping”. Clearly, the way we model the ontologies has important consequences for the way we deal with the mappings between such ontologies and the linking, transformation and enrichment of databeing instances/individuals of theontologies and their mappings specifications involving mapping rules.

This modelling guide is developed and applied in a variety of projects including the European V-Conand Odysseus projects in which CSTB, RDF and TNO participate.

2.Design & Implementation Principles

  • Maximize reuse of existing open ‘semantic web’ standards (OWL2, RDFS, RDF, SPARQL, LDP, Turtle)
  • Minimize own particular restrictions, extensions and modelling rules for maximum reuse
  • Keep everything as simple as possible (but not too simple)
  • Stick fully to the assumptions by the ‘semantic web’:
  • Open World Assumption (OWA): all OWL ontologies follow the Open World Assumption: all things not asserted are unknown (not false).
  • No (one) Globally Unique IDentifier (GUID) assumption.All identifiers (IDs) for OWL primitives (classes, properties, individuals) are never assumed to be Globally Unique for those primitives. They can be unique names in themselves but one primitive might have more than one such identifier. OWL provides modelling primitives to state explicitly whether identifiers refer to the same or another resource (owl:equivalentClass, owl:equivalentProperty and owl:sameAs).
  • Profiles. Two profiles for the Modelling Guide[1] are defined:

Profile 1 – These are just guidelines for OWL2/RDFS/RDF oradd new modelling primitiveson class level only (for use on the individual level). This profile guarantees maximal reuse and OWL2/RDFS/RDF compliancy without any extra assumption on the language/meta-level. If you can live without the added Profile 2 modelling power THIS is the profile of preference!

Profile 1 – capabilities on top of OWL2/RDFS/RDF:

  • explicit quantity and unit annotation modelling
  • individual level decomposition modelling
  • typical, class-level, decomposition via restrictions on individual decomposition

Profile 2 – Now Profile 1 is extended with a small set of extra primitives on meta-level to enhance modelling power (for use also on the class level). Since the language level itself is adapted, the “standard language”-aspect is compromised for more modelling power.

Profile 2 – capability on top of Profile 1:

  • class level andindividual level requirements modelling. Some forms don’t need meta-level extension but they are kept together as ‘requirement modelling’ capabilities in this profile 2
  • The set of extra modelling primitivesfor both “Profile 1” and “ Profile 2”are modelled asa generic ‘upper ontologies’referred to as CMO. CMO stands for Concept Modelling Ontology and both profiles are distributed asTurtle files: cmo.ttl resp. cmoProfile2.ttl.These ontologies can be imported and reused in/by any other end-user ontology. The used prefix is ”cmo”.
  • The CMO ontologies themselves are available at:
  • The project specific ontologies (and data) using CMO are available at:
  • All relevant ontologies and data will be available for browsing at:
  • All relevant ontologies and data sets will be available for SPARQL querying at:

3.Definitions

Ontology: Anontologyis an abstract, simplified view of a part of reality to be represented for some purpose. An ontology is essentially a set of Concepts, Properties and Relationships, or in OWL-terminology: a set of Classes, Datatype Properties and Object Properties respectively. Furthermore it contains Datatypes and all kinds of Restrictions (cardinality restrictions, universal/existential (owl:allValuesFrom/owl:someValuesFrom) logical restrictions, owl:hasValue restrictions, rdfs:domain and rdfs:range for properties etc.).

Hierarchy: A hierarchy is a set of Classes or Properties connected by a specific Object Property that constitutes a partial or completeorder between those classes. Such object property can be used to say that one class is ‘higher/lower’ than another class. Note: a hierarchy is not necessarily having a tree-structure: one higher class might be associated to 0,1 or more ‘lower’ classes and one lower class might be associated to 0, 1, or more ‘higher’ classes. Often the interest goes to a hierarchy that constitutes a complete order: all classes of an ontology are part of the hierarchy, there are no "hanging classes", classes which have no higher/lower link with other classes.

Taxonomy & Meronomy: A taxonomy is a special kind of hierarchy where the object property connecting the classes is ‘rdfs:subClassOf’ with top-level class“owl:Thing” (the predefined ‘most generic’ class). Another hierarchy example, not directly supported by OWL is a Meronomy where the object property connecting the classes is ‘typicalPart’. In general the focus will bein the first place on taxonomiesbut meronomies are made possible via restrictions where all, in some way restricted properties are interpreted as “typical”. In case of optional properties/parts, explicitly modelling minCard=0 (which implicitly is the default already) for a property,marks it as a qualified hasPart property.

‘Typical’ doesn’t say anything about necessity! This approach is introduced because in OWL anything can be a part of anything else (when not constrained explicitly). Sometimes however, it is handy to make this (optional) relevance explicit so that the end-user can be given a template involving typical/relevant parts for an individual of certain class.

A taxonomy or meronomy or both typically form(s) the "backbone" of an ontology. An example where a meronomy is the backbone of the ontology (instead of a taxonomy) is the Dutch standard NEN-2767-4 for measuring the condition of infra objects.

Decomposition: explicit decomposition will only be applied onindividual level by providing a predefined hasPart object property on class-level. As stated before, typical decomposition will be handled via qualified restrictions on this hasPart object property.

4.Modelling Guidelines

4.1 Profile 1

  1. Language

The language chosen to define ontologies is: OWL 2.

Authoritative reference: OWL 2 Web Ontology Language Primer (Second Edition), W3C Recommendation 11 December 2012,

Since we do not want to restrict ourselves w.r.t. expressivity we allow the “OWL 2 Full profile” to be used, knowing the consequences w.r.t. computational complexity and the limited support by reasoners.OWL uses constructs from RDFSchema and RDF:

  • Authoritative references: RDF Schema 1.1, W3C Recommendation 25 February 2014,
  • RDF 1.1 Concepts and Abstract Syntax, W3C Recommendation 25 February 2014,
  1. Syntax

The syntax form (“format” or “serialization”) chosen in is: Turtle.

Authoritative reference: RDF 1.1 Turtle, Terse RDF Triple Language, W3C Recommendation 25 February 2014,

Issue: a discussion is ongoing about the use of the “Named Graph”concept from RDF1.1 and associated Named Graph serialisations like TriG (being a clean extension of Turtle), JSON-LD and N Triples. Because of conceptual issues (like how to deal with graphs as subjects or objects in statements/triples) and limited software support on the ontology editing/collaboration side (RDF servers playing a role as SPARQL endpoint typically do support named graphs as grouping mechanism); we stick to non-NG Turtle for now. Not all normative W3C specs (like RDF1.1, TriG and JSON-LD) have a consistent story yet.

  1. Direct access

Beside import/export (aka upload/download) of Turtle files we assume direct access via the SPARQL query language.

Authoritative reference: SPARQL 1.1 Overview, W3C Recommendation 21 March 2013.

  1. Natural correspondence (‘interpretation of OWL meta-concepts’)
  • Concepts are modelled as OWL Classes
  • Datatypes are modelled as OWL Datatypes (reusing underlying XSD Datatypes)
  • Attributes are modelled as OWL Datatype Properties
  • In complex cases where “values” are really unsufficient one can always consider a complex property as a Concept and hence represent it as a Class (think material properties)
  • Some predefined attributes reflecting quantities: base quantities like length and time but also derived quantities like velocity, timesPerYear etc.
  • Relationships are modelled as OWL Object Properties
  • One predefined relationship: hasPart
  • Constraints are modelled as OWL Restrictions

EXAMPLES

Class level:

:Bridge rdf:type owl:Class .

:height rdf:type owl:DatatypeProperty .

:isConnectedTo rdf:type owl:ObjectProperty ;

Individual level:

:Bridge_1

rdf:type Bridge ;

:height “10.0”^^xsd:float ;

:isConnectedTo :Road_1 .

Limitations following from modelling attributes directly as properties are known: modelling of complex attributes, units and other meta-info on individual values is compromised but accepted for simplicity. Modelling of attributes as classes is done already in too many incompatible ways which situation we do not want to worsen.

Initiatives modelling attributes as OWL classes (like the Dutch BIR/CBNL) have to be mapped to properties to be compliant to this CMO-based modelling guide.

  1. Class/property naming conventions
  1. A class name always starts with a capital (upper case) letter (“CamelCase”)
  2. A property name always starts with a non-capital (lower case) letter (“camelCase”)
  3. Class and property names are in English.
  4. Classes and properties can have multi-lingual labels using rdfs:label
  5. In case of multiple labels in the same language skos:prefLabel can be used in case one wants to visualize the taxonomies in multiple languages , the preferred labels are then the ‘determined choice’ for the tree-node names per language.
  6. Character names according to RDF1.1 Turtle production rules (UTF-8)
  7. Class and property names are singular.

EXAMPLE (from CBNL):

cbnltop:Activity

rdf:type owl:Class ;

rdfs:subClassOf cbnltop:Object ;

rdfs:label "Activity"@en, "Activiteit"@nl , “Action”@nl, "Aktivitet"@se ;

skos:prefLabel "Activiteit"@nl .

  1. Subclassing

See: Taxonomy concept defined above.

EXAMPLE

:Tunnel

rdf:type owl:Class ;

rdfs:subClassOf :CivilInfraArtefact .

We can also subclass and giving the exact discriminating property value (Dutch example):

:terrainType

rdf:type owl:DatatypeProperty ;

rdfs:range [ ardfs:Datatype ;

owl:oneOf ( "ground"^^xsd:string "water"^^xsd:string )

] .

:Bridge rdf:type owl:Class ;

rdfs:subClassOf :SpanStructure ;

rdfs:subClassOf [ aowl:Restriction ;

owl:hasValue "water"^^xsd:string ;

owl:onProperty :terrainType

] .

It is also possible to use ‘range-like’ discriminators (not just specific values):

:CheapTunnel rdf:type owl:Class ;

rdfs:subClassOf :Tunnel ;

rdfs:subClassOf [ aowl:Restriction ;

owl:allValuesFrom [ ardfs:Datatype ;

owl:onDatatype xsd:float ; owl:withRestrictions ( [ xsd:maxExclusive "6000000"^^xsd:float ] )

] ;

owl:onProperty :cost

] .

Discriminators

When needed, ‘discriminators’ can be specified in OWL as restrictions at the subclass (simple ones like owl:hasValue or more complex ones lie owl:allValuesFrom or even certain data ranges, etc.). In fact, in OWL, any restriction at a subclass differentiates it from its superclass(es).No specific constraints are defined w.r.t. completeness or exclusivity of subclasses. So subclasses not necessary span their whole superclass and can be overlapping.

  1. Individual decomposition

We predefine an instance decomposition object property:

:hasPart

rdf:type owl:ObjectProperty .

This property is not transitive! It defines the direct parts of a whole. The transitive variant can be easily defined and derived if needed. We choose the direct variant for not “counting double” when traversing all parts of a whole in total cost, total energy etc. calculations.

EXAMPLE

:Deck_1

rdf:type :Deck .

:Bridge_

rdf:type :Bridge ;

cmo:hasPart :Deck_1 .

  1. Typical decomposition

As stated earlier, typical decomposition is modelled at classes via restrictions on the hasPart object property in a qualified way. The interpretation is that any property restricted in some way (min/max cardinality, allValuesFrom, someValuesFrom, hasValue…)is by definition relevant for the class hence a “typical”property. For optional properties without constraints we explicitly model explicitly“minCard=0” to indicate this fact.

EXAMPLE

:Bridge

rdf:type owl:Class ;

rdfs:subClassOf [ a owl:Restriction ;

owl:minQualifiedCardinality "0"^^xsd:nonNegativeInteger ;

owl:onClass :Deck ;

owl:onProperty cmo:hasPart ] .

  1. Typical properties

In OWL ontologies Classes and Properties are fully independent. In other modelling language one typically defines properties in the context of a class (like in EXPRESS: ‘Explicit Attributes’ in the context of an ‘Entity’). Not so in OWL: any property can be a property of any class, unless restricted explicitly (i.e. via a domain restriction for a property). This holds for both datatype properties and object properties. The same approach we used for typical parts we apply to typical properties (now non-qualified, i.e. no use of “owl:onClass”):

EXAMPLE

:Bridge

rdf:type owl:Class ;

rdfs:subClassOf [ a owl:Restriction ;

owl:minCardinality "0"^^xsd:nonNegativeInteger ;

owl:onProperty :height ] .

This approach can be used for both datatype properties and object properties (standing for typical relationships in that case).

  1. Domains & Ranges of properties

We do not forbid the use of domains and ranges for OWL properties but warn for the effects for reusability. If a property has a certain domain and/or range defined it can never be undone by a reusing ontology (in fact any restriction stays valid at reuse; you can only add restrictions in a way…). For instance adding a domain in an extended schema for an existing property means that you get two domain clauses that always have the conjecture (AND-logic) interpretation, what is, in general not what you want (“if there is a height, it is the height of a buildingand of a table…”)

If ontologies have existing fixed schemas as source, domain and ranges, can make the ontology more as they were meant (better resemble the original). The classes for which properties are defined become domains for the property. In case of multiple classes having this property the domain becomes a union of these classes (OR-logic). The underlying target datatypes/classes of the property are represented by qualified owl:allValuesFrom restrictions at the class to allow for different ranges of the same property in the context of different classes.

  1. Quantities & Units

There are many (again often incompatible) ways to deal with quantities and units for quantitative properties. Ontologically, a unit is not so very interesting: it’s ‘just’ a scaling agreement for the value of a property. Conceptually, the information of ‘quantity’ for properties is much more interesting since it is dealing with the nature of the properties.

Authoritative reference: ISO 1000:1992(E), Third Edition, 1992-11-01, International Standard, SI[2] units and recommendations for the use of their multiples and of certain other units.

Itis decided to model the existing seven SI base quantities (see Table 1) and a set of commonly used derived quantities (like amount area, energy, velocity, humidity etc.) in CMO which can be specialized into the more specific properties (like width, height, netArea, topSpeed)needed in end-user ontologies. For all quantities we can model their “exponents” and “unit” as annotation. Base units have a trivial “exponents” annotation (just 1 “one”, rest “zeros”).

SI base quantity / SI base unit
length / metre
mass / kilogram
time / second
electricCurrent / ampere
thermodynamicTemperature / kelvin
amountOfSubstance / mole
luminousIntensity / candela

Table1 Seven SI base quantities and their SI base units

In CMO we defined in general:

:quantity

rdf:type owl:DatatypeProperty ;

rdfs:range xsd:float .

:baseQuantity

rdf:type owl:DatatypeProperty ;

rdfs:subPropertyOf :quantity .

:derivedQuantity

rdf:type owl:DatatypeProperty ;

rdfs:subPropertyOf :quantity .

:hasUnit

rdf:type owl:AnnotationProperty ;

rdfs:range xsd:string .

:hasExponents

rdf:type owl:AnnotationProperty ;

rdfs:range xsd:string .

Next we defined the seven SI base quantities (and their standard base SI units):

:length

rdf:type owl:DatatypeProperty ;

rdfs:subPropertyOf :baseQuantity ;

:hasUnit "metre"^^xsd:string ;

:hasExponents "1,0,0,0,0,0,0"^^xsd:string .

:mass

rdf:type owl:DatatypeProperty ;

rdfs:subPropertyOf :baseQuantity ;

:hasUnit "kilogram"^^xsd:string ;

:hasExponents "0,1,0,0,0,0,0"^^xsd:string .

:time

rdf:type owl:DatatypeProperty ;

rdfs:subPropertyOf :baseQuantity ;

:hasUnit "second"^^xsd:string ;

:hasExponents "0,0,1,0,0,0,0"^^xsd:string .

:electricCurrent

rdf:type owl:DatatypeProperty ;

rdfs:subPropertyOf :baseQuantity ;

:hasUnit "ampere"^^xsd:string ;

:hasExponents "0,0,0,1,0,0,0"^^xsd:string .

:thermodynamicTemperature

rdf:type owl:DatatypeProperty ;

rdfs:subPropertyOf :baseQuantity ;

:hasUnit "kelvin"^^xsd:string ;

:hasExponents "0,0,0,0,1,0,0"^^xsd:string .

:amountOfSubstance

rdf:type owl:DatatypeProperty ;

rdfs:subPropertyOf :baseQuantity ;

:hasUnit "mole"^^xsd:string ;

:hasExponents "0,0,0,0,0,1,0"^^xsd:string .

:luminousIntensity

rdf:type owl:DatatypeProperty ;

rdfs:subPropertyOf :baseQuantity ;

:hasUnit "candela"^^xsd:string ;

:hasExponents "0,0,0,0,0,0,1"^^xsd:string .

EXAMPLE

:width

rdfs:subPropertyOf cmo:length ;

:hasUnit "metre"^^xsd:string ;

:hasExponents "1,0,0,0,0,0,0"^^xsd:string .

So, ‘width’ is a specialization of the base quantity ‘length’ (not a derived quantity). Note that unit and exponents information is not inherited but have to be restated for specializations (because they are annotation properties).

Next to the base quantities we can construct derived quantities in an algebraic way described by their ‘exponents’. Clearly the are infinite amount of derived quantities so we only provide a common set in CMO which can be extended by any end-user ontology where needed. See some examples in Table 2.

SI Derived Quantity / Unit / Exponents
velocity / m/s / 1,0,-1,0,0,0,0
acceleration / m/s2 / 1,0,-2,0,0,0,0
volume-density / kg/m3 / -3,1,0,0,0,0,0

Table2 Example of SI derived units

Again, we model the (now non-trivial) exponents as an OWL annotation property. Based on the exponents for the derived quantities we also know their derived units.In CMO we define (see for complete list appendix A):