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.
Sam,
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.
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.
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.
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 :-)
Sam,
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?
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:
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.
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]
"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 http://dannyayers.com/archives/001719.html 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.
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.
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.
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.
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.
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).
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]
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...
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]
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.
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......
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]
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......