Open saiprasadbalaji opened 4 months ago
Hi there @saiprasadbalaji! Good to meet you and thanks for raising this issue.
We talked a little bit about this issues with @connorjcantrell today. My understanding from the description you gave is that the re-introduction of Supply/Return would allow you to more easily differentiate between points relating to the system vs points relating to individual equipment w/n the system; in the absence of other contextual information (i.e., having those entities modeled in the graph), the tendency would be to imbue the point classes with additional semantic meaning that differentiates between those cases.
I would like us to think more about how we could solve this w/o having to have points that insist on what kind of entity they are connected to. Could we have mock "stub" systems that are eventually resolved into a single "known" entity? Or some global "virtual" system that can own points before we know what instance they are associated with. Essentially, I think we can address this issue by figuring out a way that points can be associated with a TYPE of entity without having to know what INSTANCE of that entity happens to have that point. Do I understand this ok? @connorjcantrell please chip in with your thoughts too!
For the water systems, I propose reintroducing the terms “supply” and “return” which were deprecated recently in favour of the terms “leaving” and “entering”. In the context of BMS, the distinction between "supply/return" and "entering/leaving" is crucial, especially when dealing with a common header. Therefore, I propose bringing back the terms "supply" and "return" due to the following reasons:![image](https://github.com/BrickSchema/Brick/assets/163540458/fad2975e-8f2d-4288-b13b-eecf3d944a2a)
For Hot water system,![image](https://github.com/BrickSchema/Brick/assets/163540458/e48740de-e863-4722-927a-0bb65340b2d1)
Thanks, Sai