Brick REC concept selection table - RealEstateCore/Brick-REC Wiki

In the tables below, the Brick and RealEstateCore consortia indicate their preference for which ontology should host which top-level concept, in future compatibility-breaking releases (Brick 2+, REC 4+).

Brick Concepts

Concept Subconcept Brick Consortium preference REC Consortium preference
Collection Either REC or Brick or third party ontology. Important to align on second-level hierarchy!
Collection Loop Same
Collection PV Array Same
Collection Photovoltaic Array Same
Collection Portfolio Same
Collection System Same. Name is too ambiguous though.
Equipment Brick (possibly including updates from REC 3.3?). Clean up semantics of context (placement/direction etc) so this is not just inherent in inheritance hierarchy.
Equipment Camera Same
Equipment Electrical equipment Same
Equipment ... (please fill out remaining subclasses) Same
Location REC
Location Building REC
Location Floor REC
Location Outdoor Area REC
Location Outside REC
Location Region REC
Location Site REC
Location Space REC
Location Storey REC
Location Wing REC
Location Zone REC
Measurable Brick
Measurable Quantity QUDT
Measurable Substance Brick
Point Brick (possibly including updates from REC 3.3?). Clean up semantics of context (placement/direction, etc) so this is not just inherent in inheritance hierarchy. Needs payload schema semantics?
Point Alarm Brick
Point Command Brick. Needs payload schema semantics and ideally actuation model (e.g., responses, etc). Borrow from REC?
Point Parameter Brick
Point Sensor Brick
Point Setpoint Brick
Point Status Brick

RealEstateCore Concepts

Concept Subconcept Brick Consortium preference REC Consortium preference Note
AnalysisProcess Not really used? Maybe deprecated or re-developed in future versions
Role REC
Agent REC
Agent Organisation REC
Agent Person REC
Asset REC Is name (Asset) appropriate for Brick users? Renaming is an option.
Asset ArchitecturalAsset REC
Asset Component Maybe deprecate or reorganize – represents reusable components that reoccur across assets in DTDL models.
Asset Equipment Brick Add new bits from REC.
Asset Furniture REC
BuildingComponent REC Refactoring for better spatial model compliance is in progress.
Capability Brick
Capability Actuator Brick
Capability Parameter Brick
Capability Sensor Brick
Capability State Brick
Collection Either REC or Brick or third party ontology. Important to align on second-level hierarchy.
Collection AssetCollection Same
Collection Portfolio Same
Collection SpaceCollection Same
Document REC Possibly reuse third party model if good one exists?
Event Neither/Both? Should we investigate SSN/SOSA? Or other relevant models? Probably natural to keep with Points/Equipment (in Brick). At least for sensor/actuation events. How about business events?
Information did not get further before Thursday meeting
Information ResponseCode Part of the actuation bits, see below
Information Address
Information AnalysisConfiguration Not really used? Maybe deprecated or re-developed in future
Information DataSeries Not really used? Maybe deprecated or re-developed in future
Information DataSchema Overlaps with DTDL language featurews
Information PropertySet Attempting to graft on custom/customer-specific tags onto the REC ontology. Driven by, e.g., Microsoft customer needs.
LogicalDevice
Service
Software
Software SensorInterface Can we maybe borrow this subhierachy from SSN/SOSA or DTDL?
Software ActuationInterface Can we maybe borrow this subhierachy from SSN/SOSA or DTDL?
Space
geo:Geometry Reusing GeoSPARQL
qudt:QuantityKind Reusing QUDT
qidt:Unit Reusing QUDT