Classifying Elements

Introduction

There are at least four ways of expressing the semantic meaning of an Element which authors and consumers of BIS schemas should understand:

• Element Classes: Primary classification of semantics. A static part of metadata. Determine properties.
• Type Definitions: Further specialization within an Element Class. Optional. Dynamically defined in "reference data". May map to "catalog entries".
• Classification Systems: Optional. Typically express industry or company-specific semantic classification that may be orthogonal to Element Class and Type Definitions.
• Categories: Classification of geometry primarily for display purposes, like CAD "layers" or "levels". Only applicable to geometric elements.

Element Class

Every Element has an ECEntityClass that defines its primary semantic meaning and defines its properties.

Examples of Element Classes include Pipe, Column or Pump and are defined in Domain Schemas.

The BisCore schema defines the core Element classes from which all other Element classes must derive. See Element Fundamentals for more details on Core Element Classes.

Type Definitions

Class and Type organize Elements along roughly the same semantic/property dimension. The Type is a further specialization of the Element Class, but is defined more-dynamically in data as TypeDefinition instances.

A schema author must enable such further specialization of a particular Class by defining a TypeDefinition Class that "applies to" that Class and creating a RelationshipClass that expresses that constraint.

The properties of the TypeDefinition define the properties whose values will be common among all instances of a given Type.

Types often correspond to "manufacturer's models" in a catalog, e.g. catalog entries for Pump RCP-24 and Pump RCP-26 can be thought of as specializations of the Pump Class. In some domains, the set of TypeDefinition instances may not be thought of as a "catalog", e.g. Wearing course layer, Base course layer and Sub-base course layer are specializations of the Course Class.

For a real-world specialization hierarchy, how much of it should translate into a Class hierarchy vs a set of Types? Generally, Classes are used for specializations that are known when the schema is designed and tend not to vary per project or facility. Types can easily vary among different digital twins. Types can also be used to hold property values shared by many Entity instances, whereas classes assume that all property values can vary per Entity instance.

See Type Definitions for more details.

Classification Systems

Relating an Element to one or more Classifications in one or more ClassificationSystems allows even more dimensions along which to organize and express the meaning of Elements. These systems can be specific to a particular digital twin, but they are commonly representation of an externally-defined standard used in a given discipline. Examples include Uniclass and OmniClass.

See ClassificationSystems.

Categories

Categories can classify Elements along a different dimension than Class/Type, though in practice often correlate with the Class/Type dimension.

Categories are used by the visualization systems to efficiently categorize GeometricElement instances for display purposes. Categories are ultimately controlled by end-users, but defaults can be proposed by Standard BIS Domains or Applications.

Please refer to Categories for more details.

General Recommendations

• If a concept can be further classified beyond what is covered by the chosen Element-Class strategy, it typically leads to the need of introducing bis:TypeDefinitionElement subclasses.
• Deep hierarchies of physical-element instances typically model multiple levels of containment. Such cases are usually better modeled via Spatial Composition. That usually results in the more fundamental and granular physical concepts modeled via bis:PhysicalElements while the higher-level containment semantics are captured in classes that follow the patterns defined by the SpatialComposition schema.
• Categories are primarily introduced by users, driven by element-visualization needs. Standard BIS Domains and Applications can propose default Categories to users, but they shall not enforce them. Thus, Standard BIS Domains and Applications shall not rely on the usage of any particular Category for semantic classification.

---

| Next: Type Definitions |:---