Internet Alchemy

An interview with Elliote Rusty Harold in which he discusses the question: What’s Wrong with XML APIs?

Some APIs, such as DOM, are simply wildly broken and complex in ways that they don’t need to be. Other APIs are too simple in that they don’t completely and correctly model XML. These APIs try to pretend that XML is simpler than it actually is.

Any reasonable XML API will have some rough spots, because XML has rough spots. Some of those rough spots are design flaws in XML, but an API shouldn’t be trying to fix that. A few APIs are both too simple and too complicated at the same time. The designers tried to throw in so many features that the API became excessively complex and hard to understand simply by its sheer size, while at the same time, they didn’t actually get all aspects of XML correct.

Norman Walsh has some words to say about RDF in RSS on his new weblog:

My problem is that "almost RDF" formats are a pain in the ass, just like all the other "almost" formats you’ve ever encountered. Yes, the transformation to RDF is easy with XSLT, but it’s still an extra step.

From my perspective, the added complexity of RDF in RSS seems pretty minor and the payoff is less irritation for me. I call that a win. But I’m prepared to believe my perspective is a bit skewed.

It’s worth checking out how Norman runs his weblog since it includes all kinds of juicy docbook, rdf and xslt goodness.

I’ve written an article over at Semantic Planet called Parsing FOAF with PHP which shows how to use the rather nifty RAP RDF parser for PHP to parse FOAF files.

After reading this article by Ben Hammersley, it stuck me that what the weblog community needs is a Weblog API Multiplexer service. This would be a service that would accept a ping containing some posting info, e.g. the entry’s trackback snippet and then make all the various weblogs.com, blo.gs etc pings for you, thereby reducing server load for thw weblog author. To make it a completely hands-off operation API developers should be able to register their APIs with the multiplexer, specifying what information they require, and get added to the ping list automatically.

This site is a brilliant illustration of the power of CSS. It challenges designers to supply a stylesheet with artwork to restyle the site’s home page without changing any HTML. Some of the designs are stunning (The Garden Beneath, Dead or Alive, Boddhidarma); I can hardly believe they share the same HTML.

Sam Ruby:

While it was greatly maligned, RSS 0.90 really wasn’t all that much different from RSS today. What it got right was that things like titles were represented as <title> instead of <PV name=”title”>.

I’ve realised that I’m unconciously using a subset of
the RDF/XML serialization syntax. My mind must have read the spec, absorbed shedloads
of RDF over the years and filtered out all the bits
that aren’t immediately useful. Now that we’re all fired up
about the syntax issues it might be prudent to write them down. So
here are my informal style rules for writing RDF/XML:

• Do use typed nodes (rss:channel, foaf:Person) - makes the RDF so much more readable.
• Do use anonymous nodes - assigning a URI is making a long term commitment.
• Do use xml:lang - we’re using XML for a reason
• Do use rdf:about instead of rdf:ID - keeps the notation simpler.
• Do use rdfs:seeAlso, but give some other properties too - let people know where to find out more, but give them something now.
• Don’t write properties as attributes unless you’re hiding RDF in XHTML - it’s inconsistent.
• Don’t use collections - their semantics have been removed away anyway
• Don’t use rdf:parseType - it’s for squeezing random stuff into RDF
• Don’t use rdf:datatype - maybe can you use a resource instead of a literal?

Using these rule would lead me to write the example from the RDF spec as the following. Note I’ve introduced
another vocabulary to remove those rdf:Descriptions.

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:dc="http://purl.org/dc/elements/1.1/"
         xmlns:ex="http://www.example.com/terms/"
         xmlns:foaf="http://xmlns.com/foaf/0.1/">

  <foaf:Document rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
    <dc:title>RDF/XML Syntax Specification (Revised)</dc:title>
    <ex:editor>
      <foaf:Person>
        <ex:fullName>Dave Beckett</ex:fullName>
        <ex:homePage rdf:resource="http://purl.org/net/dajobe/" />
      </foaf:Person>
    </ex:editor>
  </foaf:Document>
</rdf:RDF>

Since we’re talking about RDF serialization, what’s the most basic XML serialization possible? One answer might be a serialization of the graph itself:

<graph>
  <!-- Here's my data -->
  <node id="n1" label="http://www.w3.org/TR/rdf-syntax-grammar" />
  <node id="n2" label="RDF/XML Syntax Specification (Revised)" />
  <node id="n3" />
  <node id="n4" label="Dave Beckett"/>
  <node id="n5" label="http://purl.org/net/dajobe/"/>

  <arc from="#n1" to="#n2" label="http://purl.org/dc/elements/1.1/title" />
  <arc from="#n1" to="#n3" label="http://www.example.com/terms/editor" />
  <arc from="#n3" to="#n4" label="http://www.example.com/terms/fullName" />
  <arc from="#n3" to="#n5" label="http://www.example.com/terms/homePage" />
</graph>

It looks pretty simple and I can see how it would be easy to draw the graph on a piece of paper just by following the instructions. However, it misses out a lot of the implied graph that the standard XML serialization supplies such as which nodes are literals or resources. Here’s the same graph again with the RDF stuff explictly shown:

<graph>
  <!-- Here's my data -->
  <node id="n1" label="http://www.w3.org/TR/rdf-syntax-grammar" />
  <node id="n2" label="RDF/XML Syntax Specification (Revised)" />
  <node id="n3" />
  <node id="n4" label="Dave Beckett"/>
  <node id="n5" label="http://purl.org/net/dajobe/"/>

  <arc from="#n1" to="#n2" label="http://purl.org/dc/elements/1.1/title" />
  <arc from="#n1" to="#n3" label="http://www.example.com/terms/editor" />
  <arc from="#n3" to="#n4" label="http://www.example.com/terms/fullName" />
  <arc from="#n3" to="#n5" label="http://www.example.com/terms/homePage" />

  <!-- Here's some of the RDF stuff that is inherent in the normal RDF serialization-->
  <node id="rdfsResource" label="http://www.w3.org/2000/01/rdf-schema#Resource"/>
  <node id="rdfsLiteral" label="http://www.w3.org/2000/01/rdf-schema#Literal"/>
  <node id="rdfProperty" label="http://www.w3.org/1999/02/22-rdf-syntax-ns#Property"/>
  <node id="rdfType"  label="http://www.w3.org/1999/02/22-rdf-syntax-ns#type" />

  <arc from="#n1" to="#rdfsResource" label="http://www.w3.org/1999/02/22-rdf-syntax-ns#type"/>
  <arc from="#n2" to="#rdfsLiteral" label="http://www.w3.org/1999/02/22-rdf-syntax-ns#type"/>
  <arc from="#n3" to="#rdfsResource" label="http://www.w3.org/1999/02/22-rdf-syntax-ns#type"/>
  <arc from="#n4" to="#rdfsLiteral" label="http://www.w3.org/1999/02/22-rdf-syntax-ns#type"/>
  <arc from="#n5" to="#rdfsResource" label="http://www.w3.org/1999/02/22-rdf-syntax-ns#type"/>
  <arc from="#rdfType" to="#rdfProperty" label="http://www.w3.org/1999/02/22-rdf-syntax-ns#type"/>

  <node id="n6"  label="http://purl.org/dc/elements/1.1/title" />
  <node id="n7"  label="http://www.example.com/terms/editor" />
  <node id="n8"  label="http://www.example.com/terms/fullName" />
  <node id="n9"  label="http://www.example.com/terms/homePage" />

  <arc from="#n6" to="#rdfProperty" label="http://www.w3.org/1999/02/22-rdf-syntax-ns#type"/>
  <arc from="#n7" to="#rdfProperty" label="http://www.w3.org/1999/02/22-rdf-syntax-ns#type"/>
  <arc from="#n8" to="#rdfProperty" label="http://www.w3.org/1999/02/22-rdf-syntax-ns#type"/>
  <arc from="#n9" to="#rdfProperty" label="http://www.w3.org/1999/02/22-rdf-syntax-ns#type"/>

</graph>

Still easy to draw, but probably a lot harder to conceptualise. Well I can’t anyway - maybe says something about me. Merging two graph documents is a matter of rewriting all the id, from and to attributes so that they don’t clash. Does it pass the view source test? I don’t think so, but what do you think?

Tim Bray has followed up on his RDF ugly syntax posting yesterday with some more thoughts and analysis of the responses he receieved. It’s a debate that has to happen sooner or later. I think that most of us have been holding back until the latest suite of RDF specs have progressed to the recommendation stage. The current charter of the RDF WG states one of the deliverables as update the RDF Model and Syntax Specification (as one, two or more documents) clarifying the model and fixing issues with syntax. It’s essential that the model is watertight before we can do anything major with the serialization syntax.

Tim Bray is moaning about the RDF/XML syntax again.
I wrote about this last time
and even pointed Tim at my experiment. No response so far.

He disingenuously presents two examples of the same set of triples, the first in his
cryptic RPV format, the second in RDF/XML. Except that he’s changed the rules. In his RPV example he’s
not using namespace prefixes for his elements. Let’s see what RDF/XML looks like if we do the same for the RDF namespace:

<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:dc="http://purl.org/dc/elements/1.1/"
         xmlns:ex="http://www.example.com/terms/">

  <Description about="http://www.w3.org/TR/rdf-syntax-grammar"
                   dc:title="RDF/XML Syntax Specification (Revised)">
    <ex:editor>
      <Description ex:fullName="Dave Beckett">
        <ex:homePage resource="http://purl.org/net/dajobe/" />
      </Description>
    </ex:editor>
  </Description>

</RDF>

That looks a little easier to read doesn’t it?

I don’t like the mixture of attributes and elements, so I’ll rewrite it using just elements for the data:

<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:dc="http://purl.org/dc/elements/1.1/"
         xmlns:ex="http://www.example.com/terms/">
  <Description about="http://www.w3.org/TR/rdf-syntax-grammar">
    <dc:title>RDF/XML Syntax Specification (Revised)</dc:title>
    <ex:editor>
      <Description>
        <ex:fullName>Dave Beckett</ex:fullName>
        <ex:homePage resource="http://purl.org/net/dajobe/" />
      </Description>
    </ex:editor>
  </Description>
</RDF>

Now, looking at Tim’s example again, you can see he’s moved the collection of triples about Dave Beckett to
a seperate structure. We can do the same:

<RDF xmlns="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns:dc="http://purl.org/dc/elements/1.1/"
         xmlns:ex="http://www.example.com/terms/">

  <Description about="#Dave">
    <ex:fullName>Dave Beckett</ex:fullName>
    <ex:homePage resource="http://purl.org/net/dajobe/" />
  </Description>

  <Description about="http://www.w3.org/TR/rdf-syntax-grammar">
    <dc:title>RDF/XML Syntax Specification (Revised)</dc:title>
    <ex:editor resource="#Dave" />
  </Description>
</RDF>

Now compare this to Tim’s RPV version and tell me which one is easier to read:

<RPV xmlns="http://www.rdf.net/rpv/">
  <R id="Dave" pbase="http://www.example.com/terms/">
    <PV p="fullName">Dave Beckett</PV>
    <PV p="homePage" v="http://purl.org/net/dajobe" />
  </R>
  <R r="http://www.w3.org/TR/rdf-syntax-grammar">
    <PV p="http://www.example.com/terms/editor" v="#Dave" />
    <PV p="http://purl.org/dc/elements/1.1/title">
    RDF/XML Syntax Specification (Revised)
    </PV>
  </R>
</RPV>

PS It’s been suggested to me that Tim’s complaint is not that RDF/XML is hard to read but that it’s hard to parse with tools like XSLT. I don’t buy this. What makes RDF/XML hard to parse with structural based tools like XSLT is the model, not the syntax. Since RPV shares the same model it’s no easier to parse.