Recovered from the Wayback machine.
The posting I wrote on Friday about RDF has triggered much debate (in posting and at xml-dev), which is a goodness. I think it’s also triggered much misinterpretation and misunderstanding, which is what happens when a debate occurs across threads of mailing lists and weblog comments.
There has been summary attempts of the debate, such as at O’Reilly Network and at Joe Gregorio’s, but I’m not going to attempt to summarize it myself. Why? I have a viewpoint in this, and this would slant my summary. I’d rather just provide the links and let you form your own summation.
However, I do want to clarify something with my own position.
First, I’m not speaking for the RDF Working Group, in any way. I am giving my own viewpoints and opinions, which the WG may not agree with. No one can speak for the WG members, but they, themselves.
Additionally, I do not discount the complexity and difficulty inherent with RDF. I am aware, all too aware, of how complex the RDF Model documents can be. I know that there is much of the lab and not enough of the real world associated with the effort. And I’m not trying to dismiss people’s concerns with the model or the RDF/XML serialization when I say that we need to release the RDF specification rather than start over.
When I say that I don’t have problems with the RDF/XML, people should be aware that this is because I spent an enormous amount of time with the RDF specifications learning the core of the RDF model. I then spent a considerable amount of time learning how RDF is serialized with RDF/XML. I will now spend a significant amount of time reading through the newly released specifications to see where my understanding differs from the newest releases.
All of this has taken time and effort. I do not deny this.
I also don’t deny the importance of people being able to read and write RDF/XML. However, my interpretation of XML has been, and continues to be, that it’s a mechanical language rather than a biological one, and that it must be accurate, consistent, and reliable in a mechanical sense first, and foremost. Within these constraints, though, we should work to make the syntax as biologically understandable as possible.
Ultimately, I’m not trying to defend RDF/XML as much as I’m trying to generate understand that the problems people are having with RDF/XML aren’t consistent, and may not necessarily be problems with RDF/XML, at all.
Tim Bray creates RPV, which makes the RDF triples easier to read, but Simon St. Laurent says he doesn’t think in triples. Simon, on the other hand, is more concerned that RDF is having a deleterious effect on XML directly, as witness discussions about Qnames and URIs. These are two separate interpretations of “what’s wrong”, and lumping them all together into vague generalizations such as “RDF is ugly” or “RDF/XML is ugly” won’t help anyone.
Because of the discussions in the last week, I am re-visiting the chapters I wrote on the RDF specification for the Practical RDF book, coming in with a fresh perspective, and a better understanding of what the heck I need to write about. Unfortunately, I know enough after this weekend to be aware that this is going to be the most difficult technical writing task I have ever had. Can I clarify RDF and RDF/XML to the point that everyone understands both equally?
Exactly how does one achieve the impossible in 10,000 words, or less?
