Ghost of Done: How Backbone and RDFa are incompatible, and a Grand Unified Theory thereof.

Posted by Elf Sternberg as Uncategorized

Last night, I was working on a little demonstration project, teaching myself the intricacies of Backbone/CouchDB interaction. I wrote my first CouchDB views and figured out what they’re for, which is a massive step toward world domination and all that. I was working on the retrieval layer, and thinking about the create/update features, when I said to myself, “Hey, Self, can you use that sexy new RDFa stuff to handle the create/update feature?”

I’ve been thinking about this because I have a different project that’s very RDFa-heavy, and the details of implementation have been challenging. But no, I had to come to a different conclusion:

RDFa and Backbone.js are incompatible.

RDF is a framework for self-describing data, such that the data carries along with itself tokenized indicators for how it is to be organized, presented, and edited. The idea is simple: the browser requests a page, the server sends it all: the HTML represents the structured data, the CSS the visual depiction, and the javascript detects the RDFA (the ‘A’ stands for ‘attributes’, HTML attributes) and decorates these islands of content with controls to make the content editable and saveable back to the server.  The data itself is kept in a representative semantic form of (X)HTML trees.

Backbone, in contrast, is a software framework in which the data is represented in a tree-like structure in Javascript itself, in the models and collections. The data does not come down with the page, but is requested after the fact by Backbone.  The HTML is rendered as a side-effect (my Haskell classes are rubbing off on me): it is a representation of the data-state on the client. Backbone works hard under the covers to keep the client and server state in sync, but in all cases the HTML is just a representation of the data; it is not the data itself.  The data itself is kept in Javascript trees.

These are two completely different approaches to managing data on the client. Both are valid. And both have their uses, but for the moment they don’t mesh well.

“If you have an idea and publish it on the internet, it counts as the ghost of done.”

So here’s my ghost:

We need a Backbone-like for RDFa. RDFa cannot easily be coerced into working with Backbone, but let’s face it: there are only a few things we work with on the internet: text and inputs, and lists and trees of text and inputs.

It ought to be possible to formalize a backbone-like collection of Views, Schemas and Rules, such that the transition from presentation to revision is seamless and perhaps not even distinct, and synchronization for a range of RDFa-enabled articles, forms, fieldsets, and the like is automagical. In other works, make Models and Views “know” about their data because it’s already present in the HTML, and not the other way around.  It’s the transition from page-format to server-side format that’s the pain point.

Hmm. This needs more thinking.

10 Responses to Ghost of Done: How Backbone and RDFa are incompatible, and a Grand Unified Theory thereof.


January 25th, 2012 at 12:38 pm

I suspect mapping between Backbone and RDFa might be more complicated than it needs to be, probably easier to address the RDF model underneath the RDFa syntax.

I’m not familiar with Backbone, but looking at an example:

var Meal = Backbone.Model.extend({
defaults: {
“appetizer”: “caesar salad”,
“entree”: “ravioli”,
“dessert”: “cheesecake”

this could be represented in RDF (using Turtle syntax here) as something like:

food:appetizer “caesar salad” .
food:entree “ravioli” .
food:dessert “cheesecake” .

The rdfquery libs (and probably several others) support parsing of RDFa:


January 25th, 2012 at 12:40 pm

aargh, it ate my markup!
imagine angle brackets instead of [] here:

[#default] food:appetizer “caesar salad” .
[#default] food:entree “ravioli” .
[#default] food:dessert “cheesecake” .

Vibrancy in Social Media « The Library of Dresan

January 25th, 2012 at 7:15 pm

[…] this analysis any deeper. Right now this is just a thought posted to the intarwubs – the ghost of done (from the Cult of Done manifesto) since done is the engine of more. More thoughts after I spend […]

Elf Sternberg

January 25th, 2012 at 10:41 pm

Backbone is an MVC engine with HTML as a representational layer, whereas RDFa treats HTML as the data representation directly. I thought more about this and realized that the disconnect isn’t in the model; it’s in the idea of collections. To the extent that RDFa is a graph, it doesn’t represent lists in a direct manner. The Backbone-Relational tool allows Backbone to treat data as a tree, but RDFa (again) has the problem that every entity on the page is a unique one; it doesn’t handle nests very well (that I’m aware of). To tackle these issues, a description of an entity as a modeled object, with lists of child objects, is the primary challenge presented. I don’t know much RDFa, but I know a ton of backbone; it was in tinkering with how to make something in Backbone be RDFa-responsive, to the needs of my client (and that’s key), that I realized this essential incompatibility between a pure MVC approach, and what RDFa is intended to do.

Randall Leeds

January 26th, 2012 at 2:58 am

I’ve been trying to wrap my head around the same technology stack, actually. An interesting thing about Backbone is that it doesn’t actually have a hard DOM or selector dependency. For that reason, Backbone should be able to bind CouchDB documents to Backbone Models on the server-side, rendering the result out through HTML+RDFa templates. The desired effect of rendering self-describing data is achieved. However, it may be possible to perform the inverse transformation.

Could a client-side Backbone application extract the RDF and reflect it back into Backbone? From here the Backbone application works as normal.

It seems like converting with high fidelity between HTML+RDFa and JSON-LD is the key. Is it possible to “reflect” a Backbone application through design document functions in this way? This allows maximal code sharing and being wire-format agnostic. In other words, the CouchDB JSON API could use JSON-LD (enforced via validate_doc_update ?) and the design document APIs of _show/_list/_view/_update would present or consume the RDFa (and form encoded submissions of updates to their content).

Can you explain more why you think Collections are a problem?


January 26th, 2012 at 5:31 am

Did you take a look at the javascript library VIE? (RDFa – Backbone.js bridge – http://viejs.org)
I hope it’ll put a new light to the question.
Also interesting: http://createjs.org, making cms editing decoupled from backend. It’s based on RDFa, Backbone, VIE and Midgard frontend-only components.

Elf Sternberg

January 26th, 2012 at 8:55 am

Szaby: No, I hadn’t seen CreateJS, but that’s a really nifty trick.

Randall: I think Collections are problematic because I don’t see a direct mapping between RDFa’s specification and lists. To take an example, let’s say I have a to-do manager for Extreme Programming, the way PivotalTracker does things: Projects have Features, Features have Implementation Tasks. “Denormalizing until it hurts,” as the the saying goes, and putting the Task list within the HTML representation of the Feature, makes it programatically awkward (not impossible, just awkward and inelegant) to manage the RDFa for both the Feature and each Task.

I think there’s an evolutionary step up the ladder here, to make these two technologies play together. As I said, this will require some thinking.

Making Backbone and RDFa Compatible - semanticweb.com

January 30th, 2012 at 4:01 pm

[…] Sternberg recently proposed a Grand Unifying Theory to make Backbone and RDFa compatible. He writes, “Last night, I was working on a little […]

Making Backbone and RDFa Compatible « Microformats & the semanantic web

January 30th, 2012 at 7:02 pm

[…] Sternberg recently proposed a Grand Unifying Theory to make Backbone and RDFa compatible. He writes, “Last night, I was working on a little […]


February 3rd, 2012 at 7:39 am

@Elf: nice write up!

@Randall: I think, what your are describing in your comment tends into the right direction (and @Szaby’s references as well ;) )

Re. representing sequences/ordered lists in RDF you could utilise an appropriated Semantic Web ontology, such as the Ordered List Ontology (http://purl.org/ontology/olo/core#).
Generally, RDFa is simply a serialisation format for RDF knowledge representations that could be embedded into HTML ;) So, it’s the underlying RDF knowledge representation structure that’s important for the the transformation. As proposed by @Danny, there are several libraries for different programming languages out there that support such parsing tasks.

Comment Form

Subscribe to Feed



January 2012
« Dec   Feb »