I have seen the word hRelease bandied about quite a bit lately as being synonymous with the Social Media Release. I’m happy to see all of the discussion around new release formats and new approaches to the distribution of news. However, I think it’s important to really understand what hRelease is, and also what it is not. I hope that we will also come to an agreement that hRelease and the Social Media Release are not one-and-the-same.

hRelease is a proposed data format. To my knowledge, there isn’t a formal specification for hRelease yet, but I think we have a general idea what the format will look like when it’s completed. hRelease is one way to render the elements of the Social Media Release. The elements of the Social Media Release can be, and already have been, rendered in other formats.

I’m obviously biased when it comes to this subject because I’ve created a data format for the Social Media Release called PRX. PRX is an RSS extension that conforms to SHIFT Communications’ Social Media Press Release Template. It includes the elements that were specified in Elements of the Social Media Release.

I have always maintained that I will support hRelease when the specification is finalized, and I have not changed that stance. I have, however, determined that, as a professional data processor, I do not favor the hRelease format. I fully support the hard work that has been done on the Social Media Release thus far, but I have concluded that I do not support the general Microformat approach. I see many limitations to Microformats and it is not my preferred method for the exchange of data over the internet.

I’ve taken the liberty to outline my reasons for not using Microformats in the following section. This is not an attempt to wage war on any group, but I think that I have an obligation to throw my thoughts out there for consideration. I am especially concerned by the fact that many non-technical people are latching onto the buzz around Microformats without having a good understanding of its pros and cons.

My Take on MicroFormats

Computer programs are dumb. While humans can recognize things on a web page like names, locations, and prices. Computers can’t easily read the same information. When we create web pages, we need to insert clues into the page that help computer programs identify our data. Microformats create clues for computer programs using the class attribute of HTML elements.

 

In the example below, a human can recognize my name in between the two <span> tags, but a computer program would not know what to do with the data. After adding the class=”FN” code (FN stands for Full Name), a computer can pull my name from the web page and do neat things like create a virtual business card for me.

 

While Microformats have some nice features, I see several drawbacks for processing data. In fact, my study of Microformats has led me to conclude that they are not a long-term, viable solution for data processing. Although I am pragmatic and will support Microformats where I must, I don’t recommend their use.

These are a few of the issues that I have with Microformats:

Data and Presentation Don’t Mix – It’s important to keep data separate from the rules for displaying the data. This is a basic tenet of data processing. You do not want changes in the look of your web page to affect the data on the page and vice versa. Microformats tie the look of a page directly to the data and I find that to be a major flaw. Mixing data formats with the presentation of the page is not a good idea and will lead us to pages that can’t be read by humans or computers. If your answer to this is that the tools will do it all, then I must ask why aren’t the formats being written for the tools? If the tools will do all of the work, then create formats that work best with the tools. Actually, use the existing formats that already work with existing tools.

I hate rework – Microformats force you to recreate data formats that already exist. For an excellent example of this, look at the ATOM specification and the resulting Microformat, hAtom. This seems like a lot of double-work to me and will quickly lead to multiple, out-of-synch versions of what is supposed to be a single format. Let’s come up with a solution that doesn’t force us to redo everything.

Microformat vs. Microformat – Although I haven’t personally studied this aspect completely, I’ve read from several knowledgeable people that Microformats can conflict with one another if used in the same web page.

Microformat Bureaucracy – I was told by a prominent Microformat developer that I can’t just create objects out of my head and call them Microformats. So, do I have to go through a long, community-driven process to create every Microformat? What about industry specific or business-to-business Microformats? I’m all for standards, but it seems like the need to control the Microformat class names will place an undue burden on development. It limits, for me, the usefulness of the Microformat approach.

Microformats and RSS (the big myth) – It’s true that Microformatted data can travel through an RSS feed, but did you know that it’s really not a very efficient way to publish your data? With Microformats, the computer program must open each feed item, extract the HTML, and then try to determine if a Microformat is present. If the Microformat does not exist in the feed, then you’ve wasted a ton of processing cycles. In my opinion, a much better way to publish data through RSS is by using an RSS extension.

“Designing data formats for humans first…” is the wrong approach – Sorry folks, data formats need to be written for computers. A good data format should balance the human need for readability and the computer’s need for structure. Microformats make it more difficult for computers to read your data because the data format is mixed with the presentation of the data.

Most people cannot code (and don’t want to) – Providing all of the cheat sheets, tutorials, and wiki pages in the world will not turn the average person into a coder. So stop trying. The approach that works, as we’ve seen from MySpace and countless other customizable sites, is to create something that people can cut-and-paste into their pages.

I should disclose that in my quest to come up with an approach that meets my needs better than Microformats, I developed the concept of Data Widgets. This is a cut-and-paste approach to data integration which I think would be far easier to manage for most people.

So those are my thoughts on the issue. Although I may not have totally changed your mind on all of these points, I hope that we can at least agree that the Social Media Release and hRelease have very distinct definitions.

Tags: socialmedia social+media social media pr pr2.0 public+relations public relations press releases newmedia press+releases pressreleases 101 hrelease