Last month’s column about additional functions defined in in OBIX 1.1 led to some good correspondence. In particular, different approaches to semantic tagging were compared, as well as questions about querying an OBIX server.

OBIX 1.1 does not define any query or search functions, just as it does not specify any taxonomies to use as the source for point tags. OBIX 1.1 lets you reference any taxonomy you want. These references are newly defined elements in the OBIX Lobby.

A taxonomy defines a standard language to describe a system. Haystack is an open source taxonomy, sometimes called a folksonomy, used to describe BAS systems and components. COBie is a formal taxonomy defined by the National Building Information Model Standard (NBIMS) that is drawn directly from the language of construction documents.

Other domains, say medical equipment, could use their own taxonomies. Smart Grid users could derive a taxonomy from the IEC TC57 (Power & Load Management) Common Information Model (CIM) or from substation standards (IEC 61850). Theaters could define their own taxonomies for lights and special effects, and so on. None of these taxonomies will be defined or required as part of OBIX. OBIX 1.1 merely describes how to use them.

The Lobby is the starting point for interacting with an OBIX server. If the integrator chooses to use a known taxonomy, then the Lobby can return a URI indicating the source of the taxonomy as well as a shorter tag to identify each time this taxonomy is used. This mechanism is similar to that used in XML Schema Definitions (XSDs) to reference external schemas. A single OBIX point may be associated with tags from more than one taxonomy—the shorter tag reduces the size of the data exchanges.

OBIX 1.1 makes it easy to find taxonomic information about a point. It makes no provision for approaching discovery starting with the taxonomy. In other words, while you can ask if a point is a thermostat, you can’t ask an OBIX server to return a list of all thermostats. The OBIX committee discussed this and chose not to define an OBIX query language.

In the world of sensors and controls, many taxonomies are linked to multi-dimensional features. For example, the world of BIM defines the BIM Query Language (BIMQL). A developer could choose to pair an OBIX server with a BIMQL server, the latter offering a guide to the first. In a similar way, a Haystack server can act as a query engine to discover OBIX points. As both OBIX and the Query Server are merely entry points, both could be on the same physical server, or even in the same application.

[an error occurred while processing this directive]This approach to system specification is called compositional. A system architect can select the standards he wants and compose them into the services provided by a given system. Each specification serves as a LEGO block, and specifications can be easily combined as needed. Not only does this approach simplify each specification, but it rewards the re-use of code.

The committee discussed using LDAP (Lightweight Directory Access Protocol) as a common query approach. LDAP is used most commonly to search for people and resources in organizations. LDAP servers can be quickly re-purposed to work with different directory objects. Directory objects for any taxonomy can be defined quickly. LDAP is frequently used for security, and can itself be highly secure. Multiple open source LDAP implementation already exist, and LDAP is known for high performance most and scalability. Most enterprise security systems already able to interact with LDAP-based systems.

We decided, however, that query standards are too big of a jump for OBIX 1.1. The focus of OBIX 1.1 is to add the most requested features without breaking backward compatibility. The Committee plans to consider possible query approaches as part of OBIX 2.0.

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

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