The NIH heard public comments yesterday on its plans for implementing PL 110-161 Section 218, a new law that grants the agency broad powers to intervene in the scientific publication system.

Scientific publishers were out in force. According to The Scientist, Jack Ochs of the American Chemical Society (ACS) was first in line to offer comments:

He started out by saying that a brief meeting was no substitute for the formal comments on rulemaking process like the one the NIH held when they were implementing the voluntary submission program in 2005. He was the first of several to call a halt to implementing the mandate so the details could be worked out.

A lot is riding on the outcome. The new law requires NIH grant recipients to deposit peer-reviewed manuscripts of their publications into PubMed Central, in apparent opposition to the policies of many leading scientific publishers - including the ACS.

NIH has given its grant recipients until April 7 before compliance will become mandatory. It remains unclear what steps, if any, ACS will take to enable authors to comply.

Unless ACS policy changes, NIH grant recipients face the possibility of losing one of the most prestigious publication options in chemistry.

Also see Peter Suber's comments.

How can the above atropisomers be represented without using explicit 3D coordinates?

Source: Clayden, Worrall, Moran, and Helliwell Angew. Chem. Int. Ed.

Startup School is set to take place again this year on April 19^th at Stanford University. Having gone last year, I can say it was well worth it. The one day event was a great chance to meet people with all levels of experience in starting companies. The speakers were amazing.

The speaker lineup looks at least as good as the one last year and includes Marc Andreessen (Netscape), Michael Arrington (TechCrunch), Jeff Bezos (Amazon), and David Heinemeier Hansson (37signals/Rails). Even so, some of the best speakers from last year were the ones not so well known.

If you're interested, you can apply to attend the event until March 23^rd.

A new law that introduces major changes in the way many U.S. scientific papers are published and redistributed is about to go into effect. Late last year, President Bush signed into law H.R. 2764 (now Public Law 110-161), part of which gives a broad new mandate to the NIH to intervene in the scientific publication system:

SEC. 218. The Director of the National Institutes of Health shall require that all investigators funded by the NIH submit or have submitted for them to the National Library of Medicine's PubMed Central an electronic version of their final, peer-reviewed manuscripts upon acceptance for publication, to be made publicly available no later than 12 months after the official date of publication: Provided, That the NIH shall implement the public access policy in a manner consistent with copyright law.

A new NIH Public Access Website describes how the agency intends to implement the law. Recipients of NIH funds have two options for complying:

1. If you choose to publish your article in certain journals, you need do nothing further to comply with the submission requirement of the Policy. See http://publicaccess.nih.gov/submit_process_journals.htm for a list of these journals.

2. For any journal other than one of those in this list, the author must:

   a. Inform the journal that the article is subject to the Public Access Policy when submitting it for publication.

   b. Make sure that any copyright transfer or other publication agreement allows the article to be submitted to NIH in accordance with the Policy. For more information, see the FAQ Whose approval do I need to submit my article to PubMed Central? and consult with your Institution.

   c. Submit the article to NIH, upon acceptance for publication. See the Submission Process for more information.

The new policy becomes effective April 7, 2008.

In other words, all recipients of NIH funds will soon have an obligation under Federal Law to disclose to journals not on the NIH's list that their work is subject to PL 110-161.

The question is: what will the journals, some of which represent the most prestigious in their field, do with this information?

What Will the ACS Do?

For an organization making a lot of noise recently about its new Web site and focus on communication with its members, the ACS has been very quiet on what what position, if any, it will take regarding the new law.

In fact, from the ACS Homepage, one might get the impression nothing has changed. Looking at the home pages for flagship journals with a large amount of NIH-funded content provided no insights, either; J. Med. Chem, J. Org. Chem., and Org. Lett. have nothing to say on PL 110-161 that I could find.

The ACS author copyright release form doesn't appear to have changed. In other words, when you agree to publish your article in an ACS journal, you're still handing over copyright in your work to the ACS, who has the right under Copyright Law (and presumably PL 110-161) to prevent NIH grant recipients from depositing their manuscript into PubMed Central.

Even the ACS Office of Policy and Legislative & Government Affairs has zero guidance, as of this writing, to offer prospective authors who may have questions about complying with PL 110-161.

Misplaced Burden of Compliance

One of the many problems with PL 110-161 Section 218 is that it places the burden of compliance on authors themselves, not publishers. The law states very clearly that implementations must be "consistent with copyright law." As I wrote previously, this provision gives all the latitude needed to continue business as usual, which is exactly what we're seeing so far.

Two critical questions remain unanswered:

• What obligation, if any, does the ACS have to reject manuscripts from NIH-funded authors, given that it remains ACS policy to take copyright from its authors and with it the right to deposit the accepted manuscript into PubMed Central?

• What obligation, if any, do NIH-funded authors have to avoid publication in journals that strip copyright from them and thereby prevent their ability to comply with PL 110-161?

In partial answer to the second question, the NIH offers this FAQ:

Whose approval do I need to submit my article to PubMed Central?

Authors own the original copyrights to materials they write. Consistent with individual arrangements with authors' employing institutions, authors often transfer some or all of these rights to the publisher when the journal agrees to publish their article. Some publishers may ask authors to transfer copyrights for a manuscript when it is first submitted to a journal for review.

Authors should work with the publisher before any rights are transferred to ensure that all conditions of the NIH Public Access Policy can be met. Authors should avoid signing any agreements with publishers that do not allow the author to comply with the NIH Public Access Policy.

Federal employees always may submit their final peer-reviewed manuscript to PubMed Central, because government works are not subject to copyright protection in the United States.

But even here the language is garbled. Saying that an author "should avoid signing any agreements with publishers that do not allow the author to comply with the NIH Public Access Policy" is not the same as saying authors "shall not sign any agreements with publishers that do not allow the author to comply with the NIH Public Access Policy."

The former describes a suggestion; the latter describes a punishable offense.

Regardless of whether or not PL 110-161 is good public policy, far greater clarity will be needed from both the NIH and scientific publishers if the new law is to be enforced effectively.

Image Credit: wili_hybrid

Disclaimer: I am not a lawyer.

Contrary to popular misconception, Java applets are a mature technology ideally suited for building highly interactive Web content. Although this hasn't always been the case, a lot has changed since Sun's introduction of Java over a decade ago. Previous articles in this series have discussed why the object tag alone can and should be used to deploy applets and how using the Javay deployment method can make life easier if you do. This article will address one of the most important questions of all when using applets: what happens if your user doesn't have Java?

Assume Your Users Won't Have Java

Java is ubiquitous, but it's not universal. Some users simply won't have a Java Virtual Machine (JVM) installed at all on their systems. Some will have one, but it will be disabled. Still others may have been browsing the Web for years, never realizing that Microsoft installed a hopelessly obsolete JVM on their machines without their knowledge, rendering useless a large amount of Web content.

Regardless of why they might not have the JVM your applet requires, assume that a good number of your users won't and plan accordingly.

But how?

The Javay Method and Deployment Failsafes

The Javay method for applet deployment can be broken down into three main parts:

1. Using the HTML 4 <object> tag - period. Neither <applet>, which is deprecated, nor <embed>, which isn't even part of HTML, are needed any longer.

2. Using Microsoft's conditional comments to create an opening object tag that will work with its browsers, but keeping it DRY by re-using the rest of the tag.

3. Suppressing the ridiculous "Click to activate" message in IE 6/7 with jActivating.

In contrast to other approaches, with the Javay method, we can:

• Know our applet will instantiate on all major browsers, and many niche browsers as well.

• Work only with standards-compliant HTML from start to finish.

• Stop using document.write to create tags, a method which unless properly trapped will silently fail without any indication of what's wrong when JavaScript is disabled or if the script fails for some other reason.

But perhaps the biggest advantages of the Javay method are the ones most often overlooked:

• It offers a cross-browser method to display failsafe content should Java be disabled or not installed.

• It provides a highly effective, cross-browser method for users to install Java directly from the page displaying the applet.

How the Failsafe Works

When modern browsers such as Firefox and Internet Explorer encounter an <object> tag requesting a plugin they don't understand, they do two very useful things:

1. They render any valid HTML appearing after the <object> tag's child <param> elements.

2. They prompt the user to install the correct plugin to view the content - without redirecting them to another page.

These two behaviors give us everything we need to gracefully fail if the Java plugin is unavailable. When the Java plugin is installed and enabled, users see the applet as planned. When the Java plugin is either not installed or disabled, users see both a placeholder of our choosing and a prompt, created by the browser itself, offering to install the missing plugin.

The <object> tag lets us take this even further. We can specify, down to the revision level, the exact version of Java needed to run an applet. If that requirement changes, all we need to do is change the <object> tag and users will be prompted to upgrade their JVM the next time they see our applet - if necessary.

Live Demo

Here's my company's 2D chemical structure editor, ChemWriter, deployed with the Javay method:

And here's what the failsafe code looks like when it's rendered:

One More Thing

We can take failsafes to yet another level, if we'd like. Let's say Joe comes to our site without the an installed Java plugin. Internet Explorer 6 informs him via a popup that Java is needed. Impatient to see the site's content, he closes the dialog. Without being redirected, Joe can see all of the site's content, except for the parts requiring Java, for which he sees a custom "Plugin Not Found" placeholder. Discovering that the site's content consists of highly-relevant information, he decides he wants to install the Java plugin after all. Clicking on placeholder image takes him to a Java installation page.

Unlike other Java installation pages Joe may have seen, this one is specific to his browser, Internet Explorer 6.

This approach work very well in practice. For example, my company's website, metamolecular.com uses it. Try visiting the default Java installation page, and if your browser is included below, you'll be redirected to the browser-specific Java installation page:

• Default Page

• Firefox Page

• Internet Explorer 6 Page

• Internet Explorer 7 Page

• Safari Page

More information can be found in this article on deploying ChemWriter.

Last Thoughts

Java applets gained a deserved reputation in the late '90s for being difficult to deploy, a view that's now worth reconsidering. Using some simple techniques, Web applications can fail gracefully if Java is unavailable and then take steps to quickly get users back on track.

Getting software reliably and securely installed on any client system is difficult, especially on the open Web. But the Java plugin and the Javay deployment method make it about as straightforward as it can possibly be.

It's time reconsider applets.

Image Credit: brrtha