Walking in Simon’s Shoes

The editor for my book, Practical RDF, was Simon St. Laurent, well known and respected in XML circles. Some might think it strange that a person who isn’t necessarily fond of RDF and especially RDF/XML, edit a book devoted to both, but this is the way of the book publishing world.

Simon was the best person I’ve worked with on a book, and I’ve worked with some good people. More importantly, though, is that Simon wasn’t an RDF fanatic, pushing me into making less of the challenges associated with RDF, or more of its strengths. Neither of us wanted a rah-rah book, and Practical RDF is anything but.

I’ve thought back on many of the discussions about RDF/XML that happened here and there this last year. Simon’s usually been on the side less than enthusiastic towards RDF/XML, along with a few other people who I respect, and a few who I don’t. Mine and others’ blanket response has usually been in the nature of, “RDF/XML is generated and consumed by automated processes and therefore people don’t have to look at the Big Ugly”. This is usually accompanied by a great deal of frustration on our part because if people would just move beyond the ‘ugliness’ of RDF/XML, we could move on to creating good stuff.

(I say ‘good stuff’ rather than Semantic Web because the reactions to this term are best addressed elsewhere.)

However, the situation isn’t really that simple, or that easily dismissed, If pro-RDF and RDF/XML folks like myself are ever going to see this specification gain some traction, we need to walk a mile in the opponent’s shoes and acknowledge and address their concerns specifically. Since I know Simon the best, I’ve borrowed his shoes to take a closer look at RDF/XML from his perspective.

Simon has, as far as I know, three areas of pushback against RDF: he doesn’t care for the current namespace implementation; he’s not overly fond of the confusion about URI’s; and he doesn’t like the syntax for RDF/XML, and believes other approaches, such as N3, are more appropriate. I’ll leave URIs for another essay I’m working on, and leave namespaces for other people to defend. I wanted to focus on concerns associated directly with RDF/XML, at least from what I think is Simon’s perspective (because, after all, I’m only borrowing his shoes, not his mind).

The biggest concern I see with RDF/XML from an XML perspective is its flexibility. One can use two different XML syntaxes and still arrive at the same RDF model, and this must just play havoc with the souls of XML folks.

As an example of this flexibilty, most implementations of RDF/XML today are based on RSS 1.0, the RDF/XML version of the popular syndication format. You can see an example of this with the RSS 1.0 file for this weblog.

Now, the XML for RSS 1.0 isn’t all that different from the XML for that other popular RSS format, RSS 2.0 from Userland — seen here. Both are valid XML, both have elements called channel and item, and title, and description and so on, and both assume there is one channel, but many items contained in that channel. From an RSS perspective, it’s hard to see why any one would have so much disagreement with using RDF/XML because it really doesn’t add much to the overhead for the syndication feed. In fact, I wrote in the past about using the same XML processing for RSS 1.0, as you would for RSS 2.0.

However, compatibility between the RDF/XML and XML versions of RSS is much thinner than my previous essay might lead one to believe. In fact, looking at RSS as a demonstration of the “XMLness” of RDF/XML causes you to miss the bigger picture, which is that RSS is basically a very simple, hierarchical syndication format that’s quite natural for XML; its very nature tends to drive out the inherent XML behavior within RDF/XML, creating a great deal of compability between the two formats. Compatibility that can be busted in a blink of an eye.

To demonstrate, I’ve simplified the index.rdf file down to one element, and defined an explicit namespace qualifier for the RSS items rather than use the default namespace. Doing this, the XML for item would look as follows:

<rss:item rdf:about=””>
<rss:link> <dc:subject>From the Book</dc:subject>

Though annotating all of the elements with the rss namespace qualier does add to the challenge of RSS parsers that use simple pattern matching, because ‘title’ must now be accessed as ‘rss:title’, but the change still validates as valid RSS using the popular RSS Validator, as you can see with an example.

Next, we’re going to simplify the RDF/XML for the item element by using a valid RDF/XML shortcut technique that allows us to collapse simple, non-repeating predicate elements, such as title and link, into attributes of the resource they’re describing. This change is reflected in the following excerpt:

<rss:item rdf:about=””
dc:subject=”From the Book”
dc:date=”2003-09-25T16:28:55-05:00″ />

Regardless of the format used, the longer more widely used approach now and the shortcut, the resulting N-Triples generated are the same, and so is the RDF model. However, from an XML perspective, we’re looking at a major disconnect between the two versions of the syntax. In fact, if I were to modify my index.rdf feed to use the more abbreviated format, it wouldn’t validate with the same RSS Validator I used earlier. It would validate as proper RSS 1.0, and proper RDF/XML, and valid XML — but it sings a discordant note with existing understanding of RSS, RSS 1.0 or RSS 2.0.

More complex RDF/XML vocabularies that are less hierarchical in nature stray further and further away from more ‘traditional’ XML even though technically, they’re all valid XML. In addition, since there are variations of shortcuts that are proper RDF/XML syntax, one can’t even depend on the same XML syntax being used to generate the same set of triples from RDF/XML document to RDF/XML document. And this ‘flexibility’ must burn, veritably burn, within the stomach of XML adherents, conjuring up memories of the same looseness of syntax that existed with HTML, leading to XML in the first place.

It is primarily this that leads many RDF proponents as well as RDF/XML opponents into preferring N3 notation. There is one and only one set of N3 triples for a specific model, and one, and only one RDF model generating the same set of N3 triples.

Aye, I’ve walked a mile in Simon’s shoes and I’ve found that they’ve pinched, sadly pinched indeed. However, I’ve also gained a much better understanding of why the earnest and blithe referral to automated generation and consumption of RDF/XML, when faced with criticism of the syntax, isn’t necessarily going to appease XML developers, now or in the future. The very flexibility of the syntax must be anathema to XML purists.

Of course, there are arguments in favor of RDF/XML that arise from the very nature of the flexibility of the syntax. As Edd Dumbill wrote relatively recently, RDF is failure friendly, in addition to being extremely easy to extend with its built-in understanding of namespace interoperability. And, as a data, not a syntax person, I also find the constructs of RDF/XML to be far more elegant and modular, more cleanly differentiated, than the ‘forever and a limb” tree structure of XML.

But I’m not doing the cause of RDF and RDF/XML any good by not acknowledging how easy is it to manipulate the XML in an RDF/XML document, legitimately, and leave it virtually incompatible with XML processes working with the same data.

I still prefer RDF/XML over N3, and will still use it for all my application, but it’s time for different arguments in this particular debate, methinks.


TRO For all horse meat plants set to same date


Update on Front Range Equine Rescue et al v. Vilsack et al:

Responding to a filing yesterday, Judge Armijo agreed to set the expiration date for the TRO for Rains Natural Meats to the same date as the other two plants: October 31, 2013. By that time, Judge Armijo will have a decision in the case.

Rains Natural Meats has asked the court to include it in the bond set by Magistrate Judge Scott. In the meantime, the USDA has filed a Supplemental Administrative Record covering Rains. I have issued a FOIA for the associated documents. I am particularly interested in reading the communications related to not needing a wastewater permit from the Missouri DNR.

You can see all of these documents at Docs at Burningbird.

There was also a hearing in the Missouri court case related to Missouri DNR being prohibited from issuing wastewater permits for horse meat plants. I don’t have access to these court documents, but can guess from the docket filings (available on Case Net) that the purpose of the hearing was to expedite a decision on this case, too



Recovered from the Wayback Machine.

The RDF vocabulary used throughout the examples for Practical RDF is PostCon, example here, a Post Content information dataset. The plan was that I would finish the book and then finish a Java implementation of PostCon, the application, using PostCon, the vocabulary, before the book hit the street.

What I wasn’t counting on was that I wouldn’t have a Tomcat server to run the Java application on when it was finished. I am running my own server, but it’s shared by other folks and at this point in time, a Tomcat server would be too much for it.

I also wasn’t counting on how tired I was once the book was finished. When you’ve worked on a book for two years, through four major rewrites trying to keep up with changing specifications and attitudes and tools, you get tired. I got tired.

However, PostCon the application begs to be created, and PostCon the vocabulary begs to be used.

So, what is PostCon? PostCon is a vocabulary that records information about a web resource, its movement, whether it’s been replaced, and why, and so on. It’s also an application that will maintain a history of your web content in a form that can be used to redirect HTTP requests when a resource is moved; track history of changes without the necessity of a complex change control system; and provide intelligent error handling when a resource is removed permanently. You can see the early prototype in action with this link.

The application has a user interface that allows one to query the PostCon record for a resource, add to it or modify it, and then persist the changes. Additionally, the application has a web services interface that can be utilized from other applications, such as weblog tools like the one I’m using for this page. Since the information about the change is persisted in a file (RDF/XML) rather than a database, other tools could access this information, such as webbots trying to new resources, or checking to see if a resource is still viable.

The vocabulary is based on RDF, and serialized using RDF/XML, so other vocabularies can be plugged in, simply and easily. Information about the creator is maintained in the PostCon vocabulary and this can be tied to the creator’s FOAF file. If the web resource is a weblog page, trackback information can be used to add PostCon related items for the specific page. For that matter, comments can also be added as part of the history of the resource – after all, a commented weblog posting is different than the posting by itself.

The long and short of it is that I’m returning to working on PostCon, but rather than work on it in the background, I’m going to implement the pieces and document them here in this weblog. This will not only give me incentive to get off my butt and get this done, but it should also, I hope, give me some decent feedback if I’m pursuing a less than efficient implementation strategy.

To start, I’m going to review the PostCon vocabulary one more time, to see how I want to modify it considering new efforts with Pie/Echo/Atom (to be called Atom it seems – thanks to Morbus Iff cutting through the crap – yay Morbus). Next, I’ll implement simple pages that can be used to read in and modify the RDF/XML files for a specific resource. I’ll be implementing these in PHP so that they can be accessed from my server. Later I may translate these to Java and JSP.

Next, I’m creating a second RDF vocabulary, this one to be used by an event queue system. When a resource is moved or removed, not only will the front end update the associated RDF/XML file for the document, it will also update an event queue RDF/XML file, which will then track the actions to be performed on the server side. I prefer this rather than having the front end pages implement file destruction or movement because it’s easier to secure a completely server-side application, then one that’s half front-end, half server.

In addition, by separating this layer of activity out, the application that will take the event queue information and do the actual work can be replaced depending on server-side languages supported, OS, that sort of thing.

I’ll create two versions of the application that processes the event queue – one in Java, one in Perl. The Java application won’t need a Tomcat server (no front end), and I don’t want to focus on just one langauge for this component of the entire system.

The final phase of implementing PostCon will be creating web services that can perform all of the functionality of the front-end interface functionality created in PHP. I’d like to implement these in Python and Perl. Perl because I want to try integrating this into a test copy of Movable Type; and Python because I want to improve my Python skills.

The code will be kept simple, and clean, with no frills. In addition, it’s pure open source, and can be copied, modified, and hopefully improved. When I’m finished, I’ll load all of the code to Source Forge.

I have other things to do, so I’m not going to be whipping this out over the next week, but it should be finished within the next month – knock on wood.



Yesterday I went to the Meramec State Park to hike and continue my reaquaintence with my film camera. As I pulled off the freeway to Highway 185, I saw a semi blocking the road in both directions, hit by another semi when it had tried to pull intot the road from the right. I was close enough to see the drivers and the police and was surprised at how good natured everyone was. People were smiling, even laughing, as they worked to get the blocked semi out of the way.

Eventually, they did whatever they were going to do as the semi crawled around on its own power, limping down the road, a perfect word to use because it literally was limping on its right side. Once it was past, I could see why the reason for the humor — it had been hit by a semi who was hauling what was left of another wrecked semi truck.

I arrived at the park later in the afternoon, and pulled into the Visitor Center to get my bearings. Unfortunately, when I pulled in I stopped dead in the middle of the parking lot to look at my map, assuming no one was around. I didn’t see the Sheriff’s car directly behind me. When I realized I was blocking a car I pulled into a slot, but of course, the office pulled next to me and I thought he was going to give me a lecture, deserved, about how not to drive. Instead, he asked, “Ma’am, do you need help with something?”

Assumption of innocence is a wonderous thing.

“Yes, can you advise me which trails around here don’t have tics and chiggers?”

“Well, this time of year, it’s pretty bad walking anywhere in the Ozarks but the this trail over here,” he says, pointing to one off the Visitor Center, “I take my kids on it, and it’s pretty clear.”

Thanking him, and fate for dealing me a patient policeman, I checked out the trail he mentioned, but a criss crossing of webs across the path dissuaded me. I can’t stand walking through web, I just can’t stand it. Instead, I drove to the end of the park to walk the trails near the Meramec River and Fischer Cave.

Along the way I had to crawl down the road because deer were continuously crossing it. I could see movement in the forest around the road from the corners of my eyes and I was both thrilled and a little stressed because I didn’t want to hit a deer, even at 5MPH. What I almost did hit was a teenager who decided to strap on inline skates and hurtle down the hill towards me, assuming no one was around (or not caring). I pulled over to the side to let him past, wondering who was the ‘dumb animal’ on the road that night — the deer or the kid?

I made my way through the campground at the end of the park, nodding my head at the campers out walking because the weather was fine, real fine, warm, and dry, with a nice cool evening breeze. Instead of a trail I found a path down to the Meremac river, it being low enough for me to walk along the sandy bed.

The opposite side of the river is all tall limestone cliffs covered with trees, many of which are just barely beginning to turn colors — scarlet, orange, gold, but primarily still that wonderful brilliant green of the Missouri forests. Sometimes the colors are so sharp here, so clear and pure, especially when you see them in the early morning or late afternoon that you can almost feel them as texture in the air around you — velvet reds, smooth, cool green, and sharp, rough browns and oranges.

Birds were about, diving at insects over the water, many of which found their way to dine on me — my arm is swollen about the elbow by something that bit me, and I picked up a couple of chiggers along the way. However, being part of the food chain is the price you pay to enter heaven on earth, as my little sandy beach along the river was.

I walked along until I found an area shadowed on both sides, where the river water had pooled forming a semi-lake with branches of dead trees sticking out. I was taking photos of the cliff when I heard a splash and turned around just in time to see an eagle or large hawk grabbing a fish from the water and beating its way to the top of the trees and out of sight. Other predator birds were circling about, waiting their turn, and most likely my absence from their feeding ground. Bu I couldn’t leave.

I put my camera away and stood there, breathing in that sharp Missouri Green smell; listening to the orchestra of breeze and insect and bird; watching a hawk circling about as it hovered over the fish jumping in the water, all surrounded by that glorious color.

(This non-photo photographic moment is dedicated to Margaret Adam, who could probably use a pick-me-up about now.)


Slashdot review of book

Dorothea just sent me a heads up that Practical RDF has been reviewed at Slashdot. All in all, a nice review and I appreciate the author, Brian Donovan writing it.

In fact, all the reviews I’ve read — at O’Reilly, Amazon, Programming Reviews, and elsewhere — have been very positive. Most of the criticism has been on the book organization, with some people wanting more coverage of the specs, some wanting more coverage of the tools, some wanting less coverage of the XML. However, add all of the comments together and the organization probably fit the audience about as good as it could considering the topic.

Though this site is linked from the review, I’m not getting many hits, not compared to the traffic I received for Parable of the Languages. Probably a good thing because I’m maintaining this server, and slashdot proofing is a tough SysAdmin job.

Thanks Dorothea, for pointing out the review.

PS Thanks also to Rev Matt for heads up, as well as nice note in the /. thread.

Original archived at Wayback Machine