FEED Validator

for Atom and RSS and KML

Congratulations!

This is a valid Atom 1.0 feed.

Recommendations

This feed is valid, but interoperability with the widest range of feed readers could be improved by implementing the following recommendations.

Feeds should not be served with the "text/html" media type [help]

Source: http://duncan-cragg.org/blog/atom/

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<?xml-stylesheet href="http://duncan-cragg.org/css/atom.css" type="text/css" ?>

<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en-gb">
<id>http://duncan-cragg.org/blog/</id>
<title>What Not How</title>
<subtitle>Duncan Cragg on Declarative Architectures</subtitle>
<author><name>Duncan Cragg</name></author>
<logo>/favicon.gif</logo>
<icon>/favicon.ico</icon>
<rights>All content including photos and images by Duncan Cragg. Copyright (c) Duncan Cragg, your rights preserved: see /CXL.html</rights>
<generator uri="http://www.djangoproject.com">A Django Production.</generator>
<link rel="alternate" type="text/html" href="http://duncan-cragg.org/blog/" title="What Not How" />
<link rel="self" type="application/atom+xml" href="http://duncan-cragg.org/blog/atom/" />
<updated>2015-02-10T15:58:00Z</updated>
<entry>
<id>http://duncan-cragg.org/blog/post/eup-iot-ar-minecraft-netmash/</id>
<title>EUP, IoT, AR and Minecraft | NetMash | Object Network</title>
<published>2015-02-10T15:58:00Z</published>
<updated>2015-02-10T15:58:00Z</updated>
<link rel="alternate" type="text/html" href="http://duncan-cragg.org/blog/post/eup-iot-ar-minecraft-netmash/" title="EUP, IoT, AR and Minecraft | NetMash | Object Network" />
<category term="declarative" />
<category term="rest" />
<category term="json" />
<category term="forest" />
<category term="netmash" />
<category term="cyrus" />
<category term="object-network" />
<category term="IoT" />
<category term="eup" />
<category term="AR" />
<category term="minecraft" />
<summary type="xhtml">
<div xmlns="http://www.w3.org/1999/xhtml">

These days I seem to mainly use this blog for once-a-year announcements of what I'm up to, which is useful as record for myself when I need to reflect.

So here's where I'm at, as 2015 begins..
  ...

</div>
</summary>
<content type="xhtml" xml:space="preserve">
<div xmlns="http://www.w3.org/1999/xhtml">

<div class="summary">
These days I seem to mainly use this blog for once-a-year announcements of what I'm up to, which is useful as record for myself when I need to reflect.

So here's where I'm at, as 2015 begins..
</div>
Some time ago, in summer 2012, I <a href="http://duncan-cragg.org/blog/post/empowering-the-world/">announced</a> that I was focusing on end-user programming of virtual worlds in Android.

I called the language <a href="http://duncan-cragg.org/blog/post/cyrus-2013/">Cyrus</a> at the start of 2013 and swore I'd stick to it. Well, that was obviously a dumb choice, since <a href="https://www.google.com/search?q=Miley+Cyrus+MTV+2013">she got in the news that August</a>, doing all kinds of embarrassing things.

I spent the second half of 2013 playing with Minecraft modding in Cyrus, followed by a <a href="http://duncan-cragg.org/blog/post/building-object-network/">year-long</a> exploration through 2014 of using <a href="http://duncan-cragg.org/blog/post/object-network-approach-augmented-reality-and-inte/">Augmented Reality</a> to interact with the <a href="http://duncan-cragg.org/blog/post/web-things-watching-things/">Internet of Things</a>.

Core Goal

So now I'm back to that core goal: end-user programming of virtual worlds in Android, but now with a splash of Minecraft, a sprinkling of Augmented Reality and a pinch of the Internet of Things.

Of course, any virtual world today feels like it came from the last century if it refuses to acknowledge the tactile accessibility that was discovered by Notch in his world-sweeping game.

Android is an ideal platform for all this, because it is clearly AR-native, plus it can be used as a Thing - especially with sensor-packed, Bluetooth-enabled Android tablets and phones becoming such a cheap commodity.

I want to make the language more accessible to normal people by bumping up the number of dimensions used to access it: from my one-dimensional text format (which I still think is pretty clean and nice to read) to a two-dimensional graphical or visual interface.

Names

So, while I wait to see if "Cyrus" is actually viable in the longer term to name the language, this year's names are back to the <a href="http://Object.Network">Object Network</a> and <a href="http://NetMash.net">NetMash</a>. I'm also still using "FOREST" and "Functional Observer" to describe the architectural style and programming model, respectively, if anyone asks.

But since I'm focusing my energies on end users not technical folk, I'm not expecting anyone to ask..

</div>
</content>
</entry>
<entry>
<id>http://duncan-cragg.org/blog/post/web-things-watching-things/</id>
<title>CoAP and a Web of Things watching Things</title>
<published>2014-05-19T21:21:00Z</published>
<updated>2014-05-19T21:21:00Z</updated>
<link rel="alternate" type="text/html" href="http://duncan-cragg.org/blog/post/web-things-watching-things/" title="CoAP and a Web of Things watching Things" />
<category term="architecture" />
<category term="p2p" />
<category term="forest" />
<category term="cyrus" />
<category term="object-network" />
<category term="IoT" />
<summary type="xhtml">
<div xmlns="http://www.w3.org/1999/xhtml">

With the expansion of the Internet of Things (IoT), and the diversity of products and
technologies, the one thing that everyone agrees on is that it's time to start agreeing:
the Internet of Things needs standards. Many agree that it needs open standards, like
those that underpin the Web.

Obviously, a Web of Things is going to be quite different from the Web of Documents and
Applications: it'll be much more fine-grained and much more "buzzy", with many sensors
and actuators working together with many hubs and services. It's more likely to be at
home with the next generation of the Internet Protocol: IPv6.

To meet the fine-grained and buzzy nature of the IoT, the
<a href="https://datatracker.ietf.org/doc/draft-ietf-core-coap/?include_text=1">Constrained Application Protocol, or CoAP,</a>
was created. CoAP is an open Internet standard for the Web of Things. It's based
on the Web's core pipe: HTTP, but has many differences to allow it to be used by very
resource-constrained devices and local radio networks.

CoAP can be used in many different ways, but there's a danger that a lack of clarity in
exactly how it's used means it doesn't achieve its full potential to link up the world's
embedded devices.

This article proposes a simple and clear way that CoAP could be used to build a uniform,
global, decentralised Web of interacting and discoverable Things.

This <a href="http://www.thoughtworks.com/insights/blog/coap-and-web-things-watching-things">article first appeared</a> on the ThoughtWorks Insights pages.
  ...

</div>
</summary>
<content type="xhtml" xml:space="preserve">
<div xmlns="http://www.w3.org/1999/xhtml">

<div class="summary">
With the expansion of the Internet of Things (IoT), and the diversity of products and
technologies, the one thing that everyone agrees on is that it's time to start agreeing:
the Internet of Things needs standards. Many agree that it needs open standards, like
those that underpin the Web.

Obviously, a Web of Things is going to be quite different from the Web of Documents and
Applications: it'll be much more fine-grained and much more "buzzy", with many sensors
and actuators working together with many hubs and services. It's more likely to be at
home with the next generation of the Internet Protocol: IPv6.

To meet the fine-grained and buzzy nature of the IoT, the
<a href="https://datatracker.ietf.org/doc/draft-ietf-core-coap/?include_text=1">Constrained Application Protocol, or CoAP,</a>
was created. CoAP is an open Internet standard for the Web of Things. It's based
on the Web's core pipe: HTTP, but has many differences to allow it to be used by very
resource-constrained devices and local radio networks.

CoAP can be used in many different ways, but there's a danger that a lack of clarity in
exactly how it's used means it doesn't achieve its full potential to link up the world's
embedded devices.

This article proposes a simple and clear way that CoAP could be used to build a uniform,
global, decentralised Web of interacting and discoverable Things.

This <a href="http://www.thoughtworks.com/insights/blog/coap-and-web-things-watching-things">article first appeared</a> on the ThoughtWorks Insights pages.
</div>
CoAP's Interaction Model

In simple terms, CoAP says you should send an Internet packet (UDP) to request a device's
data - a GET on a device URL - and then expect back a packet with that data, perhaps a
sensor value. You can also push a packet of data to a device - a POST to its URL.

An <a href="https://datatracker.ietf.org/doc/draft-ietf-core-observe/?include_text=1">extension to CoAP for observation</a>
allows you to keep on receiving back data packets following a GET as the device state at
its URL changes.
 
Ways of Interacting and Programming

This simple protocol is actually quite unique in the IoT world. Most IoT approaches work
through events and messages - sensors and actuators may be connected to an event stream
or message bus. The model used to program Things reflects this: events and messages tend
to lead to actions and commands, and thence to central control, either in a central
server in the house or a service in the cloud. Central control tends towards silos and
proprietary formats and application protocols.

CoAP's Web-based model of devices with their own URLs is quite different. The Web that
CoAP belongs to works through decentralisation - empowering everyone to publish and link
up to anyone else. These links encourage everyone to use the same formats for their
data, leading to re-use and "mashability". The lack of centralisation and greater
interoperability leads to greater freedom to quickly innovate and build on top of each
other's data.

But since the event/action or message/command model is so familiar in the IoT world,
many people will inevitably try to use CoAP in this way, and miss out on all the
benefits that have been proven by the unprecedented scale of the Web.

And even if they do embrace the CoAP and Web model, there's still sufficient flexibility
in there to allow various groups of people to go their own way and lose many of the
benefits. For example, people still don't have to use links between their worlds and
don't have to share the same formats. They don't have to use POST in exactly the
same way to achieve dynamic interaction with devices. The way Web APIs have gone - to
create <a href="http://www.infoq.com/news/2012/02/the-object-network/">thousands of isolated silos</a> -
is strong evidence of this risk.
 
Peer-to-Peer Programming of Things

So what way should everyone use CoAP? Well, like I said, people should at least link
up in a Web and use the same formats for lights and dimmers and locks and temperature.
And use the definition of those formats to guide the POST-side interaction models.

However, unlike the Web of large-scale documents and applications, of browsers and
webservers and client-server asymmetry, the Internet of Things is an Internet of
sensors and actuators and hubs; interacting devices which work as symmetric peers in
a, potentially IPv6, mesh.

This symmetry and peer-to-peer interaction are embraced in the CoAP model and can lead
to an interesting, simple and powerful approach to the Internet of Things, and to the
evolution of the Web itself. There's an opportunity here to go one step further than the
Web, through a simple and powerful programming model based on peer observation.
 
The Light Depends On The Light Level Sensor

For example, consider possibly the simplest IoT interaction imaginable: a light that
reacts to a sensor measuring the ambient light level and colour temperature, by
adjusting its brightness and colour accordingly, either to match or to compensate.

There are two peers - and we don't need a central controller. The light depends on the
sensor. They both have URLs, so the light can link to the sensor. We are using CoAP,
so the light can observe the sensor itself:

<a href="http://duncan-cragg.org/pictures/The_Light_Depends_on_the_Light_Sensor.png"><img class="photo post resizeable" src="http://duncan-cragg.org/pictures/The_Light_Depends_on_the_Light_Sensor.png" alt="picture" width="300" /></a>

The light depends on the light level sensor. That's the simple, powerful interaction and
programming model that CoAP allows us to use - if we allow Things themselves to be the
observing client. The state of a Thing depends on the states of the other Things that it
links to. You can also have other abstract, non-real Things interacting in the peer
mesh, which we can still call Objects.

I won't go into detail here about exactly how CoAP would be used to achieve this: the
URLs and payload formats and the use of GET, observe and POST that enables Things to be
client observers. I'll document that elsewhere, but it'll be based on my
<a href="http://forest-roa.org">FOREST</a> architectural style and the <a href="http://object.network">Object Network</a>.
 
Things Watching Things

The Internet of Things can be a mashable Web of Things. If we're going to use CoAP to
build that fine-grained, "buzzy", decentralised Web, then we should use it like the Web:
we should agree on the formats for device data, and link up all of our Things and
non-Thing Object data via their URLs. The common formats should also define how POST is
to be used. That's the basic requirement.

We can then take a bold step further by exploiting CoAP's observation mechanism, to
build a symmetric peer mesh of Things and Objects that link to, watch and depend on each
others state: simply by allowing Things and Objects themselves to be the observing clients.
That's all I'm proposing - that Things just watch each other instead of being observed
by invisible processes.

This is a peer-to-peer model, where every player in the IoT is autonomous: empowered to
control itself and to evolve its own published state independently and concurrently.
That can create a global, visible, loosely-coupled peer mesh of mutually-observing,
interoperating and co-operating Things and Objects.

Programs to animate these peer Things and Objects can be extremely simple: you only need
to describe how their new state should be set as a function of the states around. This is
similar to programming a spreadsheet. It's also an inherently concurrent and distributable
programming model. My <a href="http://object.network/onr.html">Cyrus</a> programming language is designed to
express this kind of program.

</div>
</content>
</entry>
<entry>
<id>http://duncan-cragg.org/blog/post/object-network-approach-augmented-reality-and-inte/</id>
<title>The Object Network Approach to Augmented Reality and the Internet of Things</title>
<published>2014-03-01T11:24:00Z</published>
<updated>2014-03-01T11:24:00Z</updated>
<link rel="alternate" type="text/html" href="http://duncan-cragg.org/blog/post/object-network-approach-augmented-reality-and-inte/" title="The Object Network Approach to Augmented Reality and the Internet of Things" />
<category term="architecture" />
<category term="declarative" />
<category term="p2p" />
<category term="rest" />
<category term="json" />
<category term="forest" />
<category term="netmash" />
<category term="cyrus" />
<category term="object-network" />
<category term="IoT" />
<summary type="xhtml">
<div xmlns="http://www.w3.org/1999/xhtml">

After filling up that other
<a href="http://duncan-cragg.org/blog/post/building-object-network/">blog</a> recently with 61
pages of content, one page a day, I was challenged by my ThoughtWorks colleague,
<a href="http://www.youtube.com/watch?v=MMA0Vlrdajs">Andy McWilliams</a>, to help him get in more
easily to my explanations of the Object Network applied to Augmented Reality and the
Internet of Things, especially around how my approach differs and is better than other
approaches.
  ...

</div>
</summary>
<content type="xhtml" xml:space="preserve">
<div xmlns="http://www.w3.org/1999/xhtml">

<div class="summary">
After filling up that other
<a href="http://duncan-cragg.org/blog/post/building-object-network/">blog</a> recently with 61
pages of content, one page a day, I was challenged by my ThoughtWorks colleague,
<a href="http://www.youtube.com/watch?v=MMA0Vlrdajs">Andy McWilliams</a>, to help him get in more
easily to my explanations of the Object Network applied to Augmented Reality and the
Internet of Things, especially around how my approach differs and is better than other
approaches.
</div>
Here's the short overview I came up with:

Other Approaches

Broadly-speaking, existing approaches to unifying the IoT
(<a href="https://allseenalliance.org/docs-and-downloads/documentation/introduction-alljoyn-framework#unique_14">AllJoyn</a>,
<a href="http://www.openhab.org/features.html">OpenHAB</a>,
<a href="http://thethingsystem.com/dev/Devices.html">The Thing System</a>,
<a href="https://github.com/nitrogenjs/service#readme">Nitrogen</a>,
<a href="http://www.argot-sdk.org/start.htm">Argot</a>, ..) are built around event and action messages. Messages are
often managed through a message bus and/or an API that gives message construction and a
function-call and callback interface, perhaps through socket connections.

Programming is offered through "event-action" (or "callback-call") rule programming,
perhaps in Javascript or via a visual programming interface like
<a href="https://ifttt.com/hue">If This Then That</a>.

The Object Network Approach

The <a href="http://object.network/">Object Network</a>, on the other hand, is built like the Web,
using URLs. These URLs point not to Web pages but to JSON state objects. Any peer can
publish state objects on URLs - e.g. sensors, controllers, mobile devices, servers,
etc - and that state can be pulled or pushed at any time between peers using HTTP GET and
POST (or <a href="https://en.wikipedia.org/wiki/Constrained_Application_Protocol">CoAP</a>!).

Object Network programming is based, not on events and messages, but on state and state
transfer. So instead of event-action rules, it has "state-to-state" rules, which are
simpler and more powerful. Actions, if needed, are handled by creating "intent objects",
but peer objects are very much more empowered and independent, so can run their own
rules to set their own state in the face of surrounding state objects observed through
their links.

Three Object Net Posts

I then pointed Andy at one of the posts on that other blog, but here are three posts there that are relevant:

<ul>
<li><a href="http://duncan-cragg.org/new-blog/2014/02/what-is-object-network-again.html">What is The Object Network again?</a></li>
<li><a href="http://duncan-cragg.org/new-blog/2014/01/iot-rules-event-action-versus-state.html">IoT Rules: Event->Action versus State->State</a></li>
<li><a href="http://duncan-cragg.org/new-blog/2013/12/links-between-thing-objects.html">Links between Thing Objects</a></li>
</ul>

Benefits of The Object Net Approach

These posts give more elaboration around the benefits of this approach, but briefly:

Using URLs is a force towards harmonisation of the formats they are contained in - each
end of the link will tend to come from the same family of formats. So simply putting
URLs in JSON is itself a massive benefit, if it leads to common formats for the same
data. Further, these links and shared formats, when used across multiple systems, form a
"fabric" of data that can be used to serendipitously create whole new applications and mash-ups.

It's a simple and powerful distributed systems model, as the Web itself has
demonstrated. When it becomes peer-to-peer and asynchronous through CoAP, IPv6 and the
IoT, its power increases further through timeliness and interactivity, decentralisation
and the removal of intermediaries - and puts that power in the hands of users in their
intimate daily lives.

To this the Object Net adds the simple and powerful programming model of setting object
state as a function of surrounding neighbour, environmental or public object states,
observed through links. The key aspect is the autonomy of each object in the network to
determine its own state evolution in a decentralised, loosely-coupled mesh.

CoAP-based Alternatives

Now, merely using the
<a href="https://en.wikipedia.org/wiki/Constrained_Application_Protocol">CoAP</a>
stack <a href="http://duncan-cragg.org/new-blog/2013/12/coap-and-forest.html">buys you most of the above approach</a>, being
<a href="https://datatracker.ietf.org/wg/core/">chartered</a> from the start with REST in mind, plus adding
<a href="https://datatracker.ietf.org/doc/draft-ietf-core-observe/?include_text=1">asynchronous resource observation</a>
and having great <a href="http://duncan-cragg.org/new-blog/2014/02/bidirectional-coap.html">peer-to-peer potential</a>
through IPv6 and UDP.

So really, it all depends on the code that uses it - does it build the observation model
into the programming model like the Object Network does? Does it simply let you describe
how the state of your object can be set according to the states of objects you link to
and observe? Does it talk about common data formats? I've yet to track down a framework
or platform that does this.

The nearest I've seen to an approach that has many of the elements of this, including
observation through CoAP and a model layer above, is the
<a href="http://www.slideshare.net/michaeljohnkoster/iot-toolkit-and-the-smart-object-api-architecture-for-interoperability">Open Source Internet of Things</a>
(and <a href="http://iot-datamodels.blogspot.co.uk/">see here also</a>). This project seems to be
much more complex, partly due to its being based on the Semantic Web.

I'll be exploring how the Object Net compares to it and the overall <a href="https://datatracker.ietf.org/wg/core/">CoRE</a>
approach, and maybe also see how the
<a href="https://www.ietf.org/mail-archive/web/core/current/msg02803.html">IPSO Alliance</a>
and <a href="http://postscapes.com/internet-of-things-protocols#organizations">other initiatives</a>
fit in to all that.

</div>
</content>
</entry>
</feed>

If you would like to create a banner that links to this page (i.e. this validation result), do the following:

Download the "valid Atom 1.0" banner.
Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)
Add this HTML to your page (change the image src attribute if necessary):

<a href="http://www.feedvalidator.org/check.cgi?url=http%3A//duncan-cragg.org/blog/atom/"><img src="valid-atom.png" alt="[Valid Atom 1.0]" title="Validate my Atom 1.0 feed" /></a>

If you would like to create a text link instead, here is the URL you can use:

http://www.feedvalidator.org/check.cgi?url=http%3A//duncan-cragg.org/blog/atom/

Home · About · News · Docs · Terms