If you have a local wi-fi network at home you probably use something like this Linksys wireless router on the left, to let your laptop and other devices connect to the Internet. When you bought it and plugged it in you probably followed the instructions and typed “http://192.168.1.1/” into your web browser and visited a page to configure the router: settings its name, admin password, etc.

Would you agree that this router sitting on top of your TV, or wherever it is, is a real world thing? It’s not some abstract concept of a router: you can pick it up, turn it off and on, take it apart and try to put it back together again. And the router is identified with a URL: http://192.168.1.1. When your web browser resolves the URL for your router it gets back some HTML, that lets you see the router’s current state, and make modifications to it. You don’t get the router itself. That would be silly right?

In terms of REST, the router is a Resource that has a URL Identifier, which when resolved returns an HTML Representation of the Resource. But you don’t really have to think about it much at all, because it’s intuitively part of how you use the web every day.

In fact the Internet is strewn with online devices that have embedded web servers in them. A 5 year old BoingBoing article More Googleable Unsecured Webcams shows how you can drop a web search for inurl:“view/index.shtml” into Google, and get back thousands of webcams from around the world. You can zoom and pan these cameras using your web browser. These are URLs for real world cameras. When you put the URL in your browser you don’t get the camera itself, that’s crazy talk; instead you get some HTML describing the camera’s current state, and some form controls for changing its position. Again all is well in the REST world, where the camera is the Resource identified with a URL, and your browser receives a Representation of the Resource.

If you are an Arduino hacker you might follow some instructions to build an online thermometer. You wire up the temperature sensor, and configure the Arduino to listen for HTTP requests at a particular IP address. You can then visit a URL in your web browser, and the server returns a Representation of the current temperature. It doesn’t return the Arduino board, the thermometer, or the thermodynamic state of its environment…that’s crazy talk. It returns a Representation of the temperature.

So imagine I want to give myself a URL, say http://inkdroid.org. Is this so different than the camera, the router and the thermometer? Sure, I don’t have a web server embedded in me. But even if I did nobody would expect it to return me would they? Just as in the other cases, people would expect a Representation of me to be returned. Heck, there are millions of OpenID URLs deployed for people already. But this argument is used time, and time again in the Semantic Web, Linked Data community to justify the need for elaborate, byzantine, hard to explain HTTP behavior when making RDF descriptions of real world things available. The pattern has been best described in the Cool URIs for the Semantic Web W3C Note. I understand it. But if you’ve ever had to explain it to a web developer not already brainwashed^w familar with the pattern you will understand that it is hard to explain convincingly. It’s even harder to implement correctly, since you are constantly asking yourself nonsensical questions like: “is this a Information Resource” when you are building your application.

I was pleased to see Ian Davis’ recent well articulated posts about whether the complicated HTTP behavior is essential for deploying Linked Data. I know I am biased because I was introduced to much of the Semantic Web and Linked Data world when Ian Davis and Sam Tunnicliffe visited the Library of Congress three years ago. I agree with Ian’s position: the current situation with the 303 redirect is potentially wasteful, error prone and bordering on the absurd…and the Linked Data community could do a lot to make it easier to deploy Linked Data. At its core, Ian’s advice in Guide to Publishing Linked Data Without Redirects does a nice job of making Linked Data publishing seem familiar to folks who have used HTTP’s content-negotiation features to enable internationalization, or building RESTful web services. A URL for a resource that has a more constrained set of representations, allows for Agent Driven Negotiation in situations where custom tuning the Accept header in the client isn’t convenient and practical. Providing a pattern for linking these resources together with something like wrds:describedby and/or the describedby relation that’s now available in RFC 5988 is helpful for people building REST APIs and Linked Data applications.

At the end of the day, it would be useful if the W3C could de-emphasize httpRange-14, simplify the Architecture of the World Wide Web (by removing the notion of Information Resources), and pave the cowpaths we already are seeing for Real World Objects on the Web. It would be great to have a W3C document that guided people on how to put URIs for things on the web, that fit with how people are already doing it, and made intuitive sense. We’re already used to things like our routers, cameras and thermometers being on the web, and my guess is we’re going to see much, much more of it in the coming years. I don’t think a move like this would invalidate documents like Cool URIs for the Semantic Web, or make the existing Linked Data that is out there somehow wrong. It would simply lower the bar for people who want to publish Linked Data, who don’t necessarily want to go through the process of using URIs to distinguish non-Information Resources from Information Resources.

If the W3C doesn’t have the stomach for it, I imagine we will see the IETF lead the way, or for innovation to happen elsewhere as with HTML5.