Hey folks, I'm a newcomer to Haystack. I've looked through the documentation and reference implementation, and I can't find a set of rules for when tags can or cannot be used with other tags.
Many tags show which other tags they can be used with (e.g., air is used with point), but I don't see anywhere a strict or definitive list of rules. Can implementations said to be Haystack compliant without that info?
Another point of confusion for me: curVal (http://project-haystack.org/tag/curVal) lists its kind as obj, but I don't see a definition for obj in tag kinds.
Thanks!
Robert
Brian FrankTue 19 Nov 2013
can't find a set of rules for when tags can or cannot be used with other tags.
Its really more just based on your model than any explicit set of rules. For example it doesn't make sense to say that an entity represents both a site and a point.
Another point of confusion for me: curVal (http://project-haystack.org/tag/curVal) lists its kind as obj
That basically indicates that it can be one of many different types. In the case of curVal the value type is based on the kind tag: Number for analog points, Bool for binary points, and Str for multi-state/enum points.
Mike JarmyTue 19 Nov 2013
Also, there are actually a lot of examples of tagging models defined in the docs. For instance, see the page on Chillers for an example of how a fairly complex model defines its rules for using tags.
Robert PrinceTue 19 Nov 2013
Correct me if I'm wrong, but the Chillers page doesn't show a modeling example; it lists tags that are applicable for the different sections.
In 16.4/Cooling Towers (in the Chillers page), it's noted that equip tagged with coolingTowers will also have an equipRef tag that must reference a parent chillerPlant. This is the type of thing that motivated my question in the first place: does the word must mean MUST as in RFC 2119?
I understand that a model won't be of much use unless the tags/structures/references are applied in a semantically correct way; I'm just looking for some guidance and I'm not finding it in the documentation.
Thanks, R
Brian FrankTue 19 Nov 2013
Modeling entities doesn't really fit the RFC "must" and "should", although I would say in general I have been using those terms as we would use them in an RFC. In reality modeling is pretty messy and getting just the very basics of the tagging right is way better than what we typically see today.
It is extremely application specific what turns into a MUST. Most simple apps can probably get by with very little of the tagging in place. But I've seen more advanced analytics applications which require very full and correct models be created. For example given you example, whether you really need to model your coolingTower with an equipRef to the chillerPlant is largely dependent on the application consuming that data and if it needs to understand that relationship.
I think after we have more experience under our belt that we'll probably reach a point where enough applications have been built that we might create "levels of compliance", but I'm not sure we are ready to take that step.
Robert PrinceTue 19 Nov 2013
Thank you - I have a much better sense for this stuff.
Robert Prince Tue 19 Nov 2013
Hey folks, I'm a newcomer to Haystack. I've looked through the documentation and reference implementation, and I can't find a set of rules for when tags can or cannot be used with other tags.
Many tags show which other tags they can be used with (e.g., air is used with point), but I don't see anywhere a strict or definitive list of rules. Can implementations said to be Haystack compliant without that info?
Another point of confusion for me: curVal (http://project-haystack.org/tag/curVal) lists its kind as obj, but I don't see a definition for obj in tag kinds.
Thanks!
Brian Frank Tue 19 Nov 2013
Its really more just based on your model than any explicit set of rules. For example it doesn't make sense to say that an entity represents both a site and a point.
That basically indicates that it can be one of many different types. In the case of
curVal
the value type is based on the kind tag: Number for analog points, Bool for binary points, and Str for multi-state/enum points.Mike Jarmy Tue 19 Nov 2013
Also, there are actually a lot of examples of tagging models defined in the docs. For instance, see the page on Chillers for an example of how a fairly complex model defines its rules for using tags.
Robert Prince Tue 19 Nov 2013
Correct me if I'm wrong, but the Chillers page doesn't show a modeling example; it lists tags that are applicable for the different sections.
In 16.4/Cooling Towers (in the Chillers page), it's noted that equip tagged with coolingTowers will also have an equipRef tag that must reference a parent chillerPlant. This is the type of thing that motivated my question in the first place: does the word must mean MUST as in RFC 2119?
I understand that a model won't be of much use unless the tags/structures/references are applied in a semantically correct way; I'm just looking for some guidance and I'm not finding it in the documentation.
Thanks, R
Brian Frank Tue 19 Nov 2013
Modeling entities doesn't really fit the RFC "must" and "should", although I would say in general I have been using those terms as we would use them in an RFC. In reality modeling is pretty messy and getting just the very basics of the tagging right is way better than what we typically see today.
It is extremely application specific what turns into a MUST. Most simple apps can probably get by with very little of the tagging in place. But I've seen more advanced analytics applications which require very full and correct models be created. For example given you example, whether you really need to model your coolingTower with an equipRef to the chillerPlant is largely dependent on the application consuming that data and if it needs to understand that relationship.
I think after we have more experience under our belt that we'll probably reach a point where enough applications have been built that we might create "levels of compliance", but I'm not sure we are ready to take that step.
Robert Prince Tue 19 Nov 2013
Thank you - I have a much better sense for this stuff.
Thanks, R