Bb RealTech

Recently, a group of well known web designers issued a "Super Friends" declaration of support or HTML5, with an attached set of concerns. Most of the concerns had to do with the new "semantic markup" elements included in HTML5, such as section, article, and so on. I've not previously discussed these new semantic page markup elements, because I had other fish to fry. However, I decided to take a closer look at the elements, particularly at how I would use them for my Drupal sites.

update I rest my case regarding my assertion that underlying biases are influencing perceptions regarding RDFa and HTML5.

Last Week in HTML has been practicing its wicked ways, and pulled a quote from a comment I made to a post at Sam Ruby's

Ian is wrong. Absolutely, completely, and dead wrong.

...

rather than Ian shouting out “Hurrah!”, he says we must have five different solutions to the five problems, because to do otherwise is to...what? Give up control? Fail to meet the Guinness Book of World Records for largest, most pedantic specification ever derived by man?

At first glance, this seems a repetition of an argument that is growing thin with overuse, but the recent discussions in the RDFa mailing list, about RDFa in HTML5, provides a clear demonstration of the basic disconnect between the parties. Enough so to make it of value to re-visit the discussion, again.

On the one hand, you have RDFa, which is a serialization of RDF, which is a formal data model providing support for a universal form of structured data. On the other hand, you have those whose ideology for the future of the web is based on natural language processing. This is an old, old battle and one we've been fighting since RDF was first proposed—prior, really, as I remember working ideological differences between natural language processing, as compared to structured data techniques, in various projects at Boeing in the 1980s.

One would think, then, considering the age of the debate that we wouldn't fight this old battle in the lists for HTML5. Why? Because it exists above and beyond just HTML5. It is a debate about the fundamental nature of the web, at its most general and profound level, while HTML5 is really nothing more then the next generation of HTML. However, we are fighting this macro battle out in the micro lists of HTML5, but deceptively so.

Those who support RDFa have been continuously asked to provide use cases for RDFa, and have created a wiki page to record these use cases. But each time the use cases are proposed, we're given a response that the use cases are inadequate, and different sets of criteria for how these use cases can be "improved". It is frustrating to the RDFa adherents, stumbling about in the dark hoping to hit exactly the right "fit" in order to satisfy these never ending requests.

In the new thread, though, the underlying ideological differences are peering out through the fabric of technical obfuscation, and we see the real purpose behind the demands for RDFa to justify its existence in HTML5. We're not being asked to justify RDFa in HTML5; we're being asked to justify RDF, and beyond that, we're being asked to justify the concept of structured data. Not just once, but for every instance of a use case.

Ian Hickson writes in one comment in the mailing list thread:

I wouldn't worry too much about the various solutions in each case -- a list of solutions can never be complete, and people will never agree on what consists a pro and a con. What would be useful, though, is an example of how RDFa is expected to solve the problem, e.g. with sample markup showing how the relevant data might be encoded and code snippets showing how the data would then be processed; and a discussion of ways to deal with the likely problems (e.g., for this particular use case: how to deal with authors screwing up and encoding bad data, how to deal with apathy from sites that you want to scrape data from, how to deal with malicious authors encoding misleading data, how to deal with spammers, how to deal with requirements like Amazon's desire to track per-developer usage, how to enable monetization for producers who are intentionally obfuscating the data today, etc. I expect other use cases will have different problems).

The first set of requests are reasonable, and have been demonstrated. I use RDFa in my site to document each post with a formal title, author, date, and set of topics, each of which can be extracted using a PHP API that I've installed at my site. I plan on using this data in order to generate my front page eventually. This same data can be extracted with an Firefox toolbar, too, if I'm so inclined, and used to output a RDF document for other's to consume. The data has also been extracted as part of Yahoo's SearchMonkey effort, I do believe.

Others have provided examples of the Creative Commons licenses, and FOAF, and other uses of RDF/RDFa. Not only the purpose behind the use, but even demonstrations of how the data can be combined across pages. These seem to meet the requests for demonstrating code to both incorporate the RDFa in HTML5, as well as code to pull such data out.

As for authors screwing up and providing bad data, well I have to assume the same mechanisms in place, in the browser, when a person inputs bad data into an alt attribute (if it survives in HTML5) would be in place for bad data in a property attribute. And if the data is coded incorrectly, applications expecting valid RDFa wouldn't be able to process the data, but that's little different than applications not being able to process a bad script, or malformed piece of SVG, or even a crappy video file, embedded in the page.

The questions I just responded to are legitimate questions. They serve a purpose, and a person can determine by looking at these questions what needs to be provided to ensure success of the use case. But then we start getting into murkier territory. Ian asks, how to deal with apathy from sites that you want to scrape data from, how to deal with malicious authors encoding misleading data, how to deal with spammers, how to deal with requirements like Amazon's desire to track per-developer usage, how to enable monetization for producers who are intentionally obfuscating the data today, ...

My god, how do we deal with these on the web today? HTML, itself, fails badly with all of these, so do we give up on HTML? If not, then why are we demanding a state of rigor from RDFa that we're not willing to apply to HTML5, itself?

If you think this latter set of questions were tongue-in-cheek, perhaps a bit of markup levity, Ian repeats them, later, in the same thread

Do we have reason to believe that it is more likely that we will get authors to widely and reliably include such relations than it is that we will get high quality natural language processing? Why?

How would an RDF/RDFa system deal with people gaming the system?

How would an RDF/RDFa system deal with the problem of the _questions_ being unstructured natural language?

How would an RDF/RDFa system deal with data provided by companies that have no interest in providing the data in RDF or RDFa? (e.g. companies providing data dumps in XML or JSON.)

How would an RDF/RDFa system deal with companies that do not want to provide the data free of charge?

How would an RDF/RDFa system deal with companies that want to track per-developer usage of their data?

One could ask all but the first question about HTML, and not find satisfactory answers. Yet we're being asked to provide sufficient answers to these questions for a small subset of attributes in HTML5, which would form the basis of support for RDFa. As for the first question, Do we have reason to believe that it is more likely that we will get authors to widely and reliably include such relations than it is that we will get high quality natural language processing?, this, again, brings us back to a fundamental differences in ideology, natural language processing as compared to structured data, and how can one deal with such profound differences in something like a use case?

To repeat what I said earlier, the issue isn't about RDFa in HTML5. It is about the existence of structured data on the web. It is about the underlying purpose behind RDF. It calls into questions a decade's worth of work, based on the input of hundreds if not thousands of developers and designers. It is questioning the fundamental separation of ideology between the web of the future based on natural language processing and the web of the future based on structured data. But where the structured data folks, those who support RDF, and RDFa, welcome natural language processing as a complementary process, the natural language processing folks seem to see the very existence of structured data woven into web documents to be anathema.

Now, someone tell me how we can break through this wall with use cases?

Dan Brickley chastises those on the RDFa group who see this as a battle, writing

This is not a battle. Battles kill people. It is a dispute amongst technologists who have varying assumptions, backgrounds, collaboration networks and agendas, and who are slowly learning to see each other's perspective.

Please (and I am very serious here) stop using such bloody metaphors to describe what should be a civil and mutually respectful collaborative process. You will not improve anything if you foster this kind of perspective on our shared problems. Battle talk results in a battle mindset. I do not want to hear any RDFa advocates talking in such terms.

Really, enough with the battle stuff. Go find someone who works on HTML5 and be nice to them, find common ground, try out their tools.

Play nice...try out their tools.

I have tried the tools, and in fact just tried the HTML5 validator with the SVG, MathML, and RDFa (minus Curie) preset, and aside from the fact that it tossed my DOCTYPE, didn't like my profile attribute, some of my meta elements, and the use of "none" as a value for preserveAspectRatio in my SVG, the validator had no problems with any of my RDFa. I would have to assume, then, that we have seen a demonstration of RDFa in HTML5...and found it good? And lo and behold, the RDFa extractors have also found the same page, and the same use of RDFa, to be good. Hands across the water.

But evidently, not sufficient. What else must we do to play nice? Well, Sam has laid out the "nice filter" in comments to his post that began this particular thread

What would it take for inclusion of the RDFa attributes in HTML 5 to be tracked in the W3C HTML Working Group issues list? Given the links I provided at the top of this post, I’d say that pretty much all of the pieces are in place except for a discussion on the public-html mailing list.

What work would be helpful in getting this to be resolved successfully? Fleshing out the use cases addressing as much of these concerns as are relevant.

How can you help? Join the WG and/or contribute to the wiki.

Just so that it is clear, as we move towards summer I plan to become ruthless in clearing out issues which have been raised but don’t appear to have any substantive proposals or support. There is much good work in HTML5 and it would be positively criminal for it not to advance due to procedural maneuverings. I don’t intend to let that happen either.

And this then leads us back to the questions posed by Ian, above. For each use case, must I then justify RDF? Structured data? Must I give details about how spammers will be vanquished, and evil corporations not allowed to monetize such effort? Must I provide a 12-step program in how to lure the reluctant microformat user into the fold? Does the fact that Virgin Mobile misused the Creative Commons license to publish photos of people without getting model releases, mean that the use of RDF/RDFa to document a Creative Commons license can never be a valid use case? After all, it fails the evil corporate use case requirement being demanded of RDFa.

There seems to exist a gentleman's agreement in these specification email lists, whereby the participants humor absurd questions such as those proposed by Ian. Well, thank goodness I'm no gentleman.

If the RDFa in HTML5 adherents will be required to provide not only justification for RDFa, but also justification for RDF, as a whole, in addition to a dialog and debate about the fundamental differences between natural language processing and structured data with each and every use case, then I fail to see the "niceness" supposedly in play here. It's difficult, too, to see exactly what we're supposed to do to bring about this so-called "common ground". Ultimately, structured data people see natural language processing as complementary, and that's there room on the web for both ideologies. The natural language processing folks see structured data as competitive, and that the web of the future will be based on one or the the other, but not both. How do you work through that kind of difference?

In an interview at WebScienceMan titled, XHTML Users: Grow up!, the interviewee, Sitepoint's Tommy Olsson answers a question as to whether he likes XHTML with, Grow up! :) Seriously, XHTML is long dead, due to a decade of horrible abuse. Not even the bleached bones remain..

Mr. Olsson believes that we should be using HTML 4, strict HTML 4, because HTML5 is still a bit of whimsy, and XHTML is a pile of dead bones. As I wrote in comments, HTML 4 is to markup, like 8-track is to music.

What ended up being the ultimate irritation of my brief foray into HTML5 land, is that I found out, after careful perusal of my original use of RDFa, that I wasn't using it incorrectly. However, by the time I got through listening to all the arguments, back and forth, and round and round, I was beginning to doubt whether an angle bracket really looked like < and >. I am correct, aren't I? These are angle brackets, right?

Of course not. I call them angle brackets, but others call them diamond brackets, and I'm sure someone else, most likely from the UK, calls them elbow brackets or the Queen's brackets, or some such thing.

However, the back and forth, and round and round, wouldn't be an issue, could even be a journey of discovery, if it weren't for the arrogance of some of the participants. Or, what I perceive to be arrogance. Variations of, "But that's wrong and here's why", followed up with references to other specifications that hurt, actually physically hurt just to look at, given in a tone of, "How could you think otherwise?" Or responses based on some absolutely obscene piece of markup minutia, repeated over and over again, in attempts to hammer the point home to we, the seemingly dense as bricks.

The end product of such discussions, though, is that people like myself flee the discussion—literally flee, as if the hounds of hell were chomping at our butts. The downside of running away, though, is we're left feeling that we have no input, no control over what the web of the future will, or will not, allow. That the web of the future of the web is designed by and for the web designers, and not thee and me.

The real problem, though, has less to do with communication style, and more to do with differing levels of expertise and interest. People like me, who are consumers of a specs, are mixed in with people who create the parsers and the browsers, and live and breath, eat and sleep this stuff. What else can we, the consumers, do, though? There seemingly is no way for those of us, on the dumb side of markup, to communicate our concerns, wishes, and desires to the other side. But when we do venture into the lists, we are quickly overwhelmed with the specs, the references, the minutia. Our interests get lost in the fact that we don't have the language to participate. Worse, we don't have the language to participate in a field notorious for being both competitive, and impatient.

Unbeknownst to ourselves, we have become Pinky to the markup Brains.

So we consumers flee the lists and leave them to the developers and designers, and the end result is that we have specifications, and eventually implementations, that, well, frankly, scare the shit out of most of us.

Don't believe me? How else could you explain the Yellow Screen of Death that appears whenever you make a simple mistake in markup for the post you're writing? Not a helpful error, or an error that gently points out where and why the problem occurs; an error that tries to work with you to correct the problem.

No, it is an ugly error, an angry error, with red on yellow, that screams, "Bad, Shelley! Bad", before it invariably trails off to uselessness on the right side of the browser. You don't think an actual person like you and me would have designed a specification that encourages this behavior, or a browser that implements it, do you?

The true irony, though, is when you do voice concerns, or criticism, you're typically met with, "If you want something, you need to participate in the email lists working on the specifications", and the cycle begins anew. Narf.

update Wow, speak of the devil. What will Mozilla do with that feedback? Why, conquer the world, of course.

Brain!

update The discussion on RDFa in HTML5 is quite active on the WhatWG mailing list, and so I'm closing comments down here, and encouraging the discussion in that location. There is no restriction on joining the mailing list. A place to start would be a thread I started but I'm sure new threads will be springing up.

I did want to apologize for assuming that the XHTML errors I had recently were due to WhatWG members having fun at my expense. I've had people deliberately break my XHTML-based comments in the past when I've written about XHTML, and the break was documented with a screenshot in the web site of a WhatWG member. I put 2 and 2 together and came up with 5.

I was reading the back and forth argument about the support for RDFa in HTML5, when it hit me that we, who support RDF, and its embedded serialization technique, RDFa, are going about it all wrong.

The question that gets asked, repeatedly, in the HTML5 and WhatWG mailing lists is What problem does RDFa solve? This typically then leads to lengthy discussions about RDFa versus microformats, how one only needs rel, class, meta, and script in order to seemingly record the same information. Or that marking this information up in anyway is unnecessary, as people won't use it, use it badly or for evil purposes, and the only direction forward for the web is natural language processing...yada, yada, yada—you've heard it all before.

But what if we stop focusing on the perceived purpose of RDF/RDFa? What if, instead of defending RDFa as a format for discovery of semantics on the web, in competition with other techniques, we focus on RDF, as others have focused on MathML and SVG—as a rich, mature specification with its own unique purpose, and its own unique benefit? In other words, begin with the assumption that RDF has value in, and of itself, and does not need to be "justified". Instead, let's focus on whether HTML5 can support RDF—the rich, mature specification—as is, with the existing HTML5 extension mechanisms.