Congratulations!

[Valid Atom 1.0] 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.

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

  1. <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  2. <?xml-stylesheet href="http://duncan-cragg.org/css/atom.css" type="text/css" ?>
  3. <!-- Copyright (c) 2006 Duncan Cragg -->
  4.  
  5. <feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en-gb">
  6.    <id>http://duncan-cragg.org/blog/</id>
  7.    <title>What Not How</title>
  8.    <subtitle>Duncan Cragg on Declarative Architectures</subtitle>
  9.    <author><name>Duncan Cragg</name></author>
  10.    <logo>/favicon.gif</logo>
  11.    <icon>/favicon.ico</icon>
  12.    <rights>All content including photos and images by Duncan Cragg. Copyright (c) Duncan Cragg, your rights preserved: see /CXL.html</rights>
  13.    <generator uri="http://www.djangoproject.com">A Django Production.</generator>
  14.    <link rel="alternate" type="text/html" href="http://duncan-cragg.org/blog/" title="What Not How" />
  15.    <link rel="self" type="application/atom+xml" href="http://duncan-cragg.org/blog/atom/" />
  16.  
  17.    <updated>2015-02-10T15:58:00Z</updated>
  18.  
  19.  
  20.    <entry>
  21.        <id>http://duncan-cragg.org/blog/post/eup-iot-ar-minecraft-netmash/</id>
  22.        <title>EUP, IoT, AR and Minecraft | NetMash | Object Network</title>
  23.        <published>2015-02-10T15:58:00Z</published>
  24.        
  25.        <updated>2015-02-10T15:58:00Z</updated>
  26.        
  27.        <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" />
  28.        
  29.        <category term="declarative" />
  30.        
  31.        <category term="rest" />
  32.        
  33.        <category term="json" />
  34.        
  35.        <category term="forest" />
  36.        
  37.        <category term="netmash" />
  38.        
  39.        <category term="cyrus" />
  40.        
  41.        <category term="object-network" />
  42.        
  43.        <category term="IoT" />
  44.        
  45.        <category term="eup" />
  46.        
  47.        <category term="AR" />
  48.        
  49.        <category term="minecraft" />
  50.        
  51.        <summary type="xhtml">
  52.            <div xmlns="http://www.w3.org/1999/xhtml">
  53.  
  54. <p>
  55.  
  56. These days I seem to mainly use this blog for once-a-year announcements of what I&#39;m up to, which is useful as record for myself when I need to reflect.
  57. </p><p>
  58. So here&#39;s where I&#39;m at, as 2015 begins..
  59. &#160; ...
  60. </p>
  61.  
  62.            </div>
  63.        </summary>
  64.        <content type="xhtml" xml:space="preserve">
  65.            <div xmlns="http://www.w3.org/1999/xhtml">
  66.  
  67. <p>
  68. </p><div class="summary"><p>
  69. These days I seem to mainly use this blog for once-a-year announcements of what I&#39;m up to, which is useful as record for myself when I need to reflect.
  70. </p><p>
  71. So here&#39;s where I&#39;m at, as 2015 begins..
  72. </p></div><p>
  73. 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.
  74. </p><p>
  75. I called the language <a href="http://duncan-cragg.org/blog/post/cyrus-2013/">Cyrus</a> at the start of 2013 and swore I&#39;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.
  76. </p><p>
  77. 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>.
  78. </p><p>
  79. <b>Core Goal</b>
  80. </p><p>
  81. So now I&#39;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.
  82. </p><p>
  83. 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.
  84. </p><p>
  85. 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.
  86. </p><p>
  87. 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.
  88. </p><p>
  89. <b>Names</b>
  90. </p><p>
  91. So, while I wait to see if &quot;Cyrus&quot; is actually viable in the longer term to name the language, this year&#39;s names are back to the <a href="http://Object.Network">Object Network</a> and <a href="http://NetMash.net">NetMash</a>. I&#39;m also still using &quot;FOREST&quot; and &quot;Functional Observer&quot; to describe the architectural style and programming model, respectively, if anyone asks.
  92. </p><p>
  93. But since I&#39;m focusing my energies on end users not technical folk, I&#39;m not expecting anyone to ask..
  94.  
  95. </p>
  96.  
  97.            </div>
  98.        </content>
  99.    </entry>
  100.    
  101.    <entry>
  102.        <id>http://duncan-cragg.org/blog/post/web-things-watching-things/</id>
  103.        <title>CoAP and a Web of Things watching Things</title>
  104.        <published>2014-05-19T21:21:00Z</published>
  105.        
  106.        <updated>2014-05-19T21:21:00Z</updated>
  107.        
  108.        <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" />
  109.        
  110.        <category term="architecture" />
  111.        
  112.        <category term="p2p" />
  113.        
  114.        <category term="forest" />
  115.        
  116.        <category term="cyrus" />
  117.        
  118.        <category term="object-network" />
  119.        
  120.        <category term="IoT" />
  121.        
  122.        <summary type="xhtml">
  123.            <div xmlns="http://www.w3.org/1999/xhtml">
  124.  
  125. <p>
  126.  
  127. With the expansion of the Internet of Things (IoT), and the diversity of products and
  128. technologies, the one thing that everyone agrees on is that it&#39;s time to start agreeing:
  129. the Internet of Things needs standards. Many agree that it needs open standards, like
  130. those that underpin the Web.
  131. </p><p>
  132. Obviously, a Web of Things is going to be quite different from the Web of Documents and
  133. Applications: it&#39;ll be much more fine-grained and much more &quot;buzzy&quot;, with many sensors
  134. and actuators working together with many hubs and services. It&#39;s more likely to be at
  135. home with the next generation of the Internet Protocol: IPv6.
  136. </p><p>
  137. To meet the fine-grained and buzzy nature of the IoT, the
  138. <a href="https://datatracker.ietf.org/doc/draft-ietf-core-coap/?include_text=1">Constrained Application Protocol, or CoAP,</a>
  139. was created.  CoAP is an open Internet standard for the Web of Things. It&#39;s based
  140. on the Web&#39;s core pipe: HTTP, but has many differences to allow it to be used by very
  141. resource-constrained devices and local radio networks.
  142. </p><p>
  143. CoAP can be used in many different ways, but there&#39;s a danger that a lack of clarity in
  144. exactly how it&#39;s used means it doesn&#39;t achieve its full potential to link up the world&#39;s
  145. embedded devices.
  146. </p><p>
  147. This article proposes a simple and clear way that CoAP could be used to build a uniform,
  148. global, decentralised Web of interacting and discoverable Things.
  149. </p><p>
  150. <i>This <a href="http://www.thoughtworks.com/insights/blog/coap-and-web-things-watching-things">article first appeared</a> on the ThoughtWorks Insights pages</i>.
  151. &#160; ...
  152. </p>
  153.  
  154.            </div>
  155.        </summary>
  156.        <content type="xhtml" xml:space="preserve">
  157.            <div xmlns="http://www.w3.org/1999/xhtml">
  158.  
  159. <p>
  160. </p><div class="summary"><p>
  161. With the expansion of the Internet of Things (IoT), and the diversity of products and
  162. technologies, the one thing that everyone agrees on is that it&#39;s time to start agreeing:
  163. the Internet of Things needs standards. Many agree that it needs open standards, like
  164. those that underpin the Web.
  165. </p><p>
  166. Obviously, a Web of Things is going to be quite different from the Web of Documents and
  167. Applications: it&#39;ll be much more fine-grained and much more &quot;buzzy&quot;, with many sensors
  168. and actuators working together with many hubs and services. It&#39;s more likely to be at
  169. home with the next generation of the Internet Protocol: IPv6.
  170. </p><p>
  171. To meet the fine-grained and buzzy nature of the IoT, the
  172. <a href="https://datatracker.ietf.org/doc/draft-ietf-core-coap/?include_text=1">Constrained Application Protocol, or CoAP,</a>
  173. was created.  CoAP is an open Internet standard for the Web of Things. It&#39;s based
  174. on the Web&#39;s core pipe: HTTP, but has many differences to allow it to be used by very
  175. resource-constrained devices and local radio networks.
  176. </p><p>
  177. CoAP can be used in many different ways, but there&#39;s a danger that a lack of clarity in
  178. exactly how it&#39;s used means it doesn&#39;t achieve its full potential to link up the world&#39;s
  179. embedded devices.
  180. </p><p>
  181. This article proposes a simple and clear way that CoAP could be used to build a uniform,
  182. global, decentralised Web of interacting and discoverable Things.
  183. </p><p>
  184. <i>This <a href="http://www.thoughtworks.com/insights/blog/coap-and-web-things-watching-things">article first appeared</a> on the ThoughtWorks Insights pages</i>.
  185. </p></div><p>
  186. <b>CoAP&#39;s Interaction Model</b>
  187. </p><p>
  188. In simple terms, CoAP says you should send an Internet packet (UDP) to request a device&#39;s
  189. data - a GET on a device URL - and then expect back a packet with that data, perhaps a
  190. sensor value. You can also push a packet of data to a device - a POST to its URL.
  191. </p><p>
  192. An <a href="https://datatracker.ietf.org/doc/draft-ietf-core-observe/?include_text=1">extension to CoAP for observation</a>
  193. allows you to keep on receiving back data packets following a GET as the device state at
  194. its URL changes.
  195. </p><p>&#160;</p><p>
  196. <b>Ways of Interacting and Programming</b>
  197. </p><p>
  198. This simple protocol is actually quite unique in the IoT world. Most IoT approaches work
  199. through events and messages - sensors and actuators may be connected to an event stream
  200. or message bus. The model used to program Things reflects this: events and messages tend
  201. to lead to actions and commands, and thence to central control, either in a central
  202. server in the house or a service in the cloud. Central control tends towards silos and
  203. proprietary formats and application protocols.
  204. </p><p>
  205. CoAP&#39;s Web-based model of devices with their own URLs is quite different. The Web that
  206. CoAP belongs to works through decentralisation - empowering everyone to publish and link
  207. up to anyone else.  These links encourage everyone to use the same formats for their
  208. data, leading to re-use and &quot;mashability&quot;. The lack of centralisation and greater
  209. interoperability leads to greater freedom to quickly innovate and build on top of each
  210. other&#39;s data.
  211. </p><p>
  212. But since the event/action or message/command model is so familiar in the IoT world,
  213. many people will inevitably try to use CoAP in this way, and miss out on all the
  214. benefits that have been proven by the unprecedented scale of the Web.
  215. </p><p>
  216. And even if they do embrace the CoAP and Web model, there&#39;s still sufficient flexibility
  217. in there to allow various groups of people to go their own way and lose many of the
  218. benefits. For example, people still don&#39;t <i>have</i> to use links between their worlds and
  219. don&#39;t <i>have</i> to share the same formats. They don&#39;t have to use POST in exactly the
  220. same way to achieve dynamic interaction with devices. The way Web APIs have gone - to
  221. create <a href="http://www.infoq.com/news/2012/02/the-object-network/">thousands of isolated silos</a> -
  222. is strong evidence of this risk.
  223. </p><p>&#160;</p><p>
  224. <b>Peer-to-Peer Programming of Things</b>
  225. </p><p>
  226. So what way should everyone use CoAP? Well, like I said, people should at least link
  227. up in a Web and use the same formats for lights and dimmers and locks and temperature.
  228. And use the definition of those formats to guide the POST-side interaction models.
  229. </p><p>
  230. However, unlike the Web of large-scale documents and applications, of browsers and
  231. webservers and client-server asymmetry, the Internet of Things is an Internet of
  232. sensors and actuators and hubs; interacting devices which work as <i>symmetric peers</i> in
  233. a, potentially IPv6, mesh.
  234. </p><p>
  235. This symmetry and peer-to-peer interaction are embraced in the CoAP model and can lead
  236. to an interesting, simple and powerful approach to the Internet of Things, and to the
  237. evolution of the Web itself.  There&#39;s an opportunity here to go one step further than the
  238. Web, through a simple and powerful programming model based on <i>peer observation</i>.
  239. </p><p>&#160;</p><p>
  240. <b>The Light Depends On The Light Level Sensor</b>
  241. </p><p>
  242. For example, consider possibly the simplest IoT interaction imaginable: a light that
  243. reacts to a sensor measuring the ambient light level and colour temperature, by
  244. adjusting its brightness and colour accordingly, either to match or to compensate.
  245. </p><p>
  246. There are two peers - and <i>we don&#39;t need a central controller</i>. The light depends on the
  247. sensor. They both have URLs, so the light can <i>link</i> to the sensor. We are using CoAP,
  248. so the light can <i>observe</i> the sensor itself:
  249. </p><p>
  250. <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>
  251. </p><p>
  252. The light depends on the light level sensor. That&#39;s the simple, powerful interaction and
  253. programming model that CoAP allows us to use - if we allow Things themselves to be the
  254. observing client. The state of a Thing depends on the states of the other Things that it
  255. links to. You can also have other abstract, non-real Things interacting in the peer
  256. mesh, which we can still call Objects.
  257. </p><p>
  258. I won&#39;t go into detail here about exactly how CoAP would be used to achieve this: the
  259. URLs and payload formats and the use of GET, observe and POST that enables Things to be
  260. client observers. I&#39;ll document that elsewhere, but it&#39;ll be based on my
  261. <a href="http://forest-roa.org">FOREST</a> architectural style and the <a href="http://object.network">Object Network</a>.
  262. </p><p>&#160;</p><p>
  263. <b>Things Watching Things</b>
  264. </p><p>
  265. The Internet of Things can be a mashable Web of Things. If we&#39;re going to use CoAP to
  266. build that fine-grained, &quot;buzzy&quot;, decentralised Web, then we should use it like the Web:
  267. we should agree on the formats for device data, and link up all of our Things and
  268. non-Thing Object data via their URLs. The common formats should also define how POST is
  269. to be used.  That&#39;s the basic requirement.
  270. </p><p>
  271. We can then take a bold step further by exploiting CoAP&#39;s observation mechanism, to
  272. build a symmetric peer mesh of Things and Objects that link to, watch and depend on each
  273. others state: simply by allowing Things and Objects themselves to be the observing clients.
  274. That&#39;s all I&#39;m proposing - that Things just watch each other instead of being observed
  275. by invisible processes.
  276. </p><p>
  277. This is a peer-to-peer model, where every player in the IoT is autonomous: empowered to
  278. control itself and to evolve its own published state independently and concurrently.
  279. That can create a global, visible, loosely-coupled peer mesh of mutually-observing,
  280. interoperating and co-operating Things and Objects.
  281. </p><p>
  282. Programs to animate these peer Things and Objects can be extremely simple: you only need
  283. to describe how their new state should be set as a function of the states around. This is
  284. similar to programming a spreadsheet.  It&#39;s also an inherently concurrent and distributable
  285. programming model. My <a href="http://object.network/onr.html">Cyrus</a> programming language is designed to
  286. express this kind of program.
  287. </p>
  288.  
  289.            </div>
  290.        </content>
  291.    </entry>
  292.    
  293.    <entry>
  294.        <id>http://duncan-cragg.org/blog/post/object-network-approach-augmented-reality-and-inte/</id>
  295.        <title>The Object Network Approach to Augmented Reality and the Internet of Things</title>
  296.        <published>2014-03-01T11:24:00Z</published>
  297.        
  298.        <updated>2014-03-01T11:24:00Z</updated>
  299.        
  300.        <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" />
  301.        
  302.        <category term="architecture" />
  303.        
  304.        <category term="declarative" />
  305.        
  306.        <category term="p2p" />
  307.        
  308.        <category term="rest" />
  309.        
  310.        <category term="json" />
  311.        
  312.        <category term="forest" />
  313.        
  314.        <category term="netmash" />
  315.        
  316.        <category term="cyrus" />
  317.        
  318.        <category term="object-network" />
  319.        
  320.        <category term="IoT" />
  321.        
  322.        <summary type="xhtml">
  323.            <div xmlns="http://www.w3.org/1999/xhtml">
  324.  
  325. <p>
  326.  
  327. After filling up that other
  328. <a href="http://duncan-cragg.org/blog/post/building-object-network/">blog</a> recently with 61
  329. pages of content, one page a day, I was challenged by my ThoughtWorks colleague,
  330. <a href="http://www.youtube.com/watch?v=MMA0Vlrdajs">Andy McWilliams</a>, to help him get in more
  331. easily to my explanations of the Object Network applied to Augmented Reality and the
  332. Internet of Things, especially around how my approach differs and is better than other
  333. approaches.
  334. &#160; ...
  335. </p>
  336.  
  337.            </div>
  338.        </summary>
  339.        <content type="xhtml" xml:space="preserve">
  340.            <div xmlns="http://www.w3.org/1999/xhtml">
  341.  
  342. <p>
  343. </p><div class="summary"><p>
  344. After filling up that other
  345. <a href="http://duncan-cragg.org/blog/post/building-object-network/">blog</a> recently with 61
  346. pages of content, one page a day, I was challenged by my ThoughtWorks colleague,
  347. <a href="http://www.youtube.com/watch?v=MMA0Vlrdajs">Andy McWilliams</a>, to help him get in more
  348. easily to my explanations of the Object Network applied to Augmented Reality and the
  349. Internet of Things, especially around how my approach differs and is better than other
  350. approaches.
  351. </p></div><p>
  352. Here&#39;s the short overview I came up with:
  353. </p><p>
  354. <b>Other Approaches</b>
  355. </p><p>
  356. Broadly-speaking, existing approaches to unifying the IoT
  357. (<a href="https://allseenalliance.org/docs-and-downloads/documentation/introduction-alljoyn-framework#unique_14">AllJoyn</a>,
  358. <a href="http://www.openhab.org/features.html">OpenHAB</a>,
  359. <a href="http://thethingsystem.com/dev/Devices.html">The Thing System</a>,
  360. <a href="https://github.com/nitrogenjs/service#readme">Nitrogen</a>,
  361. <a href="http://www.argot-sdk.org/start.htm">Argot</a>, ..) are built around event and action messages. Messages are
  362. often managed through a message bus and/or an API that gives message construction and a
  363. function-call and callback interface, perhaps through socket connections.
  364. </p><p>
  365. Programming is offered through &quot;event-action&quot; (or &quot;callback-call&quot;) rule programming,
  366. perhaps in Javascript or via a visual programming interface like
  367. <a href="https://ifttt.com/hue">If This Then That</a>.
  368. </p><p>
  369. <b>The Object Network Approach</b>
  370. </p><p>
  371. The <a href="http://object.network/">Object Network</a>, on the other hand, is built like the Web,
  372. using URLs. These URLs point not to Web pages but to JSON state objects. Any peer can
  373. publish state objects on URLs - e.g. sensors, controllers, mobile devices, servers,
  374. etc - and that state can be pulled or pushed at any time between peers using HTTP GET and
  375. POST (or <a href="https://en.wikipedia.org/wiki/Constrained_Application_Protocol">CoAP</a>!).
  376. </p><p>
  377. Object Network programming is based, not on events and messages, but on state and state
  378. transfer. So instead of event-action rules, it has &quot;state-to-state&quot; rules, which are
  379. simpler and more powerful. Actions, if needed, are handled by creating &quot;intent objects&quot;,
  380. but peer objects are very much more empowered and independent, so can run their own
  381. rules to set their own state in the face of surrounding state objects observed through
  382. their links.
  383. </p><p>
  384. <b>Three Object Net Posts</b>
  385. </p><p>
  386. I then pointed Andy at one of the posts on that other blog, but here are three posts there that are relevant:
  387. </p><p>
  388. </p><ul>
  389. <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>
  390. <li><a href="http://duncan-cragg.org/new-blog/2014/01/iot-rules-event-action-versus-state.html">IoT Rules: Event-&gt;Action versus State-&gt;State</a></li>
  391. <li><a href="http://duncan-cragg.org/new-blog/2013/12/links-between-thing-objects.html">Links between Thing Objects</a></li>
  392. </ul><p>
  393. </p><p>
  394. <b>Benefits of The Object Net Approach</b>
  395. </p><p>
  396. These posts give more elaboration around the benefits of this approach, but briefly:
  397. </p><p>
  398. Using URLs is a force towards harmonisation of the formats they are contained in - each
  399. end of the link will tend to come from the same family of formats. So simply putting
  400. URLs in JSON is itself a massive benefit, if it leads to common formats for the same
  401. data. Further, these links and shared formats, when used across multiple systems, form a
  402. &quot;fabric&quot; of data that can be used to serendipitously create whole new applications and mash-ups.
  403. </p><p>
  404. It&#39;s a simple and powerful distributed systems model, as the Web itself has
  405. demonstrated. When it becomes peer-to-peer and asynchronous through CoAP, IPv6 and the
  406. IoT, its power increases further through timeliness and interactivity, decentralisation
  407. and the removal of intermediaries - and puts that power in the hands of users in their
  408. intimate daily lives.
  409. </p><p>
  410. To this the Object Net adds the simple and powerful programming model of setting object
  411. state as a function of surrounding neighbour, environmental or public object states,
  412. observed through links. The key aspect is the autonomy of each object in the network to
  413. determine its own state evolution in a decentralised, loosely-coupled mesh.
  414. </p><p>
  415. <b>CoAP-based Alternatives</b>
  416. </p><p>
  417. Now, merely using the
  418. <a href="https://en.wikipedia.org/wiki/Constrained_Application_Protocol">CoAP</a>
  419. stack <a href="http://duncan-cragg.org/new-blog/2013/12/coap-and-forest.html">buys you most of the above approach</a>, being
  420. <a href="https://datatracker.ietf.org/wg/core/">chartered</a> from the start with REST in mind, plus adding
  421. <a href="https://datatracker.ietf.org/doc/draft-ietf-core-observe/?include_text=1">asynchronous resource observation</a>
  422. and having great <a href="http://duncan-cragg.org/new-blog/2014/02/bidirectional-coap.html">peer-to-peer potential</a>
  423. through IPv6 and UDP.
  424. </p><p>
  425. So really, it all depends on the code that uses it - does it build the observation model
  426. into the programming model like the Object Network does? Does it simply let you describe
  427. how the state of your object can be set according to the states of objects you link to
  428. and observe? Does it talk about common data formats? I&#39;ve yet to track down a framework
  429. or platform that does this.
  430. </p><p>
  431. The nearest I&#39;ve seen to an approach that has many of the elements of this, including
  432. observation through CoAP and a model layer above, is the
  433. <a href="http://www.slideshare.net/michaeljohnkoster/iot-toolkit-and-the-smart-object-api-architecture-for-interoperability">Open Source Internet of Things</a>
  434. (and <a href="http://iot-datamodels.blogspot.co.uk/">see here also</a>). This project seems to be
  435. much more complex, partly due to its being based on the Semantic Web.
  436. </p><p>
  437. I&#39;ll be exploring how the Object Net compares to it and the overall <a href="https://datatracker.ietf.org/wg/core/">CoRE</a>
  438. approach, and maybe also see how the
  439. <a href="https://www.ietf.org/mail-archive/web/core/current/msg02803.html">IPSO Alliance</a>
  440. and <a href="http://postscapes.com/internet-of-things-protocols#organizations">other initiatives</a>
  441. fit in to all that.
  442. </p>
  443.  
  444.            </div>
  445.        </content>
  446.    </entry>
  447.    
  448. </feed>
  449.  
  450.  

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

  1. Download the "valid Atom 1.0" banner.

  2. Upload the image to your own server. (This step is important. Please do not link directly to the image on this server.)

  3. Add this HTML to your page (change the image src attribute if necessary):

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/

Copyright © 2002-9 Sam Ruby, Mark Pilgrim, Joseph Walton, and Phil Ringnalda