#quixotechem #jiscyxz
I am still intrigued (?amazed) by the unpredictability of new ideas and technology on the Internet. All I do is fire off memes and see what happens. I’m reasonably experienced in creating memes. And even more experienced at non-memes. I’m no better at predicting success than anyone else
For example in 1994 Henry Rzepa and I developed Chemical MIME (a way of supplying chemical typing in mail and server headers). It didn’t take off in the IETF but when we released a package of free software and specs it raced through the Internet in weeks. Admittedly at that time the scientific Internet (the number of sites) was smallish but the difficulty of configuring clients and of distributing software was also difficult. I surmise that the meme (like a virus) has to have 3 essential features:
- The ability to infect someone, simply by its own power. For Chemical MIME this was the ability to display and rotate beautiful coloured molecules and to ask scientific questions. There was hardly a chemist in 1994 who would not go “wow!”. So infection was facile.
- A near-zero or zero cost of replication. If the host has to expend a lot of energy to create replicas of the memes then the process slows. (For example if the host has to manufacture “stuff” – as in the RepRaps – then most people will not replicate.) In the case of Chemical MIME all the host has to do is to clone the incoming material – this involves obtaining and mounting copies of the displayed molecules and free software.
- The desire to replicate and mutate. In this case the host wants to show the world what *they* can do. They create displays of their own molecules, which may be even more striking that the ones they saw. They also help to improve the process of replication – better tutorials, slicker web pages, improved software. So the process accelerates and prospers.
When we created Chemical Markup Language (in ca. 1994) we thought it might be rapidly copied – that in a year or two everyone would be using it. It needed 1997 to create XML but after that the world seemed to explode. We heard of financial consortia for XML which closed doors after 2 weeks. Tremendous hype. So clearly chemistry would be sucked up in the rush? Not quite.
In fact the same is true of MathML. It’s also taken its time. But both CML and MathML make steady progress. We keep hearing of new users and applications and we keep developing our toolkit. There isn’t an alternative to XML or similar language to represent the complexity of chemical documents (most of the legacy approaches deal only with molecules, or possibly simply reactions). CML can represent whole computations, crystal structures, preparations, etc.
“To everything there is a season” – I learnt at school (Ecclesiastes 3:1-8 NKJV) and timing is critical on the Internet. Because the Internet doesn’t care WHO wins, it just cares that someone does. So there was bound to be an Internet Encyclopedia, but Jimmy Wales’s wasn’t the first. Google was nowhere near the first search engine, but it hit an optimum of timing, design and performance. In rapidly changing fields – such as social networking – you have to hit everything at the right time. But some things have a different timescale. Launched too early, they fail to take off (or take root). Launched too late, and the early birds beat the latecomers. Like biological ecosystems we should expect great wastage. Ultimately if a meme has a potential place in an ecosystem its progenitors must keep launching it until it succeeds.
In WWII, Winston Churchill came up with the simple formula “We must KBO” (Keep Buggering On). It’s a simple, heartening formula. It evens out the highs and the many lows. It’s based on absolute faith that one will succeed. During the low periods you have to keep going, however boring, hopeless, however many setbacks. Rather than the heady explosion of Chemical MIME, CML has been a long long slog. There’s never been any Gartner curve (Hype cycle – Wikipedia). No peak of inflated expectations; no trough of disillusionment. Mainly long slog, with general apathy, sometimes hostility, and occasional positive moments.
There have been many friends on the journey: The Blue Obelisk; the Earth Science community; Microsoft Research; the bioscience community; and others. The time is now coming. We’re continually finding people who are starting to use CML. We’ve got a million lines of Open code written. There are clear applications – semantic publishing, computational chemistry, crystallography which simply cannot be done by other technologies.
And there’s the Open semantic revolution. Conventional tools cannot support either of these – it needs a rich structured language technology with vocabulary support.
It’s the ultra-rapid takeoff of Quixote which has finally convinced me that the technology is mature enough for success. We’re on JUMBO5. Stable. Schema 2.4. Stable. Tools for much of the computational work. 200,000 structures in Crystaleye. 200,000 downloads of Chem4Word.
There’s a lot more “buggering on” required. “Blood on the floor at midnight” it feels like to me. Rewriting the code for the 5th time isn’t fun. The Blue Obelisk has been a lifesaver. The breathing space in Chem4Word has given us a stable, viable, robust validating toolkit. The Earth science experience has given us belief in a whole sector – compchem. Quixote has been a delight.
We have tunnelled through to the Slope of Enlightenment (in Gartner’s terms). If you want to join in, now is the start of a highly productive time.
Chemical MIME is not official, though, and there was discussion on the Kalzium bug tracker [0] last week, urging the use of chemical MIMES to be removed. Why has the step never been made to make them official?
Anyway, I think you/we/the Blue Obelisk should really try to make them official…
0.https://bugs.kde.org/show_bug.cgi?id=235563
Yes, will be better if chemical MIMEs are officially registered.
It doesn’t seem too difficult to apply.
IANA application for registering Media Type http://www.iana.org/cgi-bin/mediatypes.pl
Some argue a web servicesystem is not really RESTful if it uses unofficial MIME types, and this is not without a reason. See http://tech.groups.yahoo.com/group/rest-discuss.
Sorry, Nina it won’t work. See my blog post. Chemical is not, and won’t be, a toplevel type
Well, whatever the reason for that decision, perhaps it make sense to change Chemical MIMEs a bit?
e.g. “application/chemical-smiles” ?
Internet works via standardisation and registries, MIME types are no exception, although perhaps less critical than registering IP and DNS addresses.
>>Well, whatever the reason for that decision, perhaps it make sense to change Chemical MIMEs a bit?
e.g. “application/chemical-smiles” ?
It’s not “a bit”. It’s probaly 10,000 servers – I don’t know. A few days work each = 100 person-years
>>Internet works via standardisation and registries,
Fully agreed.
>>MIME types are no exception, although perhaps less critical than registering IP and DNS addresses.
How many HTML files are there that do not conform to any specification? probably 100 billion or more. I don’t like that either. But the authoring software that created the junk is still being used and sold.
We probably got it wrong. We probably should have used x-chemical/smiles. There is no guarantee that this would have worked. How does IANA take in new x- types? It doesn’t – how do MIME processing applications deal with x-chemical? I have no idea. I bet half of them will fail.
So application/chemical-smiles would have worked in 1995. we debated it. There were good reasons for having a toplevel chemical type. We thought we would get it. We nearly did. All the time that we exposed the Draft people were creating documents with chemical/x-*. If the draft had succeeded they would have been valid. It didn’t. We guessed the future and the future didn’t oblige.
If you now change all the chemical/x-pdb to application/chemical-pdb many if not all of the molecules on the web will fail to display. Jmol will stop working over the web. A reasonable, 3-year solution would be to develop a content-negotiation approach and to expose multiple chemical/ types. How many chemists know hoe to do content-negotiation. I didn’t till a week ago. I still don’t know what a good design is.
So, in an ideal world, I would add a compliant MIME type alongside the old mime type and gradually deprecate the old one. That will take years. It might happen. If you can make it happen in 3 months across the whole world, then fine. If not the change introduces more chaos than it solves. For most people it’s not broken. For a few people (and I don’t know who they are) it’s broken in some way. I don’t know whether it’s serious or there are workarounds.
Give us a concrete set of suggestions with the pros and cons and I’ll be happy to comment. But be sure to include the effort involved as well as the benefits.
>>It’s not “a bit”. It’s probaly 10,000 servers – I don’t know. A few days work each = 100 person-years
There could be few years transition time. And also it is not difficult at all to support both “old” and “new” MIME types for 10 years from now.
>>How many HTML files are there that do not conform to any specification?
This is slightly different question. You should have asked “How many web sites provide content, which is not “text/html” MIME type and how many browsers can support it straight away.
>>How many chemists know how to do content-negotiation. I didn’t till a week ago. I still don’t know >> what a good design is.
There is no need to learn how to do content-negotiation yourself, all REST libraries these days have this embedded. You just define what MIME types a REST service needs to support and may even not be aware this is known under “content negotiation”. If one prefers to work low level, than certain knowledge of network protocols is essential.
Most chemists will not write software anyway and lot of them will use only “clickable” software, not command line, not being aware what’s running behind user interface. (I might be overgeneralizing, this is my own experience, not being a chemist myself).
>So, in an ideal world, I would add a compliant MIME type alongside the old mime type and gradually >deprecate the old one. That will take years.
No problem with this at all.
>Give us a concrete set of suggestions with the pros and cons and I’ll be happy to comment. But be >sure to include the effort involved as well as the benefits.
Provide alternative (IANA acceptable) chemical MIMEs. Encourage to support both for long time.
Pros:
– Application developers will be ensured this is an internet standard. There will be no reasons for reporting bugs like the one for Kalzium.
– Chemical Web service providers will be encouraged to support registered MIME types, and not invent their own. Nowadays, it is typical to have chemical services returning MOL in text/plain.
It’s also typical to request chemical format via URL query option, rather than any content negotiation. This doesn’t sound as compatibility, nor as RESTful behaviour (whether it is good or not). In HTML world, one needs a web server and a web browser client. To consume (chemical) web services, one needs to write a new client every time a new service appears. It’s not only content negotiation that matters, but it’s part of the whole picture.
– Eventually browser vendors might be interested to provide native support.
Cons:
– More efforts, long transition period.
Few more links to discussions related to Chemical MIME not being registered by IANA :
http://lists.freedesktop.org/archives/xdg/2005-May/005244.html
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=420795