Go Tell It On the Mountain
May 15, 2002
1. A name for prayer-books or devotional manuals for the use of the laity, used in England before, and for some time after, the Reformation
2.b.By extension, a small introductory book on any subject.
2.c. fig. That which serves as a first means of instruction.
-- The Oxford English Dictionary, 2nd ed., Volume XII
Marketing and Technology Evangelism
There are only two kinds of marketing: bad and terrible. Programmers, and other people who actually create things, generally disdain marketing for good reason: it typically overpromises, inadequately explains, and dwells on the ephemeral, to the detriment of the real.
But there are exceptions to most sentences which begin with "there are only two kinds of ..." Technology doesn't necessarily need to be hyped, but it often needs to be sold. So let's agree that marketing comes in two flavors -- bad and terrible -- but that technology evangelism, which is distinct from though related to marketing, can be vital to the success (and not necessarily in market terms) of a new technology. Let's also stipulate, for the sake of saving time and space, that the point of technology evangelism is to educate potential users about the utility of the technology for one of their purposes or ends, and to do so in a way that imparts a sense of reasonable and realistic enthusiasm. And if evangelism imparts a sense of fresh or novel possibility, so much the better; that's just icing on the cake.
The Real Problem with RDF
From at least one perspective, RDF, the Resource Description Framework, is among the most interesting of W3C specifications. But RDF is also used less often than one might expect, is not terribly well understood by its potential target audience, and generally suffers from a lack popular enthusiasm. One might even suggest that RDF is nearer to its stagnation than to its tipping point, though speculating about tipping points is notoriously tricky. In short, RDF's evangelism has not gone very well at all. For the record, I'm not interested in attaching blame to that fact; the relevant point here is that it is a fact, and it is one which can change.
Which is not to say that RDF is technically perfect; it has its fair share of flaws and warts, at least one of which -- the poorly understood distinction between the RDF data model and its best-known and most-hated XML serialization -- is or is perceived to be a real impediment to its widespread adoption. But, despite its flaws, RDF can be extremely useful for a great many Web-application tasks. So my theory about why RDF is not widely used is that to date it has not been well evangelized.
What can be done? The RDF Core Working Group part of the W3C's Semantic Web Activity thinks it has at least one edge piece of the RDF evangelism puzzle, namely, the RDF Primer, a draft of which was recently released. All good technology evangelism requires that potential users have an accurate, even if not very deep understanding of the technology. And one way for potential users to acquire such an understanding is for foundational developers to explain it to them, taking into account what users need to accomplish, as practically as possible, and what users know already about the technology and surrounding technologies. And the expression of this explanation needs to be one which potential users can reasonably trust to be accurate and reliable. Nothing spoils good evangelism like half-truths, distortions, and bumblings.
The RDF Primer
So RDF evangelists stand in strong need of something like the RDF Primer, especially a document blessed, as it were, by a trusted source. As it says, the RDF Primer is intended to "provide the reader the basic fundamentals required to effectively use RDF in their particular applications." You couldn't ask for much more.
The only other thing to ask for or about is how well the RDF Primer accomplishes this important task. As the Primer is currently at the draft stage, some kinds of comment, including those about the clarity of its sentences and paragraphs, are best left to private communication with the Working Group. However, we can take an overview of the Primer as a whole, asking ourselves whether, as a whole, it constitutes a ground upon which RDF evangelism may go profitably forward.
First, let's examine the Primer's structure: it offers an introduction to RDF, explains RDF's much-maligned XML serialization, introduces RDF Schema and RDF container types, describes a few real-world RDF applications, says a bit about RDF's model theory, its test cases, and about reification.
My initial reaction is mixed. The first section, "Making Statements About Resources", offers a relatively accessible introduction to what RDF is all about. I found the discussion of RDF "blank nodes" to be especially helpful. But the document as a whole is too long and can be hard to wade through.
The section on RDF Schema is a substantial part of the Primer, which would be stronger if the RDFS stuff were introduced very simply and quickly, with the bulk of it existing in a separate document. Of course, these judgments are very subjective, but my intuition is that the Primer should handle the most common RDF use cases, and for most of its potential users, RDF Schema is not something they need or will use first. The Primer seems to acknowledge this general point when it says that,
RDF defines a simple data model for describing the properties of resources, and interrelationships among resources, in terms of named properties and values. However, RDF user communities also require the ability to specify that they are describing certain types or classes of resources, and which specific properties will be used to describe each of those types or classes.
Which is true enough, but the implication of this claim -- that RDF provides a simple data model of its own -- for the purposes of a primer suggest that removing the RDF Schema discussion from the Primer, or at the very least slimming it down considerably, would strengthen the Primer. And while it is equally true that extensive use of RDF requires RDF Schema, the two most common public uses of it to date -- RDF Site Summary and Dublin Core -- feature user communities, the overwhelming majority of which are satisfied without extensive or any knowledge or use of RDF Schema. That some core group of schema designers needs RDF Schema (and a corresponding RDF Schema Primer, to be sure) is indisputable. But RDF is very much like XML in this respect: just because "anyone" can create an XML vocabulary or RDF schema does not itself mean that the numerical majority of XML or RDF users will ever do so. In fact, there are good reasons for believing that most users will never create vocabularies or schemas. Finally, there is the general point that, all other things being equal, short primers are better than long ones.
Also in XML-Deviant
Further, it certainly seems clear, whatever their status in the future of RDF, and despite rumors of their eventual demise, discussion of RDF containers -- <rdf:Bag>, <rdf:Seq> and <rdf:Alt> -- should precede the discussion of RDF Schema. Potential users can avoid writing RDF schemas for far longer than they can avoid dealing with container types.
As for the discussion of actual RDF applications, I'm tempted to say that the important thing is that the Primer includes consideration of applications, no matter what they are. But that's not entirely true. While the most obvious use of a framework for asserting resource descriptions is metadata, the problem is that the metadata applications are the most obvious. Hence, they're the ones mostly likely to have occurred to anyone who knows anything about RDF. Three of the five RDF applications which the Primer considers are straightforwardly metadata applications. Any responsible primer about RDF must, or so it seems, include discussion of RSS and Dublin Core. Which means that the discussion of PRISM doesn't add very much. Far more interesting and non-obvious is the intelligent routing discussion. I'd like to see more discussion of RDF applications like that, and a bit less about metadata.
Section 7, "Other Parts of RDF", has a very haphazard feel, as if it is serving as the dumping ground for things the Primer should discuss but which couldn't or haven't yet been worked into more obvious or conceptually elegant places. The discussion of the RDF Model Theory belongs in the introduction to RDF per se, at the beginning of the Primer. And if reification -- which surely plays the same role in the RDF drama that namespaces plays for XML -- is going to be discussed at all in the Primer, it too should be integrated into Section 2. As for the consideration of RDF Test Cases, while it is only a few shortish paragraphs, it really belongs somewhere else entirely, i.e., not in the Primer. Were these changes to be made, the Primer would have one less section entirely, which would contribute to the perception of it being as clear and simple as the truth.
Lastly, Section 8, presently called "RDF as Data Model" promises to be the hidden gemstone of the Primer. If I understand correctly what it promises to become, it is precisely the sort of substantive discussion which can communicate the value of RDF in a way which fires imagination and stokes enthusiasm. A discussion of the relation of RDF to relational data storage technology is particularly crucial, since it not only reaches potential users where they live, so to speak, but also hints at one of RDF's potential uses, namely, as an application-specific data model layer, which may or may not be stored in an RDBMS.
After languishing for a relatively long time, the next 12 to 18 months is a make or break time for RDF, as well as for the Semantic Web Activity, of which RDF is a crucial element. Despite the technical problems with RDF, the biggest impediment to its widespread use to date has been the failure of evangelism, not so much because it was done poorly, though there have been missteps, but, rather, because it was mostly not done at all.
And so the arrival of a Primer among the work product of the RDF Core WG is a happy occasion. It offers those of us not serving on an RDF working group, but inclined to do formal or informal evangelization of RDF among our peers, a non-normative but still blessed and trusted ground upon which to base our efforts. As well, it offers curious, potential users a more easily accessible introduction to RDF, and that can only be a good thing.
There is some sense in which there being an RDF primer is far more strategically valuable than the sort of primer it is. However, as with other introductory texts, often the only texts about a technology users ever read, there are certain principles it is hard to quarrel with. Among these are simplicity and concision. In what ways and to what extent these principles are met is, as always, at least partially a subjective question. I for one think that the RDF Primer gets more things right than it gets wrong, but I'm also hopeful that future drafts grow increasingly simplified and concise.