New Daedalus

On the NBIMS list yesterday, Louis Hecht with the Open Geospatial Consortium (OGC) observed:

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.

And he was exactly right. Bad XML Schemas, and perhaps most first generation XML schemas do not provide semantics. Good XML schemas implement semantics, bad ones do not. For an example, within the Building 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.

The larger point is true. XML and XML schema do not inherently include semantics - but the good schema do. 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. Our next challenge is to figure out how oBIX accepts an ICAL invitation to make the building system "occupant aware".

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.

It is still my plan that as I become more familiar with NBIMS, I will be able to discover the Semantics I need 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.

Got an idea on how we can bring semantics  to building systems XML  - please post a comment...

I was talking to someone today who argued, passionately, that if a protocol did not let you get to all the details, then it was irreparably badly designed.

This is wrong in several ways. If a public protocol that exposes systems to people from another domain, it is a security problem. It is harder to use because it has unnecessary complexity. It may be just too hard to use for most purposes.

Reaching for an example, I come to HAVE, the Hospital Availability Exchange. As I understand it, HAVE is a web service that makes waiting lines visible to people outside the hospital.

Imagine a scenario with an ambulance driver performing triage. He picks up the first patient and quickly decides “We’re going to need an MRI for this one.” MRI waits can be several days in some hospitals at some times. Using HAVE, the ambulance driver determines which of several hospitals within five miles has the shortest wait for an MRI.

Imagine someone had insisted that HAVE had to expose all the details. Perhaps have it include the patient scheduling, or diagnostic details. Letting anyone use such a HAVE would probably be a HIPPA violation, exposing the patient’s personally identifiable health information.

Instead, the group working on HAVE wisely limited it to some surface details. Those details are fully adequate to meet the needs of determining availability of service. Even with vigorous hacking, it is unable to reveal inappropriate information because HAVE does not include the detail.

By creating a limited protocol, the creators of HAVE created a useful protocol.

In the same way, advocates of building control protocols who want to be able to perform all functions with an enterprise function simply get thing wrong. In the same way, advocates of Power Grid protocols who want full CIM (Computer Information Models) for each house get it wrong. Such details would make the protocols to difficult and nuanced to use. They would inappropriately expose detailed inner process information to those either who do not know how to use that information, or who do not have sufficient expertise to use that information well. Either of these is a risk.

Enterprise protocols should stick to the surface. It is the nature of enterprise protocols to expose information beyond their domain. Those who know that domain should have enough respect for their own work to occult the details.

I have recently gotten a few letters from advocates for one of the many fine existing standards protesting that are already several fine protocols (in each domain) and all we have to do is wrap them in a “ web-service oriented API” and we are done. I think this is fundamentally wrong.

The established control protocols are too detailed. This makes them both too powerful to let into the open, and too difficult to use. An enterprise interface should not require its consumers to have extensive domain-specific knowledge about its inner workings.

Using them for enterprise interactions is far too much like planning an ouing with small children. Say one wants to go to the lake:

OK kids, put on your shoes. Katy, where are your shoes. No, those are your Sunday shoes. Margot, you have to use shoes that match. Are your water shoes where you left them on the porch last week? (There’s that domain specific knowledge requirement!) Did anyone pack the sun-screen? Do not sit on the couch to put on sun screen. (Experience as a requestor and knowing, alas, where most of the sun screen will end up) Who put the dog in the car - -dogs are not allowed.

And so it goes.

Instead plan the same trip with some adult friends:

I’ll come by at 7:30 tomorrow. Can you bring the beer? See you then.

I am delighted that the lower level protocols exist. We will always need them to do what they do now. I just don’t want to be required to oversee someone else’s toddlers.

Interface for Enterprise systems need to be abstract, need to occult details, need to reveal surfaces only. Interfaces for internet-scale systems need to be abstract, support appropriate security, defend their mission, and focus on service rather than procedure.

I don’t hate children. I love playing with my own. I even love, for brief periods, playing with those of others. But when I want to get something done, I want to talk to grown-ups.