Internet Alchemy

Since there’s a rather nice discussion going on around my weekend post on RMR and MVC I thought I’d dig out the description of MVC from the Gang of Four book to remind us all what we’re actually talking about. Often people forget that the GOF book didn’t include MVC as a design pattern but as a usage scenario that they decomposed into constituent patterns, most notably Observer, Strategy and Composite.

Here’s the relevant section from the book:

The Model/View/Controller (MVC) triad of classes [first described by Krasner and Pope in 1988] is used to build user interfaces in Smalltalk-80. Looking at the design patterns inside MVC should help you see what we mean by the term “pattern.” MVC consists of three kinds of objects. The Model is the application object, the View is its screen presentation, and the Controller defines the way the user interface reacts to user input. Before MVC, user interface designs tended to lump these objects together. MVC decouples them to increase flexibility and reuse.

MVC decouples views and models by establishing a subscribe/notify protocol between them. A view must ensure that its appearance reflects the state of the model. Whenever the model’s data changes, the model notifies views that depend on it. In response, each view gets an opportunity to update itself. This approach lets you attach multiple views to a model to provide different presentations. You can also create new views for a model without rewriting it.

[...reference to diagram elided...]

Taken at face value, this example reflects a design that decouples views from models. But the design is applicable to a more general problem: decoupling objects so that changes to one can affect any number of others without requiring the changed object to know details of the others. This more general design is described by the Observer design pattern.

Another feature of MVC is that views can be nested. For example, a control panel of buttons might be implemented as a complex view containing
nested button views. The user interface for an object inspector can consist of nested views that may be reused in a debugger. MVC supports nested views with the CompositeView class, a subclass of View. CompositeView objects act just like View objects; a composite view can be used wherever a view can be used, but it also contains and manages nested views.

Again, we could think of this as a design that lets us treat a composite view just like we treat one of its components. But the design is applicable to a more general problem, which occurs whenever we want to group objects and treat the group like an individual object. This more general design is described by the Composite design pattern. It lets you create a class hierarchy in which some subclasses define primitive objects (e.g., Button) and other classes define composite objects (CompositeView) that assemble the primitives into more complex objects.

MVC also lets you change the way a view responds to user input without changing its visual presentation. You might want to change the way it responds to the keyboard, for example, or have it use a pop-up menu instead of command keys. MVC encapsulates the response mechanism in a Controller object. There is a class hierarchy of controllers, making it easy to create a new controller as a variation on an existing one.

A view uses an instance of a Controller subclass to implement a particular response strategy; to implement a different strategy, simply replace the instance with a different kind of controller. It’s even possible to change a view’s controller at run-time to let the view change the way it responds to user input. For example, a view can be disabled so that it doesn’t accept input simply by giving it a controller that ignores input events.

The View-Controller relationship is an example of the Strategy design pattern. A Strategy is an object that represents an algorithm. It’s useful when you want to replace the algorithm either statically or dynamically, when you have a lot of variants of the algorithm, or when the algorithm has complex data structures that you want to encapsulate.

MVC uses other design patterns, such as Factory Method to specify the default controller class for a view and Decorator to add scrolling to a view. But the main relationships in MVC are given by the Observer, Composite, and Strategy design patterns.

From this text the two key benefits of MVC are that it allows you to:

• “attach multiple views to a model to provide different presentations” (view/model decoupling)
• “change the way a view responds to user input without changing its visual presentation” (view/controller decoupling)

Unexpectedly (for me, anyway) it says nothing about decoupling models and controllers. Anyway, my observation is that if you need the above flexibility then MVC is your best bet. However, if you don’t need those particular decouplings then you are adopting needless complexity and you’ll be paying for it in the long run.

Darren Geraghty sent me a wonderful design idea for the OpenVocab logo competition. I’ve had two great submissions now.

Stowe Boyd picks up on some very interesting research that suggests that people’s happiness is related to the happiness of their friends, their friends’ friends, and their friends’ friends’ friends. Specifically the report includes this:

we found that each additional happy friend increases a person’s probability of being happy by about 9%. For comparison, having an extra $5,000 in income (in 1984 dollars) increased the probability of being happy by about 2%.

I suspect the converse is true too. People stuck in networks of unhappy people will tend to be unhappier, which inevitably leads to their friends being slightly unhappier in return. I’ve seen this effect in organisations where people who are unhappy with their workplace tend to band together to share their unhappy experiences. When this group is in the majority then they may have the chance to change the organisation’s behaviour. However when they are in the minority, implying that the majority of the organisation are happy, then it becomes a difficult environment for them which increases their unhappiness, a spiral of despair that can bring the whole group down. That can be very damaging to the individuals, their otherwise happier peers and to the organisation itself. I wonder if this research indicates that these spirals can be unwound by the happy network reaching out to the unhappy one?

Via Ryan Tomayko’s great article on gateway caches I found this neat webapp that generates UML sequence diagrams. Very handy and a clever implementation. It even has an API for integration into other tools

Last year I wrote a short post titled MVC Obscures the Mechanics of the Web that drew together some other peoples writings on why MVC is poorly matched to the web. I didn’t give an alternative though, apart from indirectly in the comments. Now Paul James has written a succinct description of that alternative and christened it RMR - Resource Method Representation.

In RMR (which is simply REST as seen on the Web) the user interacts with resources using representations via restricted set of methods. As Paul explains, typically this is implemented as a set of classes representing the resources, a set of Response classes and some kind of routing to tie it all together. This is how frameworks like Tonic (written by Paul) and Konstrukt work. It’s also how my RDF framework Paget works, although that is very immature at the moment and doesn’t cover responses very well.

Here’s to banishing MVC from the web

Via Scott Berkun I found these two gems: a visualisation of the first 100 days in office of select US presidents and a report on just how much of a smokescreen current aviation security policy really is. I ended up on Scott’s blog originally to read The data death spiral which I also recommend.

Well, that was quick! Benjamin Nowack has already created a candidate for the OpenVocab logo and what a good one it is!

Thanks Benji

I added some visualisations of some of the relationships between properties and classes in OpenVocab:

• Relations - shows the relationships between classes and properties using domain and range.
• Sub-classes - shows the class hierarchies present in the vocabulary
• Sub-properties - shows the property hierarchies

OpenVocab is a project I have been working on in my spare time since spring. The recent VoCampsin Oxford and Galway gave me the opportunity to focus on getting it public and usable. The idea behind it is quite simple: it’s a collaborative space for building an RDF schema. It provides a simple editing interface for classes and properties plus some wiki-like characteristics that hopefully will allow many people to participate.

Often I find that people have ideas for a couple of useful properties or classes but they don’t want to go to the trouble of deciding on URIs, writing the schema, fixing problems and committing to making it available for the long term. They have better things to do. The goal of OpenVocab is to remove those barriers and make it incredibly simple to turn an idea into reality. I set up vocab.org a few years back to help with the problem of persisting schemas in a stable fashion for long periods. OpenVocab adds the other parts of the equation: naming, authoring and maintenance.

Importantly all the data and the content submitted to OpenVocab is in the public domain, free and unencumbered by any restrictions. The code that runs the site is open source as are all of its dependencies and libraries. I want this project to persist beyond a single person or organisation.

The Mechanics

All the vocabulary terms share a common URI prefix: http://open.vocab.org/terms/

The term URIs are set up to perform 303 redirects to a document describing the term. That redirection uses the HTTP Accept header to pick a suitable format. For example, visiting http://open.vocab.org/terms/favouriteDrink with a web browser will normally redirect to the HTML description http://open.vocab.org/terms/favouriteDrink.html. An RDF crawler or explorer will be sent to the RDF version http://open.vocab.org/terms/favouriteDrink.rdf. There are also turtle and JSON/RDF versions.

A full list of all the terms in the vocabulary can be obtained from http://open.vocab.org/terms which also uses content negotiation to pick a suitable format. The HTML version lists all the properties and classes in a simple alphabetical summary. The RDF version includes full descriptions of every term and of the vocabulary itself.

I enforce some strict naming conventions on term URIs, mainly because I like to have them be consistent. For example, terms are constrained to be alphanumeric plus hyphens. Properties start with a lower case first letter, classes with an upper case one. These are just generally accepted RDF conventions but there’s no technical justification for them, just my aesthetic.

I’m also recommending that labels be written in the role noun style. I encourage this by including a little bit of Javascript that dynamically plugs the label being typed into sample sentences to get the context of use right. For example property labels get plugged into sentences like “foo is “author” of thing” and “thing has “author” foo”. I’m also encouraging the additional of plural labels and using the same kind of hints: “the “authors” of thing are foo and bar” or “foo and bar are “authors” of foo”. There’s obviously no validation on the values of these labels (I certainly don’t want to write the code that checks that grammar) but providing hints like these could help keep the labelling of terms in the schema consistent. Once again this this an aesthetic choice, but all software should be opinionated.

OpenVocab supports a smattering of RDFS and OWL to help relate properties and classes to one another as well as to define their semantics. The subset of OWL supported is roughly what many people are calling RDFS++ or OWL Mini

Behind The Scenes

OpenVocab is written in PHP and uses my moriarty library and Benjamin Nowack’s ARC RDF library. The schema data is stored in a Talis Platform store (http://api.talis.com/stores/openvocab) which means it’s searchable and SPARQLable. Currently it uses the Konstrukt PHP framework to handle all the webby stuff but I plan to port it to my paget framework. All the code for OpenVocab is open source and available from Google code. I plan to write a more detailed account of how it works over on the n² blog.

Future Plans

I’m working on some visualisations of the vocabulary. Some of these experiments are in the Google code subversion repository but I’m still exploring ideas. I want to be able to see the relationships between classes and properties like an entity relationship diagram and view class and property hierarchies.

My next big plan is to add OpenID support. I’m in two minds whether to force the use of OpenID before allowing edits or retain anonymous editing. Suggestions and comments welcome on this issue.

At the moment every term created in OpenVocab is deemed to be “unstable”, i.e. it is subject to change at any time by any person using the site. Clearly that makes it difficult to build applications that depend on the meanings of the terms even if you subscribe to a Wittgenstein view of the world where meaning is use. My plan is to introduce a way for terms to migrate to being stable. One idea is that once a term has survived for 6 months without any edits to its semantics then it could change status to “testing”. Editing a term with this status would be more difficult and would reset the status back to “unstable”. If a term survives the “testing” phase for 12 months then it could move to a “stable” status where it would be locked down and become extremely difficult to change. That’s just one possible sequence and I’m looking for some suggestions here.

I have ideas for many minor additions too such as RSS feeds of the list of recent changes and just of new terms added. It would be nice when you enter the URI of a non-existent term if you were presented with a page prompting you to create it rather than a 404. I have more ideas around better usability and prompting to reduce all that typing of URIs. These are all the sort of things that I’ll probably do as late night wind-downs.

I also think there’s no reason why the codebase couldn’t be modified to manage multiple vocabularies. Currently it assumes a single global vocabulary but this could be switchable based on the URI used to access the site. If options were added to restrict edits to logged in users then the codebase could become a general purpose schema editing tool, one that has the advantage of keeping its data natively in RDF.

Competition!

Finally, OpenVocab needs a logo. I exhausted my limited artistic talent a few years ago so I’m looking for help here. There must be someone out there who could create a nice logo for the website, something that would work in the top-left area of the header and as a favicon. Email me your ideas at nospam@iandavis.com and I’ll publish them on the OpenVocab site and work out some way for the community to vote on one.

If you have any suggestions or want to get involved in this project then leave a comment here, email me or post a message to the RDF Schema Dev mailing list.

Another new innovation from Google. They are so far ahead in the search game and every innovation basically accelerates them away from MS and Yahoo even faster. I’d characterise SearchWiki as a blending/blurring of search and bookmarking. They need to unify it with Google Bookmarks, Search History and Notebook which will probably happen over the coming 12 months. The outcome is the going to be a searchable bookmarking and annotation system backed by Google’s index of the web so you always find something and often it’s the best possible. An amazing display of personalisation at the largest scale.