Like the organizing of points and equipment by system, I see a need to organize by area served. Is this something that is being looked at also. Do others have thoughts on that concept?
This will allow you to create relationships between your area and the entities you'd like to associate with it.
Samuel NelsonFri 31 Mar 2023
Hey thanks for your reply Keith! We use spaces for containment. What if I want to model containment and area served at the same time?
Samuel
Brian FrankFri 31 Mar 2023
If you have a VAV then you have two relationships. The spaceRef tag on the VAV is where it is located from a containment perspective. The relationship of what space it serves is modeled via the airRef tag on the space itself pointing back to the VAV (or VAVs). You can also trace back multiple airRefs to get the AHUs serving the space.
Samuel NelsonSat 1 Apr 2023
Thanks :) I see. A space is the physical, and so it is an entity in Haystack and served is a relationship between equipment and space. Things like airRef and hotWaterRef model different relationships. Does a system get to have such "served" relationships, or is that simply modeled through the equipment comprising it?
Samuel
Georgios GrigoriouMon 29 May 2023
"The relationship of what space it serves is modeled via the airRef tag on the space itself pointing back to the VAV (or VAVs). You can also trace back multiple airRefs to get the AHUs serving the space."
Thanks Brian for that. Can see that corresponds to flow Relationships https://project-haystack.org/doc/docHaystack/Relationships which is useful.
Personally, I think it would make sense to have a tag related to "area served" maybe as "servesRef", "servedRef" or "areaServedRef" for a couple of reasons to keep it consistent with the other Ref tags of Project Haystack for 2 main reasons:
have the relationship visible at the equipment level and not only at the space level. Also, in that way, the relationship is visible without the need to query in order to do that.
after discussing with clients, engineers, and colleagues about that, it seems that it's easier for them to understand and fill in that information with a "servesRef" tag, so seems more self-explanatory for them.
In terms of design in the ontology and to my understanding, that will mean that essentially another group of relationships should be introduced cause at the moment a "servedRef" cannot be assigned to neither containment relationships nor flow relationships?
Samuel Nelson Thu 30 Mar 2023
Hi everyone,
Like the organizing of points and equipment by system, I see a need to organize by area served. Is this something that is being looked at also. Do others have thoughts on that concept?
Take care! Samuel
Keith Bishoρ Fri 31 Mar 2023
You are probably looking for Spaces: https://project-haystack.org/doc/docHaystack/Spaces
This will allow you to create relationships between your area and the entities you'd like to associate with it.
Samuel Nelson Fri 31 Mar 2023
Hey thanks for your reply Keith! We use spaces for containment. What if I want to model containment and area served at the same time?
Samuel
Brian Frank Fri 31 Mar 2023
If you have a VAV then you have two relationships. The spaceRef tag on the VAV is where it is located from a containment perspective. The relationship of what space it serves is modeled via the airRef tag on the space itself pointing back to the VAV (or VAVs). You can also trace back multiple airRefs to get the AHUs serving the space.
Samuel Nelson Sat 1 Apr 2023
Thanks :) I see. A space is the physical, and so it is an entity in Haystack and served is a relationship between equipment and space. Things like airRef and hotWaterRef model different relationships. Does a system get to have such "served" relationships, or is that simply modeled through the equipment comprising it?
Samuel
Georgios Grigoriou Mon 29 May 2023
"The relationship of what space it serves is modeled via the airRef tag on the space itself pointing back to the VAV (or VAVs). You can also trace back multiple airRefs to get the AHUs serving the space."
Thanks Brian for that. Can see that corresponds to flow Relationships https://project-haystack.org/doc/docHaystack/Relationships which is useful.
Personally, I think it would make sense to have a tag related to "area served" maybe as "servesRef", "servedRef" or "areaServedRef" for a couple of reasons to keep it consistent with the other Ref tags of Project Haystack for 2 main reasons:
In terms of design in the ontology and to my understanding, that will mean that essentially another group of relationships should be introduced cause at the moment a "servedRef" cannot be assigned to neither containment relationships nor flow relationships?
What are the thoughts of the community on that?
Best Regards,
Georgios Grigoriou