A URL for Everything: Google's Physical Web

by Aaron Bradley on October 3, 2014

in Search Engines, Semantic Web

A URL for Everything: Google's Physical Web

In a tweet yesterday, Googler Scott Jenson proclaimed that he was finally able to announce his work on "an open web spec to 'Walk up and use anything."

The name of this open standard is the "Physical Web" (with, indeed, its tagline being "Walk up and use anything") and its aim is nothing less than to bring the functionality of the web to smart devices:

The Physical Web is an approach to unleash the core super power of the web: interaction on demand. People should be able to walk up to any smart device: e.g. a vending machine, a poster, a toy, a bus stop, a rental car, and not have to download an app first in order to use it. The user experience of using smart devices should be much like we use links on web, just tap and use.

A URL for everything (every thing)

The way the Physical Web will facilitate this is by the use of URLs. In Google's vision every smart device will have a web address, because a "URL is the fundamental building block of the web, giving remarkable flexibility of expression." More specifically, the "Physical Web is, at its base, a discovery service where URLs are broadcast and any nearby device can receive them."

This takes Tim Berners-Lee's vision of linked data – which has as its first principle "Use URIs as names for things" – to its logical conclusion: use URIs for things.

This also means that apps for smart devices are now in Google's cross-hairs as once "any smart device can have a web address, the entire overhead of an app seems a bit backward."

(Oh, and about "having a web address"? TBL's second rule of linked data is to "Use HTTP URIs so that people can look up those names.")

Ranking the world of things

On the GitHub introductory document Google has this to say about how users will be able to choose between which smart devices to use when a plethora of choices becomes available.

At first, the nearby smart devices will be small but if we're successful, there will be many to choose from and that raises an important UX issue. This is where ranking comes in. Today, we are perfectly happy typing "tennis" into a search engine and getting millions of results back, we trust that the first 10 are the best ones. The same applies here. The phone agent can sort by both signal strength as well as personal preference and history, among many other possible factors. Clearly there is lots of work to be done here. We don't want to minimize this task, but we feel that this simple signal strength ranking can get us very far for the first few versions of this project.

In the technical overview, too, Google makes reference to ranking (under that exact heading) and again references signal strength as an preliminary ranking factor.

As more devices are found, the importance of ranking the devices becomes more valuable. Sorting only be signal strength is a good start but the server could do a much better job in two ways. The first would be to track which URLs are clicked as that implies value, so higher used URLs could be ranked higher. In addition, the server could track personal use so if you tend to pick the same device at work, it would be sure to rank the device higher as well.

My SEO colleagues will be no doubt thrilled (and/or <sarcasm>thrilled</sarcasm>) to learn that rather than simply optimizing for websites, they might soon be optimizing for real-life things.

This is quite unsurprising given Google's concerted drive, encapsulated by their Knowledge Graph, to rely less on keywords in understanding and returning results for queries, and instead understand the entities underlying those queries and referred to in webpages: their "strings to things" thrust. That is, to focus on the real-life things to which URLs make reference. The Physical Web simply takes this one step further by being able to access those real-life things themselves via a URL.

From spammy webpages to spammy things

Imagine a Crappola Cola vending machine masquerading as a Coca-Cola vending machine, or a cab declaring itself to be a #25 city bus. It'll happen, says Google.

With any system, there will be people that try to exploit it. There will likely be many solutions around this problem but again, we can start with the web. Search engines today have this issue and are fairly effective and displaying the correct web sites in your search results. That same approach would apply here. Combine that with historical results of who clicks on what and it's possible to build a fairly robust ranking model and only show the proper devices.

That Google should think of spam right from the outset of the Physical Web project is both unsurprising and important. In my opinion one of the historical shortcomings of approaches to the semantic web (the representation of real-life things on web pages using URIs) is that applications have been developed based on closed data sets that don't perform well when they come up against underhanded marketing techniques (which is one of the reasons why Google and Bing have relied so heavily on respected sources of human-curated information for the Knowledge Graph and Snapshots, respectively). So Google is well-poised to come up with approaches to thing spam (or, à la webspam, should that be thingspam?), and the Physical Web will certainly benefit by recognizing the challenge from the outset, rather than having to loop back to the issue after the fact.

That Google speaks of click metrics in its discussion of approaches to both the ranking of things and dealing with thing spam should come as no surprise to search marketing professionals, although perhaps it highlights that query success factors like click-through-rate from the SERPs don't figure prominently enough in SEO discussions of how Google ranks web resources.

Meta things

What can our smart devices say about themselves in the Physical Web? Apparently, in the beginning, not much, as the devices that will be identified natively lack the potential to express rich metadata, whereas web pages identified by URLs have no such limitations.

The initial list of meta information returned by the client from the URL is, in fact, limited to "TITLE, DESCRIPTION, URL, and FAVICON" (I'm not into yelling – those are Google's CAPS). This, however, Google sees as a temporary challenge rather than as a permanent limitation:

In order to use URLs, the system expects those URLs to point to a web page, which offers up the meta information described above. This somewhat limits the URLs as they much then always point to a valid HTML page. This is likely a big limitation to URLs that want to link to native applications. This is an imporant [sic] use case and needs to be discussed. Is there an alternative way to offer this meta data but not point to a web page?

No answers to that question from yours truly, but it does have me thinking already of schema.org actions in the context of devices (especially given that the server returns "a JSON data structure listing all of the meta information"). You'll already find a ConsumeAction at schema.org: might a DispenseAction to accommodate the capabilities of a vending machine be on the horizon?

1 Takeshi Young October 3, 2014 at 2:15 pm

Do people get their own URLs and favicons as well? Or do we continue using Google+?

2 Aaron Bradley October 3, 2014 at 4:11 pm

Ha … well, I rather doubt we’ll start seeing Google+ URLs for devices.

3 Teodora Petkova December 16, 2014 at 8:24 am

Just wanted to add something I just found and think would suit here, especially the “Crappola Cola vending machine masquerading as a Coca-Cola vending machine” 🙂
Here’s what:
“It is not hard to imagine your Web-enabled microwave oven consulting the frozen-food manufacturer’s Web site for optimal cooking parameters.” This is an excerpt from “The Semantic Web: A new form of Web […]” by Tim Berners-Lee, James Hendler and Ora Lassila

4 Aaron Bradley December 16, 2014 at 9:38 am

Awesome reference Teodora – thanks for sharing!

5 Greg Johnson June 1, 2016 at 7:00 am

Such a good reference, thank you for a wonderful share! Keep the good ones coming.

Previous post:

Next post: