Class hierarchy & the is argument

Query a parent Brick class and automatically match all subtypes using the is argument.

The problem with explicit types

Without class hierarchy, querying building data means knowing every specific type you’re looking for:

# Without hierarchy, you must list every type
equipment(type: ["AHU", "VAV", "FCU", "Heat_Exchanger",
                  "Heat_Pump", "Cooling_Tower", "Pump"]) {
  ...
}

Miss a type? You miss data. Add a new equipment type next year? Every query breaks. This doesn’t scale.

How is works

The is argument queries by Brick class and automatically includes all subtypes:

# With hierarchy: one class, all subtypes
equipment(is: "HVAC_Equipment") {
  name
  type
}

This returns AHUs, VAVs, FCUs, heat exchangers, and every equipment type that is a subclass of HVAC_Equipment in the Brick hierarchy. Add a new type next year? It automatically matches.

Common hierarchies

Equipment

Equipment
├── HVAC_Equipment
│   ├── AHU
│   ├── VAV
│   ├── FCU
│   ├── Chiller
│   ├── Boiler
│   ├── Heat_Exchanger
│   ├── Heat_Pump
│   ├── Cooling_Tower
│   ├── Pump
│   │   ├── Chilled_Water_Pump
│   │   ├── Hot_Water_Pump
│   │   └── Condenser_Water_Pump
│   └── Fan
│       ├── Supply_Fan
│       ├── Return_Fan
│       └── Exhaust_Fan
├── Lighting_Equipment
└── Electrical_Equipment

Points (sensors)

Sensor
├── Temperature_Sensor
│   ├── Supply_Air_Temperature_Sensor
│   ├── Return_Air_Temperature_Sensor
│   ├── Zone_Air_Temperature_Sensor
│   ├── Outside_Air_Temperature_Sensor
│   ├── Chilled_Water_Temperature_Sensor
│   └── Hot_Water_Temperature_Sensor
├── Humidity_Sensor
│   ├── Relative_Humidity_Sensor
│   └── Zone_Humidity_Sensor
├── Pressure_Sensor
│   ├── Static_Pressure_Sensor
│   └── Differential_Pressure_Sensor
├── Flow_Sensor
│   ├── Air_Flow_Sensor
│   └── Water_Flow_Sensor
└── CO2_Sensor

Points (setpoints and commands)

Setpoint
├── Temperature_Setpoint
│   ├── Zone_Air_Temperature_Setpoint
│   ├── Supply_Air_Temperature_Setpoint
│   └── Chilled_Water_Temperature_Setpoint
├── Pressure_Setpoint
└── Flow_Setpoint

Command
├── Damper_Command
├── Valve_Command
├── Fan_Command
└── On_Off_Command

Query examples

All sensors on an AHU

{
  equipment(siteId: "your-site-id", id: "TE01-XX-AHU-001") {
    points(is: "Sensor") {
      name
      type
      currentValue { value timestamp }
    }
  }
}

Returns temperature sensors, humidity sensors, pressure sensors, flow sensors, and every other sensor type attached to this AHU.

All setpoints in a building

{
  equipment(siteId: "your-site-id", is: "HVAC_Equipment") {
    name
    points(is: "Setpoint") {
      type
      currentValue { value timestamp }
    }
  }
}

Narrow vs broad queries

is argument	What matches
Point	Every sensor, setpoint, command, and status
Sensor	All sensors (temperature, humidity, pressure, etc.)
Temperature_Sensor	All temperature sensors (supply, return, zone, etc.)
Supply_Air_Temperature_Sensor	Only supply air temperature sensors

The broader the class, the more results. Start broad to explore, narrow when you know what you need.

How it works under the hood

When you pass is: "HVAC_Equipment", Tacit resolves the Brick class hierarchy to find all subclasses:

1. Look up HVAC_Equipment in the Brick ontology
2. Find all classes where X rdfs:subClassOf* HVAC_Equipment
3. Match any entity whose class is in that set

This is the same resolution that SPARQL’s a/rdfs:subClassOf* performs, but expressed as a single argument in a GraphQL query.

Combining is with other arguments

# is + id (specific equipment, type-checked)
equipment(id: "TE01-XX-AHU-001", is: "AHU") { ... }

# is + name
points(is: "Temperature_Sensor", name: "Supply") { ... }

# Nested is arguments
equipment(is: "HVAC_Equipment") {
  points(is: "Sensor") { ... }
}

Invalid class names

If you pass an unknown class name, the query returns an empty result set. No entities match a class that doesn’t exist in the Brick ontology.

Equivalent SPARQL

The is argument replaces this SPARQL pattern:

?entity a/rdfs:subClassOf* brick:HVAC_Equipment .

Same resolution, expressed as a single argument instead of a property path.

Next steps

Relationships & traversal

Follow equipment chains with upstream and downstream queries.

Equipment reference

Full reference for equipment queries with class filtering.