Are-We-There-Yet?

We now have web services to almost any conceivable control system. We have BACnet-XML and BACREST. We have TAC Web Services. We have LON XML. We have oBIX. So...are we there yet?

[an error occurred while processing this directive]

As Louis Hecht has written:

XML does not provide semantics. XML does not solve business problems. XML Schemas do not provide semantics or solve business problems. XML, by itself, does not solve interoperability problems, yet it is an important tool for doing so.

This is true, to a point. Bad XML Schema, and perhaps most first generation XML schemas do not provide semantics. Good XML schemas implement semantics, bad ones do not. For an example form within this space, I would argue the GBXML provides semantics. Even oBIX 1.0, frustrating to me, offers semantics, but one limited to points services and therefore not readily accessible to business functions. Establishing base semantics was a critical early goal of that project.

Good XML Schemas are all about semantics, for without semantics there is no interoperability. I would refer to something like UBL (Universal Business Language) as an overarching semantic framework that is being built into numerous schemas at a deep level.

Louis’s larger point is true. XML and XML schema do not inherently include semantics—even if the good schema do.

[an error occurred while processing this directive] One of the reasons that I am watching NBIMS so closely from the oBIX vantage point is that the higher semantics will need to be there before oBIX has an enterprise interface. I have a hard time imagining what applying Policy to point services even means.

As Enterprise programmers will never be control engineers, we are going to have to wrap up the standard functions into business services. In oBIX if I define a set of functionalities for a given period of time, it is called a contract. For these to be useful, we will need to pre-define several contracts and make each of them discoverable. Discovery will mean that we need to describe each one in terms of the service it provides. The Description/Catalogue will need to be machine readable rather than human readable, which means it will be based on Semantics.

But whose semantics?

I am hoping we can find a way to map Design Intents / Systems modeled by the energy model / spaces served into Service descriptions. It would make sense, then, to invite the control system's Service to the same meeting. To do that, to make a Service that can be subject to Policy, that can have rational Security applied, that can be Discovered by enterprise applications will require that we have Semantics embedded in the XML of the Service Descriptions.

I believe that as we all become more familiar with NBIMS, we will be able to discover the Semantics needed to do this. Somewhere in the check list of Services to be Commissioned, in the Systems in the Energy Model, and even in the Function analyzed by the Code Compliance checker are the Semantics needed to create discoverable abstract services.

And that XML will be an order of magnitude more useful because it is semantically laden.

[an error occurred while processing this directive]
[Click Banner To Learn More]

[Home Page]  [The Automator]  [About]  [Subscribe ]  [Contact Us]