Export ▼
More actions ▼
Welcome to the CB-NL Wiki » Modeling Guide » Practical guidelines for modeling CB-NL content
Wiki source code of Practical guidelines for modeling CB-NL content

Last modified by Linda van den Brink on 2015/04/23 10:10
Content · Comments (0) · Attachments (0) · History · Information
Hide line numbers
  1: {{toc start="1" depth="6" numbered="true" scope="page"/}}
  2: 
  3: = Introduction =
  4: 
  5: This section of the modeling guide describes the practical rules and guidelines for creating CB-NL content (concepts, properties and relationships). These guidelines apply to the CB-NL Core only. They exist to make sure that people working on the contents of CB-NL Core have a uniform way of working. The guidelines can evolve over time because of new insights.
  6: 
  7: In some cases it could be desirable or even necessary to make an informed decision to deviate from these guidelines. In principle this is allowed: the guidelines are not normative, but have the status of recommendations. 
  8: 
  9: = The source of CB-NL Core concepts =
 10: 
 11: Several existing sources are used as input for creating CB-NL content. The sources for concepts becoming part of the CB-NL Core are: [[Semantic Concepts>>References||anchor="HSC"]], [[Cheobs>>References||anchor="HCHEOBS"]], [[OTL Rijkswaterstaat>>3\. Modeling Guide.Glossary||anchor="HOTLRWS"]], and [[IMGeo>>References||anchor="HIMGeo"]]. These are the primary sources of information for the CB-NL Core. Semantic Concepts and Cheobs are large collections of building information concepts which are not maintained or standardized. IMGeo is a standardized information model, maintained by [[Geonovum>>http://www.geonovum.nl]]. Not only concepts from these sources, but also the structure of relationships can be (but does not have to be) applied within CB-NL, as long as it is compatible with how relationships are formed in the CB-NL. 
 12: 
 13: = Concepts =
 14: 
 15: The CB-NL Core is filled with concepts. A 'concept' is some thing within the B&U and/or GWW sector which a person can have an idea or image of in his or her head. 
 16: 
 17: These concepts are ordered in a structure, in such a way that the upper concept is the 'super type' and the lower concept is the 'subtype' (elsewhere in this modeling guide these are called 'superclass' resp. 'subclass'). A subtype is always a narrower concept than its supertype. In other words: a hierarchy or taxonomy. The structuring is based only on generalization relationships; composition (part-of, has-part) relationships are not used. 
 18: 
 19: The following criteria are used to decide if a concept should be added to CB-NL Core:  
 20: 
 21: 1. The Concept is used in one or more processes / phases of the building life cycle (e.g. procurement, design, realization, traffic management, maintenance, demolition, usage processes, etc.).
 22: 1. The concept is preferably present in more than one sources of concepts (e.g. in NEN norms, object type libraries of organizations, classifications like ETIM, etc).  
 23: 1. The same level of detail is used as in NEN norms NEN 2767-2 (buildings), NEN 2767-4 (infra) or IMGeo.
 24: 1. When the level of detail according to criterium 3 is not detailed enough, it is OK to add more detailed concepts, but only if there is a widespread need for them.
 25: 1. Concepts always fall into one of the following generic categories: Physical, Spatial, Logical, Characteristic, Material, and Other. [TODO is dit de actuele lijst van top level classes?]
 26: 1. When a concept cannot be categorized, it falls in the category Other. The concept will then be properly categorized at a later stage. 
 27: 1. Values for the characteristics are initially the seven base quantities of the International System of Units (SI), and quantities derived from those. For example: Super type Length - concept Height - concept Headway (doorvaarhoogte). 
 28: 1. A Construction is a physical concept and a System is a logical concept.
 29: 1. Words ending (in Dutch) on '-ing' are only CB-NL content if they can be categorized as a logical concept. Otherwise they are left out. For example: 'Air conditioning' (in Dutch: 'luchtbehandeling') is eligible for addition to CB-NL Core. 'Sign-posting' (in Dutch: 'Bewegwijzering') ont other hand, is a method for providing users of a system with information; therefore it is not a system in itself, not a logical object and not CB-NL Core content. 
 30: 1. Concepts in CB-NL Core must be in use in reality, not fabricated within a concept library. Some concepts are so-called 'filling-words'. They are not used in reality but have been fabricated to fulfil a specific role in some source of concepts, e.g. to relate floating concepts. These filling-words are not CB-NL content. 
 31: 1. A logical concept is an aggregation of systems/objects/installations for which it is not stated how it is implemented in reality. For example: Energy supply (in Dutch: Energievoorziening). 
 32: 1. Types of work (activities) are usually not part of CB-NL Core. Concepts ending (in Dutch) in '-werk' or '-ing' usually indicate that the concept refers to an activity. For example Masonry; or (in Dutch) 'Plamuurwerk', which contains the activity 'Plamuren', or 'Betengeling', which refers to the activity 'Betengelen'. In specific cases, where the concept is very much in use, this can be an argument for adding it to CB-NL Core. For example, 'beschoeiing' or 'remming- en geleidewerk'. 
 33: 1. Only nouns (in Dutch: zelfstandig naamwoorden) are eligible as content of CB-NL Core. Exceptions may be made for words that are not nouns but are well-known concepts in the building sector. 
 34: 
 35: == Word combinations ==
 36: 
 37: Concepts that are combinations of words, such as (in Dutch) “damwand – van voorgespannen – betonnen – damwandplanken”, are not CB-NL Core content. In this example, the words represent not one but several concepts at once, e.g. 'voorspannen' which is a fabrication technique, 'beton' which is a material, 'damwandplanken' which is a composite part of 'damwand'. In CB-NL Core these are separate Concepts. In other cases, however, although a concept is a combination of words, it is still entered as a single concept in CB-NL core. Consider the 'Bascule bridge'. This is considered one Concept, because it is used in practice as one word signifying one concept (in Dutch it even is one word, not separated by a space or dash). The rule of thumb here is that if the words that form a concept can be considered as separate concepts themselves, they are entered in CB-NL as separate concepts, and the concept combining them is not part of CB-NL. 
 38: 
 39: Users of the CB-NL use Concepts by combining them. For example, a user wants to design a 'damwand' composed of 'damwandplanken'. These 'damwandplanken' are made of the material 'concrete'. To construct a damwand out of concrete, the technology 'voorspantechniek' is used. These are four word parts the user combines to design his specific damwand. These four words must be present as separate Concepts in CB-NL. In that way, the user can make his own combinations. In the same way, for example, a damwand made of steel can be designed. 
 40: 
 41: = Concept names =
 42: 
 43: 1. A concept name is always a noun.
 44: 1. A concept name always starts with a capital (upper case) letter.
 45: 1. Concept names in the CB-NL Core are in English. Concepts have both an English and a Dutch label. 
 46: 1. Avoid abbreviations. However, when an abbreviation is so well-known that everyone understands and uses it, it can be used in the CB-NL. The rules for abbreviations then are:
 47: (% style="list-style-type: lower-alpha" %)
 48: 11. Mention the abbreviation within brackets after the full unabbreviated name of the Concept.
 49: 11. The letters used in the abbreviation must also be present in the full name.
 50: 11. In the URL identifier of the Concept, only the full concept name without the abbreviation is used. 
 51: 1. Special characters such as "@", "&", "%", “#” are not used. Only use letters, numbers, and when necessary a '-'. 
 52: 1. The concept name does not contain parts that are words from another language. Well known loanwords are allowed (e.g. in Dutch: computer, viaduct, flat, traverse, appartement). 
 53: 1. Concept names that contain a property are not part of CB-NL. For example: prestressed concrete (in Dutch: voorgespannen beton). 'prestressed' is a property of concrete and the combination of the concept with a property is not entered in CB-NL. 
 54: 1. Concept names that contain a discipline or a word referring to a domain or sector are not part of CB-NL. For example, 'Hydraulic construction' (in Dutch: Waterbouwkundige constructie). Usually these are words on a more abstract level, collecting terms that are relevant in a certain domain. 
 55: 1. Two different concepts can have the same name in the CB-NL Core: homonyms are allowed. A reference to its homonym is recorded with each of the homonyms. For example: 'Gording' when applied to B&U is a different concept from 'Gording' when applied to GWW. 
 56: 1. Concept names are singular. Collection names are plural.
 57: 
 58: = Super type and sub type =
 59: 
 60: 1. In the CB-NL core, only one relationship type is used to relate concepts to each other. This is the super type-sub type relationship based on discriminating properties. That is, concepts are formed by assigning properties that indicate what makes them different from each other, and the super type-sub type hierarchy is created by grouping concepts that have a discriminating property in common together in a super type. 
 61: 1. A sub type has all but one property in common with its super type. This one property is an additional one, which discriminates the sub type from its super type. 
 62: 1. Every concept has a super type. When for some reason this is not possible (i.e. there is no appropriate super type available) it is temporarily connected to a more abstract super type. On the most abstract level there is a super type 'Other' which can be used for concepts that really do not fit anywhere. 
 63: 1.  A concept can have more than one super type. In that case, all discriminators of the concept must be recorded with the concept, in the order of discriminators (this is explained in the next section). 
 64: 1. Sub types inherit all properties from their super type. 
 65: 1. Concepts should only specialize into other concepts from the same kind of top level classes. Spaces specialize in more specific spaces, not in PhysicalObjects etc. Exceptions to this rule are possible.
 66: 1. To indicate that individuals of some concept are a part of individuals of another concept, specialization is **not** used. A special relationship, ‘composition’, would be used for that, but in CB-NL Core it is not supported. 
 67: 
 68: = Discriminators =
 69: 
 70: == Rules ==
 71: 
 72: 1. In order to create a consistent and correct ordering (taxonomy) of the concepts in CB-NL, the levels of the taxonomy are determined based on discriminating properties of concepts. I.e. the fact that a certain concept has a property that distinguishes it from other, similar concepts, is the basis for its being a separate sub type in the CB-NL Core. In other words: a discriminator is always the basis for the difference between a sub type and its super type. 
 73: 1. The correct assignment of a discriminator or set of discriminators (in popular terms also called the 'hooks' for placing concepts in the CB-NL core), makes it easier to discover missing super types. 
 74: 1. It follows from the previous section that sub types inherit all discriminating properties from their super type. This means that these discriminators do not have to be repeated at the sub type. Only the discriminating property that the sub type has, in addition to all the other properties it has in common with its super type, is stored with the sub type. For example: the concept 'Waterkerende constructie' (damming construction) only has a discriminator 'Toepassing' with the value 'Water', because the super type, 'Kerende constructie' (turning construction) already has the discriminator 'Function' with the value 'Keren'. 
 75: 1. The inherited discriminators are visible when viewing a concept, for example in the CB-NL Browser. 
 76: 1. Inherited discriminators from a super type are not specified again with the subtype. 
 77: 1. The discriminator type 'technology' is about the technology that allows a Concept to function the way it does in the real world, not about the technology that was used to create it. For example, in the concept "Voorspanduiker" (a type of culvert) the word part 'voorspan' refers to a technology which was used to fabricate the culvert. "Voorspanduiker" is therefore not part of the CB-NL Core. In the concept 'Hefbrug' (Lift bridge) the word part 'hef' refers to a technology that is used to move the bridge to allow ships to pass. This is a good example of using the 'technology' discriminator. 
 78: 1. A concept that cannot be discriminated with any discriminator from its super type, could be a synonym. It is not entered as a separate concept in CB-NL. 
 79: 
 80: == Available discriminator types ==
 81: 
 82: The available discriminator types are - in order of priority, i.e. the most important one first: 
 83: 
 84: 1. Purpose / function. Purpose and function are very close in meaning and are combined in one discriminator type. It indicates what a concept is meant for or can be used for. For example: a 'Meerpaal' (mooring post) is a pole with the function 'Afmeren'. 
 85: 1. Technology: indicates which technique is used when the concept is performing its function. For example: 'PLC besturing' or 'relais besturing'; 'hydraulic' or 'mechanic' drive system; or discriminating between 'automatic' and 'manual'. 
 86: 1. Application: the way in which something is used or how something is brought into practice. For example: a 'Spoorbrug' (Railway bridge) is a bridge with application 'Railway traffic'.
 87: 1. Appearance: says something about the form the concept takes in the real world. For example: discriminating between a 'Boogbrug' (arched bridge) and a 'Tuibrug' (suspended bridge). 
 88: 
 89: == Deprecated discriminator types ==
 90: 
 91: Discriminators that have been considered but are NOT used in the CB-NL Core: 
 92: 
 93: * Organization: some concepts could be discriminated by the organization which is the owner and/or responsible for its maintenance. For example, 'Rijksweg', 'Provinciale weg', 'Polderweg', etc. This discriminator is not used, because the organization associated with something could change over time. Concepts like this are not part of CB-NL Core, but can be defined in another context. 
 94: * Topology: defined as 'a schematically ordered network structure, at a macro, meso or micro level, using links that connect nodes. This discriminator is not used, because topology is about things like connection and orientation of mathematical spaces, which is very difficult to interpret and use as a discriminator. 
 95: * Material: indicates from which material a Concept is made in the real world. For example: 'staalkabel' (steel cable) or 'betonvloer' (concrete floor). This discriminator is not used, because it could only be relevant for the more detailed levels of the taxonomy of physical objects. It is not possible, for example, to use the Material discriminator for the concept 'Bridge', because a bridge in reality can be made of many different materials. Also, concepts that have a part indicating a Material, are a combination of words, which this guideline advises against. 
 96: 
 97: = Discriminator values =
 98: 
 99: 1. Each discriminator type has a set of predetermined possible values. This is important for uniformity. The lists of possible values  evolve during the process of initially filling the CB-NL Core with concepts. 
100: 1. Discriminator values are always composed of a single word in its singular form. Discriminator values are not complete or partial sentences. 
101: 1. Discriminator values always belong to the following types of word:
102: (% style="list-style-type: lower-alpha" %)
103: 11. Goal / function: the discriminator value is always a verb. The function describes an action or state of a process related to the concept. 
104: 11. Other discriminator types: the discriminator value is a noun. 
105: 
106: Some examples of discriminator values: 
107: 
108: * hasTechnology: Combustion technology. This discriminator value could be used in the definition of Combustion engine. 
109: * hasApplication: Road traffic. This discriminator value could be used in the definition of Road traffic sign. 
110: * hasFunction: Collecting. This discriminator value could be used in the definition of Waste terminal.
111: 
112: = Definitions =
113: 
114: 1. If a concept has a definition in the source it originates from, this is not improved or corrected as it is not used in the CB-NL Core. Definitions are only used during the process of selecting concepts for the CB-NL Core, as they give information about the meaning of the Concept in its original source. 
115: 1. Concepts in the CB-NL Core only have a 'semantic definition'. 
116: 1. The semantic definition of a concept is determined by the place of the concept in the taxonomy. See  [[Supertype versus subtype>>url:http://vps16544.public.cloudvps.com/xwiki/bin/view/MODELING+GUIDE/Practical+guidelines+for+modeling+CB-NL+content#HSupertypeversussubtype]]. In short, a concept is defined by its super type and the property (the discriminator) which makes it different from its super type. 
117: 1. The semantic definiton consists of [Name super type] + [Name discriminator] + [Value discriminator]. For example: A **Railway bridge is a Bridge with the Application of Railway. Another example: A Mooring post** is a **Pole **with the **Function** of **Mooring**. 
118: 
119: = Roles =
120: 
121:  
122: Some concepts described in CB-NL refer to things that are designed and used for one specific purpose. Other concepts, however, refer to things that can be used for different purposes. This is modelled in CB-NL using a relation type (i.e. an ObjectProperty) 'is a role for'. Concepts that refer to one of the possible uses of things that can be used for different purposes, are modeled as subclasses of Role, a class in the top level of CB-NL. For example, a 'dakbalk' (roof beam) is a beam that is used in the roof. The same beam could be used in the floor of a building. This is modeled in CB-NL by stating that 'dakbalk' is a role for 'balk'.