Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

"Getting Real" with RDF and SPARQL

"Getting Real" is an agile approach to web application development. This article explains how it can be successfully combined with the flexibility of semantic web technologies.


advertisement
he "Getting Real" 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 Trice, 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 in dooit.zip for setup instructions, you need Apache, PHP, and a MySQL database). The unzipped project file contains four directories, with dooit-specific sub-directories in code/ and themes/:
  • cache (should be write-enabled, used for CSS and JavaScript documents)
  • code
    • 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)
Why RDF Instead of a Classical Relational Database?
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). Figure 2 shows a sample to-do item drawn as an RDF graph. Every set of two nodes (subject and object, in RDF parlance) connected by a directed relation (the predicate) forms a so-called triple.

 
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:

@base <http://semsol.org/dooit/item/> @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 Figure 2. You can use semicolons in Turtle to repeat a triple subject. Reusing existing RDF vocabularies such as Dublin Core (dc:) or iCalendar (ical:) 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
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.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap