Microformats are subversive: they not only challenge the approach of full-blown Semantic Web approaches, but even question fundamental Web 2.0 building blocks such as Web Feeds and Web APIs.
I recently attended XTech 2006, where there were a few talks related to Microformats.
After summarising these talks, I'll finish with my shocking revelations about the subversive nature of Microformats! ...
Microformats are subversive: they not only challenge the approach of full-blown Semantic Web approaches, but even question fundamental Web 2.0 building blocks such as Web Feeds and Web APIs.
I recently attended XTech 2006, where there were a few talks related to Microformats.
After summarising these talks, I'll finish with my shocking revelations about the subversive nature of Microformats!
Microformats from the Ground Up
Ryan King and Brian Suda from Technorati presented a half-day tutorial.
You can describe social networks, calendars and various other semantic relationships by annotating page elements or embedding small XML structures into your page according to a Microformat spec.
Microformats take Declarative or semantic markup (e.g. in XHTML) to the next logical level. Microformats have been called the 'lower case Semantic Web', because they fill the need for a lightweight set of conventions for data in Web pages that transcends the merely renderable.
HTML has a number of extension points that make this kind of thing easier. For example, the 'rel' and 'rev' attributes on a link (say what type of link it is - maybe a tag); the 'class' attributes (used for CSS but can also carry add-on semantics); the 'profile' element (say what kind of thing the whole document represents).
Microformats examples include rel-tag (for tagging your blog entries in Technorati, etc), hCard (like vCard-on-a-page), hCalendar (like iCalendar-on-a-page), XOXO (outlines) and XFN (social networking). Technorati have an hCalendar subscription service.
However, the one that stood out for me was hAtom, with which you can publish a blog and then let feed readers poll the actual page. They can read the hAtom markup and treat it as an Atom feed.
The Intelligent Design of Microformats
Ryan King also presented a talk on the motivation and style of the Microformats effort.
There is no official standards body defining Microformats, just an "Open Source"-style engineering effort, which follows the following list of Worthy Engineering Principles: "Rough Consensus and Working Code", "Paving the Cowpath", "Keep It Simple and Stupid", "You Ain't Gonna Need It' and "Don't Repeat Yourself".
Microsummaries in Firefox and on the Web
Myk Melez gave a presentation about Microsummaries in the up-coming Firefox releases.
To quote:
Microsummaries are regularly-updated compilations of the most important and timely information on web pages. For example:
- current stock price and movement for a company profile: "GOOG: 406.74 + 0.58"
- latest headline for a news site: "BBC: US dismisses Iran attack claims"
- highest bid and time remaining for an auction item: "Godzilla DVD: $15 / 2 minutes left"
One way to create this information is to link ('rel="microsummary"') from a page to its associated Microsummary document. You can also use XSLT to build the summary on the client. Both approaches struck me as clumsy.
I commented that it would be more Microformat-like to allow embedded markup (just annotate the Microsummary information right in the page; perhaps call it 'hSummary'?).
Myk used the bandwidth and page generation cost argument against that, but good XHTML pages should be very lightweight, and there are various AJAX techniques that can assemble heavier pages.
The current manifestation of the idea is to write this summary on a corresponding bookmark button in the chrome.
Allowing just bookmark buttons seems rather restricted to me. I'd be happy with a whole page in its own tab (or a widget in an Ajax desktop).
A drag-and-drop prototype was also shown, where you visually mark up the parts of the source page you want summarised. I commented that a good extension of that would be dragging across elements to a whole new page, whose construction would be dependent on the information in one or more source pages.
Myk didn't jump up and down with joy at my suggestions, so I guess we'll have to wait before we get Microsummaries written into Web pages that generate more Web pages.
RDFa: The Easy Way to Publish Your Metadata
Of course, the Semantic Web folk have their own Microformat approaches, including this one.
To quote from their paper:
The approach taken by RDFa is that ultimately any RDF structure should be representable. This means that instead of having to 'codify' each format to describe how it must be marked up, we simply provide a set of rules that explain how any RDF can be marked up, and than any RDF 'language' can be used.
The 'a' stands for 'attribute': RDF encoded as attributes in XML.
The example shown was FoaF, whose Microformat competition is
XFN and hCard.
You can use attributes like <link rel="foaf:mbox">,
<span property="foaf:name">, <span property="foaf:phone">
to encode RDF triple information at various points around your
document.
RDFa has some arguable benefits over their competition, but I don't see why both sides shouldn't get along and share ideas. And, indeed, why the other alternatives (structured blogging, embedded RDF) shouldn't all find a place, too. There is a comparison here. Another speaker at XTech, Uche Ogbuji, has also discussed some of these issues.
Web 2.0 Centraal
Microformats not only challenge the Semantic Web, they even challenge such basic Web 2.0 technologies as Web feeds and Web APIs.
Shouldn't we be subscribing to and interacting with semantic Web pages (note the lower case 's'!), not using invisible Web Feeds and Web APIs? Technorati think so: they are leading the way in searching and subscribing to Microformats.
The redundancy of Atom itself (and feeds in general) has been remarked upon before. Further, since we're using REST in the Atom Publishing Protocol, why not use the same protocol to publish directly to an hAtom annotated site? (e.g., just POST a new article to your own blog's main page!) Web 'API's are redundant when our pages are just XML data anyway.
Writing data pages instead of document pages, then allowing those pages to be updated and then subscribed to, is the future of the Web: it's Web 2.0 Centraal.
The new lightweight, Declarative, Microformat-rich XHTML pages we're going to be generating can be polled just as Web feeds are, and events made from their changes. Then re-presented via Ajax in dynamic pages. Such standardised page formats and micro-formats should also accept standardised POSTs where appropriate.
Microformats represent some first steps towards the Data Web replacing the Document Web. Although there has been some thought given to extracting full-blown Semantic Web data from Microformats, there's a significant chance that this bottom-up, simple, minimal, change-aware (i.e., updateable, subscribable) approach may teach the Semantic Web practitioners a thing or two about the Worthy Engineering Principles that enable the social and technical proliferation of a good idea.
Standardising common formats and structures is a precursor to this two-way, dynamic Data Web. Both the bottom-up practitioners of Microformats and the top-down practitioners of the Semantic Web have much to learn from each other on this path.
Declarative Architectures focus on the What, not the How, of programming. The How has dominated the field - perhaps 80% of programming is done in the traditional Imperative style, where we tell the computer How to do a task in explicit steps.
I'd like to show in this blog how Declarative Architectures and technologies are not just an interesting sideshow to the main Imperative attraction, but a complete and powerful programming alternative in their own right - indeed, one which has already dominated certain fields.
Imagine being able to simply express What we want the computer to do - to give it constraints and rules - then let it work out for itself How to achieve our goals.
I believe that saying What, not How, will become the dominant paradigm in programming. ...
Declarative Architectures focus on the What, not the How, of programming. The How has dominated the field - perhaps 80% of programming is done in the traditional Imperative style, where we tell the computer How to do a task in explicit steps.
I'd like to show in this blog how Declarative Architectures and technologies are not just an interesting sideshow to the main Imperative attraction, but a complete and powerful programming alternative in their own right - indeed, one which has already dominated certain fields.
Imagine being able to simply express What we want the computer to do - to give it constraints and rules - then let it work out for itself How to achieve our goals.
I believe that saying What, not How, will become the dominant paradigm in programming.
What?
Declarative Architectures are about data: documents, assertions, truths, rules, tables, structures, state, bits. Data storage, changes, constraints, transformation, sharing, querying, fetching, interaction, presentation, subscription, tagging.
In summary, we talk about stuff, changes to stuff and rules governing stuff. Not processes, actions, jobs or functions.
It's amazing how many interesting Declarative technologies are actually out there already - especially given that most programming is Imperative. They tend to go unnoticed; subservient to their Imperative masters.
Here are some examples from our daily work life (assuming you work in computing!):
What all these have in common is that they are purely data- and event-driven or oriented. Not a thread in sight (if used properly). No method calls. Just querying, fetching, subscribing, tagging, declaring truths and rules, making changes to stuff, etc.
On the 'Net, all the dominant technologies are actually Declarative, not Imperative:
Again, the same things are happening: querying, fetching, subscribing, tagging, declaring truths and rules, making changes to stuff.
Email (SMTP) is a great example of a Declarative Architecture, with its routing and transformation rules and self-addressed store-and-forward transmission. And, in fact, much the same applies to the rest of this list, where the Declarative aspects may include network querying and data events.
Imperative protocols such as RPC, RMI, CORBA, SOAP, etc. haven't had anywhere near the impact of their Declarative cousins.
Now, consider the 'Web 2.0' technologies:
This is a wonderful list of Declarative approaches (as long as we use REST APIs and talk about Resources, not SOAP ones talking about functions and jobs!).
So far, I've mentioned technologies that have attached themselves to the periphery of Imperative programming, where the actual behaviour is still driven procedurally, or How-like.
However, Declarative programming itself has a history at least as long as Imperative programming, and includes:
We can, if we choose, write 100% Declarative systems (even down to asynchronous or event-driven operating systems and hardware).
Wherefore?
In this blog, I'll be pointing out opportunities where we can benefit from the Declarative approach when it's ready.
Perhaps the biggest example of a Declarative Architecture that is ready to benefit us now is the Web. In contrast, the Imperative Service-Oriented Architecture model and so-called 'Web' Services are still weaning; still trying to get a life free of their huge standards consortia. REST, in its simplicity, ubiquity and straightforward usefulness is orders of magnitude more deployed than SOAP will likely ever be.
This blog is for discussing the common problems and solutions in Declarative technologies; seeing if ideas in one area can be used in another and seeing if we can distill their lessons and their approaches.
Ultimately, heading towards a unified, distributed Declarative programming technology landscape.
I hope you'll join me in my explorations into Declarative Architectures, in particular if you're interested in the currently most promising segment I mentioned: Web 2.0, and its application in Social Software.
Or the currently massive but little-mentioned segment: Peer-to-Peer, and its application to the disruption of, well you know, all those big technological and commercial hierarchies...