approach by Web 2.0 poster child 37signals reverses the usual development process (from model to code to user interface) by going "from brainstorm to user interface sketches to HTML to coding." Principles such as, "Don't write a functional specification," or "Essentials only" can help developers stay focused and thus reduce the time-to-launch.
The Resource Description Framework (RDF) supports and accelerates many
code-oriented aspects of Getting Real. For illustration, this article describes how to create dooit, a simple
to-do list manager (a nice type of software that is usually prone to feature creep during the design phase). You can try an online demo and download the source for this application.
Pre-coding Steps and System Setup
The Getting Real process starts by formulating the overall application idea, followed by identifying the core
feature set. In dooit's case, this includes a tool to add, edit, and tick off taggable to-do items. The second step
is to create paper sketches, and after that, static HTML screens are created
(see Figure 1).
Figure 1. From Sketch to Mockup: The paper designs are turned into HTML mockups to get a first impression of the
application's look and feel as soon as possible.|
When you are satisfied with the HTML mockups, you continue by setting up the backend and then start programming.
Instead of a conventional web framework, dooit
was programmed with
which is an RDF-based system. You can download the source code and reproduce the steps described in the following
paragraphs (please see the readme.txt
instructions, you need Apache, PHP, and a MySQL database). The unzipped project file contains four directories,
-specific sub-directories in code/
Why RDF Instead of a Classical Relational Database?
- arc (the core RDF toolkit)
- trice (reusable framework components)
- dooit (the project controller, custom scripts, and templates)
- config (database configuration and path dispatching rules)
- themes (CSS and images)
RDF provides a data model that can represent any piece of information as a graph fragment (i.e., as nodes and
relations between nodes). The handy side-effect of this graph model is that it can freely evolve and changes are
cheap. You simply add relations and nodes, and the RDF system takes care of the storage layer. No need to ponder
over tables and column types, no messing with the database when the schema changes, and no complicated JOIN syntax to
retrieve information any more (querying also takes place at the graph, and not at the storage level).
shows a sample to-do item drawn as an RDF graph.
Every set of two nodes (subject
, in RDF parlance)
connected by a directed relation (the predicate
) forms a so-called
Figure 2. RDF Graph Representation of a To-do Item: The graph consists of five triples. Predicates are
always represented as web identifiers (URIs), the single subject and the ical:Vtodo object
values are URIs, too. The remaining objects are literals.|
Of course, you don't want to draw circles and arrows all the time in order to use RDF. There are several
serialization formats available, for example, the W3C-recommended
RDF/XML syntax, or
RDFa, a syntax to embed graph data in HTML. This article uses
Turtle, a text notation that is easy to read and write, but also machine-readable:
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
@prefix dc: <http://purl.org/dc/elements/1.1/>
@prefix ical: <http://www.w3.org/2002/12/cal/ical#>
<item1#self> rdf:type ical:Vtodo ;
ical:summary "Create sketches" ;
ical:status "done" ;
dc:subject "dooit" ;
dc:subject "work" .
This snippet contains the same information as the graph in
. You can use semicolons in Turtle to repeat a triple
subject. Reusing existing RDF vocabularies such as Dublin Core (dc:
) or iCalendar
) is good practice. Namespaced terms simplify global identification and also prevent
name clashes with other people's models. If you are new to RDF, be careful not to waste too much time scanning
schema repositories such as
Swoogle for matching schemas. It is possible to make up your own ad-hoc vocabulary and align data with the public semantic web at a later stage.
Data first means starting with a real use case,
an actual problem with a clear scope, as opposed to structure first where you try to predict the long-term model
your application might be using one day. Interestingly, RDF supports both approaches. The latter is still dominant in
the semantic web community, often leading to the impression that writing an ontology is the recommended way of getting
started with RDF. I suggest giving Data first a try, especially if you want your application to Get Real as
quick as possible. You may have to scribble the basic triple/graph structure on a paper, but that is usually all that is needed to start. Just think of the first data item and design the input form (on paper and as HTML mockup). When this is done, you need program the code to store data coming from a submitted form, but again, RDF helps us keep things simple.