RDF Roundup

September 22, 2004

With the exception of a not unfamiliar round of bile spilling about SOAP and web services, recent weeks have been quiet in the XML developer community. Those eager futurists from the RDF interest list have kept going, however, and an overview of that activity forms the core of my report this week.

RDF Roundup

Earlier this year Bob DuCharme published an article on XML.com called Googling for XML. Deriving from this interest, DuCharme has now set up rdfdata.org to provide a catalog of repositories of RDF data available on the Web. Though patchy in parts, it looks a good starting point for anyone needing RDF data to work with. DuCharme is also accepting suggestions for new data sources.

Howard Katz posed an interesting question to the RDF interest list recently: what is good practice for writing RDF/XML?

I'm writing a tutorial-type article that shows how to use XQuery to transform a standard XML datafile (not RDF/XML) into RDF. The main focus of the article is on XQuery, but I need to make sure that my RDF is also correct and not atypical.

Katz provides an example of the work he's doing. The question of what the RDF/XML should look like actually contains two sub-problems. The first of these concerns how to transform the incoming XML data into an RDF graph, and the second concerns how best to write this graph in RDF/XML. Tom Passin responded along these lines to Katz, giving feedback on his initial modeling, and in particular that the containment model of an XML document doesn't often translate directly into RDF.

This is a typical kind of situation that prevents automatic translation of arbitrary XML. In this case, there is a missing layer that would, if present, state what the relation is between a bib and a book. Since it is missing, you have to supply it. That is basically a little data-modeling task you have to do.

Libby Miller also responded with some helpful advice. Miller notes that it's possible to use the rdf:parseType='Resource' attribute to make descriptions shorter.

    <rdf:Description rdf:about="http://www.book-stuff.com/bib">

	<bibterm:book>

        <rdf:Description>

            <bibterm:year>1994</bibterm:year>

            <dc:title>TCP/IP Illustrated</dc:title>

                <bibterm:author>

                    <rdf:Description>

                        <bibterm:last>Stevens</bibterm:last>

    ...
Often you see rdf:parseType='Resource' being used instead of rdf:Description (i.e. where there are no types on the nodes) for brevity, but depending on your audience this might be more confusing than helpful. The result would be:
    <rdf:Description rdf:about="http://www.book-stuff.com/bib">

        <bibterm:book rdf:parseType="Resource">

            <bibterm:year>1994</bibterm:year>

            <dc:title>TCP/IP Illustrated</dc:title>

            <bibterm:author rdf:parseType="Resource">

                <bibterm:last>Stevens</bibterm:last>

    ...

Miller also points out the generally used RDF convention where classes are named with an uppercase first letter, e.g. Book, and properties in lowercase, e.g. <book>year</book>.

The thread makes an interesting read, and Katz rather nicely sums up the essence of the difference between expressing data in XML and RDF.

So in short (if I may): in XML the typing is built-in; the relationships are implied. In RDF, the typing might or might be present, and the relationships are (generally) explicit.

Finally, it was a longtime coming, but it has finally been announced that the registration of the RDF/XML media type as application/rdf+xml is now available as RFC 3870.

No Love for Web Services

General despair and astonishment at the state of web services specifications has been breaking out all over recently. As my friend and colleague Simon St. Laurent notes, the whole web services project seems to have lost its way. Personally speaking, while I admit that the complexity may serve to facilitate some deeply complex e-business scenarios, I've never been a fan of the over-engineered and largely untested web services protocol mess.

And it's not just the WS-mess, even plain old SOAP itself isn't getting as widespread a welcome as you might have thought. Many developers are now admitting in public (and privately in the case of some high-profile companies) that SOAP complicates matters too much and the simple combination of HTTP and XML that is REST will suffice.

In his weblog, Tim Bray ponders the essential question for anyone who knows those who have worked on the WS-* suite of specifications.

Here's the problem: the people writing these WS-things aren't stupid. In particular, Don Box isn't stupid. And I'm starting to see names of people here at Sun pop up as WS-coauthors; people who aren't stupid.

Leaving aside the observation that in Bray's experience stupid people often are the reason for stupid specs, what's the answer? As no logical one is forthcoming, Bray decided he will play the "loyal opposition" and be prepared, in the event of the "WS-future" emerging, to admit he was wrong.

Continuing his analysis, St. Laurent links a useful dialog map, maintained by Eugene Eric Kim, about the problems with SOAP from the Python XML mailing list in 2002. This is the first time I've seen such a map, but it would make a useful addition to the sort of analysis we attempt to provide in the XML-Deviant column.

St. Laurent's own opinion about the paradoxical enthusiasm for the WS-mess is that "it's far easier to sell complicated things rather than simple things." This is a sentiment I find it easy to agree with. There's a certain class of organization that is reassured by expensive complexity. I felt the same way at the emergence of "application servers" a few years back. The WS-mess is simply the latest iteration of mediocre middleware.

Births, Deaths, and Marriages

The latest announcements from the XML-DEV mailing list.

White Paper: XERT Your Data, Refocus Your Efforts: Brian Holmes strikes a blow for angle brackets in the binary vs. XML debate.
tkxmllint and tkxsltproc Version 1.6: It's reassuring that people are still writing applications in Tcl/Tk. Steve Ball provides graphical interfaces for Daniel Veillard's xmllint XML checker and xsltproc XSLT processor.
Proposed Change to W3C XML Schema for XML Namespace: Henry Thompson warns that the XML Core Working Group proposes to remove the default value of xml:space from W3C XML Schema for the xml: namespace. Curiously, no debate ensued after this announcement.
Micah Dubinko Launches Brain Attic: XML.com author and XForms expert Dubinko cuts loose into the fertile world of XML consulting.
EXSLT.NET 1.1: A freely available implementation of the EXSLT XSLT extensions available for Microsoft's .NET platform.
New Public List for X3D Discussions: Talk about XML-encoded 3D graphics.

Scrapings

Nothing like leaving things late to focus the mind ... 58 mails to XML-DEV last week, Len rating 7% (thin pickings) ... XML will eat itself ... or it may eat you -- sound mental health advice from Michael Kay ... Microsoft's REST support shames Google ... can't resist one more WS-Snipe.