TODO:

Based on the discussion at #32.

Motivation

Current usage of Occupancy, Occupied, Command and Status are not standardized and it's unclear when to use what. This RFC is unifying such clutter into using Occupancy and Command in general.

Introduce following TagSets:

• Occupancy_Command: Command informing Occupancy to target Points or Equipment.
  • Reasoning: "Occupied" in previous Occupied_Command misreads as it's only for true/false value.
• Scheduled_Occupancy_Command: Occupancy Command related to some Equipment, which is scheduled by a system in advance. For example, it may be on weekdays 7am-5pm.command used by the system at the moment.
• Override_Occupancy_Command: A type of Occupancy_Command that overrides other Occupancy_Value types such as Scheduled_Occupancy_Command. Usually a point of thermostats. Replace previous Temporary_Occupancy_Status to make the meaning clearer.
• Effective_Occupancy_Command: Occupancy_Command effective at the moment. It is usually calculated from other Occupancy_Command such as Scheduled_ and Override_Occupancy_Commands.

Remove following TagSets:

• Temporary_Occupancy_Status
  • Reasoning: The term is ambiguous and Override_Occupancy_Command
• Occupied_Command
  • Reasoning: It causes confusion with Occupancy_Command
  • Alternative: Keep both of them and make them sameAs. I however argue to avoid sameAs as much as possible as users will get confused. We have heard such complaints from users (which one to use between this and that?).
• Occupancy_Status
  • Reasoning: It was only subclassed by Temporary_Occupancy_Status. If it is removed, this has little usage. Occupancy_Sensor can easily substitute this.

original report: https://groups.google.com/d/msgid/brickschema/6374bdb9-d696-443b-9591-346422368f9b%40googlegroups.com?utm_medium=email&utm_source=footer

Example: There are SolarPanel and Solar_Panel
Tagsets should be separated by tags in it. SolarPanel comes from "isPartOf" column, which should be fixed. There are a few more Tagsets like that. Another example is ThermalEnergyStorage.

Background:
The current means of defining Brick tags and Tagsets is highly repetitive, does not enforce consistency / non-duplication, nor does it facilitate generating tag[set] documentation.

This is a problem when trying to use Brick in real applications.

Objective
To specify a concise method for defining tags and tagsets that allows machine-generation of an internally consistent ontology of tags and tagsets with non-overlapping semantic meaning (i.e. no two tags define exactly the same concept).

Discussion:
One of the most powerful features of Brick is that it provides a means for attaching a precise semantic definition to a piece of data that persists across the context where it is found. For example, a point tagged with zone_air_temperature_sensor (ZATS) is known to be the ambient air temperature in the region of space measured by the sensor. This definition is the same whether the point is obtained from a thermostat or a light fixture (yes, light fixtures sometimes have temp sensors).

Conceptually, the ZATS tagset is created by combining concepts from disjoint sets to create a more complex concept: _. This is very powerful because it allows a virtually infinite number of meaningful composite concepts to be created and understood without individually defining each one. To be more specific about the meaning here: If each of the individual tags in a tag set has a precise definition, the precise meaning of a tagset will, more often than not, be easy to infer. (Note: for this to be strictly true all tags must be unique, single words, combinedWithoutSpaces, or make use of a reserved-character-delimiter).

If we are also willing to use the class hierarchies in Brick (pointType, MeasurementType, Equipment, Location, etc...) to enforce a limited grammar, we could write code to generate internally consistent groups of tagsets very concisely around a central concept. With the right structure this could be done modularly and flexibly in ways that map to conceptual similarities. An example:

Take the concept of temperature. We could create code that looks something like this:

Temperature:
  group:
    media: [Air]
    types: [Zone,Outside, Discharge, return]
  group:
    media: [Water]
    modifiers: [hot, chilled]
    types: [discharge, return]

would yield: 

Zone_Air_Temperature
Outside_Air_Temperature
Discharge_Air_Temperature
Return_Air_Temperature
Discharge_Hot_Water_Temperature
Discharge_Chilled_Water_Temperature
Return_Hot_Water_Temperature
Return_Chilled_Water_Temperature

in the above, we are able to take multiple well-defined tags, and use simple rules to mechanically create tagsets. In the above example, we create groups for air and water because the concepts we want to produce for the two media are divergent. However, we could easily modify this code if we were monitoring, say an indoor-outdoor pool, to include "water" in the media list of the first group and we would get the following additional tags:

Zone_Water_Temperature
Outside_Water_Temperature
Discharge_Water_Temperature
Return_Water_Temperature

This would allow you to get all of the core concepts written. A parser for this structured file could ensure that no tagsets appear twice and that only pre-defined tags are used.

To be added in future posts: mapping to point types and equipment.

Synonyms are not created anymore. Detected by @jbkoh

Migrating a bug report from BuildSysUniformMetadata/GroundTruth#7

Was it intentional? There are several points like that:

INCORRECT: Low_Humidity_Alarm_Setpoint in Alarm
INCORRECT: CRAC_Low_Humidity_Alarm_Setpoint in Alarm
INCORRECT: Pump_Alarm_Delay_Setpoint in Alarm
INCORRECT: Chilled_Water_Pump_Alarm_Delay_Setpoint in Alarm
INCORRECT: CWS_Chilled_Water_Pump_Alarm_Delay_Setpoint in Alarm
INCORRECT: CRAC_High_Humidity_Alarm_Setpoint in Alarm
INCORRECT: High_Humidity_Alarm_Setpoint in Alarm
INCORRECT: CRAC_Low_Temperature_Alarm_Setpoint in Alarm
INCORRECT: Low_Temperature_Alarm_Setpoint in Alarm
INCORRECT: High_Temperature_Alarm_Setpoint in Alarm
INCORRECT: CRAC_High_Temperature_Alarm_Setpoint in Alarm

I will fix this if it wasn't intentional.

Suggestions by SDU Student Henrik Lange

The Brick definitions contain several abbreviations:

• AHU: Air Handler Unit
• CRAC Computer Room Air Condition
• CWS: Chilled Water System
• DHWC: Domestic Hot Water System
• FCP: Fire Control Panel
• FCU: Fan Coil Unit
• HVAC: Heat Ventilation Air Condition
• HWS: Hot Water System
• HX: Heat Exchanger
• PIR: Passive Infra Red (motion detector)
• PV: Photovoltaic
• VAV: Variable Air Volume
• VFD: Variable Frequency Drive
• WS: Water System
• DI: Deionized

While some of these abbreviations are commonly used in the building
industry, many are associated with a narrower field, such as electricity
or plumbing, or a smaller community, such as a single country. This
makes it difficult for someone to know them all across trades and cultures,
and finding translations online is not always easy. For instance, DI might
be confused with a Digital Input. In some instances, Brick supports the
same definitions with abbreviation and the full word; for instance, AHC
and Air Handler Unit are both listed as definitions. In some cases, the
abbreviation and the full phrase are both in the same definition, such as
CWS Chilled Water System Enable Command. The general syntax in
Brick is a combination of title case and snake case (Title Snake Case),
but in some definitions, it is combined with title case (TitleCase), such as
in HeatExchanger Outside Air Temperature High Reset Setpoint. This
means that the Brick syntax has 3 distinct ways of writing the same set of
keywords: In this case, HX, HeatExchanger and HeatExchanger are used
interchangeably between denitions. The words high, highest and max are
similarly also found, seemingly interchangeably throughout the definitions,
and the same goes for low, lowest and min.

A clear casing convention for definitions should be made. There is a clear tendency towards writing definitions in a combination of TitleCase and snakecase (TitleSnakeCase), but it is just a tendency, not a rule. A convention would make it easier for everyone to write the correct definition without having to check with the definition list every time. The selectied convention should be followed in the syntax and thus avoid combining casing structures, such as FireControlPanel Fire Control Panel Off Command. This problem becomes especially challenging in combination with the abbreviation problem, since a combination of these allows up to three different versions of the same words to exist. As an example, HeatExchanger, Heat Exchanger and HX all exist and are all used interchangeably in other definitions. This might mean that definitions become unclear and at worst, ambiguous, as an application looks for one definition where a programmer used another.
Use of the words max, high, highest, min, low and lowest is not ex- plained in the schema either. They might all mean the same, in which case.

Building Topology Ontology / bot https://github.com/w3c-lbd-cg/bot provides a central lightweight ontology for space and physical relations within buildings with the aim to align with or provide a base level of classes for other domains.

Given that Brick is a domain specific ontology (controls), I think Brick should either aim to align with BOT (there is an existing alignment here: w3c-lbd-cg/bot@bfee1e4#diff-73c0fa08510685b98f9b9cfe1ed24cfc) or, preferably re-jig classes like Location, Zone, etc to directly use bot, minimising duplication.

Thoughts?

How should Brick represent units?

This RFC continues this

1. Introduction
   Unit is a primary metadata to interpret/process data modeled with Brick. There was multiple requests to integrate units with Brick and there is no reason not to adopt it. However, designing every possible unit is not a feasible way as there are i) numerous units, ii) variations for same property (C vs F), and iii) various standards. Along the line I propose below:

2. Proposal
   

(1) Structure: We limit only Point to have a unit. As discussed in the thread, Points directly having a unit is sufficient enough for systems we modeled.
(2) Vocabularies: The vocabularies are adopted from QUDT.

• Examples: FT2, MilliA, A, VOLT, KW, PowerFactor, KiloW-HR, HZ, ReletiveHumidity, DEG_C, DEG_F, HR, MIN, SEC, FT-PER-MIN, Parts-per-million, PERCENT, MegaW-HR, BTU-PER-FT2, PPM

3. Required tasks
   (1) Add hasUnit property to BrickFram.ttl
   (2) Select units from QUDT (especially related to BACNet) and include them in Brick.ttl (or BrickUnit.ttl if necessary.)
   (3) Write units not defined in QUDT but in BACNet by using the related existing units. E.g., FT3-PER-MIN given FT-PER-MIN. (We could also add explicit definition of FT3-PER-MIN in the ontology.)

4. Discussions
   (1) Unit changes across time: It is not included in the current proposal, but we could specify a unit to have a valid prediod (but needs another instantiation.) E.g., "DEG_F-1 begins 2017/1/1" and "DEG_F-1 ends 2017/1/31". It's a possibility with the current structure but again not included in this RFC.
   (2) There can be an argument that we should use less ambiguous words (e.g., Fahrenheit) to represent units and directly adopting QUDT vocabularies. However, some ambiguity is unavoidable unless we use full sentences to express units. I suggest to let QUDT community to handle it and we use them directly. In fact, there is no common standard for all kinds of units and any unit standard has similar problem.
   (3) Same argument for consistency issue as (2). Not all of QUDT vocabularies are consistent. E.g., KW and KillW-HR. I would let QUDT
   (4) QUDT version 2 is under revision so not all of the vocabularies are
   (4) Alternative vocabularies: UCUM: more consistent but less comprehensive and less expressive.

What is the formal plan and process for continuing development on Brick?

Components

• RFCs: proposals for how to extend Brick. This is where the majority of discussion should take place
• Pull Requests: implemented extensions to Brick. These can be of several different types:
  • Implementation of an approved RFC: discussion should focus on the implementation, should involve extensive testing
  • Bug Fixes: typos, misspellings, inconsistencies: expected minimal discussion
• Versioning:
  • I recommend that Brick stick to Semver:
    Given a version number MAJOR.MINOR.PATCH, increment the:
    • MAJOR version when you make incompatible API changes,
    • MINOR version when you add functionality in a backwards-compatible manner, and
    • PATCH version when you make backwards-compatible bug fixes.
    • Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
• Debugging help/questions: how people learn how to use Brick and we help with any issues they have

Realization

• RFCs:
  • an RFC will be an issue on GitHub with the "RFC" label. The first post will be the operating RFC document, and discussion will take place in the comments below
  • New RFCs will be announced by a Project Maintainer on the Brick mailing lists, but discussion should be relegated to GitHub
  • RFCs will get the ACCEPTED or REJECTED GitHub label after discussion has concluded; adding this label and concluding the discussion is the responsibility of a Project Maintainer
  • if the RFC involves a change to the Brick ontology, a project maintainer will make a judgement about which release of Brick the implementation will target (see Versioning)
• Pull Requests:
  • Upon the acceptance of an RFC, one or more developers will be assigned to implement the RFC
  • If the RFC is an extension of Brick, then the Pull Request should include:
    • editing the Brick generation src to produce the new Brick file
    • a pointer to which release of Brick the PR is targeting (see Versioning)
    • changes to the example building files to make them compliant with the new version of Brick (if applicable)
    • relevant documentation on how these extensions work and how they are meant to be used
    • TODO: where does this documentation go?
    • Documentation will go on a "changelist" page on the Brick website
  • If the RFC is a proposal to change the website, alter documentation, or something other than an edit of the Brick ontology, then a
    Pull Request should still be filed on the Brick repository with a pointer to the changes (e.g. if they are on another repo) so that
    discussion can be centralized
• Versioning:
  • If we're not careful, versioning can become an Achilles heel for getting started with Brick, because we've made the choice to place the Brick version in the Brick namespace URI.
    • e.g. https://brickschema.org/schema/1.0.1/Brick#
  • Brick PATCH version numbers should not appear in the namespace URI:
    • e.g. https://brickschema.org/schema/1.0/Brick#
    • PATCHes should not affect how Brick is used, so there is no need to differentiate between them in the URI
    • TODO: do we even want to use PATCH version numbers?
    • We will keep PATCH numbers; a PATCH number will be assigned to a PR once it is accepted. This solves the problem of having multiple PRs open simultaneously.
  • Brick MINOR version numbers are incremented as the result of a milestone:
    • a milestone is a set of TODO items decided upon by an RFC
    • when all of the TODO items for a milestone are complete, the MINOR version is considered finished
    • this is the most common way of incrementing Brick version numbers
  • a Brick MAJOR version number (e.g. "Brick 2.0") will involve a fundamental, backwards-incompatible change in how Brick is used.
    I don't anticipate we'll see this anytime soon.
  • put another way, pull requests and RFCs do not automatically result in a MINOR version number increase. Instead, we will decide
    upon some set of features that constitute a new MINOR version, which will be implemented by a set of pull requests, and then we will do
    a release of that MINOR version once all of those are done.

There is a bug in tagset hierarchy creation detected by @jbkoh

:Air_Damper_Close_Limit a owl:Class ;
    rdfs:label "Air Damper Close Limit"@en ;
    rdfs:subClassOf :Damper .

The :Air_Damper_Close_Limit is obviously not a :Damper

• Add support for units

• Include smart home devices

• Interface with Haystack

• Interface with IFC

• Basic idioms:

  • represent a setpoint
  • represent an HVAC system w/ heating+cooling loops

• represent a lighting system

• represent metering infrastructure

I'm in the process of trying to map brick to a live system and I'm having some difficulty determining what maps to what because the base point types are not defined anywhere. Ex:

I have a system (VAV) with:

• a schedule-based occupancy value (schedule_occ)
• an occupancy override value (from the button a person presses to say they're here) (occ_override)
• an effective occupancy that combines the two (effective_occ)

From Brick we have (VAV_ omitted for brevity):
Occupancy_Status
Temporary_Occupancy_Status
Occupancy_Command
Occupancy_Sensor
Occupied_Command

I am assuming that the correct mapping is:
schedule_occ:occupancy_status
occ_override:temporary_occupancy_status
effective_occ:Occupancy_command

But is is not clear anywhere what the difference is between a "Status", a "Command" and a "Sensor", so It's hard to know if this is correct.

Do these definitions exist somewhere? If so, could they be added to he source? If not, maybe we need a RFC to create them?

This is related to the PR #65

I created a script to test if the tags inference is correct or not. For example, if there is an instance associated with Temperature and Sensor, a reasoner should be able to infer that this is a Temperature_Sensor, Sensor, and Point, but nothing else. Temperature_Sensor should not an instance of Temperature, for example. This is an important characteristic of Brick 1.1.0 feature as we argue that we formally validated all the tags and classes.

To do that, I instantiate entities (named as class_name + _0) and associate them with the Tags defined as restrictions for the classes. Then, I run owlrl reasoner and query what classes are inferred for the instances. A naive query to get all the superclasses are used to extract "true parents', which are compared to the inferred parents.

Here's my current result:

• Inference result: https://drive.google.com/open?id=1lrBiCQS3O8RnoGaaVI8Spzbq3_wgDEGs
• Test result: https://gist.github.com/jbkoh/438a58d2cfb250654f2b6e15431a8a55

Inference result is a ttl file and the test result is JSON file comparing incorrect inferences.

Here's an example inside Test result:

    "https://brickschema.org/schema/1.1.0/Brick#Run_Enable_Status_0": {                                                                                                                                            
      "inferred_parents": [                                                                                                                                                                                        
        "https://brickschema.org/schema/1.1.0/Brick#Run_Status",                                                                                                                                                   
        "https://brickschema.org/schema/1.1.0/Brick#Status",                                                                                                                                                       
        "https://brickschema.org/schema/1.1.0/Brick#Enable_Status",                                                                                                                                                
        "https://brickschema.org/schema/1.1.0/Brick#Start_Stop_Status",                                                                                                                                            
        "https://brickschema.org/schema/1.1.0/Brick#Point",                                                                                                                                                        
        "https://brickschema.org/schema/1.1.0/Brick#Class",                                                                                                                                                        
        "https://brickschema.org/schema/1.1.0/Brick#Run_Enable_Status"                                                                                                                                             
      ],                                                                                                                                                                                                           
      "true_parents": [                                                                                                                                                                                            
        "https://brickschema.org/schema/1.1.0/Brick#Status",                                                                                                                                                       
        "https://brickschema.org/schema/1.1.0/Brick#Enable_Status",                                                                                                                                                
        "https://brickschema.org/schema/1.1.0/Brick#Point",                                                                                                                                                        
        "https://brickschema.org/schema/1.1.0/Brick#Class",                                                                                                                                                        
        "https://brickschema.org/schema/1.1.0/Brick#Run_Enable_Status"                                                                                                                                             
      ]                                                                                                                                                                                                            
    },

Start_Stop_Status and Run_Status are incorrectly inferred in this case (false positive). There are two possibilities (analyzing Run_Status as an example):

• The restrictions of the class are not correctly defined. Either there should be more Tags or less Tags.
• The hierarchy is incorrect. There should be an rdfs:subClassOfrelationship between Run_Enable_Status and Run_Status.

Actually, there could be a worse scenario: distinguishing two classes with Tags is not possible.

Currently, there are 177 classes like this. In any case, this test result should be investigated further and I would like to learn others' thoughts.

I was stumbling around the TTL files trying to find out what CRAC was, finally found it, and I would like to rename Computer_Room_Air_Conditioning to Computer_Room_Air_Conditioner as an equipment class rather than something that describes a process. In the process I found this article and I'm curious if there should be a similar distinction in Brick with an additional family of CRAH classes.

Suggested by @blip2
Previous thread: #BuildSysUniformMetadata/GroundTruth#5
tl;dr: Adding Desk as a class under Equipment. There are sensor-enabled furniture these days. Such furniture would be useful to provide better occupancy estimation and temperature controls. Thoughts?

BuildingSync provides an XSD schema document defining many concepts related to tenants, facilities and other administrative aspects of buildings that we don't directly address yet.

It would be worthwhile to investigate how to integrate some of the BuildingSync data model into the Linked Data model we are using, and to either provide an alignment to Brick or to establish a separate BuildingSync ontology and use that for tenant-related information.

After OWL reasoning, Brick.ttl assumes that all the subclasses of brick:Quantity are instances of brick:Quantity too. Please check the regenerator code: https://gist.github.com/jbkoh/37fbec75d023eff23baeee0e7c721dd0
Quantity subclasses should not be instances, right?

I am also not sure if we want to instantiate brick:Quantity as entities. I see potential usage such as provenance tracking, but will it be actually used?

This is not a formal RFC, as it doesn't contain any concrete list of things to add to Brick. I just wanted to start this discussion as it is one of the major concepts missing in Brick right now.

Network is probably part of every equipment we have listed and is essential for many building services and applications. There is a taxonomy of networks: Ethernet, WiFi, BACnet and so on. May be we can get started with a basic list?

We also need specifics so that we can associate IP addresses to a particular equipment instance.

Thoughts?

RealEstateCore is another building ontology focused on the needs of property owners and managers. It is largely complementary to Brick and both efforts could benefit from an alignment of the concepts that we both cover (primarily the Brick Location classes)

Should be an independent dimension, like location, right?

• Integral and Integration coexist. Will replace Integration with Integral if no objections.
• Remove CWS_Chilled_Water_Pump_Command where CWS is redundant.

I just noticed that brick:measures can determine Classes alone. For example,

brick:Building_Static_Pressure_Sensor a owl:Class ;
    rdfs:label "Building Static Pressure Sensor" ;
    rdfs:subClassOf brick:Static_Pressure_Sensor ;
    owl:equivalentClass [ owl:intersectionOf ( [ a owl:Restriction ;
                        owl:hasValue brick:Pressure ;
                        owl:onProperty brick:measures ] [ a owl:Restriction ;
                        owl:hasValue brick:Air ;
                        owl:onProperty brick:measures ] ) ],
        [ owl:intersectionOf ( [ a owl:Restriction ;
                        owl:hasValue tag:Building ;
                        owl:onProperty brick:hasTag ] [ a owl:Restriction ;
                        owl:hasValue tag:Static ;
                        owl:onProperty brick:hasTag ] [ a owl:Restriction ;
                        owl:hasValue tag:Pressure ;
                        owl:onProperty brick:hasTag ] [ a owl:Restriction ;
                        owl:hasValue tag:Sensor ;
                        owl:onProperty brick:hasTag ] ) ] .

Here, there are two rules: with measures and hasTag. An inference engine could infer classes only with measures. However, there are many sensors measuring Air and Pressure other than this.

There can be two solutions

1. Define what can be measured throughout the Sensor hierarchy. For example, Building_Air can be a class that Building_Static_Pressure_Sensor measures, and then something measuring Building_Air and Pressure will be unique. This involves more complete design of "Quantity" and "Substance".

2. A simpler solution that works with our current design would be using rdfs:subClassOf for measures Restrictions instead of owl:equivalentClass.

Typically lighting systems within buildings are designed, specified and installed based on illuminance levels (measured in lux). The use of luminance for a number of classes (particularly for LightingSystem) while technically still a valid measurement, not actually the correct terminology what what happens in practice.

We need to add the following as part of Equipment class. The hierarchy can be part of Electrical System, just like a separate hierarchy for HVAC, Lighting System, etc.

• Power meters
  … We need to have a notion of which areas of a building does the power meter cover.
  ... Points: Voltage, Current, Power, Energy

• Circuit Panel
  ... Knowing where they are located and what areas they cover is useful for fault diagnosis and general maintenance.

• Fuses
  ... Knowing which circuit panel they are part of is useful for fault diagnosis

• Solar Panels
  … location and points to indicate power generation characteristics
  ... Leaving points out until we have a concrete example

• Energy Storage
  … Location, current charge levels, capacity, charging status
  ... Leaving points out until we have a concrete example

The relationships we will need:
PowerMeter isSubClassOf Meter
PowerMeter covers Location_Entity

PowerMeter can have the Points: Voltage, Current, Electrical Power, Electrical Energy
Note 1: Need the word "Electrical" to distinguish it from "Thermal"
Note 2: May need to add "Sensor" to each Point above to be consistent with rest of Brick.

ElectricalSystem isSubClassOf Equipment
CircuitPanel isSubClassOf ElectricalSystem
Fuse isSubClassOf ElectricalSystem
SolarPanel isSubClassOf ElectricalSystem
EnergyStorage isSubClassOf ElectricalSystem

Fuse isPartOf CircuitPanel (read can be part of, will be isPartOf in an instance)
CircuitPanel covers Location_Entity (also for respective instances)

BuildingSync provides an XSD schema document defining many concepts related to tenants, facilities and other administrative aspects of buildings that we don't directly address yet.

It would be worthwhile to investigate how to integrate some of the BuildingSync data model into the Linked Data model we are using, and to either provide an alignment to Brick or to establish a separate BuildingSync ontology and use that for tenant-related information.

I'd like to keep this thread to add missing TagSets whenever it's found. Anybody can add more TagSets here or comments about the list.

• Reheat Coil
• Pump Flow Status
• Chilled Water Pump Alarm
• Fire Alarm
• Supply Air Volume Sensor

EDIT: defer the two points until clarifying the meanings from Pump Status and Flow Sensor. Not handling those in this issue.

The On/Off Status hierarchy looks incorrect.

Problems:

• This forms the following two cycles:

  • brick:On_Status --rdfs:subClassOf --> brick:On_Off_Status --rdfs:subClassOf --> brick:On_Status
  • brick:Off_Status --rdfs:subClassOf --> brick:On_Off_Status --rdfs:subClassOf --> brick:Off_Status

• This makes these three classes (owl) equivalent to each other:

  • brick:On_Status
  • brick:Off_Status
  • brick:On_Off_Status

Based on the discussion at: #32

Motivation

There were no clear definitions of below highlevel Point TagSets.

Add definitions to following TagSets

1. Status: State, position, or condition of an item. (adopted from ASHRAE dictionary) Technically, this value should not be arbitrarily written by users or other systems as it is an observation.
2. Alarm: Signal, either audible or visual, or both, that alerts an operator to an off-normal condition which requires some form of corrective action. (adopted from ASHRAE dictionary)
3. Setpoint: Point at which the desired property is set. (modified from ASHRAE dictionary)
4. Sensor: device or instrument designed to detect and measure a variable.
5. Command: output point that determines equipment's behavior directly and/or affects relevant operational points.

Move Meter to Equipment

Reasoning: Meter's meaning as Point is same as Sensor. We also need the concept of Equipment measuring multiple types of values. Meter can present such things as Equipment having multiple Sensors.

E.g., Outside_Temperature_Sensor, Zone_Temperature_Sensor.

Even though it would be explicit if they have "Air" as a tag, people will commonly miss it as Location tags commonly involve Air when they are associated with Points. I would like to investigate if it's possible to have conditional rules. I.e., When Zone && Sensor, Air is inferred.

This is not an urgent issue though.

I will use this thread as a dashboard for the next release discussions. Please comment below if I missed anything. This discussion is based on the current dev repo. Once most of the items below reach some agreement, we will try to reach out to other people. Then, we will pre-release the version (guess it'd be 1.1.0).

Technical Reviews

• Review/discuss if the concept of maintaining TagSets' associated Tags is feasible.
  • This is one of the major concepts we are introducing in the new version. With this, we can formally define classes (other than just interpret a TagSet with its underscore-separated Tags.)
  • If anybody is interested in the details, we can have a call to review the design. (And I'd appreciate it.)
• Review the correctness of the current hierarchy and the Tags<->Class (i.e., TagSets) relationships.
  • Please visit our new website (thanks, @shreyasnagare!). You can navigate the class hierarchy better: https://brickschema.org/ontology/1.1.0/#Classes
  • This may be done in several subthreads.
• Grouping points by FunctionalBlocks
  • I will publish this issue later tomorrow based on the discussion between me and Aslak.
• Is feeds transitive?
  • BrickSchema/brick-owl-dl#15
• Introduce Lighting System
  • #29
  • Independent to the above issue, we have an external group interested in this. However, as the contribution has been old, I would like to finalize and merge into the next release.
• Introduce Electrical Domain
  • #28
  • https://groups.google.com/forum/#!topic/brickschema/6QvW5kJEmks
  • Similar to Lighting System
• Dangling issues
  • #49
  • #45
• Other possible features
  • Unit: We had a long discussion of this before, but we can just settle with simple unified codes.

Non-technical Reviews

• Replacing the terminology "TagSet" with "Class"
  • I won't create a separate thread for this but if there is anybody who is not sure
• Is Quantity generic enough to express what we want to model? I feel Property more fitting, but it is confusing with RDF/OWL's general Property concept. I can live with Quantity but want to learn others' opinions.

Remaining Procedure

1. Once this review is done, we will publish a beta version and get reviews publicly.
2. Once the public review/revision is done, we will publish the next version. (Either v1.1.0 or v2.0.0)

This is a reduced version of my original proposal in the other thread.

E.g., EconCycle.
Are we supposed to include proprietary names?

@gtfierro

https://github.com/BuildSysUniformMetadata/Brick/blob/21499092e0ad35705071ba8174e46baa9eeecd61/brick2/substances.yaml#L16

Just a quick fix: I believe temp should be changed to temperature.

Economizer_Mode should be a subclass of Economizer.

All,

I felt I needed to bring up this issue while reviewing our paper.

Do we really need inverse relationships? I think it carries more complexity than its convenience. Because every line of a query should be duplicated and united due to allowing inverse relationships. E.g., If I want to find sensors in a room, it should be

select ?sensor where {
?sensor bf:hasLocation ex:RM-101 .
UNION
ex:RM-101 bf:isLocationOf ?sensor .
}

because a query designer does not know whether a building manager used hasLocation of isLocationOf for the location information. Basically all queries we have used did not consider inverse relationships.

Aslak gave me an interesting example like this to show usage of inverse relationships:

select ?room where {
?room hasLocation/isLocationOf ex:RM-101 .
}

It is finding rooms located at the same hierarchy (i.e., same floor) of RM-101. However, it also needs to be duplicated and united.

select ?room where {
?room hasLocation/isLocationOf ex:RM-101 .
UNION
ex:RM-101 hasLocation/isLocationOf ?room .
}

Thoughts?

hasLocation has a nice inverse "isLocationOf"

It's also part of W3C DUL standard: https://www.w3.org/2005/Incubator/ssn/ssnx/ssn#hasLocation

Migrated from BuildSysUniformMetadata/GroundTruth#8

By @GeorgFerdinandSchneider:
Dear Brick development team!

it might be helpful for people reusing BRICK to have the license mentioned within the ontology meta-data, via the dcterms:license annotation property. For example in Turtle syntax:

@prefix dcterms: <http://purl.org/dc/terms/> .
<https://brickschema.org/schema/1.0.2/BrickFrame> dcterms:license <https://raw.githubusercontent.com/BuildSysUniformMetadata/GroundTruth/master/LICENSE> .

or similarly.

There doesn't seem to be a class to define shading devices e.g. automated blinds or adjustable brise soleil - should be a fairly straightforward definition for the equipment:

Equipment>Adjustable Shading
Equipment>Adjustable Shading>Blind
Equipment>Adjustable Shading>Louver

The control and measurement definitions would be very similar to a Damper (position, limit sensor/setpoints, command)

I believe the UndefinedMeasurement class members are those things that use the UndefinedMeasurment tag, but other than that, the class doesn't seem to be useful. For example, a battery voltage is an observable property:

:Battery_Voltage a owl:Class ;
    rdfs:label "Battery Voltage"@en ;
    rdfs:subClassOf :UndefinedMeasurement .

It seems odd to subdivide something undefined :-).

I would like to get back all the removed classes removed without discussions. I believe the general governance of Brick would be that any change should based on discussions 1) to minimize version bumps and 2) for consensus-based changes.

For example

• Emergency_Power_Off_System (i.e. EPO)
• Electricity_Meter
• All the Alarms
• Gas_Usage_Sensor
• Louver
• Smoke related points
• Standby_CRAC

I cannot enumerate all of them here for now. Though we can still remove them based on discussions, I want to defer such discussions for the next versions.

It was requested by @gtfierro and @bbalaji-ucsd to move the usesDimensions from the Brick ontology into a separated one