Wiki source code of Positioning CB-NL- a future proof approach

Last modified by Linda van den Brink on 2015/07/22 12:04
Content · Comments (2) · Attachments (2) · History · Information
Hide line numbers
 1: {{toc start="1" depth="4" numbered="false" scope="page"/}}
 2: 
 3: The CB-NL is a part of a current trend: a strong tendency away from traditional, top-down/centralized, static information structures towards distributed, flexible and highly interconnected and interactive dynamic ‘clouds of ontologies’. It facilitates a way of working where there is no small committee thinking up one truth for the world to stick to, but many initiatives, sources and individuals that all have their own valid view and truth.
 4: 
 5: In this respect the CB-NL is similar to the world wide web, but while this is basically built up of pages and hyperlinks, the CB-NL is more like a database, in the sense that the information in it is more structured, more meaningful (‘semantic’). And because of the presence of structure and semantics the information in CB-NL is usable not only for people but also for the software they use.
 6: 
 7: We can classify different ontologies in the cloud according to different levels of coverage:
 8: 
 9: * International/European (e.g. bSDD, the buildingSmart Data Dictionary),
10: * Country-specific (e.g. CB-NL),
11: * Organization-specific (e.g. for ProRail),
12: * Project-specific (e.g. the RWS Schiphol - Amsterdam - Almere (SAA) project), or even
13: * Individual-specific (e.g. a MickBaggenTaxonomy)
14: 
15: In each level or 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.
16: 
17: == 2.1 Positioning CB-NL as country-specific ontology ==
18: 
19: The CB-NL is not a standalone collection of concepts. It is part of the larger whole of international and national ontologies and standards on the one hand and organizational ones on the other. Positioning CB-NL in this international, national and organizational context is important.
20: 
21: On a higher, international level, there exist lawfully binding agreements such as [[INSPIRE>>Glossary#HINSPIRE]], to which all European countries must adhere, and relevant international ontologies like [[bSDD>>Glossary#HbsDD]].
22: 
23: CB-NL is an extension of these international ontologies. The relationship is potentially complex. Things that are modeled as classes and relations in CB-NL could be more or less semantically equivalent to something modeled as a property in the international ontology, or 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.
24: 
25: In the international layer, only those concepts that are common to 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, and common to all Dutch stakeholders. Thus, CB-NL is a framework that more specific, organizational ontologies can extend with subclasses of their own. The figure below shows the positioning of CB-NL in an international and national context.
26: 
27: [[image:cbnlandworld.jpg]]
28: 
29: **Figure: CB-NL and the world around it**
30: 
31: == 2.2 CB-NL as an autonomous ontology ==
32: 
33: As stated in the previous paragraph, the CB-NL is part of a network of ontologies. This network is open and accessible for everybody who wants to use these ontologies or publish their own ontologies. However, some ontologies in this network are more relevant to the CB-NL than others. For example, the bSDD is an important ontology, because it is the international gateway to the construction industry. CB-NL  supports the communication schema of the bSDD ([[ISO12006-3>>References#HISO12006-2]] V16, IFD) and the CB-NL Core will be positioned as a context within the bsDD. However, the CB-NL is completely autonomous. The CB-NL is responsible for managing the national semantics and primary construction 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 will stay autonomous in the network of distributed libraries, i.e. anyone can reference concepts in CB-NL, but only persons authorized by CB-NL can edit the ontology. As a consequence, the CB-NL not only extends, but can also contradict international ontologies on the national level.  
34: 
35: == 2.3 CB-NL Core and Contexts ==
36: 
37: As becomes clear from the previous paragraph, CB-NL is an ontology based on input from several existing vocabularies, ontologies etc. already in use. CB-NL makes explicit that these co-exist within the CB-NL ontology as separate "contexts". A context in CB-NL indicates a specific (sub)domain in which a term is valid and usable. Examples of contexts are IMGeo which contains concepts concerning large scale topographic information, ETIM with concepts for the installation sector, and NEN 2767-4 with concepts for infrastructural construction.
38: [[image:cbnlcoreencontexts.png||height="50%" width="50%"]]
39: 
40: **Figure: CB-NL Core and contexts**
41: 
42: These context ontologies are usually based on existing standards, and are maintained by organizations outside CB-NL. A CB-NL “Core” is defined to which the concepts from these context ontologies are mapped (how this mapping is achieved is described in [[Mappings>>2\. Accessing the CB-NL.Mappings]]). The general principle is that existing context ontologies are not mapped to each other, but only to CB-NL core, which acts as an intermediary upper or pivot 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).
43: 
44: 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. Whenever several stakeholders discover they have a concept in common, but it is not present in CB-NL, 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.
45: 
46: It also becomes important to know who actually ‘said what about what’ and other governance aspects like the status of content (accepted, draft, etc).
47: 
48: Core concepts have a semantic definition, which follows from their place in the CB-NL ontology: their super classes and additional discriminating properties that make them different from the other classes. Semantic definitions are needed to be able to map concepts from different sources. Concepts can also have an auxiliary natural language description during development of the CB-NL content. When a stable CB-NL version is released these descriptions are removed. Concepts from a context can have semantic definitions, definitions provided in natural language terms or both. 
49: 
50: Which methods are used to relate ('map') concepts in contexts to CB-NL Core, e.g. by marking them as equivalent, is under development and not discussed in this modeling guide.
51: 
52: There are three conceivable levels of integration / connection of existing national knowledge systems / standards to CB-NL.
53: 
54: === Level 1: standards as content of CB-NL Core ===
55: 
56: Concepts from existing standard specifications which are very relevant to CB-NL can be entered as content  in the Core of CB-NL. These existing standards are Semantic Concepts and Cheobs. These standards represent common ground already present in the Dutch construction community. Only those concepts from these standards that represent common national ground (the precise criteria are described in [[Practical guidelines for modeling CB-NL content>>Practical guidelines for modeling CB-NL content]]) are selected to become part of the CB-NL Core. Maintenance of these standards is transferred to the CB-NL organization, i.e. all concepts in the Core are maintained by CB-NL.
57: 
58: === Level 2: References from CB-NL to external concepts ===
59: 
60: External references can be made from concepts in CB-NL to concepts in ontologies of participating knowledge institutes.
61: 
62: For example, a concept ‘round air channel’ in CB-NL could have a mapping (equivalent class) to a class ‘roundairchannel’ from [[ETIM>>References#HETIM]], using its unique ID. In ETIM, the properties of the class are defined. The class is maintained by the responsible knowledge institute. 
63: 
64: References could also be made from CB-NL core to international ontologies, for example the bsDD.
65: 
66: === Level 3: References from external knowledge systems to CB-NL ===
67: 
68: External knowledge systems could contain references from their own concepts to CB-NL core concepts, using the CB-NL concept’s unique URI. The CB-NL does not maintain external concepts which are associated with CB-NL in this way. 
69: 
70: The concepts from external ontologies can be mapped to concepts that are already present in CB-NL Core, using, for example, a specialization relationship. Example: ‘doors outside’, which is a concept from the [[SEL>>References#HSEL]] standard, is mapped to the CB-NL concept ‘Door’ as its superclass. The SEL standard is a context ontology and contains concepts that refer to  the CB-NL core.
71: 
72: Example:
73: 
74: 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.