Smart API

Using Smart API for open data and in the sharing economy

Chapter 1. Why and how should you share data

There are many reasons and ways to open and share data. In addition to the traditional business partnerships, companies nowadays deliberately open their data also to "unknown" parties. Activities range from various long term innovation programs that run for years or even decades to very fast "hackathlons" lasting just over a hectic weekend fueled by pizza and coffeine. Data sharing has moved from extracting direct value from a set partnership to broader topics of creating innovation ecosystems and looking for fresh approaches and ideas.

The same applies to public organizations, who have in many ways been even more advanced in open data than private corporations. Open data is not only a part of the movement towards transparent governance but equally a way for cities and other public bodies to foster local innovation and this way try to create new ideas that might bring back tax money. And talking about tax money, opening the data and "giving it back" to the taxpayers who essentially have financed it, is not such a bad principle either.

Whatever the reason, opening the knowledge and capabilities is an integral part of a modern sharing economy. Not suprisingly, a ton of effort has gone into the design of the Smart API to enable just that. There is a range of features built in into the design and delivered as a part of the free Smart API SDK that help making such sharing happen.

When the sharing features of Smart API were originally designed, we used the following guidelines as the starting point

  • It should be easy. Opening data to the public should not be yet another open data project.
  • It should be visible. All too many projects fail not because of flawed design or tech but simply because no-one knows its out there.
  • It should be granular. Owners of data should be able to say exactly what and exactly when is visible and to whom.
  • It should be real time. The time of "nightly CSV file dumps" should have ended decades ago.
  • It should be possible to also get a payment for data. There should be means for digital rights management especially when something is custom made for a requester.
  • It should be possible to stop sharing data at any point. Nothing lasts forever, there must always be a way to stop and back down.

In the next chapter we'll explain how those principles have been implemented in practice.

Chapter 2. Smart API Sharing

2.1. How does it work

There are essentially four primary components that make sharing possible with Smart API.

  1. The concepts of availability and offer that define how and when data is available
  2. Cryptographic methods that protect the rights to data
  3. Security and access control that make it possible to filter data requests
  4. Service directories and transaction ledgers that help in getting visibility to data and tracking its use

Availabilities and offers are data model concepts that are integral to the Smart API model and therefore also automatically understood by the Smart API SDK. In practice both are standard format messages within Smart API communication. Availability has properties that describe at which time data is available, in which geographical area, under which logical states or conditions, etc. You could consider it as a set of filtering and access control rules specifically tailored for published data. An availability with no filters or rules is fully open i.e. for completely open public data. An availability with full restrictions on the other hand is for fully closed data. Actual implementations may then fall between those two extremes.

An availability may be publicly announced or given out per request. So someone looking for data could search for availabilities in the public Smart API directories (more about that later) or simply contact a peer directly and ask "what do you have for me?"

When someone contacts are service and is properly authenticated, that authenticated party will ask for the data from the service that has it. The service may return it immediately or alternatively respond with an offer. An offer is essentially a digital contract. Just like any contract, the offer must be accepted and signed to be valid. An offer will basically say: "Thank you for requesting data X for period Y. It will cost you Z. Do you accept?" The recipient can then a) accept and sign the offer, b) reject the offer and cut the connection, or c) make a counter-offer, in which case the parties may enter a bid-offer cycle that may or may not come to a conclusion on the acceptable price.

Security methods are used not only to sign and encrypt the data in transfer by also to provide a key ingredient in transactions - non-repudiation. The Smart API ensures that parties cannot get access to data in ways where they could claim data was not received or sent or incorrect data was transferred and this way avoid payment. Smart API Transact is a free service that can be used as a trusted ledger for recording such transactions as a proof and as bookkeeping for invoicing. With Smart API it is also possible to build secure services with strong anonymity protection. This is valuable for instance in use cases where tracking is needed but users are concerned about their privacy.

The Smart API SDK also contains ready-made code for supporting authentication and access control of requests, including standards such as OAuth2. When a data sharing API is created with the SDK, these methods are automatically available. Access control can then be applient to any data or part of data in the system, giving full control over who can read or manipulate any particular part of data.

Availability checking, authentication, signing, transaction processing and data delivery all happen in an automates sequence managed by the Smart API that takes just fractions of a second to complete fully. It can easily be used for real-time transfers of commands and measurement data.

If a system that has Smart API components in it is configured to publish the availability of data, that system can register itself to Smart API Find directory. Smart API Find maintains a map of data management relationships. You can consider it as kind of a "phone book" of Smart API systens. Find knows who is who, what that party can offer, and how to contact that entity. Other systems can then perform searches of that directory to find a specific shared services and equipment that have particular properties and capabilities. Because of the semantic nature of Smart API data, new features can be added on the fly to the data and corresponding searching.

2.2. How to take it into use

Smart API Sharing is a part of the free, open source Smart API SDK. For an existing IT system, the recommended approach is to download the SDK an embed it into the source code of that system.

Smart API SDK has a class called SharingAgent that hides all the nitty gritty details of sharing functionality behind a straightforward interface. In an implementation a programmer would pass the details of their API onto the SharingAgent which will then handle the rest.

For those who are not programmers or do not have access or a need to change the functionality of an existing IT platform, Asema Electronics provides application software that has the sharing functionality embedded in it. Asema IoT Central is an Internet of Things solution that has full Smart API functionality embedded in it.

Asema IoT Central has an easy point-and-click interface for sharing any object managed by the system. Just select from the menus when, where and how an object should be available for others and tap on share. Asema IoT Central also naturally can act as the counterparty of such transactions. It can seek for resources published by other compatible systems and then attach to them. Access is negotiated automatically and the systems open APIs for each other to use.


<bookinfo>Asema Electronics Ltd<copyright><year>2011-2017</year></copyright><legalnotice>

No part of this publication may be reproduced, published, stored in an electronic database, or transmitted, in any form or by any means, electronic, mechanical, recording, or otherwise, for any purpose, without the prior written permission from Asema Electronics Ltd.

Asema E is a registered trademark of Asema Electronics Ltd.