mca blog

over the last few months i've been working w/ Leonard Richardson on a book. along the way we've been collecting lots of ideas, assessing how things have worked out over the years, etc.

one of the things that has come up several times -- so much that it will likely be covered in the book -- is the idea that some Web patterns are focused, not on representing the state of things on a server but actually designed to describe the things on a server. this may seem like a subtle, possibly meaningless difference. but as i go through various technologies, guidance, and implementation examples, i think this way of viewing efforts on the Web today (representing vs. describing) is important. and mixing them up can cause you unnecessary pain.

what is happening?

representing the state of things on a server is what most of us assume the Web is all about. "I'll just go to that Web page and see if my order has been shipped." or "Gee, I wonder where that movie I want to see is playing this weekend?" and so forth. we use the Web to see what is happening, what has happened, even with will happen at some future point.

most of the applications built for the Web fall into this same category. we want to "go to a place on the Web" and "get something done" or "start working on something" or "see if that work is completed" and so forth. those of us who work to design and implement applications on the Web spend a good deal of our time translating stuff that happens over time into something that can be expressed in 'resources' that 'client applications' can manipulate in order to achieve the desired results.

the technologies and techniques for this kind of work are very familiar to most of us. HTTP, HTML, and Javascript are at the "front lines" of this tech stack. IIS, Apache Server, ngnix and others are the server-side engines of this work and they, in turn rely on complied components and services that store, manipulate, and calculate data that passes up and down this stack. that is programming for the Web.

what is it about?

there is another view of the Web, too. one that focuses on what the Web "is about" -- what those 'resources' mean and what they can be used for. this is a kind of 'meta Web' that works to describe the very Web we all use when we want to get things done.

this meta Web allows people to ask questions such as "Hey, that movie that's playing at the local theater is about the Crimean War. Are there other sources on that subject I can access on the Web?" or "I just saw that my online order for canned herring is being shipped this week. Where can I go to find out more about the company that processed those pickled herring?" and so forth. the meta Web allows us to link things together in new ways - ways the original authors of some Web content didn't intend when they created their content. the meta Web makes that possible even without requiring co-ordination from these various content authors.

the technologies for creating and maintaining this meta data has been around almost as long as the tech stack for creating the data in the first place. the RDF family of formats ( RDF-XML, RDFa, turtle, etc.) are on the front lines of the meta Web. these are formats that are designed to make it easy to make 'assertions' about other resources on the Web; assertions that can even support a level of reasoning across the Web. there is a long history of formats and services built around this ability to describe what all the Web data "is about"

chocolate and peanut butter?

what has been interesting to me is that i'm seeing a blending of these two worlds (representing vs describing) in new (and sometimes confusing) ways. The JSON-LD and the Linked Data community have their roots firmly planted in the "describing" world. recently, however, i'm seeing evidence of using this "describing" tech to build solutions for the "representing" world. a recent example of this is the Hydra project. here is an attempt to combine the RDF-style data description with the state-driven feature of hypermedia. this is a very interesting project.

oil and water?

but this mixing of the two worlds is not without problems. one case that comes to mind is Drupal's foray into the hypermedia space. last year, they decided to add support for JSON-LD. however, after several months of sprints, the group decided to switch to supporting HAL - a message design rooted in the 'representing' world.

of course, one case does not make a trend. but i suspect more of these cases will crop up over the near term as people work to make their applications and services more fully "Of the Web." stepping into this space w/o full understanding of these two different worlds is likely to cause some pain, frustrate implementations, and bust schedules.

this stuff matters

so, what's that point in all this?

the differences between models designed to represent vs. models designed to describe matter.

as Leonard and i work through the new crop of media type designs and implementation patterns for the Web we're seeing both of these approaches on display. sometimes the model and the use case are in close alignment and sometimes there are notable mismatches between the technology and the intent of the implementors - and that's gonna hurt.