Ontology

Decomposing Services

I had a very nice conversation with Bob Smith of Tall Trees yesterday about building services. Bob is one of my co-conspirators launching the Building Service Performance ONTOLOG group. Bob had just submitted the laundry list of check-offs developed by the City of Irvine for its construction process to the ONTOLOG discussion.

I was both happy and disturbed to receive this document. These check-offs clearly drive the contracting process, They are also inherently backward looking, enshrining the best practices of yesterday as we move forward. The best practices of yesterday are better than the normal practices of today, but can be the enemy of better practices going forward. They trade innovation for good enough.

The ONTOLOG (just google it) project is to define an ontology of Building Service Performance. The problem we are trying to resolve is that while people want specific services from their buildings, we always specify technologies or systems, which is something quite different. Buildings may be providing alert students, productive office workers, or regulated environments to store labile chemicals. By discussing the services rather than the systems, we can

  • Allow earlier discussion of / decisions on building goals in keeping with buildingSmart approaches
  • Move conversations about building performance to the business level where commercial building owners will get interested (we want to provide healthy office space metrics in the upper quartile while staying within energy use goals).
  • Commissioning then gets re-defined in terms of service performance effectiveness rather than in terms of system operations, a much more useful measurement.
  • Commissioning numbers that look like B are simple enough to get built in to the sales and leasing processes for commercial buildings, enabling owners to monetize improved performance.

Check off lists such as Bob provided are the opposite of this approach. Nonetheless, I agreed to try to dig up two other documents that are contrary to the goals and thinking of the new group.

One such document is the original list of nearly 50 vertical control system markets that we came up with as oBIX was launching. These systems are specified in buildings now, but only rarely with any sort performance or business deliverable tied to them.

The other document I am trying to come up with is a comprehensive list of ICC (International Codes Council) domains. It struck us during conversation that many of the ICC areas deal with avoiding the failure to perform these services. While we are trying to twist these services around into a new ontology, a list of all the services which must not fail to be provided would be useful.

I have found neither list yet. If you think you have one, please send it along.

The Ontology *is* the Business

Admit it. Lots of you recoil a little bit when I wander off into discussions of ontology. It sounds so academic, so far from the practical. Maybe someone down in the trenches has to think about ontology, but surely it is not a business interest.

This is exactly wrong. Ontology is discovering the meaning in facts. Ontology is what gets discussed in the executive suite. Ontology is what is going to turn the meaningless details of building systems into new services, new money machines. Ontology is what turns process into service.

By example, consider accounting. At the low end there are clerks and bookkeepers. Their concerns are in properly classifying each event. Assign a name to each number, and make sure they balance. The math is trivial; the problems of introductory accounting are semantic problems of classification. Bookkeeping is never strategic. We use it to keep score. No one wants to be told what to do by the bean counters.

Bookkeeping turns into accounting when it begins to be used for making decisions. There can be several ways to do cost accounting to understand the problems of manufacture or of construction.. Financial ratios normalizes the books so you can compare the prospects of different businesses. The focus of accounting move from what ledger to put each item on to how do I understand the business.

Accounting grows from bookkeeping when we need ontologies created from the underlying semantics. (Well, or when we need a compliance framework, but I feel that is actually similar.) ERP establishes a common ontological framework for all the activities of an enterprise. The primary purpose of today’s sophisticated business software is ultimately ontological processing of the underlying process oriented semantic information.

This observation is allied with the truism that it is very difficult to apply a service oriented architecture to a procedure oriented enterprise, while it is straightforward to do so to a service oriented enterprise. Colleges and Universities often represent the quintessential procedure oriented enterprise, with little regard for outcomes and a slavish devotion to their pieces of paper and the processes they represent. You may remember how easy they are to work with.

Building systems are, for the most point, struggling upward to get to semantics. We know how to describe the low level actions. oBIX has provided a base syntax for semantic expansion, but does not yet provide all the nouns. Progress has been made. Yet even if we get fully fleshed out semantics for building systems, we will still not be at the right level for enterprise interaction.

Enterprise programmers cannot have a fruitful conversation with the inner processes of the building systems, no matter how semantically complete. As I believe these processes will more and more be self tuning and self managing, neither will anyone else except during configuration.

Large-scale integration and wide-scale integration, in which many systems are integrated and each system agent responds to many other actors, will require to conversations of two sorts. Enterprise programmers need to be able to specify the service they desire, and the price they are willing to pay for it. Building systems need to accept the terms, and be able to provide quality of service (QOS) or conformance information back.

And for that, we need an ontology of building service performance.

Ontology of Building Service Performance

The first assigned duty of man in each of the great creation myths is the Naming of Things. The formal name for this task is semantics. Procedural programmers usually stop there. To interact with multiple procedures, to move into services, one must decide how to group things. Often a single semantic object will belong in several groups. These groups are in turn, members of still others. In everyday life, we call these groups meaning; when we discuss these groups formally, we call them Ontologies.

Ontolog is an open, international, virtual community of practice on ontology, ontological engineering and semantic technology. I have been meaning to write on these concepts for a while, but will not do so today. Instead I am sharing with you excerpts from the correspondence leading to the founding of a new Ontolog project this last week. I hope to post soon on the importance of this project.


Toby Considine

I have multiple potential participants in a project on defining the surfaces between control systems and the outside world. The goal is to define informational interoperability different domains with quite different needs. Traditional integrations have been process oriented and therefore difficult and requiring deep domain knowledge.

The surfaces that come to mind quickly are:

  • Building Systems – Design Intents (NBIMS)
  • Building Systems – Energy Models (NBIMS)
  • Building Systems – Enterprise Operations
  • Building Systems – Power Grid (Demand – Response)
  • Building Systems – Building Systems (decomposition of over-integrated systems)
  • Building Systems – Building Informatics
  • Building Systems – Remote analytics & Maintenance Management systems

Each of these implies one or several IDMs, to fit into one or several ontological frameworks…

Bob Smith:

Basically, the idea is to use a SOA to connect connecting service providers with service consumers (initially two domains: Health Informatics and Emergency Response Systems). A key standard in both of these two pilot test domains is the EDXL family of standards.

Deborah MacPherson

Do you know of similar problems, or better know of any solutions, getting the physical space and semantic space to stay connected. NBIMS is lucky because our artifacts, buildings, actually can only have one at time in the same place or time.

Deborah MacPherson

Sounds interesting. Personally, would also like to consider keeping track of material performance over long periods of time. For example owners being able to monitor warranty time periods for all their facilities, manufacturers being able to evaluate life expectancy of their products in various applications and climates. The building informatics, hopefully working towards reduce, reuse, recycle.

Toby Considine

I have just been on the phone with Bob and Deborah, in series. I was trying to align the Deborah's Building Purpose Classification with my own interest in defining a Building Service Provisioning Framework. After some arm-wrestling, Deborah and I have come up with:

BuildingServicePerformance - an Ontolog project to formalize how we describe the Purpose(s) of a Facility and the associated services expected from the building systems. We hope to include the beginning of a compliance framework as well, that is, how to understand if the service is being provided in accord with required performance metrics.

We clearly do not intend to write the metrics, but we believe the framework will allow others to formalize the metrics require for different scenarios pretty quickly.

A measure of success would be that the framework can be used to generate IDMs to at last create information bridges between building systems and buildingSmart, although that is not the only use we see.

Bob wants us to begin fleshing out the wiki to define this part of the project soon.

Deborah MacPherson

Yes - services expected from the building systems which can be "building things" like HVAC systems, a restaurant, brick and mortar cavity walls and larger performance requirements that are bigger than the building like " a tornado is coming and there are x number of people here perhaps some back and forth about how sturdy various structures can be expected to be.

Two sides of a coin where one side is the program and spatial proportions of the building "Hotel, 250 rooms, 8 stories, OCCS class etc" - which is nicely aligned to BIMstorm and OPS. To BIMStorm is to develop a project and get these spaces to work, Owners, Designers, City Planners can all play with and create the same spaces. Analysis can be performed on the results for any number of reasons - cost, geospatial and so on.

The other side is physical performance - for example a necessary performance requirement of the hotel class is to achieve an acoustical goal between rooms, to get there x, y, z gypsum board and a certain type of insulation are used. All the materials have classes which can be mapped into other classes and, what I'm trying to do, eventually map into the spatial programming world of BIMstorm and similar.

There is now a bridge between idea requirements and physical requirements. That same bridge may be able to be extended and reused for other purposes that need the physical world and semantic world to stay connected under certain conditions.

Rex Brooks

BSP is fine with me, but it misses the one part of Toby's original post that resonated especially well with me, which was the notion of helping standardize practices in the interface between building control systems and the outer environment. In the exchanges since, another particularly relevant concept surfaced, improving/maintaining the alignment/awareness/contact between semantic space and physical space. However, I think both of these fit within the rubric of BSP, but we might want to elaborate a bit on these and other aspects/factors that we want to capture and work with.

That said, I also think that we have more than enough to get us started.


The team will need to develop its charter at its upcoming initial organizing meeting.

It should be an interesting project. Come on by if you want to participate.

ONTOLOG - collaborative work environment

Getting from Registers to Ontologies

Control programming today is like writing device drivers. Internal to a computer, low level programming is about moving data in and out of internal registers. Control system programming is, for the most part, reading and setting remote points. oBIX 1.0, first and foremost, provides point services for setting, reading, and tracking remote control systems. By defining a web-services based pattern for accessing the point service, control systems have been made accessible to enterprise systems and to enterprise programmers. Point services are not, however, enterprise friendly.

In almost all creation myths, the first task of man is the naming of things. We call formal rules for naming of things “semantics”. The next task for oBIX is to move to formal semantics of embedded systems. There are three approaches we could follow for semantics: tagging, system, and service.

Tagging is the most traditional naming for control systems. Tags are merely the naming of each point. Tags may appear on the initial schematic diagram of the control system. There may be some sort of internal logic to tagging. CWCRT007 may be the Chilled Water Coil Return Temperature #7. I might just as easily use the tag CWC007RT for the Chilled Water Coil 7 return temperature. The control system integrator assigns tags within control systems. If I am lucky, the integrator working on the third floor will use a naming convention compatible with that used by the man working on the sixth floor. If I am an advanced owner, I might have specified the standard to be used pre-construction. Tag standards such as these do little to help the enterprise work with multiple buildings.

System based semantics will name things by the system they are part of. This approach aligns well with the data life cycle defined by NBIMS (National Building Information Model Standard), especially if the contractor uses COBIE (Common Operation Building Information Exchange) to hand over NBIIMS information to maintenance and operations. Each system gets the same name it had on the initial design documents. One problem with this approach is that most design documents have significant errors and duplication in the controls portions. These names, while useful to those performing maintenance on the building, they often have little to do with how the tenants see the building, and thus may be difficult for enterprise programmers to use.

Service-based semantics name systems for what they do, not what they are made of. Service-based semantics may be mapped to the spaces they support, i.e., “Heating and Cooling for Big Conference Room”. This makes it easy to link business processes with building processes; we can easily imagine inviting the heating and cooling system to the big meeting. It may require additional maintenance, as the C-level executive’s office, however critical, may move from one room to another.

Ontologies are the next step above semantics. Ontologies are the classifications that semantics fit into. A computer-based ontology would enable a computer to fit a system into one or several hierarchies of meaning. To illustrate, consider a room in which a cat is playing. I ask the computer, “Are there any animals present?” Using semantics, a cat is not an animal, and the answer is “No”. Using an ontology, the system considers that a Cat is a type of Pet and a type of Mammal. A Mammal is recognized as a type of Animal. Now the computer can answer, correctly, yes.

Today, we talk of the interactive web, and call it Web 2.0. Web 2.0 is interactive and responsive in ways that the initial internet was not. Small point services add increased functionality such as the type-ahead and spell-check functions in Gmail. Current discussions of the future of the internet imagine systems being able to negotiate with multiple remote web sites to increase function and responsiveness. These functions may include discovering new remote service on the fly to respond to user or system requests. These new functions will require that systems be able to recognize and understand the services provided by remote systems. The basis of Web 3.0 will be the formal ontological classification of web services.

Service-based semantics provide a better basis for ontologies than do system-based or tag based semantics. A single system may provide more than one service. Each service may be linked to multiple chains of ontology, just as the cat above is linked to both the “Pet” and the “Mammal” ontological hierarchies. A single service may be linked to both an external standards-based ontology and an internal organization-based ontology.

All of this sounds at first hearing as a bit of a stretch, but in the near time, it will become the basis of what we expect from all system integrations. Interested readers may wish to check out Ontolog ( http://ontolog.cim3.net/ ), a Web 2.0 home for those exploring how to find meaning (ontology) in engineered systems.