An individual format, like hCard is something that people can build on–and hCard is a good thing. But it seems uncritical to say that it’s a Microformat and therefore more / all Microformats are a good thing. Unless you are suggesting that “Microformats” define something independent of any group of people–e.g., it’s just the common idea of using class names to make it easier to find data embedded in HTML, in which case I am misunderstanding your point.

In contrast, if RDFa ever proves itself to be a good thing, it really is a “thing” in that sense of being a platform technology or technique for any kind of content / data, that any individuals can choose to build on independently. RDFa’s semantic is another generic one like HTML, rather than content specific ones like hCard or hAtom.

I do think it’s fair to say that hCard is useful and “so what” if you can do RDFa-vCard since people are already using hCard. Those are content specific arguments. And, a most of the important “data” needs people have can be defined in content-specific terms.

So, it’s great that the Microformat group is focused on providing content-specific semantics, as opposed to general ones.

But, it’s also a good thing that RDFa is focused on a generic semantic, rather than content-specific ones. It offers other opportunities / different ways to approach the unending challenges of managing content / data.

With both RDFa and Microformats, the real measure isn’t the number of pages that have those formats built-in (especially when many of those pages are really just a single template being used over and over): the real measure is the number of interesting consumers of those formats. And, generic consumers (e.g., for RDFa) have totally different strengths and weakness against content-specific consumers (e.g. hCard, RDFa-vCard). People, in the general case, likewise need the flexibility to choose between those approaches.

Sam

And even if that RDF/XML is ugly, there’s one thing which should be very pleasing to the eye when reading that: that it contains a ton of URIs. URIs mean extensibility. Extensibility means not having to live with broken design decisions of yester-year. Extensibility means being able to replace only the broken bits while keeping the good bits. And it means you can take good designs and add new stuff experimentally. Vocabularies for expressing data need to be able to be designed by individuals and communities on their own, in much the same way that websites can be.

The URI is the thing. What makes URIs different is that unlike any other data format, you can follow them to find out more. You can’t do that with ISBNs or DOIs, usernames, foreign keys in relational databases. RDF is really the intuition that foreign keys need to be URIs, not integers. You can’t stick an integer or a username into Firefox or Safari. If I get some weird bunch of XML or JSON come down the pipe, I need to know in advance what makes it tick. Sometimes that’s obvious, but a lot of the time it isn’t. Seperating the syntax and the semantics is a good first step to solving that problem.

I thought you guided good. The most weak point of semantic web technology is its difficulty to normal web developers still. It’s one of reason for them to prefer REST or Javascript rather than SOAP in Web API. I thought the same rule was applied in competition between microformat and RDFa which it’s easier than others still.

Front-end developers to treat “view” area are not familiar with complexity of logic and meta-data in real world. Microformat also can be harmonized with HTML itself in various aspects. BTW microformat was one of solution for question how to make a name in “class” or “id” attributes.

Sure, quite a few publish hCard or XFN, but none use it as the foundation for their core offerings. If the hCard and XFN class/rel values were stripped from their markup, the sites would not cease to function. hCard and XFN is just part of their HTML output template and could be removed on a whim.

Even for those few social sites that do support hCard/XFN import, it’s going to be a second tier input mechanism compared to manual entry of contact details / friends.

The web’s nature doesn’t seem to afford clean breaks, and it may be that that nature is required for the kind of success its seen. In order for there to be uptake and innovation within it, a framework seems to need a certain amount of flexibility. At the risk of misreading the history, comparing SGML with HTML with XML there’s a trend of relaxing ontological rigidity and a corresponding trend of uptake and innovation. It may be that to get total buy-in to one way of describing resources is to reach a point of stagnation.

Like you I have tried to follow the W3C work on RDF, OWL and SPARQL and I have to admit I have found it difficult to grasp and without examples in the wild even harder to justify the time to conquer the steep learning curve. That said given the recent announcements from Google (RDFa support) and Yahoo (SearchMonkey), I am once again trying to grasp the complexity in order to better understand the future value of LinkedData.

The good news is real world semantic web examples are beginning to appear in products like Twine, Glue, Zemanta, OpenCalais and FreeBase which make it easier to understand how the semantic web might work for me in the future and gives me hope that the time I might invest now in learning semantic technologies may not be totally wasted or surplanted by some new semantic technology/syntax.

That said I too recently came across a conundrum in regard to RDF(a) and microformats proving the lack of knowledge I currently have because I still have no answer.

Like you and many others I am a user of twitter. I am also an advocate of XMPP (push real-time) and Atom XML datastreams. So I live in hope that Twitter will change its model back to an Atom Data Stream pushed over XMPP in order to deliver genuine realtime data. Not the psuedo HTTP based pull model they use today.

If that happened I then began wondering what the metadata model was for this Atomstream. After some research it was clear that it certainly wasn’t going to be RDF (this example here shows how to turn Twitter Atom feeds into an RDF Store along with triples http://www.devx.com/semantic/Article/40869) or microformats. (Even if the twitter client already supports hAtom, hCard and XFN.)

I then began to think that the way you were developing ActivityStreams with Nouns, Verbs and Objects was very similar to RDF triples and could possibly be the metadata layer to Atom inside an activitystream, enabling apps to extract metadata about the activitystream. I hope this is how you thinking as the way forward as a new approach to metadata.

Additionally I think the ActivityStreams Atom extension can also be developed to meet your goals for picoformats. Given the limitations of 140 microblogging adding extra syntax to the tweet msg could prove a constraint unless twitter enabled the extra 20 characters they hold in reserve (160 characters) for the use of picoformat syntax.

Instead I would prefer to see the ActivityStream format develop further to provide the metadata layer especially given the way Google gWave and Laconica is developing (Federated XMPP and Atom XML).

The question is will ActivityStreams borrow more from the RDF syntax or from the microformat syntax?

You may be in the unique position to lead us to drop this false dichotomy. Microformats and RDF are different tools for different jobs. It is irrelevant now that microformats were born in opposition to RDF and positioned as the scrappy contender. No one needs to convince you that RDF has a role nor vice versa. Every application designer can do the research and use the applicable technologies.

So, please, declare the “debate” over.

Thanks,
Rick

A particularly interesting application I recently saw of microformats was the blending of the human and programmable webs in “RESTful Web Services”, where both people and computers used HTML marked up with microformats. I’m not entirely convinced by this approach, but it’s certainly innovative.

Anyway, it could be that you’re both right… microformats scratch an itch now and RDF provides a heavier, long term solution for more complex problems.

Sam