Tag Archives: Linked Data

1:1 Interview with Michael Koster


Three-part Interview Series (Part 2)


Series 2 – IoT Toolkit and Roadmap

Tom Vu (TV):  What is in the roadmap for IoT Toolkit?

Michael Koster (MK):

The IoT Toolkit is an Open Source project to develop a set of tools for building multi-protocol Internet of Things Gateways and Service gateways that enable horizontal co-operation between multiple different protocols and cloud services. The project consists of the Smart Object API, gateway service, and related tools.

IoT Smart Object Structure

IoT Smart Object Structure

The foundation of the platform is purely bottom up, based on applying best practices and standards in modern web architecture to the problem of interoperability of IoT data models. I believe that the practice of rough consensus and running code results in better solutions than a top-down standard, once you know the basic architecture of the system you’re building.

To that end, I created a public github and started building the framework of the data model encapsulations and service layer, and mapped out some resourceful access methods via a REST interface. The idea was to make a small server that could run in a gateway or cloud instance so I could start playing with the code and build some demos.

The next step is to start building a community consensus around, and participation in, the data models and the platform. The IoT Toolkit is a platform to connect applications and a mixture of devices using various connected protocols.  It’s real power lies in its broader use, where it can span across all of our connected resources in industry, ranging from commerce, education, transportation, environment, and us. It’s a horizontal platform intended to drive Internet of Things more widely as an eventual de facto standard, built for the people who are interested in building out Internet of Things products and services based on broad interoperability.

IoT Sensor Nets Toolkit

IoT Applications Run on Cloud or On Gateway

We intend to create a Request For Comment (RFC), initiate a formal process for the wider Internet of Things platform and standards.  An community agreed upon process similar to the world wide web that we use today, based on rough consensus and running code, with RFCs serving as working documents and de facto standards that people can obtain reference code, run in their system to test against their needs, and improve and modify if necessary, feeding back into the RFC for community review and possible incorporation of the modifications.

The Internet of Things interoperability platform stands as an ideal candidate, leveraging the power of the open source community’s development process.  In turn, community involvement is taken to a new level, across many fields of discipline, and in many directions. Here is where we can get the most benefit of an agile community.  Crowdsource the development process based on principles of open communication and free of the need for participants to protect interests toward proprietary intellectual property.

We need to build the platform together meshed around the community of Makers, DIY, Designers, Entrepreneurs, Futurist, Hackers, and Architects to enable prototyping in an open ecosystem.  Proliferation then occurs; a diverse background of developers, designers, architects, and entrepreneurs have many avenues of participation. They can create a new landscape of IoT systems and products.

This broad participation extends to industry, academia and the public sector.  We are aiming for broad participation from these folks, build a global platform based on common needs. As a member of the steering committee, when I participated in the IoT World Forum, I heard from the technical leaders of enterprise companies (Cisco and others), research departments, and IoT service providers. They believe an open horizontal platform would be needed to enable applications that span across their existing vertical markets and M2M platforms.

Instead of a top-down approach, where people from corporations and institutions get together in a big meeting and put all their wish lists together to make a standard, we’re taking an overall bottom-up approach, bringing together a diverse community ranging from makers to open source developers, and entrepreneurs. Together with corporations, academia, and public sector, we all will participate in a very broad open source project to develop a platform that can be ubiquitous that everyone can use.

In many ways, this is modeled after the Internet and World Wide Web itself.  As we need to create a more formal standard, it will likely engage with the IETF and W3C. A good example is the semantic sensor network incubator project, which is an SSN ontology that describes everything about sensors and sensing. This enables broad interoperability between different sensor systems and platforms, based on common data models and descriptions. What we want to do is something similar to that, only on a more comprehensive scale and intended for the Internet of Things.

Tom Vu (TV):  Can you take us through a tour of the Data Object model importance and how it yields significance for simple and sophisticated connected devices?

Michael Koster (MK):

The Internet of Things today consists of many different sensor networks and protocols, connected to dedicated cloud services, providing access through smartphone and browser apps. It is rare for these separate “silos” to cooperate or interact with each other.

We abstract the complexity of sensor nets connecting devices and hardware by adding a layer of semantic discovery and linkage. This enables the sensors and actuators on disparate sensor nets to be easily combined to build integrated applications.

The way this works is using a few techniques. First, the different sensor nets are integrated through a common abstraction layer. This works a lot like device drivers in an operating system, adapting different devices and protocols to a common system interface. Only in this case, they are adapted to a common data model.

The common data model for sensor nets is based on the new IETF CoRE application protocol and sensor descriptions. This provides standard ways for common types of sensors to be discovered by their attributes, and standard ways for the data to be linked into applications, by providing descriptions of the JSON or BSON data structure the sensor provides as it’s output.

We use the W3C Linked Data standard to provide web representations of data models for sensor data and other IoT data streams. Linked data representations of IETF CoRE sensor descriptions are web-facing equivalents of CoRE sensor net resources. Linked data provides capabilities beyond what CoRE provides, so we can add functions like graph-based access control, database-like queries, and big data analysis.

Internet Smart Objects

Internet Smart Object

Internet of Things Applications are essentially graph-structured applications. By using Linked data descriptions of JSON structures and the meaning of the data behind the representation, we can create applications that link together data from different disparate sources into single application graphs.

Then we enable the platform with an event-action programming model and distributed software components. The common semantic language enables the data sources and software components to easily be assembled and make data flow connections. The result is an event-driven architecture of self-describing granular scale software objects. The objects represent sensors, actuators, software components, and user interaction endpoints.

FOAT Control Graph

Interent of Things with FOAT Control Graph


Tom Vu (TV):  Who and what companies should be involved?

Michael Koster (MK):

Whoever wants to participate in the building out of the Internet of Things. The people that use the infrastructure should build it out; the people who want to provide products and services based on interoperability, along with those who provide the backplane of thinking low power microcontrollers / microprocessors, connected sensors, and importantly the network infrastructure.

We want to enable all avenues of participation to allow corporations, academia, policy and standards makers, entrepreneurs and platform developers, makers, and DIY hackers all to be involved in building the platform as a community.

For corporations, we will provide an important role, to build a vendor-neutral platform for data sharing and exchange, an open horizontal platform that will allow the integration of what were traditionally vertical markets into new horizontal markets.

Anyone participating or expecting to participate in the emerging Internet of Things, Internet of Everything, Industrial Internet, Connected World, or similar IoT ecosystems initiatives, could benefit by participating in creating this platform. Companies that provide network infrastructure and want to build in value add can adopt this standard platform and provide it as infrastructure. Companies that want to provide new services and new connected devices that can use the IoT Toolkit to easily deploy and connect with existing resources could benefit.

All companies, organizations, and people that can benefit from an open Internet of Things are welcome to participate in the creation of a platform that everyone can use.

Tom Vu (TV):  How important is Open Source to Internet of Things evolution?

Michael Koster (MK):

I don’t see how the Internet of Things can evolve into what everyone expects it to without a large open source component. We need to go back to Conway’s law and look at it from both the system we’re trying to create and the organization that creates it. Interoperability and sharing are key in the system we want to create. It’s only natural that we create an open development organization where we all participate in both the decisions and the work.

Removing the attachment of intellectual property, changes the dynamics of the development team, keeps things engaged and moving forward solving problems. It’s important for software infrastructure projects like this to remove the barrier to cooperation that arises from the self-protection instinct around proprietary Intellectual Property, or even egoism associated with soft intellectual property, “my” code.

Instead, we turn the whole project into a merit-based system as opposed to being ego driven.  Rather than worry about guarding our property, we are motivated to solve the problems and contribute more to the deliverable. The limits to participation are removed and there is a more rapid exposure of intentions and goals. Engagement and innovation can rule in this environment of deep collaboration.

Tim Berners-Lee said that he was able to achieve the creation of the World Wide Web system because he didn’t have to ask permission or worry about violating someone’s copyright. We are creating the same environment for people who want to build our platform, and even for those who want to build their services and applications on top of the platform.

We are going to create the service enabled layer as open source as well so that any one of the companies can help proliferate the idea and everyone has influence and access to the development of the underlying IoT platform.  If it’s open source infrastructure and platform software, you can make a service on top of that software that can contain proprietary code. With our license, you can even customize and extend the platform for your own needs as a separate project.

Tom Vu (TV):  Describe your work with the EU IoT organization and how you are involved as a voice for the Internet of Things?

Michael Koster (MK):

I work with the IoT Architecture group within the overall EU Internet of Things project. The IoT-A group is closely related to the Future Internet project. They have an Architecture Reference Model describing different features one might build in an IoT platform, a sort of Architecture for Architectures. Since their process mirrors my own design process to a large extent, I found their reference model to be compatible with my own architecture modeling process.

They are conducting a Top-Down activity, stewarding the participation in the architecture and standardization model.  One of the ways I work with IoT-A is to use the Smart Object API as a validation case for the Architecture Reference Model. They are building the reference model top down, and we’re building the architecture bottom-up, based on a common expression of architecture relationships and descriptions.

I am also involved in advocating open source of IoT and building of local IoT demonstrator projects, educating around IoT, open data, etc. as well as user controlled resource access and privacy.  I am providing a voice for open source and open standards, into the standards movement going forward.

Here in the USA, there is not anything like what they have in Europe. Here the process will be to engage corporations and institutions and create a participatory structure that enables fair and open opportunity for influence and access to both the development process and the final products.

Tom Vu (TV):  How important is an open standard – building of an RFC in which all industries can agree upon ultimately serving to a wider scale factors of adoption and proliferation?

Michael Koster (MK):

To simply put it, the construction of a formal RFC is something that describes part of system.  A Request for Comments (RFC) is a memorandum published by the Internet Engineering Task Force (IETF) describing methods, behaviors, research, or innovations applicable to the working of the Internet and Internet-connected systems.  It is a process or evolution in achieving a more widely adopted standard.  The founders of the Internet created this process, and http, etc are all built using original RFC process from many years ago.

Through the Internet Engineering Task Force, engineers and computer scientists may publish discourse in the form of an RFC, either for peer review or simply to convey new concepts, information, or (occasionally) engineering humor. The IETF adopts some of the proposals published as RFCs as Internet standards.

If the IoT Toolkit platform becomes adopted, it may eventually be as many as 10-12 different RFCs, but it’s important to get people to agree on common first set.  This is the initial phase into a more pervasively used universal standard.  In fact, it’s sort of like a strawman platform.  It’s intent is to describe and collaborate, but also invoke and seek out broader participation…  We are at the stage of putting proposals together over the next few weeks and setting up meetings to talk to many people around collaboration and participation in building an Internet of Things platform.

We believe that an open standard platform for horizontal interoperability is key to achieving the promise of the Internet of Things. Everyone needs to be able to present and process machine information in machine understandable formats on the IoT, just as we humans enjoy commonly understandable web data formats and standardized browsers on today’s WWW. It’s important that developers be able to focus on solving problems for their clients and not waste resources on communication and translation.

Read Part Three to Learn More about Why IoT (Internet of Things) Matters?

Here are Part 1 and Part 2 of the Interview Series.

1:1 interview with Michael Koster

A candid conversation of Internet of Things
By Tom Vu, Digital Manifesto and Michael Koster, Internet of Things Council Member


Three-part Interview Series


Series 1 – Inspiration and requirements for Internet of Things

Tom Vu (TV):  What inspired you to build the IoT Toolkit and educate the IoT community about data models for the Internet of Things?

Michael Koster (MK):

Michael Koster, System Architect, Open Source Internet of Things, Member of Internet of Things Council

Michael Koster, System Architect, Open Source Internet of Things, Member of Internet of Things Council

A little over a year ago my partner and I started researching the Internet of Things (IoT), with the idea of creating a system as a sort of “valet” to help manage things in our lives. At the time we lived off the grid, and generated our own energy, maintained our own water system, and spent significant time away from home. We looked at what was available, and there was nothing available in ready-to-use systems that would not require at least a layer of programming to work together in the ways we imagined.

Interoperability between multiple devices is quickly becoming a common feature as people try to build their own ‘Internet of Things’—getting all their smart, devices to be connected to the ‘cloud.’ Once they buy the device on Kickstarter, they can easily enjoy the remote control ability and automation afforded for a while. We found a lot of vendors selling devices that connected to services—services such as the Internet.  Some vendors offered open source clients but still tied the devices to their service. We wanted to pull together devices with multiple services, such as combining the home environmental control, energy management, and water, garden, and livestock automation. This requires multiple devices connected together by algorithms, controlling valves, doors, fans, lights, blinds, batteries, etc.  Very often, the vertically integrated devices and services didn’t allow all the devices to be connected because they weren’t built on a standard that was interoperable.

Soon they started to think about ideas on how they could create new relationships and interactions between devices and humans by integrating devices from two or three of these systems together. They quickly found out connecting the systems were quite complex.

This is becoming more common as people try to build their own Internet of Things. Once they buy the device on Kickstarter, they enjoy the remote control ability and automation afforded for a while. Soon they start to think up ideas about how they could create new relationships and interactions between things and between themselves and things by integrating devices from 2 or 3 of these systems together. They quickly find out that it’s not straightforward.

There is a service, IFTTT (IF This Then That) which has software connectors that hook up to the APIs of some popular IoT services and provides a rule engine to apply simple logic predicates to conditions and generate actions, if this, then that. All well and a good proof of the need, but not sufficient for the general use case.

We then decided to investigate the DIY approach, and started from the bottom, through online resources like Sparkfun and Evil Mad Science. We also used components like Arduino, many of which are driven by megaAVR (ATmega) or ARM Cortex-M3, both are AVR and ARM microcontrollers with a strong open hardware, IDE and ecosystem tied to it. We put together a few networkable connected sensors, like a weather station, environmental sensors, ambient LED displays, and power monitoring. We found it relatively easy to connect these to Xively formerly CosmPachube, for monitoring and recording, and quickly discovered a number of limitations to what we wanted to accomplish.

We discovered the same situation with the vertically integrated systems, that there was no open, standard way to connect many different devices together and build a larger application to manage things together. Some Platform-As-A-Service vendors run rules engines, similar to IFTTT, and other application logic inside their platform, but we were looking for a way that enabled us to choose where we wanted to run the software, particularly in both the cloud service and in a local hardware gateway. This allowed more embedded devices and connected sensors to potentially grow into a larger system without a central hub, where IoT is being driven.

This is important because our network connection was often impacted by weather and other variables. We realized that everyone would be impacted to some degree, even with DSL or cable service. Our experience with frequent service interruptions taught us the importance of being able to tolerate interruptions in the network connection. Even if the network connection could be made reliable enough, the services are subject to outages and “latency events”, which make them unsuitable for critical services without backup.

After a few months of inquiry and investigation, we decided a robust, common way of interacting between all devices and things was a requirement. It felt like the early days of the Internet. Before the web, before the invention of hyperlinking, HTML and the http protocol, there were no common ways for people to interact within a document, such as creating hyperlinks.

The Internet of Things is at a similar stage of development. IoT needs a standard to interact with other machines; the standard enabling software for easier interaction is essential.

A platform that provides a base set of common tools and services, similar to an operating system, is also a requirement for IoT users. This platform would enable them to get started quickly with their IoT ideas.

Accessibility and interoperability were key to enable a user to start building smart, connected devices in the era of the Internet of Things.

It became clear that if we could find a standard way to do what everyone expects the Internet of Things to do, and make it as easily accessible and usable as the web is today, that we could help enable the Internet of Things to scale and evolve into what conceivably is the next stage of the internet.

We studied a number of IoT use cases, collaborated with the IoT community, and began to map out what was needed in a common set of tools everyone could use, share, contribute, distribute, and enhance. We wanted to take what already existed in standards, infrastructure, and system components, and build an open source platform that we, and others, could use to create our own end-to-end IoT systems and products.

In the platform, we wanted to provide machine to machine (M2M) connections from sensors and devices, along with application software, and re-use common data models that can easily span across devices and other IoT data streams to build out a common language for descriptions and connections.

We started this process with Social Media, reaching out to like-minded people on LinkedIn. During our investigation, we learned that the issues we discovered weren’t widely known and discussed. Many people there were using no common tools for IoT.

We realized community learning was required to an already steep learning curve on some technologies like RDF and Linked Data. This was one of the reasons we started this IoT blog series to educate people about semantic data modeling and Linked Data driven APIs. Around the same time, we started the Open Source Internet of Things Meet Up in Silicon Valley to meet other like-minded people and build the community.

The founding principle is to create a community around Open Source and Internet of Things.  The gravitating principles follow two successful fundamentals: community and interoperability.  In fact, the very nature of Internet of Things resonates well with Open Source and Conway’s Law. We want to build a system. Create the structure we envision, based on community and sharing.

 

You can also read Part 2  and Part 3 to learn more about Michael and IoT.