crc: I'm not a huge fan of Zoom but chose it because most folks are familiar with it. I would be open to trying an alternative video conference system that is more open. Its a little soon to change that for our next meeting on Oct 7th, but maybe others on the list can chime in with how they feel? We can certainly discuss this next week.
Hi Greg:
You should be added now! Let me know if you aren't.
I've been playing around with some approaches of using Python to do some of the processing of determining the Brick types. I've encapsulated some of this in an implementation of the reconciliation API here:
https://github.com/gtfierro/brick-builder/tree/master/reconciliation-apis. I also recorded a 18-min video showing how to create a Brick model from point labels end-to-end:
https://youtu.be/LKcXMvrxXzE which you may find helpful. I think the reconciliation API is a great way of incorporating the kinds of cleaning and inference techniques you mentioned.
There are some references to papers detailing ML-based approaches to doing this transformation near the top of this thread, but often times these efforts are grappling with parsing as well as classification. OpenRefine handles much of the parsing for us, so I think there is a role for some advanced predictive software to handle the classification after OpenRefine has identified which part of the label is relevant. You can also get pretty far with some simple encoding of BMS label conventions (e.g.
https://github.com/gtfierro/brick-builder/blob/master/reconciliation-apis/abbrmap.py) which I use in the reconciliation API demo. Like we discussed last time, it might be a good approach to allow some upload/configuration of your labeling convention which can then be used to parse the points.
To your other thoughts on scope:
- the core focus of this project is to produce Brick models from BMS exports and other semi-structured 'brownfield' metadata. While we are focusing on Point labels as a data source, the goal is to be able to infer as much Brick metadata as possible from the available information, including but not limited to Point classes, Equipment classes, rooms, zones, structure of HVAC systems, etc.
- Equipment and Location can definitely be exported as part of the OpenRefine step! I do this in the YouTube video I linked above if you would like an example (the video description has some links to all of this)
- We have been working on automatic translation of unstructured metadata to Brick since ~2015, and I cite a few of those papers in the thread you linked. Because Haystack traditionally has no standardization of tags to concepts, we've been using inference techniques to perform the translation from Haystack to Brick (not yet the otherway around) using tools like
https://brickschema.readthedocs.io/en/latest/. The process is documented in this paper:
http://people.eecs.berkeley.edu/~gtfierro/papers/houseofsticks-frontiers-2020-Fierro.pdf . Haystack "protos" are a step in the right direction and as that effort settles down and coalesces we can explore the mapping between Brick classes and those protos. As it stands, I would not say that incorporating Project Haystack tags is a core focus of this specific effort, but compatibility with [[Project]] Haystack remains a long-term goal for Brick development efforts.
Hope that answers your questions!
Best,
Gabe