I'm evaluating how to map Haystack into oBIX. So far it's a slight mismatch, but maybe not too bad.
A few concepts that I'd like some input on:
Marker tags seem like a good fit for contracts. However, it seems that very few tags are required in conjunction with a marker. For example, elecMeter must always have an associated elecKw and elecKwh. haystack:elecMeter would be the oBIX contract and elecKw and elecKwh would be elements within the contract. In the current docs, there are not many required tags. It feels like there should be more required tags, but I like the flexibility that comes with the optional tags too.
As mentioned in #1, I think haystack will have its own namespace for oBIX contracts. Not sure if it should just be "haystack:" or if each domain should be separated like "hselectric", "hshvac", or something.
Non-marker tags should just be the "name" attribute of any oBIX element.
I think oBIX is also in desperate need of better search capability, but that's a different topic.
Brian FrankTue 6 Sep 2011
Hi John,
Couple of thoughts...
First off I think it makes sense to clarify the exact use case where we use oBIX and Haystack together. Are we annotating an existing oBIX server to provide additional meta-data tags via Haystack? Or maybe using oBIX as a transport for a Haystack aware query protocol? I was originally thinking if you had a haystack aware system that oBIX might be a good transport protocol. But with XML falling out of favor, I've sort of been thinking a simpler JSON/text payloads are much easier to work with.
For some context take a look at the Java Haystack toolkit which has a simple text format for serializing name/value pairs like this:
If I wanted to query history entities in a Niagara JACE, this is what I would consider the simplest you could make it:
// get tag query
GET /haystack/query?his
// response as entities of tags
id:</His/ZoneTemp>, dis:"Zone Temp", his, hisSize:105, unit: "°F"
id:</His/Demand>, dis:"Elec Demand", his, hisSize:78, unit: "kW"
But if we were interested in augmenting an oBIX object with Haystack tags what might that look like? I think the first step is to recognize that oBIX tries to predefine the "children fields" with contracts, but Haystack largely doesn't care - the "children field" themselves are what defines semantics (we don't make a distinction b/w data and types). So I think about the problem like this: how could oBIX object fields be mapped to Haystack tags? In that case we might not use oBIX contracts at all:
Luckily (and not by accident :-) oBIX and Haystack share some important characteristics:
same model for scalar types
same model for timezones
same model for units (mostly)
Couple things to note:
in oBIX we have display attribute which fills same role as dis tag
otherwise seems pretty easy to map 1-tag to 1-child obj
not sure about markers, if you want to keep thing 1-to-1 the way I did above seems nice, otherwise maybe you add all markers in root object is attribute
you could annotate each oBIX obj with attribute that says it is haystack tag, but not sure it is necessary
John SublettTue 6 Sep 2011
I agree on nearly all of your oBIX example. I haven't done a full review of all of the marker tags, but all of the ones so far seem to be related to the kind of thing (i.e. type) that an object represents. Modifying your example would result in:
<obj display='Building A' is="haystack:Site">
...
</obj>
Then it's just a question of which child elements are part of the Site contract. I realize that the trick to contract definition is to only include the things are actually required. The crux of what I'm proposing is that haystack markers be mapped as marker contracts in oBIX. I'm less concerned about which value elements are part of each contract.
Why did you do a new name/value text encoding vs. just using JSON? I agree that XML is becoming a bit passe. My knee-jerk reaction to that is to add a JSON encoding for oBIX. Then I still get parsing in Javascript applications for free.
Joe GreyTue 6 Sep 2011
Hey John,
If I understand your definition of contracts correctly, I'm not sure if they map to all marker tags 1:1. I agree with you example with elecMeter, this work out perfectly. But a marker tag such as fan doesn't work out quite the same way. When I first read contract, I was thinking "group" or maybe "type". Others that may work out as contracts could be ahu, chiller, vav or lighting. These may have required tags and also associated "children".
Something that should not be forgotten is how to model "relationships". Some tags in haystack so far end with Ref, short for reference. These are indicating a relationship and not necessarily always a 1:1 parent to child relationship.
John SublettTue 6 Sep 2011
I think fan still works as a marker contract. In oBIX it would just be:
My point is more about what feels right. I think the marker tags are all about what the thing is and the value tags represent data associated with it. A ref is just a value tag whose value is an identifier for another thing.
Joe GreyTue 6 Sep 2011
Makes a little more sense to me in your last example; wrapping up multiple tags into the is attribute.
Brian FrankWed 7 Sep 2011
I agree on nearly all of your oBIX example. I haven't done a full review of all of the marker tags, but all of the ones so far seem to be related to the kind of thing (i.e. type) that an object represents.
Marker tags mostly represent a "type", although becoming a little more muddy with our notion of breaking things up into lots of little tags: discharge air temp. I am not sure I would classify air a type per se.
Also I would say things you might traditional classify as a "type" are not always marker tags. A good example is the elecMeterLoad which indicates an entity is both an electrical load and references its most direct meter/submeter.
what I'm proposing is that haystack markers be mapped as marker contracts in oBIX
Although maybe not the cleanest solution, I think you could justify it simply for the sake of brevity and avoiding needlessly complex XML:
// Haystack
dis: "Store-1 RTU-2 Cool-3", cool, stage: 3, out, point, his
// oBIX with markers in is attribute
<obj display='Store-1 RTU-2 Cool-3' is='h:cool h:out h:point h:his'>
<int name='stage' val='3'/>
</obj>
// oBIX with markers as child objects
<obj display='Store-1 RTU-2 Cool-3'>
<obj name='cool' is='h:Marker'/>
<obj name='out' is='h:Marker'/>
<obj name='point' is='h:Marker'/>
<obj name='his' is='h:Marker'/>
<int name='stage' val='3'/>
</obj>
Rav PanchalingamTue 11 Feb 2014
Hi All,
I note that you had this conversation back in 2011. I'm now trying to do this exact thing for a project (merging haystack and oBIX into one data model). Was there any progression or development done further from what's been discussed above?
Rav
Brian FrankTue 11 Feb 2014
I don't think anything was ever formally defined. In SkySpark I'm mapping tags to oBIX objects like this:
marker tags are encoded into is attribute as tag:foo tag:bar
The 1.1 version of the OBIX spec is out for public review now, and includes a mechanism for reporting tags. If you'd like to take a look and comment on it, you should be able to find it on the OASIS site at http://docs.oasis-open.org/obix/obix/v1.1/csprd02/obix-v1.1-csprd02.pdf
The committee welcomes any input on the specification.
John Sublett Tue 6 Sep 2011
I'm evaluating how to map Haystack into oBIX. So far it's a slight mismatch, but maybe not too bad.
A few concepts that I'd like some input on:
I think oBIX is also in desperate need of better search capability, but that's a different topic.
Brian Frank Tue 6 Sep 2011
Hi John,
Couple of thoughts...
First off I think it makes sense to clarify the exact use case where we use oBIX and Haystack together. Are we annotating an existing oBIX server to provide additional meta-data tags via Haystack? Or maybe using oBIX as a transport for a Haystack aware query protocol? I was originally thinking if you had a haystack aware system that oBIX might be a good transport protocol. But with XML falling out of favor, I've sort of been thinking a simpler JSON/text payloads are much easier to work with.
For some context take a look at the Java Haystack toolkit which has a simple text format for serializing name/value pairs like this:
If I wanted to query history entities in a Niagara JACE, this is what I would consider the simplest you could make it:
But if we were interested in augmenting an oBIX object with Haystack tags what might that look like? I think the first step is to recognize that oBIX tries to predefine the "children fields" with contracts, but Haystack largely doesn't care - the "children field" themselves are what defines semantics (we don't make a distinction b/w data and types). So I think about the problem like this: how could oBIX object fields be mapped to Haystack tags? In that case we might not use oBIX contracts at all:
Luckily (and not by accident :-) oBIX and Haystack share some important characteristics:
Couple things to note:
displayattribute which fills same role asdistagisattributeJohn Sublett Tue 6 Sep 2011
I agree on nearly all of your oBIX example. I haven't done a full review of all of the marker tags, but all of the ones so far seem to be related to the kind of thing (i.e. type) that an object represents. Modifying your example would result in:
<obj display='Building A' is="haystack:Site">
</obj>
Then it's just a question of which child elements are part of the Site contract. I realize that the trick to contract definition is to only include the things are actually required. The crux of what I'm proposing is that haystack markers be mapped as marker contracts in oBIX. I'm less concerned about which value elements are part of each contract.
Why did you do a new name/value text encoding vs. just using JSON? I agree that XML is becoming a bit passe. My knee-jerk reaction to that is to add a JSON encoding for oBIX. Then I still get parsing in Javascript applications for free.
Joe Grey Tue 6 Sep 2011
Hey John,
If I understand your definition of contracts correctly, I'm not sure if they map to all marker tags 1:1. I agree with you example with
elecMeter, this work out perfectly. But a marker tag such asfandoesn't work out quite the same way. When I first read contract, I was thinking "group" or maybe "type". Others that may work out as contracts could beahu,chiller,vavorlighting. These may have required tags and also associated "children".Something that should not be forgotten is how to model "relationships". Some tags in haystack so far end with Ref, short for reference. These are indicating a relationship and not necessarily always a 1:1 parent to child relationship.
John Sublett Tue 6 Sep 2011
I think
fanstill works as a marker contract. In oBIX it would just be:My point is more about what feels right. I think the marker tags are all about what the thing is and the value tags represent data associated with it. A ref is just a value tag whose value is an identifier for another thing.
Joe Grey Tue 6 Sep 2011
Makes a little more sense to me in your last example; wrapping up multiple tags into the
isattribute.Brian Frank Wed 7 Sep 2011
Marker tags mostly represent a "type", although becoming a little more muddy with our notion of breaking things up into lots of little tags:
discharge air temp. I am not sure I would classifyaira type per se.Also I would say things you might traditional classify as a "type" are not always marker tags. A good example is the
elecMeterLoadwhich indicates an entity is both an electrical load and references its most direct meter/submeter.Although maybe not the cleanest solution, I think you could justify it simply for the sake of brevity and avoiding needlessly complex XML:
Rav Panchalingam Tue 11 Feb 2014
Hi All,
I note that you had this conversation back in 2011. I'm now trying to do this exact thing for a project (merging haystack and oBIX into one data model). Was there any progression or development done further from what's been discussed above?
Rav
Brian Frank Tue 11 Feb 2014
I don't think anything was ever formally defined. In SkySpark I'm mapping tags to oBIX objects like this:
isattribute astag:foo tag:barExample for RTU:
Craig Gemmill Wed 12 Feb 2014
The 1.1 version of the OBIX spec is out for public review now, and includes a mechanism for reporting tags. If you'd like to take a look and comment on it, you should be able to find it on the OASIS site at http://docs.oasis-open.org/obix/obix/v1.1/csprd02/obix-v1.1-csprd02.pdf
The committee welcomes any input on the specification.