Things cost what they cost to install. Ongoing charges are, in the short term, fixed. Value may be the only thing you can control. In the Internet of Things, value will be determined by how many ways you can use that Thing. Value will be determined by how many different uses can use that thing. Some of those users will be other things.
Things (as in the Internet Of…) tend to be commodities. One thing is inherently like another. Once I have more than a small number of things, I need a way to distinguish between sensors, between pieces of building equipment, and even to distinguish between tangible services such as catering and transport services. One of the first places that all of us have seen things on the internet is in conference rooms, vehicles, and tools as they are scheduled within enterprise scheduling systems.
Discovery is essential to agile integration. If systems can discover each other, we do not need to map them. If systems can understand what they discover, they can integrate themselves. One of the requirements is common semantics, that is agreements as to how something is described (or describes itself). This post is about directory directory services for the internet of things.
In Calendars, people are identified by vCards. VCards are deeply embedded in CalDav, stil the most common protocol for writing new Calendar Apps and user interfaces. Many email systems support attaching your vCard to each outgoing message. VCards are electronic business cards, and just as in traditional business cards, different people choose to include different information on them. Also like paper business cards, various companies and organizations have developed their information and format standards for vCards.
After email, the most common place to find a vCard is in a directory. There is a deep historic link between the Lightweight Directory Access Protocol (LDAP) and the vCard. LDAP is used to manage security as well as directory services in the biggest organizations. The link between directories and security is as natural as is role-based security. LDAP records include have the same variability as does the vCard standard. At some level, though, LDAP is the thing you use to get a vCard.
LDAP supports diversity of information returned, including security on particular aspects of the information. Over time, a varied set of what I will call here, for brevity, vCard profiles have been developed. These often have object-type characteristics. For example, the inetOrgPerson (RFC2798) is defined as a standard set of extensions to the organizationalPerson as defined in the ITU standard X.521. Many colleges and universities have collaborated to define the eduPerson to handle students, grad students, and faculty.
In LDAP, there is a long history returning different information about the same object in different security contexts. At universities, an LDAP will return different information when asked about a student or about staff, even when the target is the same person. Just as in medical information, the portions of student information that can be exposed to query vary widely by querier and context, and are controlled by federal privacy law. There are many security contexts, including when domestic relations go wrong, under which access to some attributes of a particular directory entry is limited. LDAP also supports multi-valued attributes easily. This is in sharp contrast with the normal expectations from, say, a SQL query.
In calendars, things that are not people are designated as Resources. Improvements to Resource vCards is a long-standing project of CalConnect. Some Resources may have a schedule, but not be schedulable. This usually means that it is scheduled by someone else using means you do not have access to, but to the user, it is not schedulable even so. Schedulable Resources may use vAvailability to indicate when and how they can be scheduled. It is of course possible, even probable, that different entities will receive a different vAvailability from the same Resource.
It will come as no surprise to my readers that I now come around to building-based resources. These are most frequently public rooms and building systems. Public rooms are invited to meetings as are other attendees. Smart buildings can optimize energy use while preserving amenity if they know when and by whom the building will be used. In a related post, I will describe how vCards for building-based resources will be standardized.
A key consumer of secure directory services for systems will be other systems. With discovery and directory services, they can find each other to interact. Through developing calendar standards, including vAvailability, they will learn when they can interact.
Secure discovery, self-integration, and autonomous assembly will be part of how we maximize the value of the internet of things.