1

NEDERLANDSE CONCEPTENBIBLIOTHEEK VOOR

DE BOUW (CB-NL)1

MODELING GUIDE

Version 1.2, October 2013

Editor Linda van den Brink (Geonovum) Authors Mick Baggen (RWS) Jaap Bakker (RWS), Chair CB-NL Jakob Beetz (TU/e) Michel Böhms (TNO) Elton Manoku (RWS) Bram Mommers (Arcadis), Secretary CB-NL Ron Nagtegaal (ProRail) Mieke van Nierop (RWS)

1 In English: ‘Dutch Concept Ontology’

2

Colofon

Publishing

Information

Project BIR/CB-NL

Author(s) Michel Böhms, Bram Mommers, Mick Baggen, Jaap Bakker, Elton

Manoku, Mieke van Nierop, Ron Nagtegaal, Jakob Beetz, Linda van

den Brink, Jennifer Oldfield

Date 17-06-2013

Status Approved

Version 1.0

History Version Date Changes Distribution

0.1 04-03-

2013

First draft (Kees Woestenenk) ICT-werkgroep

0.2 11-03-

2013

Second draft (Kees Woestenenk) ICT-werkgroep

0.3 10-04-

2013

Initial feedback & CMO/OWL-info Michel

Böhms processed (Mieke van Nierop)

ICT werkgroep

0.4 15-04-

2013

Restructuring (Michel Böhms & Elton

Manoku)

ICT werkgroep

0.5 21-04-

2013

After meeting Michel/Elton & Input Ron ICT werkgroep

0.5a 21-04-

2013

Add Linda’s URI strategy; added cmo

modeling guidelines

ICT werkgroep

0.6 08-05-

2013

After meeting 21/4 ICT werkgroep

0.7 27-05-

2013

After meeting 13/5 ICT werkgroep

0.8 05-06-

2013

After meeting 29/5 ICT werkgroep

0.9 17-6-

2013

After remote review ICT werkgroep

1.0 17-6-

2013

Released

1.1 Adaptations and clarifications;

BuildingSample added.

1.2 Additional remarks, see AL1.2

3

4

Content

1 Introduction ........................................................................................................................ 6

1.1 Background.................................................................................................................. 6

1.2 Goal of this Guide & Target Audience ........................................................................ 7

1.3 Scope ........................................................................................................................... 8

1.4 Process ......................................................................................................................... 9

1.5 Reading Guide ............................................................................................................. 9

2 Positioning CB-NL: a future proof approach .................................................................... 10

2.1 Positioning CB-NL as country-specific ontology ...................................................... 10

2.2 CB-NL as an autonomous ontology ........................................................................... 11

2.3 Contexts in CB-NL ...................................................................................................... 13

3 Requirements .................................................................................................................... 15

3.1 Introduction .............................................................................................................. 15

3.2 Prerequisites ............................................................................................................. 15

3.3 Principles ................................................................................................................... 16

3.3.1 Modeling constructs ........................................................................................... 16

3.3.2 Unique identification .......................................................................................... 16

3.3.3 Properties ........................................................................................................... 17

3.3.4 Datatypes, quantities and units ......................................................................... 17

3.3.5 Specialization hierarchy (taxonomy) .................................................................. 17

3.3.6 Decomposition hierarchy (whole – part) ........................................................... 17

3.3.7 Topological relationship ..................................................................................... 17

3.3.8 General interrelationships.................................................................................. 17

3.3.9 Cardinalities for properties and relationships ................................................... 17

3.3.10 Constraints ......................................................................................................... 17

3.3.11 Versioning ........................................................................................................... 18

3.3.12 Metadata ............................................................................................................ 18

3.3.13 Archetypes / top level classes ............................................................................ 18

3.3.14 Links/references to external information .......................................................... 18

4 Modeling Approach .......................................................................................................... 19

4.1 Introduction .............................................................................................................. 19

5

4.2 Modeling Language ................................................................................................... 19

4.3 Introduction Web Ontology Language (OWL) ......................................................... 20

4.3.1 OWL2 Subset used ............................................................................................. 22

4.3.2 OWL2 extension for concept modeling .............................................................. 23

4.4 MODELING GUIDELINES ............................................................................................ 24

4.4.1 Introduction ........................................................................................................ 24

4.4.2 Guidelines ........................................................................................................... 24

4.5 Top-level CB-NL ......................................................................................................... 35

4.5.1 Top-level classes ................................................................................................. 35

4.5.2 Top-level relationships ....................................................................................... 36

4.5.3 Extra CB-NL guidelines based on top-level ....................................................... 37

4.6 Five simple steps for end users ................................................................................ 37

4.7 Validation Approach ................................................................................................. 38

5 Sample ontology: BuildingSample.owl .............................................................................. 38

6 Glossary ............................................................................................................................. 42

7 References ......................................................................................................................... 44

8 Open issues ....................................................................................................................... 48

6

1 Introduction

1.1 BACKGROUND

In 2012 the BIR2 decided to start the development of the CB-NL (the Dutch concept library).

This decision was based on the pilot phase in which the need and objective, but also the

configuration, requirements and workplan for the CB-NL were determined. This was

reported in the document “Nederlandse conceptenbibliotheek (CB-NL) Hoofdrapportage

Pilotfase”.

This document is an elaboration of the (modeling) principles as described in the report of the

pilot phase.

The Nederlandse Conceptenbibliotheek (CB-NL) is a library or collection of concepts for the

building knowledge domain. This library is in fact an ontology, which defines concepts and

semantic relations between these concepts.

The starting point for CB-NL is [OWL2]. CB-NL conforms with [ISO 12006-3].

One aspect of the CB-NL ontology is its use as a vocabulary:TODO it contains terms and

definitions in Dutch and English. These terms function as labels or symbols for the concepts

in the library. But this is only a part of the ontology. It also contains a taxonomy: the

concepts are structured in a hierarchy. In this taxonomy concepts can be a subclass of more

than one concept. The ontology also contains non-hierarchical relations between concepts,

making it possible to capture all kinds of knowledge about the world.

The terms vocabulary and ontology are often used to mean

the same or similar things. TODO Usually, the term

controlled vocabulary is used for simple collections of

terms, while the term ontology is most often used when

referring to more complex collections of terms and their

interrelations3.

In this document, we use the terms to mean distinct things.

The controlled vocabulary is seen as the simplest form of a

collection of terms, to which a dictionary, taxonomy and

2 BouwInformatieRaad (Building Information Council). An platform in which different sectors of the construction industry are represented with the objective to increase the use of BIM in the industry. 3 http://www.w3.org/standards/semanticweb/ontology

VOCAB

ULARY

DICTIONARY

TAXONOMY

ONTOLOGY

FIGURE 1: FROM VOCABULARY TO ONTOLOGY

7

ontology each add a layer of information and complexity.

A vocabulary is a collection of terms [ISO 16354] or in other words, a set of domain-

dependent predicates and functions that provide the basis for the statement of facts

[Brachman et al 2004, p32, 209].: all the concepts that play a role in some domain, are

named in the vocabulary. A vocabulary is just a list of names of things. Part of the CB-NL

ontology is a vocabulary. The vocabulary contains terms in Dutch and/or English. These

terms function as labels for the concepts in the library.

A dictionary enriches the terms from a vocabulary with descriptions of their meanings.

A taxonomy is an ordering of concepts in a tree-like structure. The concepts have a name

(vocabulary) and meaning (dictionary). A taxonomy is organized hierarchically, with the

most general concepts at the top and the more specialized ones further down. [Brachman et

al 2004, p172]. The top concepts of the hierarchy are predefined in CB-NL and described

later on in this guideline (see 4.5, Top-level CB-NL).

An ontology, as the term is used in the field of Knowledge Representation, is a catalogue of

the kinds of objects (constants, functions, relations) that are important in a domain4, the

properties those objects will be thought to have, and the relationships among them5. The

kinds of objects in an ontology are also called concepts. The relationships in an ontology are

not necessarily hierarchic. In CB-NL, relationships between concepts such as composition

and behavior (function) are used for their definition.

1.2 GOAL OF THIS GUIDE & TARGET AUDIENCE

The goal of this guide is to describe a complete modeling approach and to provide explicit

requirements to be used by modelers who define concepts in the Nederlandse

Conceptenbibliotheek (CB-NL) ontology. The modeling process consists of modelers

capturing construction knowledge from experts in the Dutch construction domain, and

translating that knowledge into the ontology of CB-NL. The construction domain comprises

all life stages of construction works: client’s brief, design, construction and maintenance.

The target audience are the expert modelers capturing construction knowledge provided by

clients like RWS, RGD and ProRail, consultancy/engineering firms like Arcadis and Movaris,

and contractors like Ballast Nedam, Heijmans and VolkerWessels.

4 a sphere of knowledge, influence, or activity – Merriam Webster dictionary

8

This guide does not describe implementation details. It is one of three documents written by

the ICT working group:

1. This document: defines the modeling approach for the definition of the CB-NL

ontology;

2. “Nederlandse Conceptenbibliotheek – implementation guide”: will define an

organizational implementation approach. It will describe the roles and functions

necessary for the maintenance of CB- NL, procedures for entering new concepts, etc.;

3. “Nederlandse Conceptenbibliotheek – software implementation guide”: will describe

the technical requirements of the software required to realize the CB-NL.

The CB-NL is not a goal in itself. It will be used/exploited in the following three ways in

Building and Civil Infrastructure domains’ life-cycles and supply-chains:

1. For Management: As Knowledge Management framework

2. For Integration: In Information Exchange and Sharing

3. For Innovation: As enabler for new advanced software functionalities

1.3 SCOPE

This report discusses only the modeling approach for CB-NL.

Apart from a limited ‘guiding’ top-level part of CB-NL it does not define CB-NL itself.

In this guide we only focus on semantic aspects like classes and properties defining building

objects in a meaningful way. Representation or even presentation/visualization-aspects like

for shape (‘geometry’) are not in scope although we pay attention to the way such

information can be linked to our semantic definitions.

FIGURE 2: DIFFERENT LEVELS OF SEMANTICS

Individuals or instances are not in scope. TODO This guideline focusses on the semantics of

the CB-NL ontology, and its vocabulary, taxonomy, concept properties, and relationships.

The real content of CB-NL is out of scope TODO, apart from a set of top-level concepts of

which other concepts are derived. ‘Classifications’ as nouns are in scope because they are

equivalent with the meta-concept of taxonomy denoting a specialization hierarchy of

classes.

Finally, this guide is also not a functional specification for CB-NL compliant software

functionalities although decisions made in this guide determine to a large extent the

9

demands and wishes for the open interfaces such software functionalities must, should or

could support.

1.4 PROCESS

We follow an iterative/incremental process where first specifications of this guide by the CB-

NL ICT group are given to the expert modelers to play with and give feedback for

improvement in the form of changes and extensions needed.

A good example here is the need to model ‘topology aspects’ or in simple words: how things

are connected and or bound by each other, quite a relevant topic when modeling

infrastructure networks but also building spaces bounded by walls etc.

Together with CB-NL itself, this modeling guide is a living document and will evolve in time.

The first edition is edited by the ICT group of CB-NL. Together with the growing content of

the ontology the guide will evolve in time as a consequence of feedback from modelers,

implementers and end-users.

Because of the inherent complexity of the subject we will try to constantly relate the theory

and technicalities to examples from daily construction practice.

1.5 READING GUIDE

This document contains the ‘Modeling guide’ for the CB-NL. The document is initially meant

to be used by modeling experts working on the CB-NL and can therefore be considered as

complex and abstract for readers without any modeling knowledge. The reader should be

aware of this because of the risk of misinterpretation. For questions related to the content,

please contact members of the ICT group of the CB-NL.

As described, this document was initially written for CB-NL modelers. But this document is

also very useable for other organizations. For example if third parties want to connect their

ICT systems, tools or own ontologies or classifications (vocabulary) with the CB-NL, and

require more inside in the modeling principles of the CB-NL. But it can also be used only for

inspiration.

10

2 POSITIONING CB-NL: A FUTURE PROOF APPROACH

We observe a strong tendency away from traditional, top-down/centralized, static

information structures to distributed, flexible and highly interconnected and interactive

dynamic ‘clouds of ontologies’. This time there is no small committee thinking up one truth

for the world to stick to but many initiatives, sources and individuals all having their own

valid view and truth.

It’s like the world wide web but now in a “database” perspective, more structured, more

meaningful (‘semantic’), not only for people but also for the software they use.

We can classify different ontologies in the cloud according to different coverage layers:

International/European (like bSDD, the buildingSmart Data Dictionary),

Country-specific (like this CB-NL),

Organization-specific (like for ProRail),

Project-specific (like the RWS Schiphol, Amsterdam, Almere (SAA) project), or even

Individual-specific (like a MickBaggenTaxonomy)

In each layer we can position both open standards and proprietary specifications like those

associated to specific software applications. So an ontology related to the input or output of

Autodesk Revit or Civil3D would be positioned in the international layer and the RWS DISK

(on existing tunnels , bridges etc.) database would be in the organization-specific layer.

2.1 POSITIONING CB-NL AS COUNTRY-SPECIFIC ONTOLOGY

An ontology such as CB-NL could hold an infinite number of concepts. But the CB-NL is not a

standalone collection of concepts. It is part of the larger whole of international ontologies

and standards on the one hand and organizational ones on the other. Positioning CB-NL in

this international and national context is important.

On a higher, international level, there exist lawfully binding agreements such as INSPIRE6, to

which all European countries must adhere, and relevant international ontologies like bSDD7.

CB-NL is an extension of these international ontologies. The relationship is possibly complex.

Classes in CB-NL can be equivalent to properties TODO from an international ontology and

vice versa. Our own national concepts in CB-NL are either subclasses of the concepts from

these international agreements, or mapped to these concepts as having the same meaning.

In the international layer, only those concepts that are common for all countries are present.

CB-NL plays the same role on the national level: it defines only those concepts that are

specific to the Dutch context, but also relevant for all Dutch stakeholders. Thus, CB-NL is a

framework that more specific, organizational ontologies can extend with subclasses of their

6 http://www.geonovum.nl/dossiers/inspire 7 http://www.buildingsmart.org/standards/ifd

11

own. The figure below shows the positioning of CB-NL in an international and national

context.

2.2 CB-NL AS AN AUTONOMOUS ONTOLOGY

Like stated in 2.1, the CB-NL is part of a network of ontologies. This network is open and

accessible for everybody to use or publish their own ontologies. But we also acknowledge

the fact that some ontologies in this network are more relevant to us than others. For

example the bSDD is an important ontology because it is our international gateway to the

construction industry. We support the communication schema of the bSDD (ISO12006-3

V16, IFD) and we even sync information with the bSDD. TODO But besides this cooperation

it must be clear that the CB-NL is completely autonomous. The CB-NL is responsible for

managing the national semantics. The primary processes of the Dutch stakeholders will

depend on the CB-NL. These stakeholders should have total control on the CB-NL and

therefore the CB-NL should stay autonomous in the network of distributed libraries. TODO

FIGURE 3: POSITIONING CB-NL

12

There are three levels of integration / connection of existing national knowledge systems /

standards to CB-NL.

FIGURE 4: LEVELS OF CONNECTION TO CB-NL

Level 1: standards as content of CB-NL

Concepts from standards which are very important to CB-NL are entered as content TODO of

CB-NL. These are: Semantic Concepts and Cheobs. These standards represent common

ground already present in the Dutch building community. Maintenance of these standards is

transferred to the CB-NL organization. T

TODO plaatje over CB-NL core en contexten toevoegen

The concepts from the standard are mapped to concepts that are already present in CB-NL

Core, using, for example, a specialization relationship (other relationships are also possible).

Example: concept ‘door’ from CB-NL gets a subclass ‘outer wall openings’, the lowest level of

the NL-Sfb standard. In addition, the CB-NL concept ‘door’ can get a subclass ‘doors outside’,

which is a concept from the SEL standard. TODO beter bescrhijven. SEL is een context

standard en verwijst naar CB-NL core.

AL1.2

Level 2: References from CB-NL to external concepts

Whenever possible, external references are made from concepts in CB-NL to concepts in

knowledge systems of participating knowledge institutes.

Part of CB-NL content Maintained by

knowledge

institutes .

Maintained by

knowledge

institute

Properties for voor

specific contract:

- Property1

- Property2

- …

Business libraries

Project libraries

Maintained by knowledge

institute

List of properties

- Property1

- Property2

1

2

3

3

13

For example, a concept ‘round air channel’ in CB-NL could have a mapping (equivalent class)

to a class ‘roundairchannel’ from ETIM8, using its unique ID. In ETIM, the properties of the

class are defined. The class is maintained by the responsible knowledge institute. TODO

vaststellen wat nou werkelijk de bedoeling is.

Level 3: References from external knowledge systems to CB-NL

Whenever possible, external knowledge systems contain references from their own

concepts to CB-NL concepts, using the CB-NL concept’s unique ID. The CB-NL does not

maintain external concepts which are associated with CB-NL in this way. TODO

AL1.2

Example:

In a document detailing the costs of a building project references are made to concepts from

CB-NL. If these concepts are used in a BIM model, knowledge of these costs can be linked to

the objects in the BIM. The CB-NL does not maintain any knowledge that refers to BIM in this

way.

Even though CB-NL is ‘higher’ in the hierarchy than an organizational ontology, this does not

mean that it is a strict, unchangeable truth that lower ontologies must adhere to. CB-NL is

the place where commonly shared concepts live. If several stakeholders discover they have a

concept in common, but it is not present in CB-NL, then it can be added. Instead of fixing CB-

NL for say four years, a collaborative, iterative/incremental ‘growth’ process is supported. A

consequence of this is that the history of an ontology and versioning of its concepts is

essential. Earlier content must remain available for projects or organizations who use it.

It also becomes important to know who actually ‘said what about what’ and other

governance aspects like the status of content (accepted, draft, etc).

2.3 Contexts in CB-NL

As becomes clear from the previous paragraph, CB-NL is an ontology based on input from

several existing classifications, vocabularies etc. already in use. CB-NL makes explicit that

different classifications/vocabularies co-exist within the CB-NL ontology9 as separate

contexts. A context indicates for which domain a term is valid and usable.TODO

AL1.2

Besides these collections of terms that are based on existing classifications, a CB-NL “core” is

defined to which the terms from classifications are mapped. Existing classifications are not

mapped to each other, but only to CB-NL core, which acts as an intermediary upper or pivot

8 A standardization organization in the Dutch building domain. 9 In het stuk over de URI strategie leg ik uit dat we verschillende contexten met een vast onderdeel in de URI identifier onderscheiden.

14

ontology. In this way, the most efficient mapping is achieved (it requires far less references

to link all the terms from different contexts to the core, than it does to link them all to each

other).

(Core-)Concepts have a semantic definition, which follows from their place in the CB-NL

ontology, e.g. their super classes and additional defining properties or relationships.

Semantic definitions are needed to be able to map concepts from different sources.

Initially, the CB-NL-core will have at least all defining properties AL12. TODO we hebben

besloten dat we geen datamodel maken maar een woordenboek. Dus wel discriminatoren,

maar geen datamodelleringsconstructies. The management of other properties and

relationships always relates to a context, as a (part of a) name space. These contexts are

maintained by the respective stakeholders such as individual organizations, domain expert

groups or those who make the norms and regulations for the specific contexts.

Name spaces are part of CB-NL, but are managed by their respective owners. TODO term

namespace hier niet goed gebruikt. Concepts in collections from a context provider and

owner must have either a semantic definition, a definition provided in natural language

terms or both. TODO owners mogen in hun eigen context doen wat ze willen?

Verduidelijken. AL1.2 Concepts in collections can be mapped to the core elements in the CB-

NL.

Concepts in collections are related (mapped) to CB-NL core by marking them as equivalent,

using subclassing, composition, or with explicit equivalence relations. AL1.2 TODO Michel

bohms

15

3 REQUIREMENTS

3.1 Introduction

The requirements are split in two categories: prerequisites that are base requirements often

determined externally, and principles, as starting points, typically based on our own

decisions as CB-NL group for CB-NL and its modeling and implementation approach.

3.2 Prerequisites

1. CB-NL will be, just like this guide, a fully open standard that can be accessed and used

by anybody free of charge. Development and maintenance cost will not be covered

by having people to pay for the usage taking away any obstacle for acceptance and

usage and thereby maximize the critical mass.

2. The CB-NL will as much as possible (re)use existing national and international

information standards (like information modeling languages, access mechanisms but

also guidelines or even information structures themselves) AL1.2 where possible,

maximizing reuse and minimizing double work and incompatibilities. Examples

include W3C Semantic Web technology like the Web Ontology Language [OWL2],

BuildingSmart’s Industry Foundation Classes [IFC] and upcoming [IFCforInfra], and

INSPIRE information models.

3. CB-NL should accommodate AL1.2 a variety of stakeholder views where concepts are

defined once and used many times (In Dutch: “eenmalige vastlegging, meervoudig

gebruik”).The scope of CB-NL covers the whole life span and supply-chain ‘matrix’

and involved ‘ disciplines’ of a construction artifact or “ structure”, from the

programming phase (dealing with requirements), via the design and construction

phase to the actual operational and maintenance phase. In other words: the total

Asset Management and Asset Usage management (like ‘ traffic management’).

4. The context of CB-NL covers all construction-related domains: Buildings (residential,

utilities), civil infrastructures, including installation plants and environmental (in the

interpretation of the ‘surroundings’) objects.

5. CB-NL will only cover information structures as determined by laws and regulations

or that are common and relevant for multiple organizations in the construction

sector as a whole. Sub-domains (like UNETO-VNI/2BA for installations, RIONED for

sewerage, or BouwConnect for supplied products) can have their own extensions

(like organizations, projects, individuals etc.). The exact interaction between CB-NL

16

and those ‘ external’ extensions or sub-ontologies should be defined carefully. TODO

wordt elders besproken.

6. Existing information structures like ontologies, dictionaries, libraries, classifications

etc. are taken as starting point for the initial definition of CB-NL where they can be

interrelated (via mechanisms like equivalence rules, subclassing, synonyms etc.). A

good example is the Inspire Transport Network schema [INSPIRE TN] providing high

level concepts like RailwayNode and RoadLink.

7. The use of CB-NL should not in any way limit flexibility.

8. Great care should be taken to ensure CB-NL’s internal consistency. TODO

9. CB-NL will not be a static information structure. It will be a ‘living’ thing where

classes, properties etc. are changed and created all the time. Care should be given in

keeping content and interfaced functionalities compatible in time by retaining the

history in snapshots of the ontology where needed. TODO

10. CB-NL will be developed step-wise where partial results can be utilized and in each

step a cost-benefit analysis will be performed. Modularity is an important

characteristic to enable this.AL1.2 TODO

11. Only the maintainer of CB-NL has authority to change CB-NL content. This maintainer

will be appointed by the Bouw Informatieraad.

3.3 Principles

This paragraph describes the principles of the CB-NL (based on, for example, laws and

regulations like the European Inspire Directives).

3.3.1 MODELING CONSTRUCTS

Modeling constructs in CB-NL are: Classes, Properties for those classes, Datatypes for those

properties (base types like string and integer but also user-defined ones like enumeration

types) and various Interrelationships. TODO

“Concepts” in CB-NL are all things that are modeled as a class, property, datatype, or

interrelationship.

3.3.2 UNIQUE IDENTIFICATION

Each Concept has one unique ID in the scope where it is defined, one semantic definition,

one or more potentially multi-lingual labels and zero or more descriptions.TODO

17

3.3.3 PROPERTIES

Properties are defined in CB-NL as independent entities; by default, a property can be used

with any class. It is possible to make a property mandatory for a class, to define restrictions

for property values, and to give a property a fixed value for a certain class.

3.3.4 DATATYPES, QUANTITIES AND UNITS

The allowed values of data type properties (i.e. properties that have simple values as

content) can be restricted. In case of quantitative properties, a quantity kind must be

indicated on class level (a base quantity kind or a derived quantity kind). In CB-NL quantity

kinds are used as data types for data type properties (i.e. CB-NL states that there is a

property ‘height’ which has as data type the quantity kind ‘Length’). This restriction is

applied sparsely, i.e. only when the value (and unit) is the sole discriminator from other

concepts in its immediate context.

3.3.5 SPECIALIZATION HIERARCHY (TAXONOMY)

There is a predefined interrelationship for concepts to model specialization/generalization,

resulting in subclasses/superclasses. Specialization implies inheritance of all properties of

superclasses to the subclasses.

3.3.6 DECOMPOSITION HIERARCHY (WHOLE – PART)

There is a predefined interrelationship for concepts to model composition/decomposition,

resulting in wholes/parts.

3.3.7 TOPOLOGICAL RELATIONSHIP

It is possible to model how things are connected to and/or bounding each other. For

example, to model civil infrastructure we need to be able to model ‘infra networks (road

and rail networks).

3.3.8 GENERAL INTERRELATIONSHIPS

Besides the previously mentioned predefined relationships, it is possible to model general,

user-defined interrelationships (other than specialization/decomposition/topology).

3.3.9 CARDINALITIES FOR PROPERTIES AND RELATIONSHIPS

A mechanism is available to restrict the minimum and/or maximum cardinality of a property

or relationship in the context of a class. This restriction is applied sparsely, i.e. only when the

multiplicity is the sole discriminator from other concepts in its immediate context.

3.3.10 CONSTRAINTS

Mechanisms are available to define class-level constraints, for example value ranges for

properties. This restriction is applied sparsely, i.e. only when this restriction is crucial for

understanding the nature of the concept described.

18

3.3.11 VERSIONING

Concepts retain the same identification under changes in time or status. The definition of a

concept may change over time, provided that a modified concept is issued as a new version.

Concepts cannot be deleted, invalid concepts are indicated as such by their status.

Snapshots of CB-NL at a certain moment in time are also versioned.

Versioning is a complex subject and still under discussion by the ICT working group. TODO

3.3.12 METADATA

For ontology/concept management mechanisms are available to model various meta-

information (information about information, provenance information) items like source info,

version info, status, etc.

3.3.13 ARCHETYPES / TOP LEVEL CLASSES

There is a pre-modeled top-level of CB-NL. For example, In CB-NL we distinguish between

Spaces and Physical Objects and their relationships like the fact that physical objects form

the boundary of spaces.

3.3.14 LINKS/REFERENCES TO EXTERNAL INFORMATION

It is possible to refer from a concept to external information like explaining documents,

geometry, drawings etc. using a link.

19

4 Modeling Approach

4.1 INTRODUCTION

The modeling approach has three main components: (1) the modeling language chosen, (2) a

set of modeling guidelines for using that language and (3) a top-level part of CB-NL with

extra guidelines of using that top-level in the elaboration of CB-NL.

The choice of language is the first thing, but many modeling guidelines have to be specified

on top of that. Example: the fact that we have ‘concepts’ and give them names is in the

language but the fact that we start with a Capital for the name is a modeling guideline.

Finally we want to define some start of CB-NL (a small number of top level concepts, not

being part of the language but of the CB-NL contents) to kick-start and further guide the

expert modelers.

The proposed modeling approach, as a combination of language, guidelines and CB-NL

specific top-level, covers all prerequisites and principles we specified in chapter 3. The Dutch

contractors who work together in CB-NL have defined this modeling approach as a basis for

information exchange.

This chapter contains the rules for modeling concepts in CB-NL. The definition of CB-NL will

be done fully complaint tot these rules. Deviations will lead to mutually incompatible parts

of CB-NL.

4.2 MODELING LANGUAGE

In CB-NL we decided to use the Web Ontology Language (OWL) as base language. This

language is a good fit for the requirements and principles described in chapter 3. Also, OWL

is an emerging technology that is being adopted by more and more organizations.

This section describes the use of OWL as the CB-NL modeling language. To be more precise

we will use OWL Version 2 [OWL2]. OWL is developed by the World Wide Web Consortium

(W3C) and is a mathematically/logically very well-defined, international and fully generic

open standard for modeling ontologies (and hence ‘concept libraries’). It covers about 90%

of our CB-NL requirements, while not even all the available OWL2 language constructs are

needed. Only a subset of the OWL semantics is used in CB-NL; what this subset is will be

elaborated below. OWL has various, mutually equivalent, syntax forms or ‘serializations’. We

will use the most elegant and user-friendliest of them: Turtle.

The 10% of our language requirements not covered by OWL can be accommodated by

defining a so-called upper ontology covering those missing items that are included/imported

in any further CB-NL compliant end-user ontology. But before defining our own constructs,

20

we reuse elements from existing upper ontologies as much as possible, such as Dublin Core10

[DC], [QUDT]11, and possibly [SKOS]12 (for synonyms, preferred labels etc), and

[GeoSPARQL]13 (for geometry classes).

Beside the Semantic Web and more specifically OWL as system for CB-NL we will make sure

we can tightly connect to two other, secondary, worlds of library modeling from the building

domain:

bSI’s IFD/bSDD

The Dutch COINS BIM (CBIM) initiative

Links to these world are in principle bi-directional. We want to make OWL ontologies

available as IFD and/or COINS libraries and, the other way round, we want to be able to

reuse existing information structures from these worlds as first fillings in CB-NL. TODO

4.3 Introduction Web Ontology Language (OWL)

OWL is the key result of the so-called ‘Semantic Web Activity’ within the World Wide Web

Consortium (W3C), the organization also responsible for the open web standards that drive

the World Wide Web on top of the Internet (HTTP, URI, HTML, XML, XSD, XPath, XQuery, etc.

etc.).

As the name suggest it is a, fully open, international and generic, standard to model

ontologies defined as abstract, simplified views of a part of the world that we wish to

represent for some purpose. What we historically call “Libraries” (knowledge libraries, object

libraries, product libraries, concept libraries) or even Dictionaries (like bSI’s bSDD) are in fact

in OWL-speak “Ontologies”.

The basic principle of the semantic web according to its inventor Tim Berners-Lee is three-

fold:

Anyone can say anything about anything

No one knows everything about anything

My system is most valuable because of its interconnection to its peers

From the earlier ideas on a future-proof approach it is clear that these principles fit very

nicely even if we do not want to put the principle to work to the extreme: we want to

incorporate many views in CB-NL, but in a controlled way. We also know these views will

10 Provides a standardized vocabulary for metadata. 11 Provides a standardized ontology for Quantities, Units, Dimensions and Data Types. 12 Simple Knowledge Organization System 13 Provides a core RDF/OWL vocabulary for geographic information based on ISO standards such as Simple Features [ISO 19125-1].

21

never be complete but will grow in time. Finally a lot of concepts in CB-NL become more

meaningful when related to other views on the same concept.

The principle of the semantic web and its use of ontologies result in some differences with

traditional modeling in EXPRESS, NIAM, UML etc. of the past. For users of these traditional

modeling languages it requires a new way of thinking. We will therefore briefly explain the

differences of this new school of modeling below.

Open World Assumption (OWA)

The basic idea of the OWA is that things not said/stated are “unknown”, instead of “not

true/false”. In traditional modeling the Closed World Assumption (CWA) is used where

things are assumed “false” if not stated “true”. If a CWA database does not state that I have

children it is assumed I have no children, in OWA I could have children but it is unknown.

Other information could be provided at a later date or by someone else, adding to the

knowledge about me. This approach, which is well suited for dynamic concept

libraries/ontologies such as the CB-NL, results in an ever-growing and flexible knowledge

base.

Classes/Sets instead of Types

Some object-oriented modeling approaches allow you to subtype in such a way that some

super type properties are not valid anymore. In the semantic web approach, types are

replaced by more rigorous classes or sets with a very clear semantic meaning. One

consequence is that a subclass always inherits ALL properties of its superclass (since the

subclass stands for a subset of the individuals of the superclass).

Properties are “first class citizens” (just like Classes)

Traditionally many modeling languages start with classes (or entities, or types, or..) as main

modeling construct. Properties are assigned to these classes/entities/types as secondary

concepts. In OWL, Classes and Properties are on equal footing and can be flexibly combined.

Combined with OWA this means that any property can be in principle a property of any class

if not constrained (including object properties like decomposition/“hasPart”: everything

could in principle be a part of anything else, again, if not constrained explicitly).

Properties also cover Relationships (two kinds of properties: data type properties and

object properties)

Traditionally modeling languages split between attribute types and relationship types. Not in

OWL where they are all properties: data type properties in case the range of a property is a

data type (these can be compared with the traditional attribute types) and object properties

if the range of a property is not a data type but another class, referencing individuals of that

class.

22

Traditional: classes/types first, now individuals/instances first

All traditional modeling language start making information structures and then instantiate

them with instances/individuals which should be valid against that schema. With

ontologies/knowledge engineering this is often not the typical way. Ontologies are

developed, but the link between instances and the classes in the ontologies is often derived:

instances are “classified” based on their properties. Because the first focus of CB-NL is the

modeling of an ontology and not the individuals complying to this ontology, this issue will

not directly arise for us. TODO vaag. Besluit nodig over instanties

Besides these principles we have to discuss some special characteristics:

Triples as information atoms

All ontologies and data sets are basically sets of triples and this is made explicit in RDF/OWL.

Every triple functions as a kind of information atom that is in principle independent from any

other triple. This makes it easier to split and merge ontologies and to have alternative views

on the same domain. You could say that triples never change, they are just added or deleted.

Merging ontologies is done by adding all triples together, deleting the double ones and

making sure the result is consistent in itself.

Identification via globally unique web-based Uniform Resource Identifiers (URIs)

Identifiers are globally unique but not globally decided. Every party/authority can have its

own name space where the parties knowledge about concepts and individuals resides, using

their own URI scheme. Explicit modeling constructs are available to say that concepts or

individuals from different name spaces are actually the same or not the same (if this is not

stated explicitly, the OWA applies and it is “unknown”).

4.3.1 OWL2 SUBSET USED

OWL2 is a layered language itself: OWL is using

[RDFS] (and RDF) and RDFS is using [RDF].

Defining a subset of OWL2 means that we

actually define a subset of RDF, RDFS and OWL2

constructs.

OWL2, RDFS, and RDF constructs we use are: FIGURE 5: SEMANTIC WEB LAYERED PROTOCOL STACK

23

owl:Class

reflecting our need for ‘concepts’.

owl:DatatypeProperty

reflecting our needs for ‘properties’

owl:ObjectProperty

reflecting our needs for ‘interrelationships’

also used for predefining decomposition

owl:Restriction

reflecting our needs for defining ‘constraints’ on properties

making use of constructs like owl:onProperty, owl:minCardinality,

owl:maxCardinality, owl:hasValue

owl:Thing

reflecting our needs for a top-level ontology

owl: versionInfo

reflecting our need to specify the version of the construct

rdfs:Datatype

reflecting our needs for ‘datatypes’, defining allowed values for datatype properties

rdfs:subClassOf

reflecting our needs for ‘specialization’

rdfs:label

reflecting our need to ‘name’ things

rdfs:comment

reflecting our need to record ‘descriptions’ of things TODO

rdfs:range

reflecting our need to restrict the values of a property

4.3.2 OWL2 EXTENSION FOR CONCEPT MODELING

In addition to RDFS and OWL, we use a small number of additional upper ontologies. All of

these are maintained by standards organizations or come from big, stable organizations (for

example NASA). The upper ontologies used are:

dct: Dublin Core Terms, http://purl.org/dc/terms/, by DCMI14.

o dct:modified is used to record version dates

o dct:rightsHolder is used to record the owner of a concept TODO

o dct:partOf is used for modeling class-level decomposition. hasPart is not used.

o dct:references is used for referring to related resources (images, geometry,

documents, etc) TODO

o dct:alternative, used to provide alternative ‘names’ (synonyms) for things

o dct:conformsTo, used to reference standards. TODO

14 http://dublincore.org/about-us/

24

qudt: Quantities, Units, Dimensions and Types http://qudt.org/1.1/vocab/quantity,

by NASA. Quantities (as special data types, next to base type and enumeration types)

are reused from the NASA quantity & unit model (www.qudt.org).

geosparql: GeoSPARQL, http://www.opengis.net/ont/geosparql, by OGC15 for

modeling topological relationships.

For some constructs no ontology was yet found that could be reused.

cbnl:status, for the status of the concept.

cbnl:sourceid TODO arjanfor the identifier that links the concept to the source, if the

concept was extracted from a pre-existing source.

4.4 MODELING GUIDELINES

4.4.1 INTRODUCTION

This chapter contains a more detailed description of the previous sections, with specific rules

for the CB-NL ontology regarding its vocabulary, taxonomy, modeling of properties,

composition, etc.

Together with the language defined earlier in this chapter, modeling guidelines will

enable/support the right ‘quality’ of CB-NL in terms of consistency and completeness.

Besides using the same language, all collaborating expert modelers ‘filling’ CB-NL (under the

top-level) should follow these guidelines for the best, compatible results.

Sources for these rules are several existing standards:

[ISO 16354]: Guidelines for knowledge libraries and object libraries

[ISO 19150-2] (draft): Geographic information - Ontology - Part 2: Rules for

developing ontologies in the Web Ontology Language (OWL)

4.4.2 GUIDELINES

4.4.2.1 CLASSES

CB-NL consists of a collection of interrelated classes.

All newly defined classes should be directly or indirectly a subclass of the predefined

archetype classes of the top-level.

Classes should be context and view independent on the higher specialization levels allowing

for alternative contexts/views through subclasses of these levels.

Classes do not only cover tangible things like bridges and buildings but also intangible things

like involvement, interconnection. A good example of such a class (though out of scope) is a 15 http://www.opengeospatial.org/ogc

25

‘marriage’ which can be modeled as a relationship between people but also as a class

(having properties and interrelationships of its own)16.

Each class is encoded as an OWL Class:

cbnl:WallElement

rdfs:label “Wall Element”@en;

rdf:type owl:Class ; TODO

4.4.2.2 CLASS NAMES

Each class has names attached to it as labels. There is at least one name in English and one

name in Dutch (English is required because of connection to international standards),

additional names and additional languages are allowed. The set of names (terms) together

form the CB-NL vocabulary. rdfs:label is used to encode concept names, including a language

tag: TODO

rdfs:label "Wall element"@en , "Wandelement"@nl;

Naming convention for Class labels

• Uppercase-starting

• Singular

• Example: “Sliding door”

4.4.2.3 CONCEPT METADATA

Concepts may have a lexical description: a free-text account of the concept. In addition, each

class and property has attributes for version, version date, status and owner. Owner

information is encoded using Dublin Core [DC] elements.

Versioning metadata on concept level could either be encoded with Dublin Core elements or,

alternatively, CB-NL could use the versioning methods offered in the temporary modeling

environment based on Protégé, the NeON Toolkit and OMV17. This is still under investigation.

TODO

The description can be added in several languages and must always have a language tag. The

description is intended for extra information, but NOT intended to give a definition of the

concept or property. The semantic definition is given by a concept’s place in the ontology,

i.e. a class is defined by its discriminating properties and relationships to other classes.

TODO

For example, description of a fly-over:

16 Typically such objectified relationships are existing dependent of at least 2 or more other cocnepts they are related with (“no marriage for one person”) 17 Ontology Metadata Vocabulary (OMV), http://omv2.sourceforge.net/

26

rdfs:comment “The upper road (above ground) of a grade-separated

junction"@en , "De bovenste weg (boven maaiveld) van een vrije

kruising."@nl ;

Version date: date when the class or property was last changed. The [ISO 8601]

representation of date and time is used (YYYY-MM-DD).

AL1.2 TODO

dct:modified18 “2013-05-22”;

Status: indicates the stage of acceptance of the concept or property in the CB-NL ontology.

Possible values are:

“approved”: the concept/property is an accepted/approved CB-NL member

“checked”: the concept/property is a candidate member of CB-NL, but still under

development and not yet approved.

“draft”: the concept is entered in CB-NL but not yet checked by the CB-NL team.

“final draft”: the concept is checked by the CB-NL team but should be accepted by

external users. For example, a full integrity check of the ontology or the relation with

context ontologies.

“invalid”: the concept is not (no longer) valid to be used.

“transferred”: the concept is merged with another concept.

TODO

The status of every concept is at bootstrap (after conversion) set to “approved”; this means

that only by changing the status to some other value the ontology is in transition (at that

location). Th ontology is published when all statuses are set to “approved”.

There is no Dublin Core term for status metadata, so CB-NL will either define its own:

cb-nl:status “approved”;

Owner: the party responsible for making the resource available.

dct:rightsHolder19 “CB-NL”; TODO

4.4.2.4 IDENTIFICATION: URI-STRATEGY

The concepts defined in CB-NL will be re-used by many organizations for communication within the construction domain. While CB-NL is a central concept library, it is part of a distributed web of more specific concept libraries. For these reasons, it is essential that each CB-NL concept (including its versions) is uniquely and reliably identifiable. W3C recommends20 http-URI’s as identifiers. CB-NL adopts the draft URI strategy for the Netherlands for its identifiers for concepts. The URI pattern prescribed by the draft NL URI strategy and applied in the CB-NL is shown below: 18 http://purl.org/dc/terms/modified 19 http://purl.org/dc/terms/rightsHolder

27

For individual objects (individuals/instances): http://{domain}/{type}/{concept}/{reference}

which translates to CB-NL URI format: http://www.cb-nl.nl/cb/id/{reference}

Note: CB-NL does not contain /doc/ URIs . For definitions of ontology terms:

http://{domain}/def#{concept}

which translates to CB-NL URI format: http://www.cb-nl.nl/cb/def/{concept}

The domain of the URI is: http://www.cb-nl.nl/cb.

CB-NL is an ontology based on input from several existing semantic standards, vocabularies

etc. already in use. It is possible that collisions (i.e. the same terms occurring in several

collections of terms) will occur. To deal with this, the context in which the concept has a

certain meaning must somehow be part of the identifier. For this, the {path} part of the

{domain} is used. This means that CB-NL makes explicit that different semantic

standards/vocabularies co-exist within the CB-NL ontology. TODO

For example:

{domain} {path} {type} {concept}

http://www.cb-nl.nl/cb/ imgeo def Viaduct

http://www.cb-nl.nl/cb/ nen2767-4 def Viaduct

Because of the use of {path} to indicate the context, it is possible to avoid name clashes in CB-NL. A concept named ‘Viaduct’ in both IMGeo and NEN2767-4 can be identified as belonging to either IMGeo or NEN2767-4 by looking at the {path} part of its URI, and can also be distinguished from the corresponding concept ‘Construction’ in the CB-NL core. {concept} This indicates the thing the URI identifies. Concepts in CB-NL are identified with a abbreviated form of the concept label, in british english. An advantage of using concept names as identifiers is that it results in more readable, user-friendly URLs. A possible disadvantage is that different concepts could have the same name. If they are from a different context, this is not a problem because the context is part of the URI. If they are from the same context, care must be taken to distinguish the different concepts by giving them different names; e.g. not ‘bank’, but ‘river bank’ and ‘savings bank’.

20 http://www.w3.org/DesignIssues/LinkedData.html

28

This “disambiguation” step can be taken when and where the issue arises. New concepts with an identical name can be disambiguated by, preferrably, adding the name of the immediate superclass to the name. For example: bank becomes: RiverPart_Bank, as the superclass URI concept name is RiverPart. In conclusion: If one of the alternatives is used in the identifying URI, a UUID could nevertheless be used to ensure the interoperability with IFC and IFD libraries such as bSDD. This UUID could be stored, for example, in a dc:identifier field. An extra check is then necessary to ensure that there are no two things in the ontology with the same identifier. TODO

To point to versions, the NL URI strategy prescribes the use of dates in the URIs after

{concept}. The [ISO 8601] representation: yyyy-mm-dd is used. TODO

URIs for different versions of concepts are constructed. CB-NL needs versioned URI’s,

because:

Realization of construction projects often takes years. Standards that are part of the

tender/contract can change while a building project is still going on. It is therefore

necessary to refer to a certain version of a relevant standard.

In the same way, construction contracts will refer to concepts from CB-NL. If a

relevant concept in CB-NL changes while construction is still going on, this could

create confusion or problems. It must be possible to refer to the specific version of

the concept that was meant in the contract.

It must however also be possible to refer to the latest, current version of a concept. The

draft NL URI strategy does not yet describe how to do this. In CB-NL, the concept’s URI

without version is used for this. If someone uses a URI that does not include the concept’s

version, it is interpreted to refer to the latest, current version of the concept.

Example:

[A] http://www.cb-nl.nl/cb/def/[someName]/2012-02-01 -- old version

[B] http://www.cb-nl.nl/cb/def/[someName]/2013-01-01 -- current version

[C] http://www.cb-nl.nl/cb/def/[ someName]>> redirects to [B]

4.4.2.5 PROPERTY GUIDELINES

Datatype Properties give information about a thing in the form of simple values. They are

defined as independent entities as instances of owl:DatatypeProperty.

Each property has names attached to it as labels. The guidelines for property names are

similar to the guidelines for class names. There is at least one name in English and one name

in Dutch (English is required because of connection to international standards), additional

names and additional languages are allowed. The set of names (terms) together form the

CB-NL vocabulary. rdfs:label is used to encode names, including a language tag:

rdfs:label "wall length"@en , "wandlengte"@nl;

Naming convention for Property labels

29

• Lowercase-starting

• Singular

• Example: “door height”

In OWL, properties are independent things that are not by definition properties of a certain

class like in traditional languages such as EXPRESS or UML. It is possible to make explicit to

which class(es) a property belongs using domain clauses. In CB-NL however, properties are

not hard-coded to belong to a certain class. This means that we do not use domain clauses

for data type properties to keep maximum flexibility (i.e. a property can be used by any class

in accordance with the open world assumption).

When a property is essential to a class, this is defined in CB-NL by stating that this property is

mandatory (i.e. it has a minCardinality=1). In the same way it is possible to state that a

property cannot be used with a certain class by giving it maxCardinality=0.

For example, to define that a class Car has wheels, at least one:

ns:Car a owl:Class ;

rdfs:subClassOf [

a owl:Restriction ;

owl:onProperty ns:hasWheel ;

owl:minCardinality "1"^^xsd:nonNegativeInteger

] .

Every data type property should have a data type defined as range. This can be a standard

data type such as the base types from XML Schema (xs:string, xs:date, etc), or a user defined

data type. Special attention is paid to quantities and units, see paragraph 4.4.2.11.

For example, a property brand with as range the base type xsd:string (=alphanumeric text):

:brand rdfs:range xsd:string .

Properties that are required to discriminate between similar concepts in its direct vicinity

(superclass, sibling classes) may be added this way. The introduction of such properties must

be applied only when no other method is feasible. Other properties can also be added to

CB-NL. TODO

For example, an informal definition of a lock (NL: ‘een sluis’) could be that it is a movable

construction which connects two water bodies with the function of stopping water. The

property ‘isMovable’ is therefore a discriminating property of the concept Lock and is made

a mandatory property (minCardinality=1) of the class Lock. Another property could be the

average amount of times the Lock is moved in a year. This, however, is not part of the

semantic definition (a movable construction which is closed and opened at least xx times a

year…) and therefore this property is not mandatory for the class Lock (although it can be

30

part of CB-NL content), even though it may hold important knowledge for the maintenance

of the lock. TODO fasering

4.4.2.6 CLASS-LEVEL PROPERTY VALUES

Extra semantics can be added to classes by explicitly modeling class level property values.

These values hold for every individual of that class (per definition); they are not ‘free

variables’ anymore for the instances. Typically specialization discriminators can be made

explicit this way.

For example, a 15 inch wheel is a subclass of Wheel where the property ‘diameter’ has a

fixed value:

:Wheel15inch

rdf:type owl:Class ;

rdfs:subClassOf :Wheel ;

rdfs:subClassOf

[ rdf:type owl:Restriction ;

owl:hasValue 0.38 ;

owl:onProperty :diameter

] .

Note that the fixed value is not 15, but 0.38. This is because the default, SI unit of diameter is

meter, not inch. 0.38 meter is 15 inch (see 4.4.2.11 for more on this topic).

4.4.2.7 SPECIALIZATION GUIDELINES

In order to give concepts a place in the taxonomy (the hierarchy of concepts, see 1.1),

specialization relationships are used to connect more specific concepts to more general

(increasingly abstract) ones. In this relationship, we call the general class superclass, and the

specific class subclass.

It is often possible to think of different hierarchies depending on the context of the user. For

example, map makers divide the concept Road into different subclasses by their traffic

function (highway, regional road, local road, cycle path, etc.), road builders according to the

materials used (asphalt road, brick road, dirt road), and maintainers of roads by their

amount of use (main road, area access road, local access road, private access road). Which

property (function, usage, material, or some other criterion) is used to divide a class into

specialized subclasses depends on the context in which the vocabulary is used. The modeler

should be aware of this and only use a single property as a criterion for creating a hierarchy,

not several at the same time. TODO This is in all cases the property inheritance hierarchy:

what holds for any superclass also holds for the subclass. Properties are thus “inherited”.

To indicate that individuals of some concept are a part of individuals of another concept,

specialization is not used. There is a special relationship, ‘composition’, defined for this in

paragraph 4.4.2.8.

31

In addition, the following guidelines must be taken into account when modeling

specialization:

Every class must have at least one superclass (more general class).

Superclasses can have zero or more subclasses and subclasses can have one or more

superclass.

Set theory applies: a clean inheritance approach in which a subclass inherits its

definition (and narrows it down) and inherits all properties from its superclass. The

fact that a class is a subclass of another class means that there is a difference with

this superclass (usually an additional discriminator).

No loops: it is not allowed to model a superclass A with a subclass B, and a class C as

subclass of B, when A is a subclass of C.

Every user-defined class is directly or indirectly a subclass of one of the CB-NL top-

level classes.

Exclusivity among subclasses is modeled explicitly where applicable

Concepts can only specialize into other concepts from the same kind of top level

classes. Spaces specialize in more specific spaces, not in PhysicalObjects etc.

4.4.2.8 COMPOSITION GUIDELINES TODO LIEKE

When a concept is modeled as a construction of parts or elements, we use a composition

relationship (often called: decomposition) to relate the whole to the parts. Only when it is

semantically discriminating, the composition is made part of CB-NL (like with properties).

To encode composition, dct:hasPart21 is used. For example, a Wall is composed of Wall

elements:

:Wall

dct:hasPart :WallElement.TODO fout voorbeeld

Guidelines for composition:

Cardinalities (min or max or both) can be constrained on class level constraining the

instance composition property for certain ranges. To be used when a concept has, by

definition, a minimum and/or maximum number of total parts or specific types of

parts. TODO voorbeeld, bv eenwielige circusfiets.

On class level a ‘whole’ can have zero or more typical ‘parts’ and ‘parts’ can have

zero or more typical ‘wholes’. For example, a pillar can be part of a bridge or part of a

house. TODO fout

No loops. If B is a part of A, and C is a part of B, A cannot be a part of C.

No self-reference. A thing cannot be a part of itself.

21 http://purl.org/dc/terms/hasPart [DC]

32

4.4.2.9 GUIDELINES FOR GENERAL INTERRELATIONSHIPS

In cases where a interrelationship is relevant to a class, but not semantically covered by one

of the available relationships (specialization, composition, topology, or another one defined

in the CB-NL top level), a relationship can be defined for this based on owl:ObjectProperty.

Example: defining a relationship ‘hasPosition’ for the semantic definition of spatial object22.

cbnl:hasPosition

rdfs:label “hasPosition”;

rdf:type owl:ObjectProperty .

4.4.2.10 INTERACTION BETWEEN CLASS, PROPERTY AND DATA TYPE SPECIALIZATION HIERARCHIES

When specializing a class in a subclass we usually want to define a restriction on a (for that

class typical) data type property or object property (relationship). This can be accomplished

by restricting some cardinality (min, max or both) and/or by constraining the values resp.

references the range of the property can take.

This can be done in several ways so we need good guidelines here to get compatible results.

Let’s analyze the two cases.

Case 1: Specializing classes where data type properties are restricted.

In this case we can assume we always deal with value restrictions (it is hard to think up an

example where you specialize according to the cardinality of a data type property). An

example is a RedCar which is a Car having value “Red” for color. To model this, there are

several possibilities:

1. In principle we can just specialize the class and add a restriction at the subclass

specifying that property ‘color’ must have the value “Red” for this subclass. So no

change of property.

:RedCar rdfs:subClassOf [ rdf:type owl:Restriction ;

owl:hasValue “Red” ;

owl:onProperty :color] .

2. Alternatively you could make a sub property redColor (of color) that has a restriction

at this new property for the value. The data type is not changed.

:redColor rdfs:subPropertyOf :color ;

Owl:hasValue “Red” ;

:RedCar rdfs:subClassOf

[ rdf:type owl:Restriction ;

owl:minCardinality “1” ;

owl:onProperty :redColor;] .

3. Finally it is possible to define a new data type “RedColor” having just one

enumeration value being based on the original Color data type that is used as new

range data type for the new property. This seems overly complex in this example, but

22 [ISO 19101]

33

would be logical when the restriction is to a subset of the original values (i.e. the

original list of colors has different shades of red, data type “RedColor” is restricted to

only these colors indicating shades of red).

Option 1 is recommended, except when the restriction is not to a single value but to a subset

of the original values. Then, option 3 is needed. TODO michel

Case 2: Specializing classes where object properties are restricted.

In this case we can have sometimes cardinality restrictions (Unicycles are Cycles with one

Wheel) sometimes value restrictions (17InchWheelCar, a Car having only 17InchWheels as

parts). In case of a value restriction the same situation as above applies involving so-called

QCR’s, Qualified Cardinality Restrictions where the range class is restricted to a certain

subclass.

4.4.2.11 QUANTITIES AND UNITS

For quantities (sometimes also called measures) and units an existing international unit

ontology, QUDT, is used. QUDT stands for “Quantities, Units, Dimensions and Types” and is

being developed by NASA and TopQuadrant. QUDT has two goals:

to provide a unified model of, measurable quantities, units for measuring different

kinds of quantities, the numerical values of quantities in different units of measure

and the data structures and data types used to store and manipulate these objects in

software;

to populate the model with the instance data (quantities, units, quantity values, etc.)

required to meet the life-cycle needs of the Constellation Program engineering

community23.

QUDT has all the definitions and several ways (or use cases as they call it) to use them in

your own ontologies, including the use via data types as applied in CB-NL. If you do not

model units directly but apply quantity kinds on class-level, capturing the more essential

information, there are several ways to treat units. One way is to exchange units in your data

(you should in that case use an allowed unit according to QUDT and use the right value

entities from QUDT). Another approach is to not model/exchange units at all but assume SI

units24 (base and derived). We will for now follow this last approach, especially since

instantiation is not the first priority of CB-NL (this does not mean that we are not interested

at all since class-level constraints also need value instantiation).

Example:

Class: Wheel

23 http://www.qudt.org 24 The International System of Units (SI) specifies a set of seven base units from which all other units of measurement are formed

34

Property: diameter

Data type: Length

Instance/individual:

Value: 0.43 (assuming SI: meter)

QUDT provides us with predefined quantity kinds and units to use in the CB-NL ontology. In

CB-NL, quantity kinds instead of units are used as data types for data type properties whose

value is a quantity of something. Which unit is used for values, is only relevant in specific

contexts or on the data level. Only on rare occasions, when properties are restricted to a

specific value, the unit is relevant in the CB-NL core ontology (see 4.4.2.6).

To link a data type property, for example ‘height’, to a quantity kind, for example ‘Length’,

the range of the property is defined to be of one of the quantity kinds in QUDT:

cbnl:height

rdfs:label “height”

rdfs:range qudt:Length .

QUDT assumes default SI unit for each quantity kind, for example, meter for Length. Thus it

is not necessary to model units in CB-NL or even to make them explicit in ontologies or in the

data. Given the quantity kind used, QUDT knows the corresponding SI unit. This goes for

simple units like meter but also for more complex derived units like meter per second. As

long as the unit is known that way, on the data exchange level it is always possible to

transform values to another unit, or a different unit than the default can be specified on the

data level (in which case the unit of measure is added as metadata to the value).

In cases where class level data type properties are defined, we rely on the QUDT default SI

units.

If we want to deviate from the default units defined in QUDT, we have to specify this in the

CB-NL. It is not yet clear if there is a need for this in CB-NL. If so, this section will be expanded

with information on how to do this.

4.4.2.12 REFERENCES TO EXTERNAL RESOURCES

To refer from a concept to external information like explaining documents, geometry,

drawings etc. using a link, the Dublin Core element dct:references25 is used.

Example:

:Wegmarkering

dct:references “http://nl.wikipedia.org/wiki/Wegmarkering”^^xsd:anyURI;

25 http://purl.org/dc/terms/references

35

Geometry

In CB-NL we (ideally) want to model 100% in a pure semantic way. Semantic properties like

width, height, that define the shape of a thing, can be modeled in CB-NL. When the shape of

a thing is too complex to model in this way and yet needs a geometric representation, this is

added as a reference.

4.4.3 MEMBERSHIP RELATION

AL1.2 A concept may be a member of a collection, which is itself introduced as a collection

concept. This relation is called membership and takes the form of a cbnl:isMemberOf

relation.

For example, a Bridge is a “Spanning construction” but also a member of “Artifical works”

(“Kunstwerk”).

cbnl:ArtificalWorks

rdfs:subClasssOf cbnl:Collection .

cbnl:Bridge

cbnl:isMemberOf cbnl:ArtificalWorks .

AL1.2L

4.5 TOP-LEVEL CB-NL TODO LINDA

Now that we have the language and the guidelines for using that language in place we could

start modeling the CB-NL. It is however wise to do some (limited) pre-modeling for the top-

level of CB-NL. With ‘top-level’ we mean a set of global and/or generic classes, properties,

data types, etc. that all other details/specifics (typical parts and subclasses) by future

modelers have to “stay under”.

In a sense, the top-level of CB-NL (together with the modeling language and modeling

guidelines) should give the modeler exactly the right freedom:

Not too much, as this would result in getting incompatible results for different

modelers, and

Not too little, limiting his/her needs for expression.

The top level structure as presented in the next paragraphs is still under discussion by the CB-

NL ICT working group. TODO linda

4.5.1 TOP-LEVEL CLASSES

For the sake of simplicity, the initial top level structure of CB-NL is a linear list of subclasses

of owl:Thing. Classes may be added to this top level structure if necessary. The suggested

top level classes are: TODO lieke

36

Function

Space

PhysicalObject.

Material

Activity

Document

Party (organization or person)

Mechanism/Tool

A physical object is a manifestation of matter and/or energy and has physical properties such

as mass, color, etc), whereas a Space cannot have these properties.

In addition, the CB-NL top-level structure will accommodate network topology for the

modeling of roads, railways, etc. as network structures. Top-level classes, for example ‘Link’

and ‘Node’ could be added to the top-level classes, potentially on micro, meso and macro26

level. Another option is to add classes and relationships for network topology to a separate

namespace. Network topology in CB-NL will be based on the INSPIRE generic network model

[INSPIRE GNM].

4.5.2 TOP-LEVEL RELATIONSHIPS

Predefined relationships, ‘arch-relationships’, are also available, for example for behavior.

This relationship indicates that a class has a certain behavior, function, or activity (often this

is a defining property for classes). Functions and Function Fulfillers are distinguished from

each other and their typical relationships modeled in CB-NL: relations ‘isFullfilledBy’ and its

inverse ‘fulfills’.

Some important relationships are already available in RDFS/OWL (specialization:

rdfs:subClassOf) or Dublin Core (composition: dct:hasPart). In addition, several top level

relationships are defined in the CB-NL top structure:

Subject relationship Object

Space or PhysicalObject fulfills (Function)

Function or Activity involves (PhysicalObject OR Party)

Space or PhysicalObject isBoundedBy (Space or PhysicalObject)

Space or PhysicalObject dct:hasPart (Space or PhysicalObject)

Physical object madeOf (Material)

Spaces and physical objects both have a spatial manifestation, which means they have a

location and a geometry. This means that all spatial relations like isBoundedBy can occur

26 In the case of roads think about road lanes, sections and segments respectively

37

between spaces and other spaces, spaces and physical objects, or physical objects and other

physical objects.

In addition, the CB-NL top-level structure will accommodate network topology for the

modeling of roads, railways, etc. as network structures. One or more predefined relationships

for modeling topology, i.e. interconnections between nodes and links, could be added to the

CB-NL top level if necessary. These could be based on [ISO 19125-1 which in turn is based on

ISO 19101]. Another possibility is re-using the implementation of these relationships (e.g.

‘disjoint’, ‘touches’, …) in GeoSPARQL. TODO linda

In addition, it is possible to model general relationships (see paragraph 4.4.2.9).

4.5.3 EXTRA CB-NL GUIDELINES BASED ON TOP-LEVEL

This section gives extra integrity rules that apply to the interrelationships between concepts.

Concepts can only decompose in other concepts from the same kind of archetypes. Spaces decompose in spaces, not in PhysicalObjects etc.

Strictness: Mandatory

An activity/function can only be fulfilled by a space/physical object.

Strictness: Mandatory

Two concepts can have an interrelationship only if they are in the same decomposition level. Note: The decomposition level is defined by going up in the decomposition hierarchy

until reaching the top concept.

Strictness: Mandatory

4.6 FIVE SIMPLE STEPS FOR MODELERS

Above we defined all modeling constructs and guidelines used for OWL within CB-NL. Below

we define the subset that is relevant for a modeler defining simple ontologies of his own, as

part of CB-NL using ‘Must-have’ modeling constructs only.

STEP 1: Model relevant classes (English name/label only)

STEP 2: Model data type properties (again (English name/label only) including data

type ranges being often an available ‘quantity’, sometimes an xsd base data type and

sometimes a user-defined enumeration data type

STEP 3: Connect classes and data type properties

38

STEP 4: Connect classes among themselves via specialization

STEP 5: Connect classes among themselves via composition

FIGURE 6: ONTOLOGY IN 5 SIMPLE STEPS

Note that this schematic figure does not give a complete image of CB-NL content. Not all

classes are a specialization of a more generic concept, there are no examples of classes that

have more than one super class, etc. A more complete figure may be provided in a later

version of this modeling guide.

4.7 VALIDATION APPROACH

When validating (parts of CB-NL) we consider two dimensions:

1. the level of validation:

a. OWL only

b. a + Modeling Guidelines

c. a+ b + CB-NL Top Level

2. the degree of automation:

a. implicit by chosen meta-model (“you cannot do it wrong”),

b. explicitly checked automatically,

c. things that cannot be checked automatically (need manual process)

Rules that are categorized under 1c have to do with interaction between concepts in the CB-

NL top level. These extra integrity rules that apply on the interrelationships between

concepts are summarized in paragraph

5 SAMPLE ONTOLOGY: BUILDINGSAMPLE.OWL TODO

39

In order to illustrate the constructs mentioned in this Modeling Guide we provide a Turtle

ontology on a Building sample. This applies in a very restricted fashion all constructs

introduced. In order to understand the buildup of the model, we provide an UML class

diagram; this of course is not the basis for the OWL ontology, but an illustration.

The UML semantics are not followed in a strict sense; we intend to show that all concepts

(and subclasses) must have a sourceid, that all Doors (and subclasses) must have a

hasRotation property, that all Walls (and subclasses) must have a borders object property,

and so on.

All concepts may or must have the specified metadata. For example, Building is encoded as:

cbnl:Building

rdf:type owl:Class ;

rdfs:comment "Een bouwwerk"@nl ;

rdfs:label "Building"@en , "Gebouw"@nl ;

rdfs:subClassOf cbnl:Concept ;

dc:creator "AL"@en ;

terms:alternative "Building construct"@en , "Bouwsel"@nl ;

terms:modified "2013-10-01"^^xsd:string ;

class Model

Building

House

+ cbnl:numberOfQuarters: int

Bridge

Skyway

BuildingPart

+ cbnl:hasHeight: qudt:LengthUnit [0..1]+ cbnl:hasWidth: qudt:LengthUnit [0..1]

Door

+ hasRotation: cbnl:DoorRotations [0..1]

Foundation

Footbridge

Block Material

«enumeration»

cbnl:DoorRotations

Slide Rotate Swing

ApartmentBuildingSlidingDoor

SlidingDoor.type is fixed to "Slide"

AppartmentBuilding.quarters is larger than 1

Wall

Concept

+ cbnl:sourceid: char+ cbnl:status: cbnl:status+ dc:contributor: dct:Agent+ dct:alternative: char [0..*]+ dct:modified: date+ dct:rightsHolder: dct:Agent+ owl:versionInfo: char

Terrain

This association represents the group of terrains and buildings.

A Skyway joins 2 or more Buildings (not Terrains).

A Block is a context ontology is the same asa Building Part in the core ontology..

BuildingParts do not need to specify height and width; this only is relevant when the property is discriminating.

«enumeration»

dct:Agent

CBNL AL LB LV

«enumeration»

cbnl:status

approved checked draft invalid transferred

cbnl:supports

equivalence

0..*geo:coveredBy 1..*

0..*

dct:partOf

0..*

cbnl:borders

1..* 0..*

cbnl:isSetIn

1..2

joins

2..*

0..*

dct:partOf 0..*

40

terms:rightsHolder cbnl:CBNL ;

cbnl:hasStatus cbnl-instance:Draft ;

cbnl:sourceid "300-2" ;

cbnl:supports cbnl:Building ;

owl:disjointWith cbnl:BuildingPart ;

owl:versionInfo "1.0.1"@nl .

Building part is part of a Building part or a Building:

cbnl:BuildingPart

…

terms:isPartOf cbnl:BuildingPart , cbnl:Building .

A Door has a property isSetIn, which is in all cases a Wall. This relation is specific to this

ontology. cbnl:Door

…

rdfs:comment "Een daartoe ontworpen toegang tot een bouwwerk"@nl ;

cbnl:isSetIn cbnl:Wall .

The relation isSetIn is not confined to doors or walls; it can be applied any way convenient.

cbnl:isSetIn

a owl:ObjectProperty ,

owl:IrreflexiveProperty ;

rdfs:comment "A construct is fluently made part of another construct"@en ;

rdfs:label "is set in"@en .

In comparison, Relations between concepts may be expressed using domains and ranges

when this discriminates the relation from other similar relations. An example is the adjoins

relation, which only applies to buildings:

cbnl:adjoins

a owl:ObjectProperty ,

owl:IrreflexiveProperty ,

owl:SymmetricProperty ;

rdfs:label "raakt"@nl , "adjoins"@en ;

rdfs:comment "Adjoins is a relation between two buildings"@en ;

rdfs:domain cbnl:Building ;

rdfs:range cbnl:Building .

The property hasRotation, which is defined by CB-NL, can be applied to any Door, but no

other types of building parts (this is a discriminating property for hasRotation). Sliding door

is a specialization of Door; the Sliding door has a fixed value for the property hasRotation.

cbnl:hasRotation

rdf:type owl:ObjectProperty ;

rdfs:comment "Door rotation type"@en ;

41

rdfs:label "has rotation"@en ;

rdfs:domain cbnl:Door .

cbnl:SlidingDoor

…

cbnl:hasRotation cbnl-instance:Slide .

An Apartment building is a House which has more than 1 quarters. This feature is required as

it sets it apart from other types of houses.

cbnl:AppartementBuilding

a owl:Class ;

…

rdfs:subClassOf cbnl:House ;

rdfs:subClassOf

[ a owl:Restriction ;

owl:onProperty cbnl:numberOfQuarters ;

owl:someValuesFrom

[ a rdfs:Datatype ;

owl:onDatatype xsd:integer ;

owl:withRestrictions

([ xsd:minExclusive 2 ])

]

] . TODO

A Skyway is a Building as well as a Building part; it

joins two buildings (and cannot join a terrain):

cbnl:Skyway

a owl:Class ;

rdfs:label "Traverse"@nl , "Skyway"@en ;

rdfs:subClassOf

cbnl:BuildingPart ,

cbnl:Bridge .

Finally, we specify that a Block in some context ontology is the same as a BuildingPart in the

CB-NL:

:Block a owl:Class ; rdfs:label "Block"@en ; … owl:equivalentClass cbnl-core:BuildingPart .

(Note that cbnl-core prefix is mapped onto the CB-NL core as show above.)

42

6 GLOSSARY

bSDD buildingSMART Data Dictionary. This is the planned ontology by

the bSI. Although not fully clear, the idea is that countries can

submit national parts to this central ontology where they can be

harmonized. The language they plan to use is the International

Framework for Dictionaries (IFD) (ISO 12006-3).

BuildingSMART Initiatve (bSI) International organization for interoperability in the

construction sector. Results are: IDM, IFC (now in version IFC4)

(upcoming: IFCforInfra), IFD, bSDD.

Composition Composition of a compound object from component objects

(example: door = composition of frame, leaf and filling). Inverse

of decomposition.

Concept A description of an abstract (not tangible) ‘thing’, consisting of

(1) terms/labels, (2) definition en (3) properties. Concepts are

associated with other concepts through relationships such as

specialization and decomposition.

Decomposition Inverse of Composition. Indicates from what parts something is

made.

Function The intended workings of a designed object. The process of

designing something generates solutions for functional needs in

the form of function fulfillers. Its function is the reason of

existence for an object.

Function fulfiller An object which is capable of fulfilling a certain function.

Example: a pen is a function fulfiller which makes the function

‘writing’ possible.

Generalisation Inverse of specialisation. Abstraction of a class by removing

properties (example: ‘frame’ is a generalization of ‘door frame’).

Literally: making something more general.

Index An index is a list of contents, sometimes hierarchically,

sometimes a list of keywords. An example index is Nl-SfB, the

Dutch version of the international SfB classification system.

Class A set of concepts that fulfill the same primary function. For

43

example: door, wall, etc.

Object An instance/individual of a concept.

Object library A common term which is used to indicate a library of concepts.

Space Space can be unbounded, but the term usually indicates a

bounded space. The boundaries can be physical or virtual

Specialization Inverse of generalization. Divides a class into subclasses based

on a discriminator. For example, ‘Sliding door’ and ‘Revolving

door’ are specializations of ‘Door’.

44

7 REFERENCES

[BIR]

Nederlandse Conceptenbibliotheek (CB-NL), Hoofdrapportage Pilotfase, november

2012,versie 1.0.

[Brachman et al 2004]

Ronald J. Brachman, Hector J. Levesque Knowledge Representation and Reasoning, Morgan

Kaufmann, 2004 ISBN 978-1-55860-932-7

[CBIM]

NL COINS BIM version 1.0.

http://www.coinsweb.nl/wiki/index.php/COINS_Bouw_Informatie_Model_-_CBIM

[CITYGML]

OGC City Geography Markup Language version 2.0. OGC, 04-04-2012.

http://www.opengeospatial.org/standards/citygml

[CHEOBS]

Cheobs GWW-Objectenbibliotheek. CROW. http://www.gww-ob.nl/

[CMO]

TNO/RDF/CSTB Concept Modeling Ontology (CMO),

http://www.modelservers.org/public/cmo.pptx.

[CROW]

CROW nationaal kennisplatform voor infrastructuur, verkeer, vervoer en openbare ruimte.

http://www.crow.nl/

[DC]

“DCMI Metadata Terms”, 14. Juni 2012,

http://dublincore.org/documents/2012/06/14/dcmi-terms/

[GeoSPARQL]

“OGC GeoSPARQL - A Geographic Query Language for RDF Data” Version 1.0, 2012-09-10.

http://www.opengis.net/doc/IS/geosparql/1.0

[GML]

“Geography Markup Language (GML)” version 3.3, OGC, 07-02-1012.

http://www.opengeospatial.org/standards/gml

45

[IFC]

(IFC)-ISO/PAS16739. Industry Foundation Classes (IFC). buildingSmart Initiative:

http://www.buildingsmart-tech.org/specifications/ifc-overview

[IMGEO]

“Informatiemodel Geografie”, version 2.1. Geonovum, December 2012.

http://geonovum.nl/dossiers/bgtimgeo/destandaard

[INSPIRE GNM]

“D2.10.1: INSPIRE Data Specifications – Base Models – Generic Network Model” Version

1.0rc3, 2013-04-05.

http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/D2.10.1_GenericNetworkMo

del_v1.0rc3.pdf

[INSPIRE TN]

“D2.8.I.7 INSPIRE Data Specification on Transport Networks – Guidelines” version 3.0.1,

2009-10-02.

http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_

TN_v3.0.pdf.

[ISO 12006-3]

NEN-ISO 12002-3:2007 “Building construction - Organization of information about

construction works - Part 3: Framework for object-oriented information”, 1. May 2007

[ISO 16354] ISO 16354 "Guidelines for knowledge libraries and object libraries”, 15. March 2013, http://www.nen.nl/NEN-Shop/Norm/NENISO-163542013-en.htm

[ISO 19101]

ISO 19101:2002 “Geographic information -- Reference model”, 2002.

[ISO 19125-1]

“ISO 19125-1:2004 Geographic information -- Simple feature access -- Part 1: Common

architecture”

Also published as “OpenGIS Implementation Specification for Geographic information -

Simple feature access - Part 1: Common architecture” version 1.2.1, 28. May 2011.

http://portal.opengeospatial.org/files/?artifact_id=25355

ISO 19150-2] “Text final CD for DIS, ISO/CD 19150-2 Geographic information - Ontology -

Part 2: Rules for developing ontologies in the Web Ontology Language (OWL)”. 2013-04-17

[ISO 8601]

46

ISO 8601 : 1988 (E). Data elements and interchange formats - Information interchange -

Representation of dates and times.

[SKOS]

“SKOS Simple Knowledge Organization System Reference” W3C Recommendation 18 August

2009 http://www.w3.org/TR/2009/REC-skos-reference-20090818/

[NEN-ISO/IEC 15288]

NEN-ISO/IEC 15288:2008 “Systems and software engineering - System life cycle processes”

April 2008.

[NEN 2767-4]

NEN 2767-4-1:2011 nl. Conditiemeting - Deel 4: Infrastructuur - Deel 1: Methodiek. 01-07-

2011.

[NEN 3610]

NEN 3610:2011 “Basismodel Geo-informatie - Termen, definities, relaties en algemene

regels voor de uitwisseling van informatie over aan de aarde gerelateerde ruimtelijke

objecten”. Maart 2011.

[NTA 8611]

NTA 8611:2003 nl. Richtlijnen voor objectenbibliotheken. 01-10-2003.

[OWL2]

“OWL 2 Web Ontology Language: Structural Specification and Functional-Style Syntax.” W3C

Recommendation 11 December 2012. http://www.w3.org/TR/2012/REC-owl2-syntax-

20121211/

[QUDT]

Ralph Hodgson and Paul J. Keller “QUDT - Quantities, Units, Dimensions and Data Types in

OWL and XML” 11. September, 2011. http://www.qudt.org/.

[RDF]

“Resource Description Framework (RDF): Concepts and Abstract Syntax”. W3C

Recommendation 10 February 2004. http://www.w3.org/TR/2004/REC-rdf-concepts-

20040210/, http://www.w3.org/RDF/

[RDFS]

“RDF Vocabulary Description Language 1.0: RDF Schema”. W3C Recommendation 10

February 2004. http://www.w3.org/TR/2004/REC-rdf-schema-20040210/

47

[RWS/SAA OTB]

Project SSA A1-A6 Diemen – Almere Havendreef. Sample SSA Objecttypenbibliotheek. Version

1.0, 12-12-2012. http://home.kpn.nl/mbaggen/Bibliotheek%20Mick%20Baggen/index.html

[RWS IB2.0]

RWS InformatieBehoeften (IB2.0, properties for NEN-2767-4)

[SC]

Semantic Concepts. Version 3.1, 2103. http://semanticconcepts.nl/_docsAbout/about_EN.php

[SPARQL]

“SPARQL 1.1 Query Language” W3C Recommendation 21 March 2013.

http://www.w3.org/TR/sparql11-query/

[STABU]

STABU LexiCon. http://www.stabu.org/index.php?id=1439

[UNETO-VNI]

BestandsBeheer Artikelen (2BA) http://2ba.nl/

48

8 OPEN ISSUES

This is a list of open issues that, if they prove to be relevant, may be addressed in later

versions of this modeling guide.

Grouping of concepts (classes, properties) according to different views, disciplines, or

aspects. Could be handled by having a separate “name space” per view, by allowing

different alternative decompositions (e.g. with aspect criterium, one with spatial

criterium), using skos:Collection, etc. Example: properties of building from a Spatial

Quality (NL: “Welstand”) perspective. (source of issue: ICOP + CHEOBS/CROW)

“requirement-properties” such as “min-area”, as opposed to a property “area” which

can be constrained with a requirement (of type “min”). One form can be transformed

in the other. Requirements modeling could be kept entirely outside CB-NL and

positioned more in the application of CB-NL.

In a decomposition, individuals are often not explicitly summed up, but only one

specific individual which occurs a “certain number” of times. Even though this is an

instantiation issue (i.e. it is an issue on the instance level, not the ontology level), the

modeling guide should address this. Possibly, in CB-NL data should be encoded as

real individuals.

More structure in the top-level classes. The linear list of top-level classes could be a

little more structured. A proposal for this:

Starting with a view of the world based on a division in space-like and time-like

things, the following taxonomy results:

SpaceClass

- Space

- PhysicalObject

- Material

- Party (organization or person)

- Mechanism/Tool

- Document

TimeClass

- Function

- Activity

With a little more structure added this becomes:

SpaceClass

- Space

- PhysicalObject

- Material

- Party (organization or person)

- Mechanism/Tool

49

- Document

TimeClass

- Function

- Activity

The structure is then starting to look a bit like COINS … In addition we need logical,

non-tangible objects like objectified relationships (“marriage”):

SpaceClass (compare Semantic Concepts “Appearance”)

- SpatialObject

- PhysicalObject

- Material

- Party

- Organization

- Person

- Mechanism

- Document

- LogicalObject

TimeClass (compare Semantic Concepts “Energy”)

- Function

- Activity