It’s just data


These days, if you happen to spot an RJ45 outlet in a hotel room, it is a pretty safe bet that you can assume TCP/IP over Ethernet.  It wasn't always that way.  I know a company that once was betting on SNA over Token/Ring.  Remember Banyan Vines?  NetWare?  NETBIOS?  To be sure, each of these still exist, but have been greatly marginalized by TCP/IP.

How did it get there?  Not by being better, or by ruthless marketing.  But by being the connector that glues things together.

Inter - net.  The network of networks.  Ostensibly designed as the bridge between incompatible networks, the allure of implementing just this one additional protocol to complement your native one ultimately begat the notion that TCP/IP was the only protocol one would ever need.

On one hand, I have little sympathy for those who see too steep of a learning curve in spelling a concept as rdf:about="uri" instead of <id>uri</id>.  Both are equally as templatable.

On the other hand, demanding that everybody does even this one simple step in a uniform fashion before any of the wonderful network effects that have been predicted pretty much makes this a non-starter.  Things like RDF Twig are great, but they address the wrong side of the equation if one is really serious about getting the initial bootstrap going.

Aaron's wonderful little hack points the way to the solution.  By adding this one line to your existing XML, you can have all the proper rdf:parseType elements sprinkled throughout your infoset in all the right places automagically.

Unfortunately, however, this hack relies on a leaky abstraction, namely support of XML parsers for attribute defaults.  Furthermore, the results are rather brittle as one stray attribute can render the document invalid.

The fulcrum that we need to focus on is the RDF parser.  If we can train that to intelligently consume a large subset of XML grammers, critical mass can be achieved.  One constraint, however.  This needs to be limited to the addition of at most one line to the XML.  Like a DOCTYPE, but more general.  Perhaps a PI like xml-stylesheet.  But instead of a general purpose stylesheet, perhaps it could be a special purpose grammar designed for the task, like XR.  Perhaps it could be as simple as a list of 3-tuples containing XPath expressions.  If not a PI, then perhaps a single element that needs to be dropped into whatever corresponds to a header section in the target grammar.

Let's turn this thing around.  Instead of requiring one to make their XML RDF friendly, let's make RDF XML friendly.  Or, at least make RDF meet XML half way.


Thanks for coming out with this. This is the obvious solution that offers the best of both worlds. XML is the lowest common denominator so to speak and so it makes little sense to replace this with RDF. BTW, I believe Danny Ayers already solved this problem with something called SSR. Originally it was a few elements but I recommended he use PIs (it's what I use internally) and I think he changed it. Like the sytle-sheet PI, it'd be trivial to define a PI that linked to a transform which would render the current XML document into "equivalent" RDF. Add support for this into the few standard RDF parsers and RDF advocates could finally fulfill their dream of turning everything from RSS, WSDL, Email and calendars into email.

I would like to emphasize that this is the way to go. I believe the exact opposite of what Shelly said earlier; this is not about standards it's about interoperability. Standards are not an end in of themselves they are merely a means towards interoperability which is the real goal. Forcing everybody to adopt complex (or even trivial) standards won't ever fly no matter how many times it's tried. But by using transformations it's possible to let everybody retain complete autonomy while still effecting arbitrary context transitions.

In this spirt of transformation I would also like to see a canonical transformation of an Atom feed into an RSS 2.0 and 0.91 feed with a strongly defined mapping between the different elements which is part of the Atom standard. Regardless of how you feel about RSS there's a lot of code out there already built for parsing RSS and an effort should be made to preserve the utlity of this code.

Posted by Bo at

Err, much of the above doesn'tmake sense but hopefully the core ideas got through. This is what happens when you go to bed at 6am.

Posted by Bo at

In response to making RDF XML friendly, just junk RDF with all it's constraints and use the XLink standard instead.  XLink does everything RDF does and then some with the addition of 3 or 4 attributes sprinkled on your own XML grammer.  How much more XML friendly can you get.  Hasn't anyone noticed that RDF standards mimic corresponding XML standards, RDF Schema vs. XML Schema, RDF Query vs. XML Query, etc.?  Seems like the RDF community is just reinventing existing XML standards.

Posted by Andy at

Sam, I wholeheartedly agree.  RDF needs to be able to work with any XML.  rdf:parseType is, in essense, what was called 'colors' in SML-DEV.  In SML-DEV, we recognized that the best place to apply 'colors' is not at the producer layer, but at consumer and middleware layers.

Posted by Don Park at

Just in case it isn't obvious, the above Andy is not me.  I just thought I'd note that if I have to make a daily effort to keep my blog XYZ compliant....It will just cease to be XYZ compliant.  It won't be a political statement or anything, just laziness.  I do nothing to support TCP/IP and yet here I am complying with it :-)

Posted by Andy at

Dare Obasanjo

  It seems we are on the same page. I thought I had misread all the various posts encouraging ATOM to be RDF-friendly when the only benefit that I could acertain was that if it didn't then in the future when everyone is using RDF you ATOM folks will be sorry but it seems this is the same conclusion you came to as well.

  As for some of the discussions about PIs and the like, what is wrong with an xml-stylesheet PI that points to your atom2rdf.xsl transform?

Message from Dare Obasanjo at

I like this.  I like it a lot.  Thank you Sam for reminding me of the xml-stylesheet PI - I had been hung up on the idea that there is no standardized way of specifying in an XML document how to turn it into some other kind of XML document.

It's unfortunate that xml-stylesheet doesn't seem to have a pseudoattribute defined to indicate the result format.  The only type attribute is for the type of the stylesheet itself.

Hmmm... the 'media' pseudoattribute might be amenable to this usage, as in:

<?xml-stylesheet alternate='yes' type='text/xml' media='robot, application/rdf+xml' title='RDF' href='...' ?>

On the other hand, an XSLT has a 'media-type' attribute which indicates it's output, so it might be sufficient to say:

<?xml-stylesheet alternate='yes' type='text/xml' title='RDF Version' href='...'?>

That puts a lot of work on the parser - it would have to look up each stylesheet in turn and examine their media-type for 'application/xml+rdf' - but at least it's automatable.

Posted by Avdi at

Exclusionary Policies and the Principle of Just Get By

I am disappointed in the comments related to the Pie/Echo/Atom posts and being RDF-enabled at Sam Ruby's Sam has a new posting today, Inter-Net, in which he writes: The fulcrum that we need to focus on is the RDF parser. If we can train that to... [more]

Trackback from Practical RDF


"The fulcrum that we need to focus on is the RDF parser.  If we can train that to intelligently consume a large subset of XML grammers...". I assume you're suggesting mappings between those grammars and the RDF model, which is a reasonable approach, at least you have a shared model. If a mapping is specified, then any XML parser can be used programmaticaly to extract the RDF model from the data. As Bo mentioned, I did something along these lines to RDF-ify RSS 2.0 with Simple Semantic Resolution (see also for more on the programmatic approach).

Personally I think it's worth looking some more at the alternate approaches before settling on anything. It would be nice to see some practical examples, this particular suggestion sounds like it needs a lot of work to get the RDF interop, though I could be wrong. Anyhow, there's a lot of ground and a lot of techniques in between plain XML and pure RDF/XML to explore.

fyi - some useful comments on using a DTD for default attributes :

Andy - please read some of the RDF documentation before talking about reinvention.

btw, in an earlier life I ran a Netware network, it worked a treat alongside TCP/IP too.

Posted by Danny at

What I find really compelling about this piece is the implied analogy that climaxes with this sentence:

"Ostensibly designed as the bridge between incompatible networks, the allure of implementing just this one additional protocol to complement your native one ultimately begat the notion that TCP/IP was the only protocol one would ever need."

Seen in this way, XML and it's relationship to it's ancestors is remarkably lucid.

Thanks, Sam! You definitely hit this one out of the park.

Posted by david at

While I am most definitely in support of efforts to be even more flexible in the ways in which RDF and XML can meet and interact, the following reminder (and this is purely a reminder) is most definitely worth stating:

RDF already meets XML halfway. That meeting point is called RDF/XML. And in meeting XML half way much is sacrificed in terms of capability, readability, ease of use, conciseness, etc. compared to, say, N3. Try to remember that RDF/XML was specifically designed to ease this process, and that while it has its warts and while tool support definitely needs to be improved in order to produce more XML-friendly results, the RDF working group worked (and continues to work) very hard to provide a good meeting point.

With the above in mind, one could easily argue that the ball is in the XML users' court. All that's needed now is recognition of potential, openness of mind, and an honest willingness to learn.

Posted by Jeremy Gray at

Jeremy: I want to the ball to be in everyone's court.

Posted by Sam Ruby at

Andy -

Much as I once liked XLink, it's gone pretty genuinely nowhere, outside of a few internal systems and half-hearted use in a few W3C specs.  I don't like RDF much, but even though I'd prefer XLink, I have a hard time seeing XLink as a plausible answer given its current state of adoption.  Even understanding of what it does (especially in extended links) is mostly MIA.

XLink also repeats some of RDF's more annoying habits, like the "URIs are the answer" vision for role and arcrole, not to mention XPointer's gratuitous use of namespace-qualification for scheme names that don't happen to be concocted by the W3C.  The WG has disbanded at this point as well.

As for RDF's reinventions, I think it's necessary.  XML is trees, RDF is graphs.  Applying tree tools to graphs produces an awful lot of infinite loops, and probably isn't a good idea anyway.

Posted by Simon St.Laurent at

Dare Obasanjo

Applying tree tools to graphs produces an awful lot of infinite loops, and probably isn't a good idea anyway.

Yup, imagine trying to query a graph containing circular links with XPath. Ouch.

Message from Dare Obasanjo at

more RDF vs. XML

Sam Ruby: Inter-net Man, this is getting thick.......

Excerpt from slouching toward bethlehem at

In Chapter 4 of "Towards The Semantic Web" the authors talk about a process of aligning ontologies.  The idea is you create an ontology (that develops over time) which takes in many XML documents (all in the same domain) and maps the data to this ontology.

The process takes the XML, converts it to RDF and then maps that onto the ontology. They defined something called RDFT that uses a small RDF schema to convert any XML into RDF.

The advantages are many.  The overall ontology can be controlled and evolved over time.  The process can be reversed to create any related XML format.  RSS 0.91 -> 2.0 or whatever.  If there is missing data or defaults that you want to add you use the RDF representation of the data.

So for syndication you can take any XML based one, convert it to the grand RDF ontology and spit out any other XML or RDF file format you want.

Posted by Andrew Newman at

Thanks for the refs Andrew. This looks reasonable as a general approach, but in the case of Atom we know a lot about the material being represented, and so can make a mapping that works at the semantic as well as structural level (or of course we could simply use RDF directly).

Heh - I just stumbled on a W3C Note Harvesting RDF Statements from XLinks.

Posted by Danny at


Comments to Shelley's post Exclusionary Policies and the Principle of My Way or the Highwaycontinue to accumulate. That post was...... [more]

Trackback from Raw Blog


RDF, XML and Interoperability

The Pie/Echo/Atom/Whatever discussion is bringing up the RDF/XML debate... yet again. On one side are the folks that say PEAW should use RDF/XML serialization, on the other side are the folks that say PEAW should just use some vanilla XML...... [more]

Trackback from snellspace


Let's Make RDF XML-Friendly

Sam Ruby kicked off an interesting thread that re-iterates my preaching over these many months. Quote: "Let's turn this thing around.  Instead of requiring one to make their XML RDF friendly, let's make RDF XML friendly.  Or, at least...

Excerpt from iBLOGthere4iM at

Blindsiding and Forward Thinking

When Sam Ruby invited me into an IRC chat last week to talk about creating a compliant RDF/XML syntax for Pie/Echo/Atom, I wasn't aware that there was an agenda behind this effort. Not until Sam published the full model at his weblog and discussed how... [more]

Trackback from Burningbird


In case you missed, here is some parallel thought that I had over XML and RDF interoperability: semanticsheets.

I came to the conlusion that "rdf:resource" is as bad as "font". we need people to concentrate on their markup in their content file and then explain others how to interpret that markup in a semanticsheet. it would give the best of both world and make everybody happy

But another thing is for sure, don't use XSLT for this but, just like CSS, a specially crafted semantic augmenting language, hopefully without angle brakets.

Posted by Stefano Mazzocchi at

My gut on RDF

I need to read Shelley's book, because I'm still fairly clueless about RDF. While I think it's silly to harp on colons in the format (would <a:href> really be all that hard to type or understand if that had been......

Excerpt from ephemera at


DanBri pointed me to a specification named GRDDL.  It looks like exactly what I was looking for last August.  Any XML file is one namespace declaration, one attribute definition, and one XSLT file away from RDF. Oddly, it defines a completely different... [more]

Trackback from Sam Ruby


My gut on RDF

I need to read Shelley’s book, because I’m still fairly clueless about RDF. While I think it’s silly to harp on colons in the format (would a:href> really be all that hard to type or understand if that had been......

Excerpt from Layers of Meta at

Add your comment