## 3 An Approach to Generate the MEP Logic Chain from BIMs
### Identification Rules of Logic Chain in MEP Systems
#### 3.2.2 The User-Defined Logic Rule  
According to different MEP design or FM requirements, pre-defined rules stipulated according to prior experience do not always work. Therefore, this approach proposes a user-defined logic rule as a supplementary to pre-defined rules. To define those rules, a domain query language with lexicon and grammar of their statements should be introduced first. The query, for example, may ask for the position of the valve on the supply water pipe connected to the reheat coil in the terminal box [38; 39]. The contextual information items used in the query language for HVAC systems can be categorized into three general groups: entities, properties, and relationships. The relationship between entities is simplified as follows: A is the upstream component of B, A is the downstream component of B, or NULL (means without any relationship).  
Each entity specifies a type of object that has a set of instances in MEP systems. Hence, in a rule statement, the name of an entity represents all instances with the same name. Each entity contains several property sets, each of which contains a number of properties, such as the component name, ID, or spatial geometry information. This information provides lexicon of upstream and downstream logic rules. Numbers or strings can typically represent the values of these properties. The predicates of these values shown in Table 2 were identified according to SPARQL.  
Each property of an entity instance has a set of values that describe the instance. The values can be individual or an array of either a primitive, such as number, character and Boolean, or instances of other entities. Since the values of properties describe the characteristics of the instances, they can be used to specify the target instances. For example, to retrieve the instances of all temperature sensors in the data model, the users can specify the query statements to identify the instances of sensors that have their property \"MeasurementType\" with value equaling to \"Temperature\", such as (Sensor. MeasurementType, =, \"Temperature\").  
Although the actual relationships between components can be highly complex, the relationship in the user-defined identification rules considered by the algorithm is either \"UpstreamOf\" or \"DownstreamOf\". The upstream and downstream relationships are not interconnected in space, unlike the functional relationships. For example, the valve as a logic upstream component controls its downstream components, such as pipes, and the axial fan as an upstream component will affect the working state of its downstream components, including outlets.  
\begin{table}
\begin{tabular}{c c c} \hline \hline
**Predicate** & **Syntax** & **Description** \\ \hline = & v1 = v2 & True if value v1 equals to v2 \\ Contains & v1 contains v2 & true if value v2 is a substring of value v1 \\ Connects & v1 connects v2 & true if value v2 is topologically connected to value v1 \\ \hline \hline \end{tabular}
\end{table}
Table 2: Predicates reused from SPARQL for the inspection rules.  
The syntax of a query language specifies the grammar for the logic chain statements. It provides guidelines about how the statements should be parsed and interpreted. After defining the information items in a specific logic chain, the syntax of object-oriented query language rules is extended to express the entity, property and upstream and downstream logic relations. Table 3 provides examples for each definition.