Which Contact and Event Formats for the UK Government?

Today, Paul Downey and I submitted two "challenge suggestions" to the UK Government's Standards Hub.

Now, we both work at the Cabinet Office, so I guess we have a head start in knowing about all this, as insiders .. but no-one will find the standards we're proposing to be in any way controversial.

We suggested that the UK Government should pick a standard for contact information exchange and calendar event information exchange. I won't bias the process by naming the obvious *ahem*vcard*cough* standards to *ahhh*icalendar*choo* at least give due consideration to, for these needs.

In true UK Government style (or the style of any Government I imagine), this process is done politely and at a slowww pace. Several packets of tea are consumed from the start to the end of the process.

To evidence this, there are already two accepted standards: paraphrasable as "Use UTF-8!" and "Use URLs!".

Baby steps, baby steps.

It's a long way to go from this to the Object Network contact and event formats, but once we've got something in the Standards Hub for contact and event, the next one to try for is: "A textual structured data encoding format with maps and lists, that is useful for moving data into and out of APIs".

That way we can then go on to suggest such an encoding of all the data available from our Government, which could include those contact and event types.

Not sure if we'd have to get HTTP - sorry, a hypermedia/data transfer protocol - in first, though.

Anyway, I've got plenty of time...

Bidirectional CoAP

I mentioned before that CoAP would seem to be a good protocol to implement FOREST over, as most implementations implement the observe spec.

CoAP is based on HTTP, thus inherits its asymmetric client-server model. However, it is also built over UDP, which is another loosening up of HTTP in CoAP that can help implement FOREST. FOREST's basic mode of interaction is peer-to-peer, with clients able to be servers and vice-versa.

So if I use CoAP, I'll have UDP packets for requests going in both directions between peers, and UDP packets for responses also going back in each direction. Even though CoAP isn't specified to be bidirectional, I could easily implement a bidirectional version of it once I have a unidirectional implementation.

If the code is all in NetMash, which is used on both clients and servers, then the bottom of the CoAP stack will be simply sending and receiving UDP packets: there's no separate TCP connection in each direction. You could have a single UDP port number at each end.

If you need to keep receiving updates to your cache of a response to an earlier request (which it seems is a feature being added to HTTP/2), then you're already getting towards a bidirectional protocol, since a spontaneous packet can now come back at the client instead of it always being the initiator.

I played with such a bidirectional protocol of my own for an earlier version of the Object Net, back in 2005, but then switched to using just dual HTTP channels and long-polling to cover asymmetric infrastructure. It's nice to be able to re-visit the concept with the IoT and CoAP.

What is The Object Network again?

I've been working on this project without really stopping to give an overview of all the elements of the Object Network. You can work it out from the articles and links, but here's everything summarised in one place.


Functional Observer

This is the basic programming and interaction model underlying everything. In a nutshell:

An object’s state is set as a Function of its current state plus the state of other objects it Observes through links. 

So imagine an object representing a light that is shining yellow. It links to another object representing the values of a dimmer. The brightness of the light depends on the value of the dimmer, so as the dimmer value observed by the light reduces, the light calculates a new RGB setting based on whatever colour it's set to, modulated by the dimmer value it can see through the link.

In the style of a spreadsheet, whenever the current light colour on the light, or the current value on the remote dimmer changes, it has work to do to set its current output in the RGB values.

I mentioned Functional Observer here and here.


FOREST

Functional Observer REST simply allows our objects to reside on different host machines. They talk RESTfully over HTTP in JSON. They have URLs and exchange state using GET and POST.

I mentioned FOREST here and here.


Cyrus

In order to know what state to set itself - what dependencies it has on peer objects and its current state - an object needs to be programmed or "animated". It could be programmed in Java - and that's exactly what I do for some functionality in NetMash.

But we can create a language that is a direct mapping onto the Functional Observer model above. The "Function" part can be pure: you don't need I/O or side-effects when all of that is taken care of in the objects you're rewriting.

Cyrus is a pure Functional Observer language. Being homoiconic, it is based on the JSON of the objects it is animating, but with much noisy syntax removed. Cyrus rules have their own URLs, of course.

I mentioned Cyrus here, here and here.


Object Network Types

These distributed, interacting objects can form a global Object Network or graph. But only if they all look pretty much the same.

So the Object Network defines a number of simple and stable formats within JSON for common needs, such as contacts, events, feeds, articles, media, GUI layouts, users, 3D objects, IoT Things, Cyrus rules, etc.

These types can also be represented in the cleaner Cyrus syntax.

I mentioned Object Network Types here and here.


NetMash

All of this is implemented in the NetMash Java code. NetMash is an Android app and a Java server. They share the same Object Network core code, including the implementation of the Cyrus language.

This whole blog is full of screenshots of NetMash in action.

Internet of Things and Augmented Reality in Retail

Today I received my latest copy of the Thoughtworks Perspectives mailing. This month's issue was a special on Retail. Our European Head of Retail, Mark Collin, has been interviewed on the "Essential Retail" site about the latest trends.

That's where I discovered a new term: "Phygital", which of course means the merging of physical and digital. Cute. "Internet of Things" seems quite a mouthful in comparison.

.. it will become a necessary reality that retailers have to find ways to subtly and seamlessly incorporate digital into a store experience and not just for technology sake or as a gimmick but to tackle core retailing issues like real time inventory, faster checkout, everything in my pocket (mobile – payment, loyalty, receipts, rewards, etc). The behind the scenes analytics opportunities are the significant side benefit to a customer experience premised on digital. 

- Mark Collin

Here's another, related article on the Thoughtworks website: Will iBeacon Further Enable the Passion of Shopping? And another from a Thoughtworker's own blog: Introduction to iBeacons by Andrew McWilliams.

Retail: The Thoughtworks Application of IoT/AR

So this got me thinking, that soon enough I'm going to want to explain how my 60 Days of Things, that I'm coming to the end of pretty soon, will benefit Thoughtworks.

And the obvious applications are all in retail, in interacting with customers within some environment, such as shops, malls, airports, stations, libraries, museums, theme parks, cinemas, sports centres, swimming pools, holiday camps, and so-on.


IoT/AR in Retail

Now currently, all the demos we have been doing inside TW and the typical example ideas that people have been coming up with in general in this area are about "IoT plus 2D smartphone app" interactions.

I can't see anyone else that has spotted the potential of combining "IoT plus Augmented Reality".

Tomi Ahonen, a mobile industry analyst who's predictions are extremely reliable, believes that Augmented Reality is the next big wave after mobile.

Just sayin'...

FOREST: a higher-level RESTful interaction model

I was having a good chat with my buddy Jim Barritt today, and the subject came up of how one could describe the difference between my FOREST approach to REST and the widely-used, traditional AtomPub style.


AtomPub

Quick summary of the AtomPub style: you have a client and a server where the server is a lot like a database of articles and HTTP is used by the client to edit those articles.

So the editor client says "POST" and a new article is created. It says "PUT" and the article is updated. "DELETE" is pretty obvious. The client, and indeed the world, can "GET" to read an article.

The client basically runs things and the server more-or-less does what it's told, modulo whatever it needs to do to ensure security and integrity. There are other bits like Media Types and Link Relations, but that's basically the model.


Almost Database Integration

When people want to "do REST", if they think they want to do it "properly", chances are they'll use this approach as their paradigm. I was slightly involved in the creation of the AtomPub spec, so I'm not knocking it, at least for this use case - editing articles.

Trouble is, it only makes sense if your application is a lot like a database, where you have some data that you want to create, update, delete or read. So, in order to do what they believe to be "proper REST", people end up forcing their inter-server interaction protocols into this simple, low-level, data read-write model.

And that feels uncomfortably close to a database integration style!


FOREST

In contrast, in the FOREST style, two application servers talk to each other at a higher level, as peers - they can be both client and server to one another.  A peer can GET the data of another - pull or poll - and can POST its own data to another - push.

It's a simple, symmetric model of interaction where the application protocol is like a two-way conversation. Being RESTful, all such data can be found at their URLs - this isn't just a substitute for messaging. PUT and DELETE aren't used at all, because the interaction model isn't about just low-level editing of data.

I'll be illustrating FOREST with an example on this blog, to show how such a conversation between peers can proceed. You'll see how it enables interactions that are at a higher, domain level.

Beacons that Move

Up to now, I've been talking about BLE beacons attached at fixed points around the house, office, shop, park, etc. The moving bit is you; or rather your Android device, that picks up the URLs and the signal strengths and drives a 3D AR app that maps out your surroundings.

Beyond that mode, I did mention that a fixed beacon could also scan around it - when first installed - to find out what place it was in and whereabouts it sat.

So the other two combinations left involve the Android device itself broadcasting, either to the fixed beacons or to other Android phones. Unfortunately, Android can't yet broadcast as a beacon through BLE - see this issue here and vote on it by starring. Android needs "Peripheral Mode" support, which iPhones do already have.

Once your phone can also act as a beacon, it can broadcast the URL of your person or avatar object.

The first benefit of this would be more accurate location - the surrounding Things would know how far you are from them and could collaborate on trilaterating your position, which you could combine with your own trilateration of their positions for more accurate results.


Publishing You

If your device were broadcasting, it could be used to notify surrounding people and machines of your presence, identity and other parameters and links you want to make public, through a packet of JSON fetched through the advertised URL.

This would allow various applications such as: automatically paying for a service by walking through a gate, exchanging behavioural tracking for store discounts and a conference birds-of-a-feather locator. You could even advertise that it's your birthday, or that you like rock climbing, your blog URL or your relationship interests. A more private view could show your health to your doctor.

You don't actually need BLE to do something like this: when you have WiFi switched on, your device gives away its unique MAC address while scanning for networks. Now you just need to map from that to your personal URL, which could be done through a MAC-to-URL lookup service a bit like DNS.


Beacons that Move

While waiting for Android to get peripheral mode and enable this huge range of applications, there are other examples of physical objects that can move and can be tagged with a beacon.

The TI SensorTag, the Ninja tag, the Chipolo, the Light Blue Cortado - all allow BLE tracking of the location of things they're attached to, or of values of their sensors, such as accelerometers.

Like you, your car can have its own URL, allowing similar applications such as automatic payment of tolls, fuel and parking fees, detection of presence for tracking in the home or the street, perhaps again in exchange for information or discounts. A more private view could show you the health of the car and allow you to set certain parameters and rules of operation.

Android better fix that peripheral mode if its Open Auto Alliance is to beat iOS, though..

Finally, robots can have "beacons that move", allowing all the above functionality plus a whole lot more, around collaboration and coordination of their joint activities.

Venice Holiday Snaps.. Not Today

I was hoping to show you some holiday snaps from Venice today, but I can't upload from my phone into the Blogger editor.

So here's my Twitter link, anyway, which has some photos: https://twitter.com/duncan__cragg