Lambda the Ultimate

I think Tim Bray's point is well-taken. It certainly should be since, as Tim reminds us, he helped to create the very syntax that he's criticizing. In the beginning of the definition of the XML serialization of RDF, I don't know that there was an adequate appreciation of the impedance mismatch between the graph-structured RDF data model and the tree-structured syntactic model of XML, and so I suspect that the mismatch manifests itself in that serialization. Frankly, I don't find the alternatives compelling, mostly because they punt on the graph structure and rely on a simple (simplistic?) representation of triples. While I understand that this is still just a serialization format, meaning that the graph structure will be reconstituted when the serialization is parsed, I find that the stated goal of readability of the serialization is not met since this vital aspect of the RDF data model is obfuscated by a triple-based representation.

So it seems to me that we're left with the argument that the alternative syntaxes can be read and written by hand. I also don't find this compelling, and the Dreamweaver/HTML analogy seems lacking: we're not talking about presentation of human bite-sized pieces of information that fit in a screen or two; we're talking about arbitrary amounts of machine-readable metadata. If we must confine ourselves only to what a single human being can hold in his/her head, or structures that can be trivially represented as trees, we radically reduce the scope of applicability of RDF. The challenge is to come up with the spreadsheet, if you will, of RDF: perhaps ground-breaking technology when it is first invented, but something that we all now take for granted to such an extent that if someone pulled out an actual, physical spreadsheet and started writing equations on it, we would quite rightly look at them funny. That's all the tool-builders want, and all the angst about "waiting for tools" and "complexity" seems misguided. Computers are here to shoulder the burden of complexity in a variety of application domains; why should structured metadata authoring be considered out of bounds? The fact that we don't currently know what such a "spreadsheet" should look like reflects the novelty of the domain, not the unworthiness of the goal.

Does it also say something about the urgency of the goal?

It also worthwhile to keep in mind that deciding that syntax form carries no useful semantic information depends, often enough, on implementation intuition. Is let syntactic sugar over lambda? The transformation is trivial enough. However, using let can provide a valuable hint to the interpreter.

Technically, it utterly fails its dual purpose of human and machine readability. Nobody is going to write XML by hand. On the machine front, it is both time and spatially inefficient.

On the market, XML is a train nobody can afford to loose. So even developers like myself that are aware of its technical deficiencies have to make sure their products talk it. Fortunately we can limit the extent of XML in our products to import/export facilities, and use technically sound formats internally.

For writing RDF textually, here's a couple of languages that surpass XML by lightyears:

- Prolog, and maybe just its fragment Datalog

- Dot, a language for annotated graphs, associated with GraphViz from AT&T Labs (www.graphviz.org)

For writing RDF visually, I've been looking for such a tool for ages, and since I seem to be a really bad surfer, I'd appreciate suggestions.

However, I agree that other syntaxes might be better.

IsaViz? Interestingly, it uses dot under the hood.

LtU is indeed horribly slow the last couple of days. Usually the site is much more responsive.

I admit I've missed large chunks, but I don't ever remember LtU being fast (at least after the first few months).

A smaller, but still interesting, proportion of people will generate XML from programs with some variant on 'print "<foo type="$bar">$baz</foo>"....' (code is Perl, principle applies to many languages).

I find RDF M&S revisited : From Reificationn to Nesting, from Containers to Lists, from Dialect to pure XML by Conen et al. one of the best papers in SWWS'01, The First Semantic Web Symposium. Conen et al. describe an extended RDF model and syntax. They use two syntaxes really. One is XML. The other has this grammar:

  R ::= r | '(' R ',' R ')' | '[' R ',' R ',' R ']'

to which they add a lot of syntactic sugar, e.g. commas are dropped, nested lists are flatten.

Example (section 3):

  [Gustaf says [Ecki likes (Reinhold Wolfram)]

This is expressed in 'flat' statements via reification and containers:

  [Gustaf says r1]
  [r1 rdf:type rdf:Statement]
  [r1 rdf:subject Ecki]
  [r1 rdf:predicate likes]
  [r1 rdf:object s1]
  [l1 rdf:type Seq]
  [l1 rdf:_1 Reinhold]
  [l1 rdf:_2 Wolfram]

An use statement would improved this already-better-than-XML syntax:

  [use rdf]
  [Gustaf says r1]
  [r1 type Statement]
  [r1 subject Ecki]
  [r1 predicate likes]
  [r1 object s1]
  [l1 type Seq]
  [l1 1 Reinhold]
  [l1 2 Wolfram]

Note the use statement is my proposal, not Conen at al.'s (nor anyone else's as far as I know, so maybe I should run to the patent office now...) Note I also changed _1 to 1. Obviously the integral numbers are not rdf names! Unnecessary complication is a plague in XML and RDF, and I suspect one of the things putting people off.

I have used this approach to prepare the submission of an OMF (weather observation markup format) into the DISA repository. The important part of the submission was the description of all the elements, attributes and documents -- in a format that closely resembles RDF. For some reason MITRE, which designed the repository, did not like RDF itself. When I mentioned RDF on one of the meetings, I was told that the RDF Recommendation was 'rushed' and was called 'Sir'.

In more detail, the example is described in Section 5 of
http://pobox.com/~oleg/ftp/papers/SXs.pdf

The reverse transformation, parsing of namespace-rich RDF documents (in particular, DAML ontologies) is also possible:
http://pobox.com/~oleg/ftp/Scheme/daml-parse-unparse.scm

It's trivial to convert the parsed ontology into a set of triples. OTH, we can use SXPath on the SXML tree directly.