You don’t have to look far to see how Responsive Web Design has transformed the web from a network of immutable layouts to documents that mold to fit the user’s given screen size. With some clever CSS tricks, a single document can become an organism that fills the dimensions of a user’s device to provide an optimal experience.

But, as is often the case with this sort of thing, the landscape is quickly becoming more complicated. The types of screens being targeted by developers has grown beyond the typical dimensions of the phone, tablet, and desktop. Even within those parameters, the variances have grown unwieldy.

It’s going to get much worse. Photo by Brad Frost, CC BY 2.0

This is just the current day landscape — What of devices of the near future? Or changing behaviors, such as the rise of the 10 foot user interface as our TVs spend more time on the internet? The ways we will be able to view the web can go from very small (the smart watch) to the fully immersive (the VR headset). Hell, the web shouldn’t even have to be viewed — It should be able to be queried by voice with the Siris of the future. This hypothetical web doesn’t — and shouldn’t— behave on these devices the same way it does on your desktop, or even your phone.

As devices diversify, responsive design is fast becoming less of an efficient means of delivering content for every interface. Even when done very well, it’s really just a series of hacks — and we are already feeling its limitations. As the edict goes, “Content is King”, and yet so much of a website that is not content is getting in the way of delivering the message. In these new and evolving cases, everything but the content should be stripped away when a device requests a web site, delivered in a software-friendly, structured format that the UI of the device itself is left to display in the best way possible.

A Common Language

Developers use APIs all the time to integrate third party services into their own sites and applications. Usually, each API is developed from scratch with its own semantics tailored around the nouns and verbs particular to that system. If every website – Every blog, every online store, every discussion forum – Had its own, standardized API, they in turn could easily be integrated elsewhere in the web and in environments unknown.

With a common API between websites, web browsers in divergent interfaces can render the experience in a way best suited for the interface in question. In this world, the onus of presenting content in the best way goes from generalist designers to experts in the particular medium. A VR user might call up a game tutorial in the midst of a battle and have the content overlaid on top of their game. Or a smart watch user might bring up a blog post and have the output automatically formatted to their small screen, with all the standard layout cruft filtered out.

Not the right way to browse the web in VR. Image courtesy FaceRift.

The trouble here, of course, is the standardization. How do we represent web content, in all its many varieties, in a finite way that is queried easily enough by any system that wishes to? How do we organize all that is on the web in such a way that it can easily be accessed in a common protocol by any developer that knows the standard? The answer to this has been around (conceptually) for almost as long as the web has and has been waiting in the wings for a moment just like this.

The Semantic Web

Not many years after he helped invent the web, Tim Berners-Lee coined the phrase “Semantic Web” to describe a network of linked data evolving out of the human-centric web. Simply put, the Semantic Web puts a layer of descriptive metadata over the content of the existing web so that machines can extract and relate meaning between documents. This structured content can be linked to other structured content in the web (hence its other monicker, linked data), creating what amounts to a massive graph database that can be conceptually understood by machines.

When software can understand what the contents of a web page are, we can build systems to more accurately search them, and explore relations between concepts. A global database of linked data allows for futuristic concepts such as artificial intelligence agents that are able to parse questions and provide useful answers by traversing the web of data, making inferences and gleaning insight in ways that humans can’t.

The metadata of the Semantic Web takes form in the shape of an ontology (e.g. schema.org)– an overarching framework of descriptive terms and a syntax that can (ideally) describe all possible content on a page. This ontology, if well-formed, is essentially an API for extracting meaning from a document and connecting it with others.

“The Web as I envisaged it, we have not seen it yet. The future is still so much bigger than the past.” — Tim Berners Lee

Despite its advantages the dream of the Semantic Web has never been realized. It seems to be stuck in academic limbo, with progress only coming in the form of belabored standardization process and new standards to compete with old ones. Commercial projects are minimal, and though they exist (e.g. the New York Times), they have failed to gain any traction. The utopian initiatives of the semantic web have yet to find the killer app to bring it into the mainstream.

At the same time there are technical reasons that are really holding back greater adoption of the Semantic Web. For one – Most technical solutions are a form of XML. Ask most developers and they will tell you that XML is the devil’s data format. Fortunately, with the recent advent of JSON-LD, developers who want to make their data semantic will have a much easier time.

Secondly, for the Semantic Web to succeed, the web has to be semantic. This requirement, while obvious, has not yet been achieved simply because of a lack of good tools that help people mark up their documents semantically. Semantic markup should be a side-effect of using a good Content Management System. Even if people don’t care if their data is semantically structured, this should be a fringe benefit of any CMS.