Apologies if this is an overly general topic, but I'm in the process of researching/designing a metadata model for campus building and electric systems data and had a few questions about the Haystack model.

In looking at the tag model used in Haystack, it seems that there isn't much sense of direction or mapping between entities. The site/equip/point hierarchy (and associated ref tags) incorporates some level of direction, but really only applies to one of many potential hierarchies. It also seems to lend itself to one-one or one-many mappings (not really supporting many-many).

Would someone be able to explain some of the thinking that went into the tag model instead of something like RDF triples or similar directed metadata models?

As an example of another take on the problem, I found this article interesting in that it combined some of the tagging concepts along with a more directed graph approach that enables a geospatial layer to the metadata linkages: http://www.cs.berkeley.edu/~krioukov/BAS.pdf

Thanks in advance.

Hi Dylan,

The Haystack meta-data model is very simple by design for two reasons:

1. it must be easily understood and applied by contractors installing systems to have any hope of gaining widespread acceptance; the terminology and model developed seems to have been a good sweet spot
2. it is designed to be easy to apply to existing data models that might be used in BAS systems

The tag model is pretty simple: a tag name and value model some fact or attribute about an entity. That model leads itself to work very well with object oriented data, relational data, formatting in CSV and Excel, etc. And it actually maps very cleanly into RDF triples. So if you want to use RDF, then Haystack maps right in. I believe this has been prototyped by two different companies.

The ability to establish relationships with Ref tags is deliberately very simple. But in practice has worked very well. We've been able to successfully model a lot of different aspects of buildings and their equipment systems. Although I think at some point, we might have to tackle many-to-many relationships.

Brian,

Thanks a lot for the response. Definitely helpful information, and I guess some of my questions are driven by thinking about some different use cases for the metadata than the primary use case that Haystack is driving at. We are trying to support a number of applications that may go outside of standard building data organization. We may end up having to enable a couple layers of metadata, and knowing that people have piloted the tags-RDF mapping is nice to know.

I agree that in general, the tagging structure has achieved a nice combination of flexibility and simplicity... and we are definitely considering how to incorporate this into the overall metadata scheme. As we get deeper into the process, I'll probably reach out again.

Have you ever considered a geospatial layer similar to that referenced in the paper I linked? It sounds like it contains shapes that overlay onto the entities in the building.

Thanks for the feedback.

Have you ever considered a geospatial layer similar to that referenced in the paper I linked? It sounds like it contains shapes that overlay onto the entities in the building.

That is essentially what the discussions about space and zone are trying to solve. So yes we will be formalizing that at some point - its a big part of the domain

At the risk of posting a commercial, and safe harbor statement: all of this is under development and subject to change.

Our new semantic model in development for Niagara 4 is based off of the Haystack tag model but adds tag namespaces and defined, directed relationships. It also allows you to traverse a relationship in reverse. For Haystack, we have modeled ref tags as relationships. It works out great and allows Haystack to map perfectly into our new graph database.

Haystack filters work as is plus some extra syntax for relationship traversal when needed. And while we haven't completed the ability to publish as RDF, that is looking very straightforward at this point.

The simplicity of the Haystack model is simple, yet powerful and enables it to be mapped into multiple different underlying technologies.

If only there was a more machine readable description of the tags, refs, and associated rules. :) That's another thread.

John,

Safe harbor statement is totally fine :) Its cool to know that other folks are thinking along some similar lines, and that mapping into a directed graph has gone well. The ref tag idea makes a lot of sense.

I agree that Haystack provides a flexible/powerful base...that hopefully gains even more widespread adoption...making all the additional capabilities built on it more inter-operable, and potentially warranting the overhead involved with the machine readable concept (would this be something similar to the URIs associated with RDF?, sorry maybe we should take that to another thread at some point).

Regardless thanks for the input, and as we ramp up our work on compiling the database for our campus, maybe I will reach for a more in-depth discussion.

Cheers.