routers, webcams and thermometers
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 “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: 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 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.
4 thoughts on “routers, webcams and thermometers”
I made much the same argument in, erm, 2003. I had a Tivo on the home network with an ethernet card added, and a Web server. It had /proc/therm so I could get the temperature in the room…
www.w3.org/2003/03/06-SW-Arch
[...]
timbl [at white board]
when someone makes up a property and uses it, how do we know what it means?
my view of web architecture, unformalized, but useful
when you have a URI, you look in a registry that points to another spec.
that spec points to the DNS spec which allows you to n IP
you use the HTTP spec to open a TCP connection and send a request based on that URI
you get back a string of bits that have a mime type.
that give you a pointer to the RDF spec.
patrick stickler
[re-expresses question]
timbl
specs says how bits are arranged. rest of this is all context
danbir
you get a triple set and want to see which are core and which are fluff.
timbl
if you understand part of it, that’s ok.
[... lots more dicussion along this line...]
timbl
Roy and my models differ because it’s not tested in the conventional web.
Roy maintains philosophically that foo.rdf could be a car.
That introduces a lot of inconsistancy for me.
red /w yellow stripe
why can’t it be a car (or piece of hardware)
lynn
danbri
you run into the same problem with content negotiation.
why can’t i give the thermometer in my tivo at home a URL.
[...]
@danbri interesting historical details there. Are those actual notes you still have from the meeting? If so, colo(u)r me impressed :-)
Thanks for putting this out there, well said. Converges nicely with Ian Davis and Andy Powell’s posts on this topic.
One point that I think is particularly clear from the view of we in libraries who work with “information resources that are not on the web”, is how tricky that ontological/epistemological/metaphysical/whatever-fancy-word-you-want to use distinction actually is, it doesn’t always make a lot of sense. (Is an eBook an ‘information resource’, but a printed a book a ‘non information resource’ huh?). Something you blogged about first running into with the historical newspapers project.
The way httpRange-14 prioritizes that binary distinction as THE fundamental ontological decision — I think that will seem less and less useful as the internet continues to increase as an intrinsic part of daily life. Not sure that sentance makes any sense, heh.
There ARE some real problems with understanding and being clear about what the subjects of our assertions are — but httpRange-14, in my opinion, does not actually succesfully solve them, at the cost of being a very confusing barrier to putting your open data on the web in a machine friendly way. (This will be laughable to some, but I think the FRBR ontology does a _better_ job of modelling the entities we make assertions about when dealing with information, then httpRange-14 does, with it’s effective ontology of two entities, ‘information resource’ and ‘non-information resource’. With FRBR instead your data can simply declare within itself (rather than as a transient side-effect of it’s transfer protocol) whether it’s subject is a ‘manifestation’ (a particular respresentation), or a ‘work’ (the abstract ‘non-information resource’ that is “my book about aardvarks” whether in ebook, html, or print form).
Pingback: Arguments about HTTP 303 Considered Harmful – Tom Heath’s Displacement Activities