My Dog Recently Became a Thing in the Internet of Things

If you read into the enterprise perspective or academic perspective of the internet of things, it is often argued that there are three major visions of the Internet of Things. One such source of this argument is in a whitepaper, The Internet of Things: A Survey From the Data-Centric Perspective, which was co-opted by individuals from IBM, UC Irvine, and Wright State University. I tend to agree with their statement that the IoT can be broken into the following visions: 1. a things-oriented vision, 2. an internet-oriented vision, and 3. a semantic-oriented vision.

The things-oriented vision refers to the area of this paradigm in which RFID tagging allows objects in space to be trackable with a unique identifier. Just think coffee cup, painting on the wall, dog. A person could be part of this if that person were dead, but when they’re alive, they tend to interact with things and sensors, which, in IoT, we call “social sensing”. A dog however, can’t talk, so I would argue that they are more of a passive thing than an active thing when it comes to social sensing, but let’s just say she’s somewhere in between the two. The RFID perspective of IoT is often what people think of when they hear the term “the internet of things” — it is only partially true. There is much more going on beyond the typical buzz words you will read in tech blogs. For all intents and purposes, I’ll refer to things in this category as passive things.

The internet-oriented vision corresponds to the ability to turn objects into smart objects by virtue of making them internet connected. This is different than the RFID approach in that RFID tags typically come as passive electronic hardware and are powered by the RFID reader, which causes a lot of issues in data clarity and reliability. The active electronics can be internet connected and thus have the ability to push information out into the web. A smart phone, for example, would fit this category. Also, note that a smart phone is powered by a battery that is connected to the device, which a human is responsible for recharging, usually. Taking this approach with objects that do not interact with humans requires some special infrastructure to make them maintainable, such as a power grid, wifi, etc. Also, these things tend to communicate via APIs over HTTP.

The semantic-oriented vision is more a matter of data management. Sensor data typically comes in a form that is somewhat meaningless to the big picture. What I mean by that is applications and devices that produce data are no good unless deeper meaning or knowledge can be extracted from them. A good example was posted in a thread on the W3C’s public email group The Public Web of Things, in which a participant wrote, “[Assume you have the following sensor data], ‘sensor_data: {temperature: 38}’. Is this hot or cold? :-) ” The point being that this number has significantly different meanings depending on the region in which you live, or what unit of measure we’re using (Ferenheit, Celcius, Kelvin, etc). So, there is great value in being able to apply a bit of connected conceptual knowledge to this number to give it better context, and thus more meaning.

A property of semantic data, aka Linked Data, aka RDF data, is that it uses URIs as unique identifiers. Properties can be strings, and the tree of data would stop there, but otherwise, using another URI as the value to another URI declaration will define a relationship between two concepts. This relationship-based data format is designed to associate properties, functionalities, and relationships to a unique data entity works beautifully to solve the problems of data meaning in the web of things.

Now that I’ve described what the typical definitions of the IoT are, lets go back to the really interesting topic at hand: my dog.

Nowadays, its a common practice to take your dog to the vet to get a “chip” implanted just beneath their skin so that way if they are found straying through the neighborhood or are in a questionable situation or are found without a tag, they can be identified by simply waving a reader device within a couple meters of the dog, give or take, et voila! we know the dog’s identity. After talking with the veterinarian about this, I was told that the “chip” is a simple RFID chip. Which, interestingly, is the focus of the “things-oriented vision”, and also that means that my cute little puppy can be considered a passive thing. This is really cool, because whether she knows it or not, there is a unique identifier associated with her that is hers and hers only. If the dog chippers we so inclined, they could apply semantic web principles to this RFID tagging data and give each dog a unique URI, rather than simply a unique integer. By doing that, they could relate this dog entity with the concept of a dog in general.

But why would that be cool? Well, semantic data is all about conceptual relationships. Dog is an animal. Animals are living things. Dogs have certain things they do like bark, go potty, and dig. Also, dogs have breeds, and breeds have unique properties like weight, temperaments, colors, unique physical characteristics, and more. So, by applying a bit of elbow grease and giving my cute little puppy a URI as a uid, we could easily toss her and all of her friends into a semantic database and then start doing queries against her and dogs in general to gain higher level knowledge about her.

“How many times should a golden doodle be going pee per day at the age of 8 weeks?”, “how long until the puppy loses her baby teeth?”, “how will a golden retriever react to bringing new people over to visit?”. These are questions that you’d typically have to use Google to fish for answers for, and the answer would be buried deep in some Joe’s blog article. But now, with the help of conceptual data, aka the Semantic Web applied to the Internet of Things, we will be able to generate beautifully concise knowledge and meaning from the people, things, plants, objects — whatever — that are around us.

To tell you the truth, I really like that vision of the future.

 

Place Your Bets on the HTTP PATCH Method

Partial updates are somewhat problematic in the world of RESTful applications. Currently, we use POST and PUT to write data or update it, but on sub-properties of data updates, it actually can get somewhat hard to code for when you get into the more subtle application logic and error management, let alone on datasets that are very large or have very deeply nested data structures in a single JSON object, for example.

But, regardless, PUT and POST have done a satisfactory job up until now, and nobody really needs to use PATCH in a relational context. But therein lies an interesting point: data is getting bigger, and naturally, semantic data is starting to become much more prevalent, and its URI-based. It logically follows that if data continues to become more semantic, and you’re dealing more often in deeply nested structures, you’ll need a URI-based updating method that can be more flexible than PUT and POST.  But you don’t have to take my word for it, lets ask an expert.

Continue reading

The Nike FuelBand Made Me Fat… Sortof.

As a software guy, I believe it, and as a user experience guy, I guarantee it: data entry is the biggest problem in the software world.

A lot of applications are bidirectional in the sense that I use the application for something, and the application uses me for something. I want gratification, or information, or help with something, and it wants information. So why is it that we’re still using forms for everything? Well, in the not-so-distant past, we started getting introduced to the concept of devices and human interaction working harmoniously to produce wildly fluid experiences, as well as giving the user the ability to give instant feedback and information without them having to type things. Of course, this isn’t always the case, but we’ve gotten a taste of that design philosophy, and its really nice.

Fast forward a few years and we started seeing wearables creep into the tech market. Wearable technology often makes use of accelerometers and other hardware to record data passively while you function in the world. The activities include exercise, sleeping, monitoring your vitals, walking, and things like that. This is revolutionary stuff not just because of the hardware being able to do amazing things, but rather it provides a way for people to record specific data about things and upload them into applications without having to type anything. Eventually, they’ll be including miniature wifi-access-points, computer vision, and other amazing technologies. By combining these technologies into physical devices, it gives you, the human, the ability to skip over the cumbersome step of manual data entry.

Continue reading

Google is Torching Keywords, Finally

So, if you’re part of the SEO community, you’ve probably heard the news that Google recently decided to go from sometimes-encrypted search to always-encrypted search. If you use Google Analytics to track the performance of your website out there on the web, then you’ve probably noticed that often the top recorded search terms that brought visitors to your website showed a value of “(not set)”. This value corresponds to visitors that were using the then-sometimes-encrypted search. Now, technically, everyone predicts that this will be the only keyword information we’ll see for inbound search traffic.

This scares SEO companies because typically their business model has been heavily based around the notion that websites need to be optimized for certain keywords, which will then result in people seeing your website when they search for those exact terms. “If we can’t sell that service, then is the death of SEO?” they ask. The answer is no. But before I explain why SEO is not dead, let me explain why Google doesn’t mind getting rid of keyword optimization.

Continue reading

Embrace Code Standards & Business Process, and Reap the Rewards

When I talk to someone who belongs to or runs a development team, I often hear reoccurring themes in their criticisms of their existing setup or business flow. I frequently hear things like, “Our management wants XYZ to be written and delivered by this date, and that’s totally unrealistic!”, “We were stressing out last week because we found a really critical bug in production”, or “Our server did XYZ the other day, which caused downtime”, and much more.

What’s interesting about this is that, while they’re not uncommon problems, they also have pretty common solutions, and also suffer from a very common set of barriers to fixing them: they’re too deep in some technology, their team is too used to doing some other process, the code was architected in a funny way, and now there is too much legacy code to do it differently without restructuring everything.

I’m not saying that those problems aren’t valid — In fact, they’re really difficult to fix. But, if you find yourself in a position in which your application is not very old, there isn’t too much code, and your team isn’t that big yet, I guarantee that you can make your life easier in the future by doing the following three things.

Continue reading

Bypassing iFrame Restrictions to Make Rich Multi-Site Applications

There are web applications out there on the interwebs that are designed to take a website’s url, load the page, and then dress that page up with additional functionality. When trying to develop one of these on your own, you will quickly learn that there are several ways of displaying a page within another page, but only two of them are really popular: 1. displaying the page in an iFrame, and 2. rendering the contents of that page as markup in an html5 canvas.

Both methods are troublesome at first due to the fact that its hard to get the markup without having access to it from the parent DOM. So the most popular solution is to build a proxy to take in the data and return it to you before displaying. Let’s dig deeper into the idea of proxying data.

Continue reading

Is RMR the new MVC?

Sounds rich, doesn’t it?

I did a quick google search for RMR after reading an article about it. I realized that the real premise of RMR over MVC is that if you’re serving up remote webservices, like a RESTful service for example, there is really no good reason to maintain a view layer. Any output in a true webserver is going to be, at most, a matter of mime type and language of the output (i.e. to be able to output as xml or json at will), but not layout or templating, etc.

So, ya, OK. RMR.

Here’s a link to the article about Resource-Method-Representation

In Search of Rodriguez

I recently had a conversation with my father about our favorite Netflix documentaries, and Searching For Sugarman came up. He explained that the film had won an academy award, for good reason, and was unfortunately not available for viewing on Netflix.

Soon after, he lent me access to his Amazon Prime account so I could watch it. So we sat down and watched it. Needless to say, immediately upon finishing the film, I found myself experiencing a kaleidoscope of feelings about what I had just seen.

Continue reading

The Grand Repurpose

I was once told by one of my college professors, who coincidently had a PHD in Organic Chemistry from Harvard, that most of innovation and discovery is a matter of using something you already have to do things that it wasn’t meant to do. While there are a lot of examples of pure innovation and discovery that don’t necessarily follow that narrative, I do see what he means, and I tend to agree with him.

Continue reading