hackability

Adam Bosworth has some good advice for would-be standards developers in the form of a 7 item list. It is strangely reassuring to know that someone in the US Federal Government called someone like Adam for advice about standards…even if it was at some inhuman hour. Number 5 really resonated with me:

Always have real implementations that are actually being used as part of [the] design of any standard … And the real implementations should be supportable by a single engineer in a few weeks.

It is interesting because I think it could be argued that #1, #2, #4, #6 and #7 largely fall out from really doing #5.

  • Keep the standard as simple and stupid as possible.
  • The data being exchanged should be human readable and easy to understand.
  • Standards should have precise encodings.
  • Put in hysteresis for the unexpected.
  • Make the spec itself free, public on the web, and include lots of simple examples on the web site.

That leaves #3 Standards work best when they are focused — which seems to be a really tricky one to get right. Maybe it comes down to being able to say No to the right things, to keep scope creep at bay. Or to be able to say:

Stop It. Just Stop.

to ward off complexity, like Joel Spolsky’s Duct Tape Programmer. But I think #3 is really about being able to say Yes to the right things. The right things are the things that bind together the most people involved in the effort. Maybe it’s the “rough consensus” in the Tao of the IETF:

We reject kings, presidents and voting. We believe in rough consensus and running code.

Whatever it is, it seems slippery and subtle — a zen-like appreciation for what is best in people, mixed with being in the right place at the right time.

We’ve got five years, my brain hurts a lot

Recently there’s been a few discussions about persistent identifiers on the web: in particular one about the persistence of XRIs, and another about the use of HTTP URIs in semantic web applications like dbpedia.

As you probably know already, the w3c publicly recommended against the use of Extensible Resource Identifiers (XRI). The net effect of this was to derail the standardization of XRIs within OAISIS itself. Part of the process that Ray Denenberg (my colleague at the Library of Congress) helped kick off was a further discussion between XRI people and the w3c-tag about what XRI specifically provides that HTTP URIs do not. Recently that discussion hit a key point by Stuart Williams:

… the point that I’m trying to make is that the issue is with the social and administrative policies associated with the DNS system – and the solution is to establish a separate namespace outside the DNS system that has different social/adminsitrative policies (particularly wrt persistent name segments) that better suits the requirements of the XRI community. There is the question as to whether that alternate social/administrative system will endure into the long term such the the persistence intended guarantees endure… or not – however that will largely be determined by market forces (adoption) and ‘crudely’ the funding regime that enables the administrative structure of XRI to persist – and probably includes the use of IPRs to prevent duplicate/alternate root problems which we have seen in the DNS world.

It’ll be interesting to see the response. I basically have the same issue with DOIs and the Handle System that they depend on. Over at CrossTech Tony Hammond suggests that the Handle System would make RDF assertions such as those that involve DBPedia more persistent. But just how isn’t entirely clear to me. It seems that Handles like URLs are only persistent to the degree that they are maintained.

I’d love to see a use case from Tony that describes just how DOIs and the Handle System would provide more persistence than HTTP URLs in the context of RDF assertions involving dbpedia. As Stuart said eloquently in his email:

Again just seeking to understand – not to take a particular position

PS. Sorry if the blog post title is too cryptic, it’s Bowie’s “Five Years” which Tony’s post (perhaps intentionally) reminded me of :-)