Discussion about the integration of Building elements (ifcOwl and Haystack)

[pbourreau]

The domains that seems of a particular interest in the IFC are the following:

• the IfcProductExtension which contains physical objects that are relevant in describing the building/site. In particular, we are interested in the spatial structure of a building site through the IfcSpatialStructureElements, and IfcZones classes.
• the IfcBuildingControlsDomain which includes monitoring elements such as sensors, actuators, alarms…, which are instances of the IfcDistributionControlElement class.
• the IfcHvacDomain (for elements that are used to describe heat, ventilation and air-conditioning systems), IfcElectricalDomain (for elements related with electricity production/consumption/storage). All the elements of interest are accessible under the IfcFlowStorageDevice, IfcFlowMovingDevice, IfcFlowController, IfcFlowTerminal, IfcFlowTreatmentDevice and IfcEnergyConversionDevice classes

I guess all the classes listed above should be set as ssn:FeatureOfInterest. Also, I guess there should be an equivalence relation between IfcSensor and some concept of the SSN ontology (ssn:SensingDevice? ssn:Sensor?).

Additionally, three elements extracted from the Haystack model could be integrated in the HVAC domain:

• airHandlingUnit
• plant
• fanCoilUnit
• chiller Nevertheless, we are not sure these elements are not already present in the ifcOwl ontology under different names.

[pbourreau]

Also we need add categories to the different elements - in particular the currently so-called h2g:BuildingAppliance:

• Type (can be HVAC, Electrical, Monitoring, Wearable) - this is partially done with h2g:wearable and h2g:monitoring which is equivalent to IfcDistributionControlElement
• Sometimes subtypes - for electrical appliance: audiovisualAppliance, communicationAppliance, electricAppliance, lamp and solar. But this is already done in ifcOwl so it is just a matter of importing the corresponding classes in the model (same name, prefixed with ifc)
• Function: heating, cooling, iaq (only for HVAC, but a single sometimes can perform various of these functions)

[ycardinale]

the IfcProductExtension which contains physical objects that are relevant in describing the building/site. In particular, we are interested in the spatial structure of a building site through the IfcSpatialStructureElements, and IfcZones classes.

Yudith ==> Those classes are already included in the data model

the IfcBuildingControlsDomain which includes monitoring elements such as sensors, actuators, alarms…, which are instances of the IfcDistributionControlElement class. the IfcHvacDomain (for elements that are used to describe heat, ventilation and air-conditioning systems), IfcElectricalDomain (for elements related with electricity production/consumption/storage). All the elements of interest are accessible under the IfcFlowStorageDevice, IfcFlowMovingDevice, IfcFlowController, IfcFlowTerminal, IfcFlowTreatmentDevice and IfcEnergyConversionDevice classes

Yudith ==> Done, all of them are included.

I guess all the classes listed above should be set as ssn:FeatureOfInterest.

Yudith ==> They are FoI through ifcDistributionElement, which in turns is a subclass of ifcElement which is a subclass of ssn:FeatureOfInterest

Also, I guess there should be an equivalence relation between IfcSensor and some concept of the SSN ontology (ssn:SensingDevice? ssn:Sensor?).

Yudith ==> Yes, I have it in my diagrams. I did the update in the diagram of this repository: <ssn:SensingDevice, IsA, ifcSensor>

Additionally, three elements extracted from the Haystack model could be integrated in the HVAC domain:

airHandlingUnit plant fanCoilUnit chiller Nevertheless, we are not sure these elements are not already present in the ifcOwl ontology under different names.

Yudith ==> May be they are considered as subclasses of ifcEnergyConversionDevice (which is a subclass od ifcDistributionFlowDevice) are ifcChiller, ifcCondenser, ifcCoil etc.. Are those the same that Pierre means? If yes, I will include them in the data model.

[ycardinale]

Also we need add categories to the different elements - in particular the currently so-called h2g:BuildingAppliance:

Type (can be HVAC, Electrical, Monitoring, Wearable) - this is partially done with h2g:wearable and h2g:monitoring which is equivalent to IfcDistributionControlElement

Yudith ==> Currently, h2g:Monitoring, h2g:Wearable, and ifc:FlowTerminal are subclasses of h2g:BuildingAppliance, and <h2g:BuildingAppliance,hit2gap:containsElement,ifc:DistributionElement>. There is no direct relation with IfcDistributionControlElement. Is it necessary? On the other hand, we do not have a class HVAC (neither ifcOwl), should we create a new one? or is it enough with ifcDistributionFlowDevice?

Sometimes subtypes - for electrical appliance: audiovisualAppliance, communicationAppliance, electricAppliance, lamp and solar. But this is already done in ifcOwl so it is just a matter of importing the corresponding classes in the model (same name, prefixed with ifc)

Yudith ==> All IfcFlowTerminal subclasses are considered.

Function: heating, cooling, iaq (only for HVAC, but a single sometimes can perform various of these functions)

Yudith: We can represent Function as properties.

[pbourreau]

Few comments:

1. Also, I guess there should be an equivalence relation between IfcSensor and some concept of the SSN ontology (ssn:SensingDevice? ssn:Sensor?). Yudith ==> Yes, I have it in my diagrams. I did the update in the diagram of this repository: <ssn:SensingDevice, IsA, ifcSensor> Should we have a stronger relation (equivalence?) between ssn:Sensor and ifcSensor? This is more a question/remark than an advice.

2. Additionally, three elements extracted from the Haystack model could be integrated in the HVAC domain: (airHandlingUnit, plant, fanCoilUnit, chiller). Nevertheless, we are not sure these elements are not already present in the ifcOwl ontology under different names. Yudith ==> May be they are considered as subclasses of ifcEnergyConversionDevice (which is a subclass od ifcDistributionFlowDevice) are ifcChiller, ifcCondenser, ifcCoil etc.. Are those the same that Pierre means? If yes, I will include them in the data model. A deeper understanding is required: maybe there is an alignment between these Haystack concepts and ifc concepts.

3. Currently, h2g:Monitoring, h2g:Wearable, and ifc:FlowTerminal are subclasses of h2g:BuildingAppliance, and h2g:BuildingAppliance,hit2gap:containsElement,ifc:DistributionElement. There is no direct relation with IfcDistributionControlElement. Is it necessary? I am not so happy with the relation <h2g:BuildingAppliance,hit2gap:containsElement,ifc:DistributionElement>: it is wrong that a wearable or sensor contains a distributionElement. In my opinion this needs to be removed. On the other hand, we do not have a class HVAC (neither ifcOwl), should we create a new one? or is it enough with ifcDistributionFlowDevice? This needs to be created. The categories that I pointed out need to appear in the data model (i.e. HVAC, Wearable, Monitoring, ElectricalAppliance, Heating, Cooling, IAQ...) if they do not already exist under different names

[ycardinale]

1. Regarding to ssnSensor and ifcSensor. On May 4th 2017 SSN changed (https://www.w3.org/TR/vocab-ssn/): Classes ssnDevice and ssnSensingDevice were eliminated. We use them to align SSN and IFC. Hence, we have to update this alignment.

The definition of ssnSensor is more general that ifcSensor:

ssnSensor: Device, agent (including humans), or software (simulation) involved in, or implementing, a Procedure. Sensors respond to a Stimulus, e.g., a change in the environment, or Input data composed from the Results of prior Observations, and generate a Result. Sensors can be mounted on Platforms.

ifcSensor: looks like it is related only to devices since it is a subclass of ifcDistributionControlEllement.

Then, I think that the relation should be <ifcSensor, isA, ssn:Sensor. Do you agree? I will wait for your comments to update the diagrams.

2. I'm working on Systems and subsystem proposed in D4.1. In a next message I will comment about that.

3. This point depends on point 2. In a next message I will comment about that.

[pbourreau]

I am OK with <ifcSensor, isA, ssn:Sensor>

[ycardinale]

I have verified all terms specified in D4.1

1. Building Information: 1.1. Building Types: They are considered as subclasses of h2g:BuildingType. All subtypes will become instances of these corresponding classes.

1.2. Zone types (Room, Floor, Desk, Other) have been created as subclasses of ifcZone, except Other. We have the relation <ifcBuilding, contains, ifcZone>

1.3. Floor Types (Subterranean, Ground, Roof, Other). We have created Subterranean, Ground as subclasses of Floor. There exists ifcRoof but we do not have it under Floor (it is a subclass of IfcBuildingElement). Do you think that ifcRoof should be also a Floor type? Or should we create our Roof as a subclass of FloorType?

1.4. Space types (office, circulation area, …, cafeteria). There exists ifcSpace, and we have created all these types as subclasses of ifcSpace, which is a subclass of ifcSpatialStructureElement and also a subclass of ifcBuildingElement).

1.5. Windows covering type (Curtains, Blinds, Shutters, Shades) : We have created them as subclasses of ifcWindow. However, I think that we should instead create a h2g:WindowsCovering class ; Curtains, Blinds, Shutters, Shades as subclasses of h2g:WindowsCovering, and a relation <ifcWindow, has, h2g:WindowsCovering>. Don’t you think?

In general, for Building Information there are some relations that we have to review.

2 Geographical Information 2.1 Hemispheres (Northern, Southern): We have created h2g:Hemisphere and Northern, Southern as subclasses, also <_Feature, locatedInHemisphere, h2g:Hemisphere>

2.2 Climate types: We have created h2g:Climate and its respective subclasses (Tropical, …, Polar), also <_Feature, locatedInClimate, h2g:Climate> Subtypes can be created as TropicalTypesEnum,…,PolarTypesEnum. and Subsubtypes can be created as ClimateTypeEnum (Hot,Hot summer, warn summer, etc.). What do you think?

2.3 Orientation: We have created h2g:Orientation and North, South, … as members (instances), also <_Feature, hasOrientation, h2g:Orientation>

3. Energy categories 3.1. Renewable: 3.2 Nonrenewable: 3.3 Other Ontomg has classes for all the Types specified in D4.1. For subtypes, I asked Khouloud to include them into ontomg. I will include them when she finishes.

3.4 Energy Usages (relations): Produces (heat, air,water), Cools (air, water), and QAI. **There is nothing in OntoMg. In the document D4.1 Pierre says: “The relations above will be inferred by transitivity on the property on systems (i.e. a heating system that consumes gas, implies the relation heatAir between the building the gas energy).”

We should implement these relations explicitly.**

4. Systems 4.1. System types: 4.1.1 HVAC: Does not exist in ifc with that name. However there exists the class IfcEnergyConversionDevice, which has as Individuals: AIRCONDITIONINGUNIT, AIRHANDLER, DEHUMIDIFIER, NOTDEFINED, ROOFTOPUNIT, SPLITSYSTEM, USERDEFINED

Subsystem of HVAC:

• airHandlingUnit: We have created h2g:AirHandlingUnit as subclass of IfcEnergyConversionDevice.

• humidifier: There exists ifcHumidifier which is a subclass of IfcEnergyConversionDevice

• evaporator: There exists ifcEvaporator which is a subclass of IfcEnergyConversionDevice

• boiler: There exists ifcBoiller which is a subclass of IfcEnergyConversionDevice

• chiller: There exists ifcChiller which is a subclass of IfcEnergyConversionDevice

• coil: There exists ifcCoilwhich is a subclass of IfcEnergyConversionDevice

• evaporativeCooler: There exists ifcEvaporativeCooler which is a subclass of IfcEnergyConversionDevice

• heatExchanger: There exists ifcHeatExchanger which is a subclass of IfcEnergyConversionDevice

• airToAirHeatRecovery: There exists ifcairToAirHeatRecovery which is a subclass of IfcEnergyConversionDevice

• coolingTower: There exists ifcCoolingTowery which is a subclass of IfcEnergyConversionDevice

• condenser: There exists ifcCondenser which is a subclass of IfcEnergyConversionDevice

• burner: There exists ifcBurner which is a subclass of IfcEnergyConversionDevice (in IFC4, in IFC2 does not exist)

• engine: There exists ifcEngine which is a subclass of IfcEnergyConversionDevice (in IFC4, in IFC2 does not exist)

• spaceHeater: There exists ifcSpaceHeater which is a subclass of IfcFlowTerminal

• fireSuppressionTerminal: There exists ifcFireSuppressionTermina which is a subclass of IfcFlowTerminal

• vibrationIsolator: There exists ifcVibrationIsolator which is a subclass of IfcElementComponent

• fan: There exists ifcFan which is a subclass IfcFlowMovingDevice

• compressor: There exists ifcCompressor which is a subclass IfcFlowMovingDevice

• pump: There exists ifcPump which is a subclass IfcFlowMovingDevice

• tank: There exists ifcTank which is a subclass IfcFlowStorageDevice

• valve: There exists ifcValve which is a subclass IfcFlowController

• damper: There exists ifcDamper which is a subclass IfcFlowController

• chilledBeams: We have created h2g:chilledBeams as a subclass of IfcEnergyConversionDevice

• fanCoilUnit: We have created h2g:fanCoilUnit as a subclass of ifc:Fan which is a subclass of ifc:FlowMovingDevice.

• plant: It is not in the data model, Should we create h2g:plant?

• waterPlant and steamPlant: We have created h2g:WaterPlant and h2g:SteamPlant as a subclass of IfcEnergyConversionDevice. If we create h2g:Plant, Should they be subclasses of it?

• heatPump: We have created h2g:heatPump as a subclass of ifcPump which is a subclass of IfcFlowMovingDevice.

4.1.2. PlumbingFireProtection: We have created the h2g:PlumbingFireProtection as a subclass of ifcDistributionFlowElement. Its subtypes (sanitaryTerminal, stackTerminal, wasteTerminal, fireSuppressionTerminal) are subclasses of ifcFlowTerminal and ifcInterceptor is a subclass of ifcFlowTreatmentDevice. IfcFlowTerminal and ifcFlowTreatmentDevice are subclases of ifcDistributionFlowElement. Thus, h2g:PlumbingFireProtection has not any relation with the subtypes as defined in D4.1. Should we change this? On the other hand, we have created the relation <IfcFlowTerminal, IsA, h2g:BuildingAppliance>, but we do not have such relation with h2g:PlumbingFireProtection neither with ifcFlowTreatmentDevice. Why not?

4.1.3. Electrical: We did not create a particular class for this system. Should we create h2g:ElectricalSystem? As for PlumbingFireProtection?

• ElectricFlowStorage: There exists on IFC as a subclass of IfcFlowStorageDevice which is a subclass of ifcDistributionFlowElement.
• AudiovisualAppliance: There exists on IFC as a subclass of ifcFlowTerminal, which is a subclass of h2gBuildingAppliance. Its subtypes (amplifier, camera, display/screen, microphone, player, projector, receiver, speaker, switcher, telephone, smartphone, station, tuner) can be defined as ENUMERATES or instances (?).
• CommunicationAppliance: There exists on IFC as a subclass of ifcFlowTerminal, which is a subclass of h2gBuildingAppliance. Its subtypes (antenna, computer, fax, gateway, modem, network appliance (bridge, hub, router, repeater), printer, scanner) can be defined as ENUMERATES or instances (?).
• ElectricAppliance: There exists on IFC as a subclass of ifcFlowTerminal, which is a subclass of h2gBuildingAppliance. Its subtypes (dishwasher, boiler, cooker, coffee machine, FS electric heater, FS fan, FS water heater, FS water cooler freezer, fridge, hand dryer, kitchen device, microwave, photocopier, refrigerator, tumble, dryer, vending machine, washing machine) can be defined as ENUMERATE or instances (?).
• Transformer: There exists on IFC as a subclass of ifcEnergyConversionDevice, which is a subclass of ifcDistributionFlowElement.
• ElectricGenerator: There exists on IFC as a subclass of ifcEnergyConversionDevice, which is a subclass of ifcDistributionFlowElement.
• ElectricMotor: There exists on IFC as a subclass of ifcEnergyConversionDevice, which is a subclass of ifcDistributionFlowElement.
• ElectricTimeControl: We have created the class h2g:ElectricTimeControl as a subclass of ifcEnergyConversionDevice, which is a subclass of ifcDistributionFlowElement.
• Lamp: There exists on IFC as a subclass of ifcFlowTerminal, which is a subclass of h2gBuildingAppliance. Its subtypes (desk light, central light)) can be defined as ENUMERATE or instances (?).
• Solar: There exists ifcSolarDevice as a subclass of ifcEnergyConversionDevice, which is a subclass of ifcDistributionFlowElement. Its subtypes (solar electric,solar thermal) can be defined as ENUMERATE or instances (?).

4.1.4. Monitoring: We have created the h2g:Monitoring as a subclass of h2g:BuildingAppliance. The subtypes: sensor (ifcSensor), actuator (ifcActuator), alarm (ifcAlarm), controller (ifcController), and meter (we have created h2gMeter) are subclasses of h2g:Monitoring.

4.1.5 Wearable: We have created the h2g:Wearable as a subclass of h2g:BuildingAppliance. Also we created the subtypes: h2g:smartwatch and h2g:smartphone as subclasses of h2g:Wearable. We also have created a h2g:WearableElement as a subclass of IfcDistributionFlowElement, but nothing else about this h2g:WearableElement. Should we eliminate it? I think that we have to review all theses subclasses relations between BuildingAppliance and Systems and subsystems Types. Some System/subsystems types are subclasses of h2gBuildingApplicance, others are subclasses of ifcFlowTerminal (which is a subclass of h2gBuildingApplicance and ifcDistributionFlowElement), others are direct subclasses of ifcDistributionFlowElement , others are subclasses of subclasses of ifcDistributionFlowElement. The think is that not all systems/subsystems are related with h2g:BuildingAppliance. For example, why ifcDistributionFlowElement is not a subclass of h2g:BuildingAppliance as ifcFlowTerminal is?

4.2. Energy and systems (Relation): Consumption, Production, Storage, Controls, Measures: We have created the relations h2g:produceEnergy, h2g:consumeEnergy, h2g:storageEnergy, h2g:controlEnergy, and h2g:measureEnergy between ifcSystem and h2g:Microgrid. I think we have to review this relations because ifcSystem has not relation with h2gBuildingAppliance.

4.3. Buildings spaces and systems (Relations)

• isLocatedIn: We only have h2g:locatedInHemisphere between geo:_Feature and Hemisphere
• outputs, inputs, open/close (used to control windows or window coverings – must specify a value between 0 and 1). The outputs and inputs relations will be used only for heating, cooling and QAI systems, to specify for instance, which are the zones heated by a heating system. An additional field will be included for heating, cooling and QAI systems, to specify if it is central to the building. We do not have these relations explicitly in the data model.

4.4. Relations between systems (Relation)

• Supplies to: Electricity, Water, Steam, Gas, Other
• Transports to: Liquid, Gas
• Contains
• Measure running (used with monitoring device)
• Has set point (used with measure)
• Measure input/output (used with monitoring device)

We do not have these relations explicitly in the data model. Relations between Systems and subsystems (see Table in D4.1). We do not have these relations explicitly in the data model.

5. Measures: 5.1 Measure Types/subTypes: We have a h2g:PhysicProperties as a subclass of ssn:Property. h2g:PhysicProperties has as subclasses h2g:Air, h2g:Electric (with subclasses h2g:ElectricEnergy, h2g:heatFluxEnergy), h2g:Volume (with subclasses h2g:Flow (inFlow, outFlow)), h2g:Temperature, h2g:Pressure. For Water, Steam, State, AirQuality, Climate, Occupant State, Position, Humidity, Co2Rate, Intensity, Tension, Light Radiation, Wind Orientation, Wind Speed, Stress – pulse, [Longitude, Latitude, Height] there is nothing in this subclasses. Should we create them in tis module?

5.2 Measure Units: Almost all units are in QUDT.

6. Occupancy
   • Gender, Age, Knowledge level, Activity frequency, and comfort aspects are considered. * Distance to a point: Far, Near, InBetween. They are not considered yet.

[pbourreau]

Partial answers:

1.3 I think there should not be any relation between Roof and Floor 1.5 I agree with you. I think there already exists some element for window covering in IFC

2.2 I do not know which are the best way to define the subclasses. The problem is that all sub-subtypes are not correct depending on the subtype itself... 2.3 For orientation, ensure that we have NorthWest, SouthWest, etc.

3.4 I agree.

4.1 4.1.1 I think the type HVAC contains elements from different IFC concepts, not just EnergyConversionDevice.It contains elements that in the HvacDomain, basically. 4.1.2 Do not focus on FireAndPlumbingProtection: it is optional, I do not think it is relevant in the project (there is a footnote about it in D4.1) 4.1.3 Yes. Basically the same than for HVAC: it is in the ElectricalDomain 4.1.5 I think the relation between Wearable and DistributionElement should be removed.