Home › HTML5/RDFa Arguments
Sat, 2009-08-22 18:19 — Tantek (not verified)

Re: HTML5/RDFa Arguments

Jeni,

A lot of calm, very well reasoned analysis here that demonstrates you have dove into the depths of many of these technologies. Thank you for adding a high quality critique to these discussions.

When I first proposed microformats in 2004[1] with Kevin Marks, it was in many ways a proof of concept that the neither the RDF data model nor (and especially) syntax(es) had significant advantages as a way of modeling (and especially *authoring*) data over and above not just Javascript object structures, but simple markup that perhaps mainstream to modern web designers were already broadly familiar with. And not just a lack of advantages, but that frankly, perhaps simpler, more real world solutions were possible.

Five years later and there is solid support for several microformats in numerous sites from as large as AOL, Google, Yahoo, Yelp, to a very long tail of smaller sites - at last count Yahoo Searchmonkey reported over 1.3 billion hCards on the web. What started as a proof of concept has become the dominant form of representing semantics (over and above what's built into HTML) on the web.

Thus, it is not only right to challenge the assumptions[2] from the perhaps more "official" RDF / Semantic Web community, but there is absolutely the possibility of developing better solutions that will be more useful and more easily/widely adopted on the web, in less time.

Note that microdata didn't happen overnight. Much of the design and simplicity of microdata is based on years of work on principles[3] deliberately designed to help guide and create simpler, more usable and accessible solutions. It happened so quickly because Ian Hickson designed microdata based upon years of work by others, as good (efficient) scientists and engineers do.

I think there are some very clever ideas in general purpose microdata, it has a lot of potential, and despite being a bit more abstract than microformats, still much simpler/easier to explain to web designers/developers/programmers than any form of RDF.

General microdata may be the right solution to the general purpose data representation problem that microformats specifically chose not to work on.

One bit of technical addition to your post regarding microformats, and URIs for vocabulary:

When I was working on XFN (effectively the first microformat) in 2003, I specifically designed the underlying technology of XHTML Meta Data Profiles (XMDP)[4] to *enable* all HTML rel/class additions/extensions (what would later become known as "microformats") to be *optionally* bound by URLs. And not just any URLs, but URLs that were compatible with and looked like RDF vocabulary URLs that ended with a "#" and term name. This was a deliberate design decision on my part, because I knew that there would be those who insisted on defining their terms with URLs. Here is an HTML markup fragment that demonstrates this with the above-mentioned hCard:


<html><head profile="http://microformats.org/profile/hcard">
<title>a document with hCards</title></head>
<p class="vcard"><span class="fn">Jeni Tennison</span> wrote an article, 
<cite><a href="http://www.jenitennison.com/blog/node/124">HTML5/RDFa Arguments</a></cite>, 
that compares and critically analyzes HTML5 and RDF approaches to representing and publishing data.
</p>
</html>

The terms "vcard" and "fn" which are used as class names are defined by the hCard XMDP profile[5] and the respective URLs for those terms are created by referencing the fragment IDs in that document:

http://microformats.org/profile/hcard#vcard
http://microformats.org/profile/hcard#fn

Thus providing the necessary URLs for any (meta)data system that stores/reasons about data based on vocabulary based on URLs (whether RDF or some other URL-based vocabulary store).

The key here is that this was made *optional*, not required, and thus does not have the potential "web of fragility" problem that you described for systems (like RDF) that *depend* on URI based vocabulary.

In practice, few people use XMDP profiles, well, except for at least the millions Wordpress blogs[6] out there - just view source on them and you'll find: profile="http://gmpg.org/xfn/11" near the top of the page.

But the point is that those that want to use XMDP profiles have the *option* of using them, while not burdening everyone else with doing so.

Tantek

[1] http://tantek.com/presentations/2004etech/realworldsemanticspres.html
[2] http://microformats.org/wiki/namespaces-considered-harmful
[3] http://microformats.org/wiki/principles
[4] http://gmpg.org/xmdp/description
[5] http://microformats.org/profile/hcard
[6] http://wordpress.com/

Reply

The content of this field is kept private and will not be shown publicly.