The scope of the TUBES System Ontology is to explicitly define interconnected building service system in the AECO industry, their hierarchical subdivisions, structural and functional aspects, and links to spatial entities. As such, TSO supports the effort to represent linkable information in a future semantic web of building data. It has a strong alignment to other ontologies within the W3C community.
A persistent URI namespace for the TUBES System Ontology (tso) will be provided by W3ID at https://w3id.org/tso.
The latest version of TSO is provided in Turtle, RDF/XML and JSON-LD format. Extensive documentation is also available.
The three main classes of the TUBES System Ontology are tso:System, tso:Zone and tso:State. A tso:Zone is defined as a part of the physical world or a virtual world that is inherently both located in this world and has a 3D spatial extent. It has a strong alignment to the zone concept of the Building Topology Ontology (BOT). The object properties tso:servesZone and tso:servesSystem define relationships linking states of systems and zones to describe that a zone is served by a system, respectively a system serves a zone. tso:locatedIn and tso:contains define relationships to describe that a system is located in a zone, respectively a zone contains a system. tso:State defines the internal condition of a (planned) system. To link a state to a system, respectively a system to a state, the inverse properties tso:stateOf and tso:hasState are defined. A tso:System is a model of a whole which is isolated from the world or a supersystem, which may consists of interconnected components or subsystems and has links between attributes such as inputs, outputs and states. Within this definition there are three concepts with are further detailed in the following.
The hierarchical concept describes a system as a model of a whole which is isolated from the world or a supersystem. To represent the these aspects of building service systems the four subclasses tso:IntegratedSystem, tso:FunctionalSystem, tso:TechnicalSystem and tso:Component of tso:System are given in TSO. In the following the term “system” is used to describe all of them. tso:IntegratedSystem represents the coupling of different functional systems with independent inherent functions which are interconnected. tso:FunctionalSystem denotes a system which is defined by its overall inherent function. Typical examples would be tso:HeatingSystem, tso:CoolingSystem or tso:VentilationSystem. tso:TechnicalSystem is defined as a system with a coherent technical solution with which the inherent function (of the upper functional system) is fulfilled. Existing subclasses contain tso:DistributionSystem and tso:ConversionSystem. tso:Component denotes a system, for which the boundary that isolates it from the environment is defined by the manufacturer in terms of the product. Therefore, an air handling unit as well as the included rotary wheel heat exchanger or sensor could be instances of tso:Component. To classify components, TSO is aligned with ifcOWL. tso:subSystemOf defines a relationship linking a system to its supersystem. tso:hasSubSystem is defined as the inverse of tso:subSystemOf and describes a relationship linking a system to its subsystem. Both object properties have their range and domain defined as tso:System.
The structural concept describes a system as a model of a whole which may consists of interconnected components or subsystems. To represent the topological aspects of building service systems and answer CQ2, TSO builds upon the concepts tso:ConnectionPoint and tso:Connection proposed in SEAS and extends these by the subclasses tso:InnerConnection and tso:OuterConnection to differentiate between the connections inside a system and between different systems. tso:ConnectionPoint refers to an inlet or outlet of a system for a connection to other systems or within the same system, where some kind of matter, energy or data can be transmitted. Using these concepts and the object properties which define the relationships between them, the symmetric object property tso:connects can be qualified to describe that two systems are connected. These concepts can be implemented to represent the system topology on every hierarchy level introduced in the last section.
The functional concept describes a system as a model of a whole which has links between attributes such as inputs, outputs and states. To represent the functional aspects of building service systems TSO relies heavily on the concept of states. A tso:State is defined as the internal condition of a (planned) system. It can be used to add a level of abstraction to represent systems where the function, and therefore the flow of matter, energy or data, can change due to given states. Hence, a system can have multi- ple potential states assigned via the tso:hasState object property. To represent “what” is exchanged between different systems or inside a certain system, the classes tso:Matter, tso:Energy and tso:Data as well as multiple subclasses are defined. These classes can be linked via tso:hasInput and tso:hasOutput to the states of different systems. Based on these concepts the inverse object properties tso:supplies and tso:suppliedBy, which link the states directly, can be inferred, as well as their subproperties to denote what is supplied. To represent the flow inside a system, the classes tso:Matter, tso:Energy and tso:Data can be connected to the given state by using the tso:hasInnerExchange object property. To qualify the exchange the considered matter, energy or data can be linked to a tso:Connection via tso:transmitsThrough or to the tso:ConnectionPoints via tso:transmitsFrom and tso:transmitsTo.
Within the W3C linked building data ecosystem several alignments are proposed. Currently, these are available:
Examples for the use of TSO are provided for an application example of an active cooled beam, the DigitalHub project and CUBE project.
- Nicolas Pauen [email protected]
- Dominik Schlütter [email protected]