The Real-World as a Web API is our first proposal:

The world of “physical devices” such as home appliances/electronics, real-time city data, RFID-tagged objects, mobile phones, etc. has long been longing for a seamless and universal integration platform. Out of a great number of heavy-and-not-so-great middleware a surprising one is emerging: the Web! In this presentation we would like to show how Web developers might well be the next generation of real-world hackers. We’ll demonstrate how the current developments in Web standards make it one step closer to the real-world. We’ll show how REST and the light IPv6 (lowpan) protocols fit really well to control most physical devices. We’ll illustrate how the real-time Web (Web sockets, Pubsubhubbub, Twitter, etc.) makes it easy to sense the world and get physical devices to trigger events. We’ll show how HTML 5, Microformats/data, rich snippets and social networks can help us to search and share the real-world. We will finally show how this Web integration and Javascript toolkits (e.g. JQuery, Sencha touch, etc.) enable us to mashup the world on the Web layer as we wish: from configuring our connected homes to building on top of our real-time cities with our mobile phones. The success of books such as “The Next Internet” or blogs such as Web of Things and theinternetofthings.eu emphasize it: the Internet of Things is coming and Web developers are its most powerful actors!

Next, we have a closer look at the city use-case in:

The public infrastructure of our cities are obscure structures whose workings are not accessible to most citizens. What if every sensor in our cities would have a Web API anyone could access in real-time and mashup? Open and easy to use Web platforms that enable efficient integration, processing, storage, and access to the enormous amount of data digital cities generate are increasingly needed, and we’ll explore the various technologies that are making such solutions possible. Furthermore, we’ll go much more beyond the technical aspects of such a platform to address the more controversial implications of such an Orwellian scenario. Hopefully, this session will provide a forum for the different disciplines involved in the design of future cities to establish a common ground for better interdisciplinary cooperation and understanding in this area.

The idea is to concentrate the first workshop on the technology side and the second a little more on the conceptual side, if you want to be able to attend any of those at SXSW 2011 then please vote here: The Real-World as a Web API or here Web Mashup Platforms for Future Programmable Cities. Or better vote for both
Votes are closing Friday 27th of August!

Unlike the WoT2010 which brought together WoT researchers, we emphasize here concrete applications practical solutions that can be built on top of WoT. We particularly welcome real-world deployments that can highlight the plus/minuses of using WoT as infrastructure for a scalable urban-scale data collection and processing.

We would like to bring closer practitioners in the area of smart cities (industries that build the various components of smart cities such as infrastructure, sensor, software, middleware, hardware, etc), along with researchers in various fields related to networked objects (that’s why we do this workshop in the context of IOT conference), and with architects/designers/urban planners that are in charge of designing the points of contact between citizens and this invisible (& growing) digital infrastructure.

The outcome would be for participants to get to know the latest trends in research/technology (& each other) and at the same time get practical insights about the challenges in building such scalable (city-wide+) infrastructures to collect, process, share and store huge quantities of real-time data from various urban sources. Pretty much like a combination between twitter and data.gov, but for sensor data which emphasizes open access to real-time data streams from cities (public APIs that anyone can access and code with).

As we wanted to avoid a “classic” mini-conf like workshop to enable active participation, we have been preparing a few surprises that will allow you to get your hands dirty and join the conversations and hands-on sessions with world-class experts in this area. More to follow soon.

Also, we are still looking for sponsors that could cover the travel costs of our keynote speaker, so if you know someone or are interested to sponsor us in exchange of some promotion/visibility, please get in touch with us (info@{guesswhat}.com would do).

Read more on the official call for papers/demos.

The most surprising fact was probably how close the two communities are getting. Web people are increasingly interested in embedded/physical/sensor computing, and on the other hand, pervasive people are getting more and more convinced that the Web protocols as not so bad after all (take this paper for instance), at least good enough for a good range of applications. Quite a change of mindset compared to a year ago.

One of the good outcomes of the workshop was the fruitful final discussion. Three big challenges seem to emerge: the discovery of things, the real-time things and understanding the needs for Web-enabled things. Three challenges that were also identified as keys at WOT 2010.

Discovery
We need to look at describing things so that they can be both discovered by machines (i.e. network discovery) and their “services” understood by humans (i.e. service discovery). REST is good, REST is great but it’s raw expressiveness is not enough to understand things. By crawling a RESTful API you can find the resources it exposes, by reading the URIs you can get rough “tags” (e.g. /temperature) describing their nature. But this is not enough for users, neither for machines. As an examples, attendees mentioned the need to generate sense-making UIs on the fly or to customize page rendering depending on the thing one discovers. A simple example of this is Google rich snippets where the search engine renders the page results differently if they embed some semantics. What if Google could render search results for things in a way that helps users interacting with them.

Thus, researchers are exploring ways of better describing things directly inspired from the semantic Web. In “A Triple Space-Based Semantic Distributed. Middleware for Internet of Things” the authors suggest using RDF. In the mashup framework we presented an RDFa based solution to be able to integrated newly discovered devices as mashup actors directly. Those solutions however have the drawbacks of being based on well-know syntax but “proprietary semantics”, i.e. they cannot be understood by One alternative we (and others) currently explore is the use of Microformats which enables to use “agreed-upon” lightweight semantics. Their recent fast-pace expansion makes them even more interesting (I should post about our early experiments with things and microformats here soon!).

Real-time Things
Next in line of the important aspects for a WoT was the need for real-time communication patterns. Not ground-breaking, since this topic has been around WoT architectural discussions since the beginning but the workshop made it clear: client server architectures are great for controlling things, but for monitoring we also need things to be able to push data. Of course, we would also like this push pattern to be as Web oriented as possible. On the REST-side People talked about Atom and especially the latest push based mechanism using it, aka PuSH (or pubsubhubbub). On the more WS-* side, speakers talked about using WS-eventing. We also talked about our experiences with WS-eventing in DPWS (a device tailored WS-* stack) and concluded that it was getting better but still quite heavy for many devices and rather hard to get hands on.
Overall it seemed that this space for still open for further exploration. Speaking of which we also presented a paper at the main conference about a light messaging service for things called RMS (Vlad will tell you more about it here soon!)

Understanding the Needs for Web-enabled Things
Last but not least one really tricky question emerged: “why do we do this?” We propose a re-programmable world where everything is created not as a single purpose object but rather as an API ready for opportunistic applications, but do people want that and why?
Most of the people there believed they do and for various reasons ranging from sustainability (objects have a second life thanks to involving them in new use cases), to customization (things are often not quite the way we want them to be) and satisfaction of DIY (Do It Yourself).
However, raising this question is key and depicted the strong need for better understanding the “mashup space” from an end-user point of view. What would people like to mash in their homes, cities and offices?

Thanks to you all for coming. Thanks for your feedbacks Let’s continue the discussion here and on Twitter #webofthings.

You’ll find the slides below and the doggy bag here.

You can find a full recording (about 1.5 hours) of the lecture here, but you’ll need to install the plug-in to watch it (sorry about that!).

Alternatively you can find the slides below:

Sharing smart things with your social networks using FAT (Friends and Things)

There are still many challenges to face towards a Web of Things: discovery, search, scalability, event driven interactions and sharing. For the last few month we’ve been focusing on the latter, because let’s face it: if you do not have a mechanism to share your Web-enabled things it is not really worth having them Web-enabled in the first place!

Core to the Web of Things vision there is this idea of the physical world as a “composable ecosystem” where devices can be used and re-used simply to create emerging applications, i.e. physical mashups.

Well, the success of Web mashups is closely dependent upon the trend for Web 2.0 services (e.g. Google, Twitter, WordPress, Doodle, etc.) to provide access to some of their services through relatively simple, often REST-based, open APIs (Application Programming Interface) on the Web. Mashup creators in turn often share their mashups on the Web (sometimes through directories such as Programmable Web) and expose them through open APIs as well, making the ecosystem grow with each application and mashup.

Enabling this model on a Web of Things requires a sharing mechanism for smart things, by enabling access to the services offered by devices through their API. For example, you could share the energy consumption sensors in your house with the community. However, this is a complex process since these devices are part of our everyday life and their public sharing might result in serious privacy violations.

The most straightforward way of solving the issue is to create ACLs (or Access Control Lists) for your devices. For each device you create a number of credentials (login + password pairs) and give them a number of roles (e.g. admin, reader, etc.).

This is, however quite a heavy and time consuming solution. When considering a large number of smart things it becomes simply unmanageable. Furthermore, it also quite abstract and does not reflect the social structure of the real-world. What if we could simply re-use existing social structures as a basis for sharing our things and sensors? Social networks such as Facebook and Twitter increasingly reflect our social relationships. Using them I could simply share access to my things with friends (e.g. Facebook) or colleagues (e.g. LinkedIn). No need to create and maintain abstract lists, simply select friends or group of friends you want to share with!

Thanks to the APIs most social networks now offer, we (together with Mathias Fischer, from ETH) were able to create a platform (SAC, or Social Access Controller) and a Web app (FAT, or Friends and Things) which lets you share REST-enabled things with the rest of YOUR world.

Architecture of the Social Access Controller

I won’t give more details about the platform here as it is the matter of an article we got accepted for the First IEEE International Workshop on the Web of Things (yeah, the one we organize BUT the article was peer-reviewed, and the reviews were tough!)

Get the paper here!

And the Bibtex below:

@inproceedings{Guinard,
Address = {Mannheim, Germany},
Author = {Dominique Guinard, Mathias Fischer, Vlad Trifa},
Booktitle = {Proceedings of the 1st IEEE International Workshop on the Web of Things (WoT 2010) at IEEE PerCom 2010},
Month = {March},
Title = {Sharing Using Social Networks in a Composable Web of Things},
Year = {2010}}

What is COAP I hear you saying? From the draft:

The use of web services on the Internet has become ubiquitous in most applications, and depends on the basic REST architecture of the web. The proposed Constrained RESTful Environments (CoRE) working group aims at extending the REST architecture to a suitable form for the most constrained nodes (e.g. 8-bit microcontrollers with limited RAM and ROM) and networks (e.g. 6LoWPAN). One of the main goals of CoRE is to design a generic RESTful protocol for the special requirements of this constrained environment, especially considering energy and building automation applications. The result of this work should be a Constrained Application Protocol (CoAP) which easily traslates to HTTP for integration with the web while meeting specialized requirements such as multicast support, very low overhead and simplicity.

I can’t wait to read it, as it’s definitely what we’ve been pushing since we started WoT: show that REST is indeed a viable protocol for constrained devices. We’re glad to see this great milestone rolling out, and we’re glad we’re here to make WoT a reality.Next step: turn it into a RFC! Maybe now, our papers will finally be better understood and not rejected on the basis “REST is not good for sensor networks”. Yay!
Oh, our WoT team wishes you all a Merry Christmas and a fantastic 2010! Thanks folks for all your support, encouragements, comments and emails, and we’re confident in saying that 2010 will be the WoT year! Keep up the good work, and looking forward for even more fruitful collaborations with you!!!

We created a page to host the application, you’ll find the latest version and additional info there.

Note that it currently only works with the Bluetooth Ploggs and on Windows (XP or later).

The bundle you download there basically contains two applications. First is contains a Web of Things Gateway for the Ploggs (written in C++) which is discovering the Ploggs and making them available through a RESTful interface. Then, it contains a Web UI and datastore based on the great Google Web Toolkit and on the wonderful RESTlet.

The bundle contains the binaries but not the source code. If you are interested in getting the source code please contact us.

We hope you’ll enjoy the software! Note that it is provided “as is” without support. However, you are very welcome to use this blog entry to post your comments, bugs reports or feature requests.

We would like to invite you to participate to this event by submitting a contribution about your current project(s) in that field.

WoT 2010 is also a unique occasion to share experiences in the field as well as to bootstrap a Web of Things scientific community.

Note that we also welcome demonstration papers reporting about your latest prototypes of things integrated to the Web or Web applications using sensor networks, embedded devices or real-world data.

Looking forward to see many of you in Mannheim!

However it seems like the REST-* initiative is also generating a lot of unhappy people amongst the RESTians. One of the reason is that they fear the REST-* initiative being a generated WS-* initiative (which is pretty much the case, JBOSS is an Enterprise Server after all, not a Web Server…) will end up with lessons like: “look guys, we did great stuff in the WS-* world now let’s apply what we know to the REST world”.
Fundamentally this would of course be wrong. If the initiative really takes off (which I quite doubt looking at the virulent feedbacks) then it is a great opportunity to rethink the WS-* integration patterns and not re-do what was done for WS-* in REST.

Essentially the first goal of such an organization should be (and is probably going to be, let’s hope) to educate people on the RESTful philosophy. Because it is definitely not trivial to entirely master (while trivial to use) and takes a while to fully understand. It probably took me over a year to go from “REST is just about URLs and Verbs (PUT, POST, etc.)” to “REST is really an architecture with constraints and great great benefits when you are interested in making you application PART of the Web”
REST is simple to use for the RESTful “API” (as word that RESTians don’t always love…) user but hard to grasp in a correct way for the RESTful “API” architect or developer.

So please REST-* guys and gals, do not do standards for the sake of it. The WS-* galaxy has so many standards that no one on earth can tell me how many (watch you eyes if you click on that). REST-* is a great idea which could turn so wrong, don’t waste it!

Indeed, there is a need to clarify what RESTful Web Services (which go beyond REST only) are about and this organization may help towards this particular goal. As a starting point what really helped ME towards this goal already exists. It is a book (a thing with a lot of pages that you can read without Internet connectivity) by people who understood most points of a RESTful architecture. A book that I read over and over again, understanding each time a little more while putting it in practice.

Btw, we are currently writing a more techie and scientific article for a conference which we will publish as a more detailed white paper once it is ready. It should also give its share of advices on building RESTful architectures for… things!

As hinted a little while ago (see this post!) we are proud to officially announce the first International Workshop on the Web of Things.
Following on the success of our workshop at Lift 2009 we decided a little while ago to organize a similar event but targeted a little more towards the scientific community.

The idea of this workshop is to attract researchers and practitioners from both the web/web engineering field and the ubicomp/pervasive computing field. The motto of this first edition is “Architecting the Web of Things”, thus we are expecting contributions (papers) defining the basis of the future Web of Things. More concretely we listed a number of topics which we found relevant and interesting such as:

• Web-based interaction patterns for embedded devices (streaming, eventing, etc.)
• Applications, deployments, prototypes and evaluations of Web of things systems
• Human-things interaction models and paradigms (mobile interfaces, etc.)
• User-oriented, context-aware discovery and dynamic search for the real world
• Composition (e.g. Web mashups) and macro-programming for the real world
• Semantic technologies for description and representation of devices and services
• Optimizations method and platforms for embedded Web servers and applications
• Security, access control, and physical sharing of physical things on the Web

More information on these topics as well as the call for paper can be found here.

The workshop (which official name is: First International Workshop on the Web of Things, WoT 2010) is going to take place in conjunction with the PerCom 2010 IEEE conference in Mannheim, Germany. The PerCom conference lasts from March 29 to April 2 and it is likely (but yet to be confirmed!!) that the workshop will take place on March 29 or April 2.

We are already looking forward to your submissions and to continue building the WoT community!
For more information check out the workshop official website.

In conjunction with the 2009 European Conference on Web Services (ECOWS 2009)

November 9, 2009, Eindhoven (The Netherlands)

The Workshop on Emerging Web Service Technology (WEWST) is the premier workshop
for academic and industrial communities to discuss innovative ideas and
research contributions advancing the state-of-the-art in Web service technologies.
Although the advantages of Web services to allow businesses to interact with each
other while maintaining a loose coupling are well known, there are still many
challenges to be solved in this important field of research. The wide variety of
tools, techniques, and technological solutions presented in WEWST share one common
feature: they suggest new directions for Web service research by introducing new
and sometime controversial ideas into the field. The workshop allows participants
to gain new insights and to start collaborations by discussing how their own work
can be used in related but different areas.

Important Dates

• Paper submission: September 1, 2009
• Acceptance notification: October 4, 2009
• Camera-ready papers: October 18, 2009
• Workshop: November 9, 2009

Topics

The WEWST 2009 program committee seeks original, high quality papers related to
emerging aspects of Web services, including but not limited to the following topics.

• Self-organizing SOA
• Dynamic service discovery
• Automated service composition
• Dynamic service binding
• Service evolution
• Coordination and business transactions
• Embedded devices and sensors as services
• Streaming services
• Event-driven architectures
• Middleware for SOA
• SLA enforcement
• Reputation mechanisms
• Technologies for social collaborations and service markets

Format and Proceedings

The workshop features regular papers of max. 8 pages and short papers of max. 4 pages. The workshop proceedings will be published as an ICPS volume by the ACM, available in the ACM digital library. Papers must be prepared according to ACM’s ICPS format; the LaTeX and Word template including the ICPS volume details are provided on the WEWST web page.

Submission

Please use the online submission system: http://www.easychair.org/conferences?conf=wewst2009.

Program Chairs

• Walter Binder, University of Lugano, Switzerland
• Erik Wilde, UC Berkeley, USA

Program Committee (to be completed)

• Luciano Baresi, Politecnico di Milano, Italy
• Ciarán Bryce, INRIA Rennes, France
• Christoph Bussler, Merced Systems, USA
• Emanuele Della Valle, CEFRIEL, Italy
• Elisabetta Di Nitto, Politecnico di Milano, Italy
• Peter Dolog, Aalborg University, Denmark
• Schahram Dustdar, Vienna University of Technology, Austria
• Rik Eshuis, Eindhoven University of Technology, The Netherlands
• Boi Faltings, EPFL, Switzerland
• Luis Ferreira Pires, University of Twente, The Netherlands
• Martin Gaedke, Chemnitz University of Technology, Germany
• Daniela Grigori, University of Versailles, France
• Paul Groth, University of Southern California, USA
• Thomas Gschwind, IBM Zurich Research Lab, Switzerland
• Yanbo Han, Chinese Academy of Sciences, China
• Jörg Hoffmann, SAP Research, Germany
• Radu Jurca, Google Inc., Switzerland
• Bernd Krämer, FernUniversität in Hagen, Germany
• Philipp Leitner, Vienna University of Technology, Austria
• David Lowe, University of Technology, Sydney
• Claus Pahl, Dublin City University, Ireland
• Cesare Pautasso, University of Lugano, Switzerland
• Heiko Schuldt, University of Basel, Switzerland
• Niranjan Suri, Institute for Human and Machine Cognition, USA
• Stefan Tai, University of Karlsruhe, Germany
• Alex Villazón, University of Lugano, Switzerland
• Wolfram Wöß, Johannes Kepler University Linz, Austria
• Wolf Zimmermann, University of Halle, Germany

Contact

For more information and inquiries about the workshop, please contact Walter Binder
(walter.binder@unisi.ch).

In conjunction with the Future Internet Symposium 2009 (FIS2009)

September 1, 2009, Berlin (Germany)

++ Deadline for submission: Aug 07, 2009 ++
++ Full papers and position papers invited ++

The Second International Workshop on Blending Physical and Digital Spaces on the Internet (OneSpace2009) will be held in conjunction with the Future Internet Symposium 2009 (FIS2009) in Berlin on 1 September 2009.

We welcome technical papers and shorter position papers addressing the identification and study of the complex relationship of the Internet with space, place, geography and distance, whether physical or virtual. Technologies as well as novel ideas, experiments, and insights originating from multi-disciplinary viewpoints, including internet, computer and GI sciences, humanities, digital media, and social sciences are welcome.

Important dates

• Submission deadline: Aug 07, 2009
• Acceptance Notification: Aug 17, 2009
• Camera-ready paper: Aug 24, 2009
• Workshop date: Sep 01, 2009

Description

OneSpace proposes to contribute to the cross-domain exploration of how Internet technologies and spatial notions co-exist and evolve.

One of the most important effects of the Internet and of the Web has been to relax spatial and temporal constraints on human activities – the so called “space-time collapse” – allowing fast global access to information as well as to physical resources and services. Recently this movement accelerated, due to the success of mobile devices such as the iPhone allowing almost ubiquitous mobile access to the Internet, to the generalisation of digital social interaction through platforms such as Facebook and Twitter, to the virtual environments provided on gaming platforms enabled by the Internet, instant communication supported by popular VOIP providers such as Skype, and an emerging web of things. Many now spend as much time involved in digital spaces over the Internet than in “real” ones, and continuously update the digital with elements of their physical life in “lifestreaming” process. Moreover reality itself is augmented by information collected from the Internet, through the increasing availability of GPS devices that ease location based search, or through “magic-lense” based applications that add information to recognized physical elements, or reconstruct them in digital space from various media collected on the Web.

While allowing users to experience a profound modification of their interaction space, the Internet has familiarised us with new topologies – alongside the prominent hyperlinked topology exhibited by the Web, Deleuze and Guattaris’s “rhizome”, which has become the model of many new forms of organization – leading to the creation of new virtual spaces and communities. Indeed, P2P networks of devices create semi-private sharing environments; (micro-) blogging and lifestreaming induces new notions of spatiotemporal as well as social proximity, while sensor and controller networks enable ubiquitous access, sensing and interaction with the real world. Furthermore, Virtual globes and GIS technologies continue to improve and to blur the boundaries between spatial representation and perception by providing mashup opportunities, photorealistic visual navigation, and three-dimensional representations.

Many agree with what came to be known as Waldo Tobler’s first law of Geography: “Everything is related to everything else, but near things are more related than distant things.” The Internet, by establishing new connections between geographically distant entities cannot but provide us with a radically new image of Space and Time that this workshop is aiming to explore in an interdisciplinary way. OneSpace proposes to take the measure of the aforementioned developments and their repercussion as well as to identify trends and directions for a new future blended Internet.

Topics of Interest

Topics of interest include, but are not limited to:

• Representation of physical/virtual spaces and topologies
• Spatiotemporal knowledge representation (ontologies and reasoning)
• The 3D and 4D Web
• Location-based services
• The Web of sensors
• New-generation Web mapping frameworks and applications
• Mobility and ubiquity
• Application of Linked Data for physical and digital spaces
• Digital Sense of Place and Presence
• Visibility and privacy in the Internet of people and things

Submissions

The following types of contributions are welcome:

• Position papers, max. 4 pages
• Technical papers, 4-10 pages

Workshop Organizers

• Vlad Tanasescu – The University of Edinburgh, UK (contact)
• Pierre Grenon – The Open University, UK
• Arno Scharl – MODUL University Vienna, Austria
• Erik Wilde – UC Berkeley, California, USA

Program Committee

(provisional, please check the website for updates)

• Susanne Boll – University of Oldenburg, Germany
• Catherine Dolbear – Sharp Laboratories of Europe, UK
• Stefan Dietze – The Open University, UK
• Hans W. Guesgen – Massey University, New Zealand
• Puneet Kishor – University of Wisconsin, USA
• Vinny Reynolds – National University of Ireland
• Dumitru Roman – STI Innsbruck, Austria
• Mike Worboys – University of Maine, USA

Further information

Updated information about the workshop can be found on the workshop website: http://onespace.ace.ed.ac.uk/2009/. For further information, please send email to
onespace2009@easychair.org.

from my point of view, this workshop nicely complements the Location and the Web (LocWeb) workshops organized in 2008 and 2009. however, i guess we will face the exact same challenges: my vision for the LocWeb workshops was to not focus on location-enabled application that happen to have a web interface, but to really focus on the larger, systemic issues of location on the web; to look at what it takes to location-enable the web, and thus to look beyond single applications. this did not work as well as i hoped, we still had a lot of submissions about location-enabled applications on the web, but that was also good, because it provided a nice forum for presenting various approaches of how to use and expose location on the web.

for WoT, the challenge will be the same: the goal is to mainly attract submissions that look beyond the single application, and that look at systemic issues of making the web a better place for things. my guess is that we again will get the majority of submissions about projects that deal with real-world things, and somehow expose these on the web. and again, it will not be a problem, because that will allow us to provide a nice overview of the current landscape of these applications.

since i am currently at ICWE 2009, i couldn’t help but notice the similarity to what’s going on here: even though it’s called Web Engineering, the majority of the conference is actually about Web Application Engineering, or more specifically Model-Driven Web Application Engineering. but even though this is more about engineering for the web (or even software engineering for the web) and not as much about engineering the web as i would lke it to be, it still is a great forum to see the ongoing developments in how apps for the web can be created. and regardless of personal preferences, the thing that matters most is that there are forums where people can meet and discuss the future of the web, and not only that of web apps.

For now still not much code to play with

Read the abstract:

Wireless Sensor Networks provide unprecedented possibilities for monitoring and interacting with the real-world. Unfortunately, the lack of open and simple standards for ad-hoc collaboration between heterogeneous embedded devices makes it difficult to build large-scale deployments; every particular application requires complex integration work, and therefore technical expertise, effort and time. Inspired by the success of Web 2.0 mashups, we propose a similar lightweight approach for interacting with networked devices. In particular, we describe a gateway architecture that enables to access sensor nodes through a RESTful interface. With this approach, interacting with a sensor node becomes as easy as typing a URI in a Web browser. By reusing the architectural principles of the modern Web, we show how one can built a loosely coupled infrastructure for the Web of Things that scales well and extends the current Web to the real world.

Maybe that makes you want to know more about it. We’ll hopefully present more in details the prototypes one can build on top of this gateway in the next few months, so keep watching. And very likely release some code when it reaches a more solid form.

Download it here!!!!

Here is the BibTeX:

@inproceedings{Trifa09b,
Address = {Marina del Rey, CA, USA},
Author = {Vlad Trifa and Samuel Wieland and Dominique Guinard and Thomas Michael Bohnert},
Booktitle = {Proceedings of the 2nd International Workshop on Sensor Network Engineering (IWSNE’09)},
Month = {June},
Title = {Design and Implementation of a Gateway for Web-based Interaction and Management of Embedded Devices},
Year = {2009}}

Of course, the current one is so much better (and I’m soo modest), but anyway it contains some scientific basis of my current research so that you have a better idea of what’s going on behind the WOT curtains.

Download it here!

I tried to find it online with all the official stuff, but didn’t find anything about it yet, so here’s the .bib if you want to quote it.

@inproceedings{Trifa09c,
Address = {Nara, Japan},
Author = {Vlad Trifa},
Booktitle = {Adjunct Proceedings of the Seventh International Conference on Pervasive Computing},
Month = {May},
Title = {Towards an Open Infrastructure for Fast Prototyping Applications on the Web of Things},
Year = {2009}}

To be clear: we don’t claim to have invented WoT; it’s been here since the Web itself, and tons of projects have already connected objects to the Web. This is cool, but doesn’t reflect our WoT. The core concept of WoT is in the W (remember, Web), and it’s about reusing what’s on the Web not only for documents, but with also to interact with things in the real world. In particular, use as much as possible of the HTTP standard to build applications for devices, instead of relying on middlewares or other proprietary protocols. This is completely different from the pre-WoT projects, where the Web was used only to access Web pages with data from devices. What we propose is use as many functionalities of HTTP as possible to make everything in the world both a Web server and a Web client (some of these functionalities might not even be supported by firefox – although they are part of the HTTP specification).

Spot the difference? It’s very subtle, yet fundamental (okay almost philosophical).

The actual debate of what the WoT really is, stems directly the debate between REST and SOAP based Web Services. The point is not which one is the best, but which one is better to fills your requirements. And in the context of WoT more about end-users, rather than big companies, REST might be a better candidate, and that’s what we’re talking about on this site.

Historically, the first time I saw WoT is in these two presentations of Dave Raggett. For me, these slides are the clearest and first conceptualization of the Web of Things. Around the same time, this tech report by Erik Wilde (who should use his account here to post from time to time is what I could say the seminal and most inspirational source and documentation about the WoT vision. That was straight to the point, and he laid the finger on exactly what the WoT is about. Our work here is merely a continuation and implementation of Erik’s initial vision. However, the term “Web of Things” itself is older and from what I know, the earliest occurrence can be found in Traversat’s paper.

On the other hand, when I see people publishing and marketing things about WoT without even mentioning that paper (or Dave’s slides), means that either they didn’t google “web of things”, or they just try to hide the fact that they didn’t actually come up with the idea. The same is true for people publishing papers today 2009 about WoT, without acknowledging our papers, or worse none of Erik’s or Dave’s – how about googling “web of things” before proclaiming inaccuracies?

The coolest thing yet for me is to see people popping out of nowhere (such as a totally different area), and being self-proclaimed WoT experts. Check this keynote for example (did anyone of you ever hear about this conference by the way?). I’d sincerely love to see WoT hackers and coders and [insert occupation here] popping out throughout the world and join us to make the WoT a reality, but I don’t think powerpoint is really the tool that would help us the most. We need coders, and people who really want to see what’s underneath the surface of HTTP.

For the sad part, is when I hear people talking about “web of things” without actually caring about the Web (as in HTTP) at all. These folks actually mean Web as in Web 2.0 (you know, facebook, twitter, wiki, bla bla blaaaah), but not a single word about the technology and architecture of the Web. It seems that what is important is to put toilets and things on twitter no matter how (this twitter trend is seriously driving me mad btw). Hmmm, okay, if you say so. This is only the tip of the iceberg which is “putting things on the Web”, and not the real problem which is “making things part of the Web”.

Again, a fundamental difference.

What you guys think? Are we just too religious (and almost fetishistic) about that, instead of focusing on more relevant higher level issues? Would love to hear what you think!

But the best of them is the WOT whitepaper, about the general vision. It’s short, a little geeky, but has the vision and motivation in it. In a few words we hope people can a little better understand what the WOT is all about.

We plan to do a few more of those guys, in particular the elevator pitch for business people, and another one like a tech report for total geeks (guess which one we prefer), but for now it’s an initial milestone that should at least help spread our vision.

Send us please your comments, and we’ll hopefully improve it much more in the future version (I feel like it’s still very geeky). Indeed, I think the hardest part of WoT is the communication and the positioning of WoT, i.e. what it is, what is it good for, and how to use it. Help us spread the word and ideas, send it all around the world.

Here the WOT white paper

Update: As Stefano proposed, here is the embeddable version, Thanks!
Web of Things whitepaper v1

People have been asking for more “scientific” and concrete material to be posted on WOT. Hence this post which is about a paper that we got accepted for INSS 2009 here is a summary of what it talks about:

Wireless Sensor Networks (WSNs) have promising industrial applications, since they reduce the gap between traditional enterprise systems and the real world. However, every particular application requires complex integration work, and therefore technical expertise, effort and time which prevents users from creating small tactical, ad-hoc applications using sensor networks. Following the success of Web 2.0 “mashups”, we propose a similar lightweight approach for combining enterprise services (e.g. ERPs) with WSNs. Specifically, we discuss the traditional integration solutions, propose and implement an alternative architecture where sensor nodes are accessible according to the REST principles. With this approach, the nodes become part of a “Web of Things” and interacting with them as well as composing their services with existing ones, becomes almost as easy as browsing the web.

The paper is focusing on comparing (rather qualitatively) WS-* service with a more RESTful approach. It then presents in greater details our “RESTfication” of the Sun SPOTs WSN (Wireless Sensor Network) platform.

For more info, download the paper here!

Bibtex:

@inproceedings{guinard_wot_2009,
address = {Pittsburgh, {USA}},
title = {Towards Physical Mashups in the Web of Things},
booktitle = {Proceedings of {INSS} 2009 {(IEEE} Sixth International Conference on Networked Sensing Systems)},
author = {Dominique Guinard and Vlad Trifa and Thomas Pham and Olivier Liechti},
month = jun,
year = {2009}
}

If you want to know more, just come, and read our MEM paper. I’ll be posting soon what I present there. I can’t wait to be there, and meet all these cool people! Given what I read about the first one, it’s gonna be awesome!

Dom: Just for the records, I have to admit that this paper is clearly amongst my top five for 2009. It’s a paper we can use and cite quite a lot in frame of our web of things projects in order to justify our design choices.

Cesare begins by asking the audience whether WSDL is loosely-coupled? Most people said no which kind of crashed Cesare’s effect (Dom: I guess many people like me pre-read the paper ). Some aspects of WSDL go towards loose-coupling (like the fact that you get language independent) but then it is also not loosely-coupled because for instance there are a million ways to describe operations in a WSDL.

His point is that loose-coupling should be considered as a multifaceted decision where the goal is to find the best-effort solution for your case. Erik goes on talking about the facets they identified such as discovery, identification, binding, platform, interaction, etc. (see the paper for a full list).

Cesare goes on with the first facet: Discovery. Centralized registration is tightly coupled, de-centralized for instance by providing links (Dom: as it is the case for RESTful services) is loosely-coupled. For naming globally unique names are considered to be more loosely-coupled since they do not introduce micro-worlds where names are unique and prevent the need for translation. A platform is loosely coupled if you do not use some abstract and language independent means of describing your functionality. Cesare take the example of using Java only (tightly coupled) vs using WSDL on top of Java (loosely-coupled). Erik talks about models. He says that loose-coupling can be achieved when the model is focusing on what you exchange and on how do you act on it rather than entirely describing the exact semantics of the interchanged data and services.

After describing the facets, Erik and Cesare go on by explaining how they evaluated RESTful HTTP, RPC over HTTP and WS-* / ESB (Enterprise Service Bus). They provide graphs which can be used as a basis to take decision on where to use what technology depending on how important is one facet against another for your own use case. Overall REST wins if all the facets have the same weight for you (Dom: which is unlikely to happen, you should know what’s more important for you!). They explain however that this deeply depends on the particular case.

Erik and Cesare also ask the audience to provide some input on new facets we could think of. I propose considering the “time to first running prototype”, namely the time it takes you to have something running and not too unclean. I also suggest that this could be a nice facet for the world of research where applications need to be designed quickly but still re-usable to some extends. Erik replies that they indeed want to look into more, soft, development-time facets such as ease of development, ease of understanding the system, etc.

Dom:This paper, is a very nice attempt to end the RESTful vs. WS-* (which you could read as X vs. Y) war in terms of loose-coupling since it offers a nice and neutral (although I do know they both like REST very much ) framework to evaluate what technology is best depending on what really matters for you and how much you need your solution to be loosely-coupled. There is no ultimate answer, there are systems you should not use anymore (mainly because they are dead or not supported by any sufficient community, like plain RPC, Remote Procedure Calls) but choosing amongst the still-alive systems is a matter of really evaluating what you need, and this paper can help you towards that goal. In the case of the Web of Things we picked RESTful services but we did this after evaluating the WS-* approach and we also know that in some cases the WS-* approach still makes sense.

Update: the slides of the talk can be found here.

Woralak starts by explaining that they devices to use Excel as a mashup platform exactly for that reason. They consider it as one of the most successful end-user programming environment. It also has a flexible data model and apps can be built incrementally, formula by formula. Having said that she explains why it is also rather challenging. For instance accessing and representing complex data within spreadsheets is not trivial. Cells are meant to contain a single type of data (e.g. integer, one picture) not composites.

She explains how the system is based on a mapping middleware which takes data sources (e.g. mail, company databases) and turns them into services accessible using a data access RESTful API. Quite a nice model which they published at EDBT’08 (Dom: note to myself, read that paper!).

The component model of their mashups is based on three main components. The Data View Components allows accessing data from several internal and external sources. The Presentation Component specifies how the data extracted from a Data View should be mapped to the tabular display of spreadsheets.The Interaction Component synchronizes the data view and the presentation component.

Ideally, users should be able to create these components. However, it is very unlikely since we are not all complete geeks! Thus she explains how they extract a number of mashup patterns (from studying 500 spreadsheets from different domain) which are generic boxes that can be bound to data, sorts of widgets or spreadsheet gadgets.
The first one is the table pattern which is a traditional table with headers and place holders for content. The content pattern is used to display content and the repeater pattern is used to replicates units of content. These patterns and some others were described in a CASE’08 paper. Again, they aim at providing understandable building blocks for mashup builders. Dom: these patterns are what other people from the mashup community name logical building blocks.

She then shows how these patterns can be visually configured, directly in Excel to be bound to data sources. Configured patterns are then saved and could be shared (this is however not yet implemented). Thus, if you need the live Nasdaq in a table pattern you directly find it in the shared repository (provided somebody previously configured it) and could drag and drop it to Excel.

A very nice work which would, I believe (such as our work on physical mashups for real-world services) need some evaluation with real users. This is something we also discussed in frame of MEM 2009, mashup researchers tend to say that things are easy to use but do not really go beyond evaluation by demoing. Let’s change that Having said that I think the Excel approach might well turn out to be, indeed, rather easy to use!

Dominique Guinard presents this paper. (You might wonder how I manage to both present it and blog about it, well this is thanks to Ghislain Fourny who wrote a summary of my talk).
After introducing a couple of smart objects and noticing that the audience is uncool as nobody has a Poken, Dominique asks how we are going to deal with the 1000+ smart objects each person is going to have within the next 5 to 10 years. Communicating with these objects could be made easier with Mash-ups.

The agenda will consist of a discussion of the Web of Things, the introduction of a Web-oriented architecture of the real world, the demonstration of two prototypes one of which is going to crash, and finally real-world Mash-ups.

Architecture:
1. Resource design: each resource is accessed through a URL, e.g., http://webofthings.com/spots/2/sensors/light
2. Representation design: XHTML would be the default, JSON would be better for parsing and XML would be ideal for integration
3. Uniform interface: the HTTP protocol does the job with GET, PUT, DELETE, POST. HTTP headers tell what data is being sent, and HTTP bodies contain the data.

The integration could be done through a smart gateway which discovers the devices, understands their API and exposes them as a RESTful API. Dominique mentions that Nokia is going to introduce a home control center, which will, so he says, fortunately for his work be proprietary. As opposed to the integration with the smart gateway, a direct integration would consist of smart objects having all a RESTful API.

Dominique attempts a demonstration. He turns on a sensor which gets an IP address. Two LEDs indicate that it is on the web. With an AJAX website developed with the Google Web Toolkit, Dominique selects the sensor URL and explores its services, described using JSON.

The goal of the next example is to integrate smart plugs (Ploggs) thanks to the smart gateway. Dominique plugs one of them to his smart phone, the other one to his computer and starts the gateway. Using three rounds of bluetooth, the gateway identifies all phones, well, plugs (as of course everybody in the room kindly turned off their phones upon Dominique’s request). Then Dominique navigates to the gateway URL and notices with surprise that his computer consumes 80W.

In order to compose real-world Mash-ups using these devices and this architecture, it is possible to use Yahoo pipes, Microsoft Popfly, etc. For the example, he uses his own program showing diagrams of the consumption of his devices. After 20 seconds, the data are plotted and Dominique notices that his smart phone only consumes a cool 4W.

Eventually, he introduces a physical Mash-up with an ambient energy meter, which is a Mash-up made of Ploggs, Sun Spots and gateways.

Dominique concludes by considering REST as a suitable approach for small embedded applications, although it would be nice to have asynchronous mechanisms so that they are investigating protocols like XMPP. Mash-up editors would also be nice to have.

The video of the prototype in this presentation is available on: http://www.youtube.com/watch?v=1H49H1pPSBI
The presentation is available below:

Bibtex:

@inproceedings{dguinard:wotMashups:2009,
author = {Dominique Guinard and Vlad Trifa},
title = {Towards the Web of Things: Web Mashups for Embedded Devices},
year = {2009},
month = apr,
booktitle = {Workshop on Mashups, Enterprise Mashups and Lightweight Composition on the Web (MEM 2009), in proceedings of WWW (International World Wide Web Conferences)},
address = {Madrid, Spain}
}

Steffen Haak is providing us with some blueprints for RESTful apps. He starts with a number of principles:
1) Resource oriented architectures -> services should expose data instead of functionality
2) Lightweight composition and flexible binding -> services should be re-composables
3) Mass collaboration, customization and perpetual beta -> ability to share the compositions.

Steffen then explains how these principles were applied against a number of tools (e.g. Yahoo Pipes, etc.) to evaluate them. They identified three types of shortcomings:
1) Integration -> rather hard to integrate third-party services, not already available in the library.
2) Robustness -> most mashup editors do not allow robust composition
3) Collaboration -> the sharing of mashups is often lacking flexibility.

Thus, Steffen proposes using blueprints to solve these three shortcomings. Blueprints are some kinds of design patterns, in the case of mashups these blueprints specify the rough type of composition you want to achieve (tagging and then mapping and then…). According to Steffen these blueprints could then be re-used to build mashups in a more formalized way.
Steffen and his team proposes an approach going toward a specification blueprints, he then shows a prototypical realization of a graphical blueprint planner as well as an adequate architecture design that enables mass collaboration and a policy language. Finally they analyze the performance issues
performance issues that may arise during real-time validation.

A seemingly interesting paper, definitely research-oriented, which I will check to understand the details and invite you to do so as well.

Mobile widgets are very lightweight applications similar to mashups. They offer to use content on the web, just like mashups, but also content from your mobile phone such as data coming from on-board sensors, address books, messages, etc. Unfortunately mobile widgets platforms are rather proprietary and incompatible amongst the vendors. Efforts at the W3C are going towards a standard for mobile widgets which could really help towards more homogeneity.

Alison then talks about the differences between a web app and a widgets. First of all mobile widgets are highly optimized in order to be lightweight enough to run on phones, then mobile widgets do not necessarily need to be online to work. Finally mobile widgets need to be installed and can not just be used online. (Dom: now, what’s the difference between a widget and a mobile app? What’s the connection between widgets and mashups? Aren’t widgets
some kind of mashup building blocks?)

Talking about their experience, Alison presents the Mobile Meetings application which is some sort of net-meeting for your mobile phone which enables you to manage meetings and share data. Remote content access is another widget that enables people to remotely access files on office or home machines.
The Mobile Habitat widget is mashing up several sources of information (desktop data, traffic, maps, meetings and contacts) to help office workers while on the go.

There is no clear definition of what a mashup is. It’s about data processing, reuse, Web 2.0 (especially the do-it-yourself part). Victoria
provides an essay of definition: “Web-based applications that is created by combining and processing on-line third party resources, resources that contribute with data, presentation and functionality”.

She goes on with comparing traditional SOAs and Mashups. Basically, the differences are in the contract, for mashup usually no formal definition (Dom: do you guys agree with that? I don’t entirely, I’d like to see contracts, more flexible contracts such as RESTful APIs but still some kind of common ground in order not to fully rely on screen-scraping) of the combined resources is required mostly because the integration and composition is not always intended.
Also, integration is usually performed at the UI level in mashups whereas it occurs at the logic level for traditional SOAs.

Victoria then goes on with the WHAT, WHERE of mashups. For the WHAT she lists lots of different data such as pictures, text, etc. For the WHERE she talks about server-side composition where the mashup is stored online, on a platform but also about client-side composition where JavaScript is used to “store” the references of the composition.

Talking about challenges she mentions the fact that users are often both contributors and creators of mashups which might lead to inconsistencies,
instability and incorrect data. She also talks about the fact that there is no contract between content providers and consumers which means techniques
such as screen-scraping techniques need to be improved (Dom: I don’t really agree with that I’d rather have providers provide an easy-to-understand
contract such as a web-page that describes their RESTful API, than completely relying on screen-scraping). Furthermore, version control is a real problem,
providers’ APIs are changing on a regular basis which often breaks the existing mashups.

Victoria proposes a guide for a methodological construction of mashups:
1) State the problem domain
2) Identify the existing IT environment
3) Identify the technical requirements
4) Identify the technology sets
5) Think about the maintenance

Finally she talks about tools such as Deri Pipes, an open-source mashup editor which supports RDF, XML, Microformats, JSON and binary streams and can be freely extended (Dom: I’ll definitely look into that tool, any experience with that dear readers?)
And Dapper.net which is a nice commercial use of mashups. Dapper Dapper is s tool that pulls products from advertisers (from several of their data sources) and bring them to the (hopefully ) right customer.

In this first talk of the 2nd International Workshop on Mashups, Enterprise Mashups and Lightweight Composition on the Web at the WWW conference (WWW 2009), Volker Hoyer (a colleague from SAP Research in St-Gallen) talks about patterns to integrate information resources (e.g. an ERP) and generic cloud services (e.g. storage) in the context of enterprise computing.

Enterprise mashups are web resources that combine other web resources that have a business relevance, but unlike traditional compositions mashups can be created by end-users using simple editors. For Volker Enterprise Mashups can be represented in a 3-layers architecture, we first have Resources (e.g. APIs to ERPs, information systems, etc.) these APIs are consumed by Gadgets which are basically visual representations (screens, graphs, maps) and building blocks (piping, flow, aggregates, etc.) consuming the resources’ API. Finally we have the actual mashups which often occur in an online editor
where the gadgets are combined together to create a new ad-hoc application.

Volker explains how resources should also go beyond APIs to enterprise information systems to also include services from the cloud such as storage, asynchronous queues, hosting, etc. In particular in their prototype they use the Amazon Web Services (EC2, S3, SQS, etc.)

As an example they demonstrate a promotion request system where a company A creates requests for promotions that other companies can accept to fulfill. When say company B wants to read the requests from A it can do it by extracting an Atom feed built from a storage cloud service at Amazon fed by company A.

Finally, Volker talks introduces the FAST project which deals with mashups in the enterprise context. Note that FAST is an open project, meaning the sources are available on the web.

You can find the slides here.

Mashlight is a lightweight mashup framework which aims at a software solution providing: flexibility (support for data, logic and presentation), usability (come to an abstraction level that everyone can understand) and fast prototyping.

Their starting point is that mashups are created through the process-like disposition of logic activities. Sam starts by presenting the model they use for their mashup framework. The notion of Mashlight Block is the first being introduced. It represents a functional unit with clear goal, e.g. a map block, a movie search block, etc. Next is the Mashlight Processes, they are basically graph representation of the process. Using them you can go from a Block to another and back. The processes are a rather high level of abstraction, there is no explicit conditional branching or looping. Finally the Advanced Aspects offer special building Blocks to for instance to: aggregate data Blocks, prioritize data assignment, undo operations so that you can go back in the process tree.

Currently the architecture implements a blocks library, a runtime engine and a mashup builder. The team also works on a Block builder which will enable users to create their own Blocks which they can then use in their applications.

Sam goes on with an example called NightPlan which enables people to organize their night out: pick a restaurant and a cinema. The example is composed of three building Blocks, a Google maps Block a PagineGialle (Italian Yellow Pages) Block and a Movie Tickets. We start with the Google map block where you give your location, you go on with the Yellow Page block to which you give the type of restaurant you’re looking for and you end with the Movie Tickets Block which let’s you choose a movie. When running the process the Blocks appear one after the other on the screen. Finally you get a Google map Block which will sum up the whole process and tell you where you have to go through.

Eventually, Sam is talking about supporting mobile devices so that the process could start on a PC and continue on Android or the iPhone.

We’d like to apply this approach to things so that you can for example, make your alarm clock talk to your toaster (e.g. I’m waking up, prepare my toats) without going into FPGA or PLC programming! Thus, we sent a paper at this (according to colleagues) state-of-the-art workshop on mashups.

The paper got accepted and here am I, at WWW 2009 and live blogging the workshop for our beloved visitors and community members. Note that as usual I won’t respect the #1 rule of conference blogging, i.e. I’m going to add my two cents of comments to the posts. Also note that these posts reflect my understanding of the presentations not a literal transcription.

PS: no I’m not THAT lucky to be in Madrid the weather here reminds me of my time living close to Scotland!

I’ve notice that all the people I talk to not really understand what WOT is about, and for this reason we’re working on the WOT manifesto with Dom. I want to position the WM (yes, for WOT manifesto) as a central starting point of our joint action, and I think there are a few important points to clarify to convey our message perfectly. This post is in the continuity of the previous one, but more aimed at WOT in particular.

WOT is not a technology. It is not a standard either. WOT is a vision and a community.

This is maybe the most important aspect of WOT. We tend to radically position our work on a higher level than the current Internet of Things and alike. For us, the Internet of Things is to connect devices together over the Internet. Great! Wow! So what? Why should we care?

Networked objects have never been (and should never be) about just connecting things together. It’s about why we need to connect things, and most people ask us “but why do you guys want to connect your fridge with your toaster, what’s the point? Why would you want to do that?“. I seriously don’t know, and I really don’t care! And if somebody asks me that again, I’ll slap him in the face, I promise! That’s as simple as that. I also have no idea of why would anybody connect a dildo with the RSS feed of the vibration sensor on a volcano in Vanuatu. But I’m sure there’s a lucky girl (or boy) out there who knows! And if she can’t hack it herself, then she’ll never have a volcano-linked dildo, and that’s no good. That’s exactly the kind of people we care about (not the sex freak, but the average Bob or Alice), people who want to connect something to something else! That’s what the Web of Things is all about! People who know just a little bit about of computers and would like to do much more with them to create new things that nobody thought of before without a PhD in computer science. Technology today just sucks because people who build things are too selfish to care about the users, and because of that, in the end most things out there are way to complex to do what they were supposed to. Technology is so not plug & play, and we can change that because the technology to do it is out there and works well enough for my parents (but maybe not for guys playing with the LHC).

I’ve been working with wireless sensor networks (WSN) for over five years 2004, and although I can see today better tools, algorithms, and protocols, these devices area still only made for geeks. Or for the new rich with tons of cash to show off. Seriously, after a decade of active research in this area I think that WSN are have become a product-ready technology sufficiently robust and performant for most non-industrial applications. However, as mentioned in my previous (mis-titled) post, I still want to see something that is made for the end-user. I mean, we have hundreds of different products that could potentially gather data and monitor places and things, but there’s nothing on the market that I can buy, unpack, plug, and use right away. I didn’t try commercial solutions such as Arch Rock‘s or Crossbow’s EKo nodes, but I’m certain that they’re almost impossible to change to build new applications on top of it. And devices made for research (tmote, sunspots, etc.) solutions are either too expensive or too hard to use. Or both.

A few of the toys we’re Web-enabling. TMote sky and Sun SPOTs.

From a technology point of view, I’m sure that the price of a WSN node could drop to less than 20-30$ each. But even so, who would want to learn TinyOS or Contiki to program them? Who wants to implement their own mesh routing algorithms or time synchronization? Nobody does! There are tons of solution for doing that, maybe not perfect but certainly sufficient for monitoring electricity and temperatures in my house. Imagine buy a couple of devices, configure them easily in a Web-based interface (yes visually, not with code), add new modules from the Web (or from apple store). But there aren’t any LEGO-like approach for WSN or embedded devices.

But why is that so?

Look at the Arduino. It’s a slick sexy wonder! Simple, cheap, easy to use and to program, and it just works. WSN people have a lot of lessons to learn from that slap in the face! How come an open-source piece of hardware that didn’t even come out from the higher circles of academic research in the area of embedded devices has become so successful? Simple: anyone can buy one for like 30$ and can code a hello world within minutes. And that is what matters the most today! While technology keeps improving all the time, devices become faster and more powerful, but we humans don’t. If a device today needs 10 minutes to do something today, it’ll take only one minute to do the same in 10 years. And if that something is programmed in 100 lines of code today, well in 10 years, it will require… still 100 lines of code. But if it takes 10 lines of code instead of 100, then we have something. That’s also what the Web of Things is about.

The Arduino. Such a slick and sexy toy!

For me, the field of Ubicomp has become mature enough so that people should stop digging their own graves, look around, climb up of their hole, look around again, and think. What do we see? Thousands of projects in all directions, with basically no overlapping or links between them. A common ground for connecting all these devices together is lacking, right? Does it ring a bell to you? Yes? Do you really think Internet would have worked if every server would have tried to push its own standard? Of course not! And what’s more important? Internet is only the lower part, how data gets transferred from point A to point B. It’s about sending data, be it Morse code over telegraph or smoke signals. But the Internet doesn’t say anything about data that gets transmitted and that’s how it should remain. But on top of TCP/IP comes the application. You’re free to design your own application of course, but why create a new one when you already have something that work just great, and that would get your job done?

No matter which devices I buy, they should understand each other right away, because they all use the same application – and that’s where the Web comes into play. We don’t think the HTTP is the best solution in the world for everything. We just think it’s out there, it’s used by 1.5 billion people, its simple, yet powerful, and its potentials are largely untapped! Most people use only 5-10% of what HTTP is about, and automatically assume “that’s it. we’ve seen the whole think and it sucks. it not good for embedded device”. It’s so wrong, because the people who say so never used HTTP, but only HTML to build their frame-based homepage, filled with animated gifs (you remember, like the very first home page you made in the mid 90′s?!).

Many people think we advocate religiously the Web (and HTTP, or worse HTML) as being the best solution for everything and that we want everything in the world to become a Web page. That’s so not true, especially because we have no links whatsoever with W3C or any other standardization comity. The fact is we are just lazy. We don’t want to reinvent something that already exists just for the sake of it. Our central goal is to reuse as much as we can, and to spend our time to tackle unsolved problems. Recap:

Our aim is to enable developers of applications for embedded devices to spend as few time as possible to program the device, so that people spend most of their time on developing their application and how to combine the data. Developers should never care about the underlying communication or implementation, and certainly not low level data routing and other weird aspects irrelevant to them.

This is another essential point of WOT! JDRTFW (just don’t reinvent the f***g wheel)! There’s so much code out there that we can take, reuse, tinker, and optimize, yet so many people come up with yet another lousy standard or protocol that serves only to connect fridges and TV sets! Guys, just stop that, it’s simply useless. Of course, once in a decade there’s a cool standard that gets invented and adopted and that’s OK. But unless you’re Vint Cerf or Tim Berners-Lee, then maybe you should focus on reuse and improve what’s out there for doing what you want. That’s exactly what we want at WOT! And we propose to use the Web because it’s the most wonderful example of a great, simple, and functional technology in the area of distributed computing. After 20 years of the Web, we now have access to the tools and expertise to build efficient websites that scale to millions of concurrent users. HTTP is a great technology, because it’s simple and was not made for something in particular other than connecting data. Not so much data about fridges or people, but about anything you want. The versatility, openness, and simplicity of HTTP was detrimental to its success, therefore our goal is to learn a lesson from the Web and reuse the same principles that made it success. Then reapply the same principles, and if possible technologies, to connecte not just virtual data but also things in the real world. Many people told us to forget it as that’s will not possible given that the Web was not done for that. Sorry Nostradamus wannabees to disappoint you, but you were wrong and we’re here to prove it. That’s another aspect of WOT, to show that the Web can be very well used to conenct things together. Just like house can twitters, we’re working on putting tons of objects on the Web, and you’ll be able to ping out fridge and subscribe to the RSS feed of my chair so that you know when I stand up and sit down? Why? To feed it your dildo, don’t you get it yet?

Finally, the most important thing maybe about WOT, is the notion of community. We would like thank you all so much for your mails, comments, koudos and support! It’s so great to see the impact we had in just a few months, and so many people responded positively so thank you! At the moment, we’re still thinking about the materialization of the WOT as something beyond a blog and a vision. How can we get you guys involved? How can we build the world of tomorrow all together? We don’t know yet, but we’re working hard on it. We don’t want to build an open source community around a single project, but an intersection where people from all fields interested in networked things can find each other (no dating service if you ask), share their creations, ideas, and feeds, and simply build cool and usable toys for a better world. Oh, if you’d like to join our bloggers team in particular if you want to blog about existing tools, products/projects, please send us a mail.

Maybe WOT could be summarized as follows: “Now we got technologies and protocols to connect things in a sufficiently reliable manner, so how about we stop focusing so much on technology only, and let’s have a look at the big picture. Let’s have a look about how anyone could use these devices simply without being frustrated by technology under the hood. What can people do when we can connect virtually anything together? And how to make it simpler for the average people to build their own mashups of physical objects? How to enable anyone to do anything they want with the electronic devices they buy? These are the important questions we should start considering. Let’s focus mainly on people and let’s see how they behave. Let’s stop thinking only about technology, because in the end it is not what matter. Technology is a tool, and if it’s cumbersome to use, then it sucks.”

We also still have a PhD to finish, so most of the things we’re working on are still lab prototypes and not so much user-oriented, and we don’t intend to create commercial products any time soon. At this moment, we mainly focus on the scientific value of our toys (no, we don’t ship web-enabled dildos), and are testing and analyzing them to prove that, yes, the Web for connecting things works a lot better than anything else out there. Maybe not in terms of performance, but certainly in terms of functionality and flexibility. We even dare to say that we got a bunch of awesome toys and ideas that will rock the world, but we’ll release them slowly (yeah if we give the whole pack to you, you’ll sell them, make money, and not even say thanks to us nor invite us for a champagne on your yacht you bought with our sweat!). Let’s call that marketing. One thing is sure: stay tuned! We’ll soon release little jewels you can take, play, and tune, but also more scientific and tech data so you can also take contribute to the Web of Things, not just toys and prototypes. For now, we just want to make our work more solid, reliable, and more scientifically valid to show to the world that we don’t just talk non-sense, but actually get awesome things done (and they’re freaking awesome, so you’ll for sure soon hear more about them).

In the next weeks, expect a finalized version of the WOT Manifesto both in an elevator pitch form (1-2 pages), and then later this year the “impress-your-girlfriend” version (in like 10 pages with much more tech meat). Pfeew, that was a long post, and congrats for reading it up to here. You deserve a beer! And I’m going to grab one on the that sunny terrace too. Pfewww.