gtfierro
commented
1 year ago Of course! Answers inline
I'm curious to understand the technical reason for defining equivalent classes instead of creating alternative labels for a class e.g., Air Handler Unit and AHU, each of which are equivalent to Air Handling Unit ?
No fundamental reason other than that's how we first approached it -- it can be nice to use the abbreviations/aliases as "shorthand" when creating a model. If we were to do Brick again from scratch I probably would just have multiple alternate labels
Similarly, what is the intent of the aliasOf property for equivalent classes? Does it represent the same semantics as class equivalence?
aliasOf allows us to point from the alias to the "primary" class, e.g. from AHU (alias) to Air_Handling_Unit (primary). Using equivalentClass directly would prevent us from making this distinction
Several classes in the 7/14 nightly build are sub-classes of owl:Thing instead of Brick:Entity or Brick:Class. Will they be moved into the appropriate sub-tree at some point?
What classes are these? It sounds like an oversight. Do you mean "Cooling Discharge Air Flow Setpoint" and things like it?
Properties represented as Classes e.g., Cooling Discharge Air Flow Setpoint, is there a write up that explains this tech architecture?, and will there be an abstract class under which they are grouped, so they are not at the top of the tree under owl:Thing?
"Cooling Discharge Air Flow Setpoint" is a class, not a property. It is also an "aliasOf" the Cooling Supply Air Flow Setpoint -- you may need to run SHACL reasoning to get the correct relationships to show up. This maybe suggests we should run SHACL reasoning on the ontology as part of the build process
I hope it' ok to ask a few questions here...if not, please feel free to close this issue.
I'm curious to understand the technical reason for defining equivalent classes instead of creating alternative labels for a class e.g., Air Handler Unit and AHU, each of which are equivalent to Air Handling Unit ?
Similarly, what is the intent of the aliasOf property for equivalent classes? Does it represent the same semantics as class equivalence?
Several classes in the 7/14 nightly build are sub-classes of owl:Thing instead of Brick:Entity or Brick:Class. Will they be moved into the appropriate sub-tree at some point?
Properties represented as Classes e.g., Cooling Discharge Air Flow Setpoint, is there a write up that explains this tech architecture?, and will there be an abstract class under which they are grouped, so they are not at the top of the tree under owl:Thing?
Thank you, Andrew