From Open Source Publishing 2.0
Save LaTeX (All) |
Save LaTeX (Body)
\section{Introduction}
The last ten years has seen an evolution in how research is published. This evolution began when databases such as INSPEC went online to allow users to search for articles. Competition encouraged publishers to publish online. All this innovation was essentially market driven as users demanded easy access to content. Presently, the new content of every journal in engineering is available online and some journals are published online only. There is also a growing movement by university researchers, administrators and librarians to make journal content open and free to all~\cite{Taxpayeraccess.org,Tanner2006:,cic_provosts,cic_provosts_addendum}. This movement is a consequence of publishers putting their content online; the value they add by printing and distributing the material no longer seems worth the cost. Indeed, for-profit journal publishing is a very good business, e.g. the operating profit margin for Elsevier's journal publishing division was an astounding 30.5\% in 2006 and Candover and Cinven, a private investment firm, bought Springer and Kluwer for a combined \euros{1.5b} in 2003~\cite{arl.org}. Every non-profit publisher studied showed publishing revenues exceeded expenses.\footnote{It appears the publishing divisions of non-profits are not run efficiently with no pricing pressure in the industry.}
One response to this movement for open access is to shift the cost burden of publishing onto the author. The Public Library of Science (PLoS)~\cite{plos.org} is the best-known such case. They have been publishing online since 2003 and have seven journals. They charge each author between \$2100 and \$2750 to publish a paper but do give fee waivers. It is not clear if the difference in fees is market or production cost driven. With roughly 20 paying authors per month, this would suggest that PLoS Medicine costs about \$600,000 per year to publish. While this seems like a lot, PLoS is targeting the very high end, does substantial editing, has offices in downtown San Francisco, and has invested a great deal in their web site.
PLoS with their special PLoS ONE~\cite{plosone.org} journal (\$1250 per paper) and other publishers such as Nature with Nature Preceding and the European Geosciences Union with Atmospheric Chemistry and Physics (ACP) are just beginning the next evolution in publishing--reader/reviewer interaction, but implemented in very different ways.
With ACP~\cite{copernicus.org}, submissions are done as any other journal and the editor, with assistance from select reviewers, pre-screens the papers. If accepted, the paper is professionally typeset and posted in ACPD(iscussion) as a discussion paper. The paper is open for discussion for eight weeks during which time the official reviewers submit their reviews (which are open for all to see) and registered users comment. The authors can respond at any time to the reviews. Once revisions are made, the authors submit a final version for consideration by the editor. Based on the reviews, the editor decides to accept the paper into the archival ACP journal or reject it.
The PLoS ONE journal has a more closed review process that is essentially identical to traditional journals. Once a paper is accepted by the editors, it is typeset, but not copyedited, and published.\footnote{Users are encouraged to pay a scientific editing service to improve the readability.} The paper is then open for annotating and discussion. The benefit is not clear, other than allowing readers to point out typos and publicly discuss the paper. The annotation system is quite clever and implemented in Javascript. A similar feature will be part of the Open Source Publishing System (OSPS).
Nature Publishing's system called Nature Precedings~\cite{precedings.nature.com} is closest to what is proposed here. From their web site, ``Nature Precedings is a place for researchers to share documents (...). It provides a rapid way to disseminate emerging results and new theories, solicit opinions, and record the provenance of ideas. It also makes such material easy to archive, share and cite.'' They will accept any work that fits into the scope of the journal--biomedicine, chemistry and the earth sciences; they explicitly do not accept articles in the physical sciences. All submissions are converted to PDF and cannot be edited once submitted. Users can post (attributed) comments about any submission. A voting system is used to acknowledge good submissions and rank them in terms of popularity. While Nature Precedings is a great place to publish preliminary ideas and findings, most of engineering is excluded from it and it is not designed to foster the growth of virtual organizations.
The coming evolution will use of so-called Web 2.0 technology extensively. While there are many different definitions of a Web 2.0 site, the publishing systems described above are not true Web 2.0 sites, although they use some of the technology. For example, PLoS ONE's annotation feature is a Web 2.0 technology. The commenting feature of each system uses circa 1995 technology. True Web 2.0 sites make extensive use of Javascript, the Document Object Model (DOM), and Cascading Style Sheets (CSS) to make a truly interactive experience that is user friendly and conducive to collaboration.
Google has many examples of Web 2.0 sites such as Google Maps~\cite{maps.google.com}, Google Docs \& Spreadsheets~\cite{docs.google.com}, and GMail~\cite{gmail.com}. Meebo~\cite{meebo.com}, Writeboard~\cite{writeboard.com}, Flickr~\cite{flickr.com}, and del.icio.us~\cite{del.icio.us} are other examples of sites that make extensive use of Web 2.0 technology. With Web 2.0 and the browser playing to role of higher level OS, computing is truly distributed, allowing virtual organizations to grow. Information exchange will advance to a new level as (near) real-time collaboration and idea disclosure are made possible. The OSPS proposed here will make use of these technologies to help build virtual organizations to revolutionize scholarly publishing.
\section{Open Source $\nLeftrightarrow$ Open Access}
Open access means the manuscript {\it access} post-publication is free to readers. Open source means that manuscript {\it sourcing} (i.e. content, assessment, review and discussion) is open. Our goal, in open source publishing, is to convert readers from passive gathers of research into an active open source research community.
From lengthy discussions within the publishing and mechanics communities about this proposal, one thing needs to be made very clear: open source publishing is not the same as open access publishing~\cite{imech.org1}. There is confusion that this proposal is fundamentally about open access. It is not. While open source and open access are somewhat related, they are neither dependent upon one another nor is one necessary for the other. Depending on the specific requirements and needs of an organization, open source publishing could be strongly coupled to open access publishing or it could be completely decoupled. Open source publishing may be a way to move towards open access but this connection is at the discretion of the users.
{\bf Open source publishing} is the primary concern of this proposal and a fundamentally new concept in disseminating research. The purpose is to allow researchers to quickly publish results and reviewers to quickly respond. This system could be used to maintain an entire open access journal or it could simply be used for small groups to effectively collaborate. The organization running a site will decide whether it is password protected to prevent outsiders from seeing the work, requires readers or authors to pay for access, or is simply open for anyone to use.
{\bf Open access publishing} gives readers free access to published research. In addition to PLoS, many publishers are making journal content freely accessible after some time (usually six to 24 months). This is a response to so-called e-print archives such as arXiv.org, authors publishing their work on their own sites, and universities, government organizations, and funding agency requests. However, there is still debate over the issue~\cite{amsci.org,imech.org2} and the PIs plans to take the `high road' in this proposal and do not completely agree with each other on the issue. They understand there is a cost to publishing but mostly believe no one should profit from publishing scholarly work. Additionally, the system currently in place seems to lead to monopolistic behavior and little pricing pressure to keep expenses of even non-profit publishers in check.
\section{Enabling Technologies (Web 2.0)}
While the phrase ``Web 2.0'' suggests a new version of the Web, it does not refer to a radical technical upgrade of the World Wide Web, but rather refers to a significant change to make the web a platform. There has been an evolution of internet technologies that have allowed a much richer user experience. What constitutes a Web 2.0 site is hard to define but most internet users have seen and used (maybe unknowingly) many of these technologies. Most are behind the scenes on the servers and in modern browser software, and have actually been around for years but never utilized extensively due to browser support. The technologies briefly described here have matured to the point that they will enable the PIs' vision for the OSPS.
Server-side scripting languages have been a big reason for the evolution of web content. Languages such as PHP, Perl, Python, and Ruby have developed into robust solutions and powerful alternatives to lower-level languages. Scripting languages appear to be the next evolution in programming, like the first human-readable languages. Obviously, scripting languages are not optimized for performance, but most web applications are not computationally intensive. For those that are, one can write performance-critical libraries in a lower-level language. Because scripting languages are not (necessarily) compiled, nearly anything written in them is open source. Thus, there is a wealth of code that one can modify or use for inspiration and education.
Another contributor to this evolution is the implementation of the Document Object Model (DOM) in all modern browsers. The DOM is basically a tree of `nodes' that describe how a web page looks. Browsers take the HTML source and translate it into a DOM and then render the page. One can think of browsers as HTML to DOM converters and DOM parsers/typesetters. While this extra step does add overhead, it adds great flexibility because the DOM is not (locally) static like the HTML sent from the server. Whenever the DOM changes the browser re-renders the page. DOM manipulation has enabled what is often called dynamic HTML (DHTML).
DOM manipulation is usually done via Javascript. Each node of the DOM tree is a Javascript object that can be altered. Alterations can be triggered by a wide variety of events in the browser which are also Javascript interpreters. Like server-side scripting languages, Javascript has developed into a full object-oriented language that is extremely powerful. After the page is loaded and any initial Javascript run, the browser waits for an event to happen such as a mouse click or a keystroke. If there is a function attached to this event, the browser will run it. This function can then manipulate the DOM to change what is rendered and/or how it appears.
Another enabling technology is Asynchronous JavaScript and XML (Ajax). Ajax is a based on a Javacript API called XMLHttpRequest (XMLHR) which implements a set of functions for requesting information from a server through an independent communication channel. Based on user events, one can pass information to a server, have the server process the information, and reply. This is quite different then simply loading a page as it is all done behind the scenes and asynchronously, allowing the user to continue interacting with the page while the request is processed. For example, a Javascript function is triggered by an event. This function collects information and uses the XMLHR API to transmit it. A callback function is run when the server responds with the information and the response text is stored in the XMLHR object. The callback function can take the response and use it to manipulate the DOM with the new information. Thus, new content can be added to a page without refreshing everything. Common pages that use Ajax or Ajax-like methods are Google Maps~\cite{maps.google.com} which requests new pieces of the map as needed and Yahoo! TV~\cite{tv.yahoo.com} which uses it to get information about specific shows. Almost every major internet content provider uses some form of Ajax to improve the user experience.
Powerful and enabling web applications include content management systems (CMS), web logs (blogs), wikis, and Really Simple Syndicates (RSS).
\subsection{CMS/Blog/Wiki/RSS}
Content editing in CMSs is done in the web browser with the information stored in a database, and the content generated and formatted dynamically, allowing the content to be decoupled from the page layout. A blog is essentially a more open CMS. Each blog typically belongs to a small group who posts and edits content. Anyone can comment on the original entry. This allows readers to discuss material posted by an author and the author to respond. The most open of these systems is the wiki which allows users to edit anything. The word `wiki' is a Hawaiian-language word for fast and was first used in the context of online collaboration by Ward Cunningham who began developing in 1994 (pre-dating the idea of both CMSs and blogs) a system he termed the `WikiWikiWeb'~\cite{wikiweb}. By allowing anyone to edit content, a virtual community develops as users collaborated to refine web pages. A Really Simple Syndicates (RSS) feed provides frequently updated links to reflect a site's content. Users can subscribe to the RSS feed through a feed reader or browsers to monitor the site for updates. RSS feed aggregators allow customized subscriptions to multiple RSS feeds, providing a consolidated view of content with real-time updates.
Consolidation is now occurring with these systems. For example, Drupal is an open-source platform that integrates a CMS, blog and RSS. Each registered user has a blog to post content. All content posted is aggregated through the embedding CMS. Any user can comment on the content posted by other users and respond to others' comments. This way, both content management and active communication is achieved in Drupal. All posts and discussions in Drupal can be monitored through RSS feeds, alerting authors and readers in real time of updates of interest. A Drupal-powered online platform, iMechanica.org, will be used to manage and facilitate the discussion section of the prototype OSPS.
The most well established and frequented wiki is Wikipedia~\cite{wikipedia}, which was started as an open-source encyclopedia. Anyone can edit entries in the encyclopedia so information converges to something well written, factually correct, and comprehensive. The key feature of modern wikis that makes this work is the built-in versioning system. Each version of a page is stored in the database and the content can always be reverted back. Thus, if a page is `vandalized' it is easily restored. A wiki-type platform built on MediaWiki (MW), the same open source software running Wikipedia, will enable content publishing and management in the prototype OSPS.
\subsection{Hardware and Backend Software}
Hosting MW and Drupal is frequently done via a server platform consisting of Linux (the OS), Apache (the webserver), MySQL (the database), and PHP (the scripting language, it is not an acronym), the LAMP platform. The only piece that is currently necessary is PHP in which MW and Drupal are written. The operating system, webserver, and database requirements have all been abstracted and nearly any compatible combination can be used. The PI has found the combination of Mac OS X (which has Apache and PHP pre-installed) and MySQL a very efficient development environment. The LAMP platform has proven to be extremely robust and scalable, running many of the web's most popular sites including Yahoo!, Flickr, and Facebook~\cite{PHP_Leads_Web_2.0}. As OSPSs grow the server platform will be able to grow with them and require no major migration to new technology.
PHP is an object-oriented language integrated with Apache, a free open-source web server used to host many high-traffic sites. When a request is made for a page the server interprets any PHP code and sends the results. IBM, Intel, and Oracle are now actively supporting PHP's development~\cite{zend}. The PI has become proficient with PHP and has written and/or modified many web applications using the language~\cite{smallfeats, nsfevo} and will modify MW and Drupal to fit the needs of this effort. MySQL is used for data storage and is also open-source, freely available, and extremely powerful and scalable~\cite{mysql}. Mockensturm and Crespi are proficient with SQL and will be able to implement changes.
\begin{figure}[tbh]\centering\centerline{\epsfxsize=6.5in\epsfbox{Screenshots.pdf}}\label{fig:screenshot}\caption{Screenshot of a paper formatted for online view. Highlights include equation rendering from source, automatic numbering and cross-referencing (with hyperlinks), pop-up equation references, baseline shifting for inline equations.}\end{figure}
\subsection{Frontend Software}
{\bf MediaWiki}, the software running Wikipedia, is open source, one of the most actively developed and used wikis, and the logical framework for the OSPS. The PI has extensive experience with the software. One important features of MW is the email notification system which notifies users when their `watchlist' pages are modified. Users do not have to actively monitor pages and this feature significantly reduces vandalism of pages; vandals know that anyone watching the page will be immediately notified and the content reverted. The PI will also implement a notification system into the (Drupal) software used for discussion pages.
The PI has used MW to write seven collaborative proposals over the past four years. This way of writing has been extremely productive and many others have shown interest in the idea. The wiki used to write this proposal and demonstrate the power of the OSPS is open to all and can be found at {\bf <a href="http://dssl.mne.psu.edu/nsfevo}" class="external free" title="http://dssl.mne.psu.edu/nsfevo}" rel="nofollow">http://dssl.mne.psu.edu/nsfevo}</a>. Figure~\ref{fig:screenshot} shows a screenshot displaying part of a paper~\cite{nisoli2007:} used to test the OSPS. Key features are enlarged and explained in the caption.
{\bf LaWML} is a markup language (ML) developed by the PI that combines WikiML (WML) and \LaTeX, and is easily formatted for on-screen display and printing. While HTML is an extremely well established ML and can render a document as flexibly as any word processor, the subtleties needed for intricate formatting are well beyond the casual user and still browser dependent. XML/XSLT could be used but is obscure outside of professional publishing. Knowledge of WML is growing rapidly, but it is likely not widely known in engineering communities. However, simple formatting requires simple WML and it has a shallow learning curve. Conversion from WML to HTML is done by the MW parser so formatting will be consistent across documents. For printing, the natural choice for a ML is some superset of TeX. Many potential users of the OSPS will be at least vaguely familiar with \LaTeX~and some would likely be extremely knowledgeable. Wikipedia encourages users to use \LaTeX~to add formulas to pages~\cite{wikipedia_formula}. Both the PI and Wikipedia have discovered that a combination of \LaTeX~and WML (LaWML) is very powerful. It is a fairly trivial matter (using regular expressions) to convert basic LaWML to pure \LaTeX~or HTML, and the PI has a prototype system in place as shown in Figure~\ref{fig:screenshot} and accessed via <a href="http://dssl.mne.psu.edu/nsfevo" class="external free" title="http://dssl.mne.psu.edu/nsfevo" rel="nofollow">http://dssl.mne.psu.edu/nsfevo</a>. The \LaTeX~can also be easily converted to PDF by the server and distributed for printing or storing offline.
One hurdle to get people to use the OSPS for collaborative writing is to convince them that using a \LaTeX-derived ML is not as difficult as commonly thought. Experience has shown this is not a huge hurdle since users never see all the ugly header information and class styles that intimidate most novice \LaTeX~users. Users learn the mathematical syntax quickly and begin to appreciate the non-WYSIWYG way of writing, i.e. get the content down and worry about the formatting later. The PI has developed a WYSIWYG \LaTeX~equation add-on that will work with MW much like the equation editor that is bundled with MS Word~\cite{AjTeX}. Using Ajax techniques, the equations are updated in near real-time in the browser to simulate the experience with which most authors are accustomed. The PI will also develop a similar add-on for making tables, something with which even skilled wiki and \LaTeX~users struggle.
Other pieces of an effective and user friendly ML, will be developed with funds provided. These pieces are discussed below.
</p>
\begin{enumerate}
\item Convert LaWML to HTML. This task will not be overly challenging, yet time consuming. The PI already has already written a prototype MW extension called WikiPub that does a great deal of LaWML to HTML conversion. However, because LaWML is so extensive, only a small percentage is currently converted to HTML. Fortunately, this small percentage encompasses the most commonly used formatting commands. As an extension, WikiPub can be readily added to existing and future MW installations.
\item Convert \LaTeX~to LaWML. The PI has worked to convert raw \LaTeX~from a few different sources for the demonstration site and has developed a collection of robust regular expressions to do this conversion. These will be extended to convert a larger set of \LaTeX~commands and to recognize user defined macros. Having such a facility will allow current \LaTeX~users to simply submit their raw \LaTeX~source (and figures) without having to convert anything to LaWML for proper on-screen formatting.
\item Integrate BibTeX into MW. One of the great benefits of \LaTeX~is the ability to automatically generate a properly formatted bibliography from the content of the document. This facility is not currently built into MW, although an extension called Cite and a template called Ref are used extensively in Wikipedia. Those familiar with BibTeX will find Cite/Ref lacking as the bibliography is built directly from marked text in the body of the document. References have to be individually formatted, are not kept in a separate database, and clutter the content of the document. For proposal writing, the PI currently keeps a separate page in the wiki containing a database of references in BibTeX format. Users can add references to this page by simply copying them from their local BibTeX collection or by exporting from, say, EndNote. In the current implementation, references are added using \LaTeX~markup, the BibTeX file is generated from the MySQL database along with the \LaTeX~headers and content, and conversion to PDF is done with \verb,pdflatex, and \verb,bibtex,. This works well for producing results in PDF. An effort to produce HTML has already begun by defining a new MW parser class and tags (\verb,{{\#cite:}}, and \verb,{{\#bibitem}},) in WikiPub. References will be pulled from a database and replicate the functionality of BibTeX in the MW engine. Additionally, there is an outstanding MW extension called BibWiki that makes managing BibTeX databases extremely easy. Importing records from a variety of online sources is implemented and the PI has added sources (e.g. Web of Science) he uses extensively.
\item Add cross-referencing and automatic numbering. Cross-referencing can be accomplished in MW through the powerful ParserFunctions extension and internal templates. However, implementing something that works more like \LaTeX~(with \verb,\ref, and \verb,\label, tags) would be helpful for new users with some \LaTeX~experience. One problem with MW is there is no automatic way to number figures, tables, and equations. The Cite extension automatically numbers citations and the PI has used it as a starting point to develop similar automatic numbering mechanisms for other objects in the document. A prototype system is in place and used on the demonstration site but needs to be refined and thoroughly tested.
\end{enumerate}
\section{Justification}
It is hard to get an entire community to support a revolution unless there is much discontent. Because this is not the case in scholarly publishing communities, revolutionary changes will be difficult. Thus, from a practical perspective, a revolution needs to occur as a sequence of evolutions none too big, pushing people from their comfort zone. Hopefully, in five years we will look back and wonder why things were ever how they are now. This proposal thus contains a set of evolutionary ideas that the PIs hope will start a revolution in the way organizations publish research.
\subsection{The Cost of Content}
To make OSPSs sustainable beyond the funding period, it is important to understand the costs involved in running such a site. These costs will be largely dependent on how an organization uses the OSPS. The costs will be controlled by the organization, not a third-party publisher.
The real cost to publish is difficult to estimate because large fixed costs in marketing and sales for commercial sites must be factored out. Also, while access charges for individual journals are readily available, overall publishing revenue greatly exceeds the expenses associated with publishing material, making individual journal expenses difficult to measure. For example, in 2006, Reed Elsevier's journal publishing division generated \euros{2.24b} and earned \euros{683m} in profit, with 52\% coming from scientific journals and 48\% from medical journals. Net operating margins for the division are high (30\%) because the content and assessment via editors and reviewers comes free\footnote{Note that Reed Elsevier's overall net operating margins are 16\%, high by most standards.}.
The enormous scatter of journal subscription costs suggests that the market is being driven by monopolistic practices and not free exchange of information. Ted Bergstrom (economics, UCSB) has done much research on the cost to end users of journals, and he and Preston McAfee (economics, CalTech and VP and Research Fellow, Yahoo! Research) have an excellent web site~\cite{journalprices} estimating the value of journals in various ways. A summary of the data~\cite{journalprices_summary} shows that for-profit publishers charge significantly more for access (even when normalized by citations) than non-profit publishers (\$26.41/article vs. \$6.77/article). This primarily measures the cost relative to the contribution and is only indirectly related to the cost of production. Production costs should be normalized per unit area of content since for-profit journals tend not to have as many page restrictions per article as non-profit journals and journals vary significantly in how much content there is per page.
Even when this is done, for-profit publishers charge significantly more. For example, the cost for both the print and online version of the \emph{ASME Journal of Applied Mechanics} is roughly \$10/m$^2$ while that for the \emph{International Journal of Solids and Structures} is \$30/m$^2$. This difference is due to the monopoly effect of copyright; once a given journal has the copyright of a given paper, researchers will demand libraries provide access to that paper. Libraries are then forced to pay the fees or have a gap in their collections. Imagine, for example, if each paper was involuntarily licensed to exactly \emph{two} journals, and libraries could subscribe to a journal article by article. That would immediately force competition on cost and normalize fees.
Still, monopolistic pricing make it difficult to determine the true cost of publishing (i.e. in a competitive market). The subscription charges for non-profit journals provide a much better estimate of publishing costs. However, most non-profit publishers have print editions that increase cost, especially on a per subscription basis. Plus, the financial reports the PIs studied (ASME, APS, IEEE, AIAA) do not provide an expense breakdown for just scholarly journal publishing, instead lumping all publishing expenses into one category. The PIs also found that most non-profit organizations make a profit on publishing. With no pricing pressure from a competitive environment, it is hard to determine the real cost of publishing; non-profit costs are just an upper bound to the system proposed here.
One can also estimate the cost of publishing through PLoS's 2006 financial statements~\cite{plos_financials}. Their total expenses were \$6.3 million, of which \$2.6 million went to salaries and wages with another \$1 million spent on employees. They spent \$247,000 in occupancy fees (rent) and \$183,000 on travel. Their total income was just under \$5 million, which caused their net assets to drop to \$2 million from \$3.3 million. Clearly PLoS is targeting the high end of publishing, trying to compete with Science and Nature. With substantial support from the Gordon Moore Foundation, PLoS has decided to build an expensive infrastructure with the hope that revenue will grow to meet expenses. Again, this does not provide much insight into the production cost of a typical engineering journal.
The costs then appear to depend greatly on the support staff required and one of the advantages of the OSPS is that the cost structure and pricing scheme can be whatever an organization likes. If everything is done by volunteers or if the system is being used by a small research group, expenses could be zero. If the organization decides to develop a high-end publication requiring extensive editing, formatting, and/or software customization, there will be significant recurring costs. Ultimately, the cost and the method by which to recoup those costs will be decided by each virtual organization.
\subsection{The Deterioration of the Publishing Community}
The PIs feel that the current peer-review system is collapsing under its own weight. However, it is an essential part of the academic system that ensures quality and allows administrators to evaluate work in unfamiliar fields. Alas, reviewing is a job that provides the reviewer no real benefit and is barely considered for promotion and/or tenure. The number and quality of reviews is never requested and does not help one's reputation, standing, or promotion success. A very small number of people (journal editors) know whether a person is a thorough and timely reviewer. Thus, optimizing P\&T success pushes the time spent reviewing papers to zero while the time spent writing them is maximized. It appears that more and more people are realizing this and it is getting harder and harder to get people to provide quality and timely reviews.
This disparity in the `reward' system for writing and reviewing papers continues to grow and, the PIs fear, will soon reach a breaking point. Most editors will now make a decision based on two reviews when the standard used to be three. Even getting two can be difficult as it frequently requires multiple reminders. The PIs must also admit to often being slow to review papers as there always seems to be more pressing matters to attend to that are actually rewarded.
One of the reasons for this growing problem appears to be the continuing decline of a community spirit among academics. People used to, or so the PIs are told, feel much more part of a community and, thus, were much more willing to contribute to that community by doing behind-the-scenes work, such as paper reviewing, for which there is no direct benefit. While there have always been (and always will be) people that will not contribute, the lack of a community spirit and an attitude that everyone is competing with one another tends to push tasks like paper reviewing aside for much more profitable endeavors.
The PIs can only speculate on the reasons for this dissolution of academic communities. They suspects that one reason is the easy and anonymous access to information. While the information age has certainly benefited academics in profound ways, it has also made research more anonymous. Before everyone had easy access to online journals and photocopying, the only way to get a paper was to contact the authors directly. The authors were then aware of the people interested in and following their work; this often resulted in further discussion and collaboration. Today there is no real way to know who is reading one's papers. The only indication usually occurs when authors notice citation from other researchers with whom they have never spoken. For example, one of the Mockensturm's papers was in the list of a journal's most downloaded papers for 2006~\cite{mockensturm2006a:}. Although gratified, he had no idea anyone was even interested in the work and still has no idea who downloaded the paper.
The PIs also think the competitive environment in which we work and position ourselves for success hampers the community spirit. With the funding rates for science and engineering so low, academics are viewing others in their community as competitors and are thus less willing to share ideas with others fearing intellectual property theft. This is truly an unfortunate development in the academic community where pursuit and sharing of knowledge should be the top priority. With academic institutions acting more and more like big businesses, it is not hard to see how this competitive attitude permeates down to the faculty level. While competition between researchers is nothing new and generally healthy, the additional pressures on today's academics lead to more unhealthy competition as people feel their advancement is tied to their success at `winning' funding, awards, etc.
Another likely cause of this deterioration is the internationalization of efforts by more and more academic institutions around the world to develop strong research programs. With so many more academics having their career advancement tied to their research success, academic communities are becoming more like large cities than small towns. Everyone passes each other anonymously and people treat each other with little respect as there is little chance of ever encountering one another again. While it is still a small world, the growth coupled with anonymity is deteriorating an important sense of community that contributes in central ways to the quality of research practices and results.
\subsection{The Need for Timeliness}
As the pace of discovery and competition to be first to publish continue to increase, researchers are growing more and more frustrated with the time it takes from submission to acceptance, and then to actual publication. Even the time it takes to turn an idea into an acceptable submission is often much too long. While this is controlled, in part, by authors, in most engineering disciplines a short paper with a basic idea not supported by lengthy analysis and examples demonstrating usefulness will certainly not be accepted. Thus, such papers are never submitted and the time it takes to get ideas out is unnecessarily long. In the PIs' opinion, ideas are the important part of any publication and should be disseminated as quickly as possible. Surveying engineering publications (and theses) will demonstrate that there is usually one fundamental idea (if that) in each publication that could be summarized in probably a page. The rest of the paper is simply there to support the validity of the idea and to present some new results that have been enabled by it.
A more dynamic publishing environment would allow authors to present their ideas rapidly and then fill in supporting material as it becomes available. A worry would be that subsequent study might show that the original idea was not good (something that can happen, by the way, in more traditional approaches to publishing). However, such `papers' could be maintained in the dynamic section of the system for comment and dissemination. If a breakthrough occurs the authors could inform the editors to consider it for review and inclusion in the static section of the OSPS. If subsequent work does not validate the idea, the authors could retract the work, or leave it posted indefinitely for further comment and the education of others who might be considering similar ideas. This will allow a forum for ideas that did not work out and hopefully prevent others from going down the same path. This would be a tremendous learning resource for graduate students. Ideas could even be revisited later by the original authors or others might try to determine why a seemingly good idea just did not materialize into something useful.
Another process that would become much more rapid is the review-revision process. In discussions with journal editors and many other faculty involved in reviewing papers, the PIs believe that a large reason for the delay in getting papers reviewed is that reviewers do not have time to write a \emph{thorough} review rapidly. Thus, while most reviewers will immediately skim through a paper and form an opinion, they delay the process of actually writing and submitting the review until they have more time to think about it. This `more time' never comes and under pressure from an editor the reviewer basically writes what s/he originally thought. In this dynamic reviewing environment, a reviewer need not be worried about writing a lengthy or well thought out review right away. The reviewer is free to post some initial thoughts that can then be expounded upon later. At the same time, the authors can address these initial thoughts by either clarifying the reviewers understanding and/or revising the paper. Thus, the reviewing process becomes much more finely discretized, resulting in much less time between submission and publication, and more importantly between idea generation and public dissemination and feedback. The loop is shortened in ways that can only benefit authors and the research community at large.
\section{Structure of Prototype Systems}
\begin{wrapfigure}[]{}{}\frame{\epsfig{file=Flow.pdf,width=}}\caption{\footnotesize }\label{}\end{wrapfigure}
One of the benefits of the proposed system is its fundamental openness, which organizations can use as they see fit. `Unintended' uses have driven many recent innovations, and putting this tool into clever people's hands will inevitably enable unanticipated results. The organization built around the system will depend strongly on its needs. The following discussion assumes a virtual organization wants to build a publishing community and/or an open source journal. User interactions will again largely depend on the organization's needs. A mock journal called $JIT^2$ (Just-In-Time Journal of Interesting Thing) will be set up for testing and be run like a real journal during the second year. The submission/review flow is summarized in Figure~\ref{fig:ospsflow}. `All' means all registered users.
\subsection{Submission Process}
Any registered user will be able to submit a manuscript. Access to this manuscript will be either (1) closed to all but the submitter, (2) open to a whitelist of users, or (3) open to all. The first option allows a user to submit something not ready to be viewed and critiqued by others. The second option allows specified users to view and comment on a manuscript. When a user is added to a whitelist, notification will be sent via email (if allowed); the email will act as an invitation to read and comment on the paper. Once the article is ready, it can be opened to all.
Once authors open access to the entire community, it can be considered published, but not accepted by $JIT^2$. This will allow authors to rapidly disseminate ideas. Authors will also maintain the copyright of their work and all submissions will be protected by a Creative Commons License.
\subsection{Review Process}
One of the key features of the OSPS is its rapid review process, achieved by an efficient discussion mechanism allowing real-time communication between authors and reviewers.
The discussion function currently available in MW is unstructured. It depends on users to format the discussion in a readable way. Experience has shown that popular discussion (talk) pages in Wikipedia lack coherency, making the discussion much less effective. By contrast, the discussion mechanism in Drupal is well organized. The comments are automatically put into a user-friendly format. The hierarchical structure of the discussion allows users to easily locate different discussion topics, in case the discussion takes multiple directions. Once a manuscript has been submitted to $JIT^2$, an associated discussion thread will be generated in iMechanica.org. The entry will contain the basic reference information of the submitted manuscript, including the title, authors and abstract. The manuscript page in MW and the discussion page in Drupal will be linked through hyperlinks to help users navigate. Authors can solicit reviews from the iMechanica community, respond to comments, and revise the manuscript accordingly. When the authors decide the article is ready for official review, a request will be sent to the editor. The editor will then assign reviewers to comment on the manuscript. Meanwhile, the manuscript remains open for discussion by the community at large. Designated reviewers can post quick, short comments for rapid response from the authors, without waiting to write an extensive review. The rapid communication between the authors and reviewers will significantly accelerate the review process, removing an inefficiency in the current system. Both the official reviews from designated reviewers and those from the community will be used to make an editorial decision.
Convincing people to remove their anonymity cloak when posting reviews will not be easy and forcing them to do so would surely hamper acceptance of $JIT^2$. Thus, registered user reviews can either be attributed or anonymous with only the editors/administrators able to see who wrote the review. The reviewers will have the option to change a comment from anonymous to attributed (and vice-versa) at any point. The hope is that most reviews will ultimately be attributed to someone so that they can get `credit' for writing valuable reviews. \emph{Requiring} people to sign a review will hamper the review process and interactions like the following may occur. Say the notoriously hostile Wolfgang Pauli posts an article containing what John Doe, a graduate student looking for a faculty position, believes are some mistakes. Not entirely confident in his analysis, John decides to post anonymously to avoid the risk of embarrassment. After reading John's comments, others confirm that he is correct and post to add credibility to his comments. With this support John decides he would like to have his original post attributed. If John is wrong, hopefully some other reviewers will point out \emph{his} error, John will learn from the experience, and the post can remain anonymous.
The OSPS will have a mechanism to attribute proper credit for valuable reviews. This will be based on a user ranking system that allows users to rate reviews (or manuscripts) based on their intellectual merit. Such a user-based ranking system has been demonstrated in community-based popularity websites such as digg.com, and there are Drupal add-on modules for user ratings. Such modules will be implemented and customized to fit the needs particular to the OSPS. While individual rating can be subjective, the collective wisdom of the community will lead to a more objective rating, and the accumulative rating of a review will be collected regardless of it being attributed; a highly rated anonymous review could be signed to allow recognition of the reviewer.
Another Drupal add-on module allows meriting user contribution through honor points. Such a module will be implemented and customized to provide a metric for accumulated credits of a contributing user. With both the user-rating and the credit-accumulating functions enabled, the PIs hope the OSPS review system will eventually evolve from mostly anonymous to primarily attributed. This will obviously lead to more constructive criticism and more insightful reviews.
\subsection{Editorial Decisions}
Once official reviews are submitted and sufficient discussion has occurred, the editors will decide to accept or reject the paper. This process will be somewhat different from traditional journals because, hopefully, the authors have been revising their article during the review process. Thus, there will be no `accept with major revisions and further review' option. With revisions made during the review process, reviewers will be able to post follow-up comments about them. Again, this will drastically reduce the time it takes to get a good paper ready for official acceptance. If the authors and reviewers cannot agree on changes, the editors can personally review all the comments or ask others to do so and make a decision.
If the paper is accepted, the $JIT^2$ editors will send an acceptance letter and the authors will have the option of having it copyedited by interns from the PSU English Department and archived in the static section of the system; a static URL will be assigned. Because the authors retain the copyright, they are also free to remove the paper (not the reviews) and submit it elsewhere, and even submit it to another journal.
If the editors decide to reject the paper, the authors then have to decide whether to keep the paper in the dynamic section for further revision, or pull the paper and submit it elsewhere. Should the authors decide to leave the article in the system, they can request that the editors reconsider it after revision. If the authors decide to pull the paper, they will be able to delete it from the MW editing system but the comments and reviews will remain in the Drupal system. Thus, a history of the discussion will remain and credit for reviewing the paper will be retained should the reviewers like to cite their reviews.
\subsection{Social Structure and Management of $JIT^2$}
The prototype social and management structure of $JIT^2$ will mirror existing journals. There will be an editor and an editorial board (the PIs). Other volunteers from the iMechanica community will likely join the editorial board.
The mock $JIT^2$ editorial board will act like current editorial boards. They will make decision about what papers get accepted into the archival section of the site and which must remain in the developmental section for further refinement. There will be closed sections of WikiPub developed to allow editors to discuss their decisions and administrative issues. The editors will also have `sysop' privileges to move, delete and edit all pages, and create organizing (grouping) pages. This will allow them to organize the papers in various ways for readers to quickly locate them. Master organizing pages will list papers by submission and/or acceptance date, keyword, or author name. The structure will be developed by PSU English interns with guidance from PI Selber.
\section{Project Management Plan}
\begin{figure}[tbh]\centering\centerline{\epsfxsize=7in\epsfbox{TimeLine.pdf}}\label{fig:timeline}\caption{Proposed time line to develop and test the OSPS}\end{figure}
The five PIs on the proposal will work together to develop the prototype systems discussed. They each have unique skills and experiences that will be used here.
{\bf Mockensturm}, the project lead and coordinator, has a background in theoretical and applied mechanics, and extensive experience developing web applications using Javascript and PHP. He will be the primary software developer on the project and coordinate the efforts of the co-PIs.
{\bf Selber} is an Associate Professor of English and Science, Technology, and Society; an Affiliate Associate Professor of Information Sciences and Technology; and Director of Composition. His research interests include rhetorics of technology, social dimensions of human-computer interaction, politics of academic computing, technical communication, computers and composition. He will coordinate editorial aspects and organize an internship program from which we can draw editorial interns, who will also help organize and document the system.
{\bf Crespi} has a background in theoretical condensed matter physics and is the developer of PSU Physics Department's web site. As an experienced publisher and web site developer, he and his students will help test early versions of the software, provide feedback and some development.
{\bf Li} has a background in solid mechanics. He and Suo are the two architects of iMechanica.org. He is also the founder and editor of www.macroelectronics.org, an information platform for the emerging technology of flexible electronics. He will develop a communication channel in iMechanica.org to serve as the discussion module for the OSPS.
{\bf Suo} has a background in solid mechanics and a member of the Executive Committee of the ASME Applied Mechanics Division; he is the main force behind iMechanica.org' success. Suo will solicit the online mechanics community through iMechanica to use and support the OSPS.
The table in Figure~\ref{fig:timeline} summarizes the tasks of each PI during the funding period and after. Mockensturm, who has the most experience with web application development, will be the lead programmer. During the first six months, he will continue to develop, refine, and expand LaWML to make it as user friendly and familiar as possible. He will also work to make the conversion of LaWML to HTML and PDF as robust as possible, and develop a \LaTeX to LaWML conversion tool. The second half of year one will be spent developing and integrating a bibliography management system. This will be a web-based front-end to BibTeX similar to WikiBib but with reference information stored in the database for easy extraction and formatting by WikiPub. Modules to pull information from literature search engines (INSPEC and Web of Science) will be written to reduce the effort of entering data. A system to upload EndNote databases will also be developed. Year two will be the start of integrating MW and Drupal in a seamless way. A central user authentication system based on LDAP will be developed. `Skins' to make MW look more like Drupal will be written so iMechanica users familiar with Drupal will be comfortable with the OSPS. The focus for the last six months will be on fixing any lingering bugs, making the system as robust and user friendly as possible, and packaging it for easy installation.
Selber will begin the project by establishing internships for senior-level English students focusing on publishing. Each such student must take a three-credit internship to graduate and this project integrates well with the existing program. During the grant period, Selber will oversee these interns, who will be working on a user-friendly system to organize whatever content the OSPS contains. Ideas for efficient ways to categorize, browse, and search the content will be prototyped and tested. They will work to make the system simple yet powerful. In the second year when the system is feature complete, English interns will begin work on documentation for the OSPS. This is an essential part of convincing people to adopt the system, and one that is often overlooked by developers who may have no interest in writing manuals. For people to understand the fundamental philosophy of the OSPS, well-written manuals are essential. During the later stages of the grant period, interns will begin to help with copyediting content in $JIT^2$. Should a full open source journal result from the prototype system the internship program will continue after the grant period to allow English student to gain experience copyediting technical writing and provide an inexpensive (free) service to the journal.
Crespi and Mockensturm have collaborated on NSF-funded research projects for the past three years and share an interest in web site development. With Crespi running a large research group, his focus will be primarily on testing the system and giving informed feedback to the rest of the group. He will also help to develop a final version of LaWML that makes appropriate trade-offs between familiarity, user friendliness, and sophistication.
Li, who is the most familiar with the Drupal software through his work with iMechanica.org, will begin the project by setting up a preliminary reviewing system as an extension to iMechanica. As mentioned elsewhere, there are existing add-ons for Drupal that provide much of the functionality required. However, they will likely need to tailored to the needs of the OSPS. Thus, during the first six months he will also work closely with Mockensturm to learn more about PHP, Javascript and web application development. Once he is comfortable with these tools he will refine the reviewing system during the second half of year one. He will then work with Mockensturm to integrate the MW-based content editing system with Drupal, fix bugs, and develop `canned' packages for other installations. Li's efforts will extend beyond the grant period as he will continue to work with Mockensturm to add features and fix bugs.
Suo, the founder of iMechanica.org, will work during the first year to solicit the mechanics community for input on and support of the OSPS. His efforts with iMechanica have been extremely fruitful with about 3,000 users registered and about 30,000 web hits daily. There has already been discussion about starting a new open source journal~\cite{imech.org1}. Other uses could include having a repository of lecture notes, or a system for community review of manuscripts before they are submitted to other journals. Suo will also act as a tester for the system, first working with Li to test the reviewing system and then beta testing the entire system.
\section{Community Acceptance}
Community acceptance of this new paradigm in publishing will not be easy. If a full journal is started, junior faculty may worry about publishing in a peer-reviewed journal with little history. Additionally, users may at first worry about allowing other user to edit their work. Convincing people this is a good idea may indeed be a challenge. However, Wikipedia's success can be used to establish the benefit. There were plenty of people skeptical of Wikipedia until it was shown that, with minimal policing, the idea of open source editing works. There are actually many benefits and few, if any, detriments to open sourcing one's work. All revisions are documented and can be easily undone. There is a record of who made the revisions, for users will be required to register to edit. A manuscript with many grammatical and stylistic mistakes can be quickly improved. Papers could become a community effort with reviewers proposing entirely new sections. The original authors can accept or reject such major revisions.
Users will likely have to alter their writing workflow. However, the hope is to eventually make the system simple enough to use that everyone feels comfortable. Hopefully the time spent learning a new system will be saved many times over, and user will be willing to overcome the activation energy needed to settle into a lower energy state. A complex system such as this will require extensive user feedback and this is planned.
When communities start to collaborate on things, attribution of credit can become an issue. Since all revisions will be tracked and the original author known, attribution of credit for authorship and reviewing will be easily determined. Users could even post paper `stubs' containing ideas and research on which they are currently working. These stubs could solicit feedback or contributions. Even if many users contribute to the resulting paper, the ideas contained will be easily attributed to those that generated them. A paper could be fully developed from idea to finished product entirely in the OSPS environment, with continual feedback from reviewers and contributors.
\section{OSPS Structure and Management}
There will be a development board (DB) initially consisting of the PIs. Like most open source software projects, this will grow as others become involved. The DB will consider suggestions for improving WikiPub and work to continually enhance the environment, which will be organized like most open source projects. There will be an open versioning system allowing anyone to download the code and submit modifications for consideration by the DB. Anyone will be able to set up their own `publishing company' by installing the software on any compatible system.
The PIs hope that with the support of NSF, WikiPub will become an official project of the Wikipedia Foundation similar to Wikiversity and Wiktionary, and an official branch in the MW development tree. Continued improvements to the MW base software will then automatically be rolled into WikiPub. For example, on the MW development roadmap is a feature called Flagged Revisions slated for the version 1.11 release. This feature will prevent users from editing pages that are mature and should remain fairly static. Any edits to these pages will require approval by a page oversight committee before becoming visible to everyone. Thus, instead of having to be diligent about reverting pages if inappropriate or malicious edits are made, the page's maintainers can take a more passive role. This new feature would be great for papers that have been accepted, with approval of any change required from the editors. Maintaining WikiPub as a separate but compatible branch of MW will obviously take some careful thought by the DB so WikiPub-specific features are developed as extensions to the MW core code, not as modifications to it. So far this has not been a problem as all the added functionality developed so far has been MW extensions.
As other virtual organizations grow up around the OSPS, the DB will solicit members of the larger groups to join. This will allow other users to have a voice in prioritizing improvements to the software. It will also allow the community to learn of new features and changes being considered.
\section{Security and User Validation}
MW and Drupal as well the server software on which they rely have gone through many iterations and are considered mature and secure platforms. This is another reason modifications will be made via extensions; only the extensions will need thorough security validations. The PIs will work with security experts at PSU to test the code. Since extensions do not typically interface directly with users, maliciously formatted input to the system (the most common attack vector) will pass through MW or Drupal's extensive data validation routines before getting to newly written code.
Initially the OSPS will be a closed system used by the PIs and their close colleagues for testing. Users of the prototype system integrated with iMechanica will be validated via a callback email. This will prevent bots from generating accounts and posting inappropriate content. During the grant period users will have to be invited by an existing user (ala Gmail) to keep the user base from growing too quickly. After the system has been thoroughly tested anyone will be allowed to register and an oversight board will be established (ala Wikipedia) to remove users. As the OSPS gets adopted by other organizations, they will have to decide on a policy. However, the infrastructure to secure the OSPS as tight as needed will be there.
\section{Institutional and Organizational Support}
In addition to support from the iMechanica.org community, included are letters of support from:
</p>
\begin{enumerate}
\item Karen Thole (PSU), Mechanical and Nuclear Engineering department head who has agreed to provide teaching release for the PI;
\item William Burkhard (PSU), Director of Information Technology and Design who has agreed to support the needed computing infrastructure;
\item Robin Schulze (PSU), English department head who enthusiastically endorses the English undergraduate internships that will be supported;
\item Charles Steele (Stanford), the past editor of the \emph{International Journal of Solids and Structures} and the current editor of the \emph{Journal of Mechanics of Materials and Structures} who will discuss using a version of the OSPS with the editorial board;
\item Thomas Conklin (PSU), the head of the Engineering Library who strongly supports the move to an economically sustainable model for academic publishing; and
\item George Voyiadjis (LSU), president of the Society of Engineering Science (SES) Inc. who will work with the PIs to encourage SES member support and possibly start the first SES journal.
\end{enumerate}
\clearpage\newpage
\section{*Summary}
Proposed here is the continued development of a system to enable open source publishing. Note that this is fundamentally different than open access publishing. The open source publishing system will allow users to post \emph{and} edit complex technical documents using open-source web-based software. The software will automatically typeset the document into a more readable format; number equations, figures, tables, and references; and generate cross-reference links for easy navigation. The system will be built from two widely used and robust open source software projects, Mediawiki and Drupal. Mediawiki is a package that allows groups large (the entire world) or small (an individual) to post, edit, and refine content. It is the very software that powers the incredible wikipedia.org project. Drupal is another kind of web-based collaboration software that is better for discussion and dialog exchange. It is the software that powers iMechanica.org, a web of mechanics and mechanicians initiated by the team members of this proposal. iMechanica now has about 3000 registered users from all over the world, with daily web hits of about 30,000. The proposed work will integrate and extend the two software packages to allow the exchange of technical content required by engineers and scientists. The PI has been using Mediawiki to write collaborative proposals for the past four years, and has coded many extensions to the software to make it better for working with technical documents. Because Mediawiki's discussion forums are very unstructured, Drupal will be used for discussion of content. The support from this grant will allow the PI to refine and package these tools for use by any virtual organization wishing to enable technical collaboration. Due to the scalability of the software used, these organizations could be anything from a small research group looking to more effectively collaborate to a large publisher or society looking to develop an open source journal. A demonstration site containing this proposal, a sample paper co-written by the PI and accepted to Physical Review Letters, and notes from a class on metamaterials generously donated by Graeme Milton and Biswajit Banerjee is online at <a href="http://dssl.mne.psu.edu/nsfevo" class="external free" title="http://dssl.mne.psu.edu/nsfevo" rel="nofollow">http://dssl.mne.psu.edu/nsfevo</a>. Anyone can edit the content (no registration is required at this point to maintain anonymity) by clicking on the edit tab at the top of the page. Another demonstration site will be tied to iMechanica.org to test the integration of Mediawiki and Drupal and scaling to a larger organization.
Intellectual merit. The intellectual merit of this proposal is twofold. First, we will demonstrate a platform that will make published knowledge constantly evolve and new ideas rapidly spread. Second, we will demonstrate a process to evolve knowledge by massive collaboration.
Broad impacts. The need to leverage the new web tools to evolve knowledge exists in all disciplines. The platform developed and experience gained should be replicable to other disciplines. The OSPS enables students and young researchers to participate in the paper review process, a potentially valuable experience exclusively available to experienced researchers in the current publishing system.
%==Test Section==
%===WikiML Tables to LaTeX===
%%{| border="1px" style="font: 10pt Times; border: 1px solid black;"
%%|+ style="caption-side:bottom"|Metrics and alternative strategies. ‡Fracture (ultimate) strength will be used %for <math>\mathsf{ZrO_{2}}</math> and yield strength will be used for 316L. †Force-deflection tradeoff is %handled using the optimization procedure.
%%|-
%%! !! Task !! Metrics !!style="width: 25.5em; text-align: left;"| Alternate plans if metrics are not met
%%|-style="text-align: center; border: 1px solid black; "
%%| 1 ||style="width: 4.5em; text-align: center;"| Make Test Coupons ||style="width: 12em; text-align: center; "| %<u>Density</u><br />greater than 99% theoretical ||style="width: 25.5em; text-align: left;"| Adjust the concentration %of particles in suspension, amount of binder and cross linking agent, and sintering conditions
%%|-style="text-align: center; border: 1px solid black; "
%%| 2 ||style="width: 4.5em; text-align: center;"| Measure Material Properties ||style="width: 12em; text-align: center; "| <u>Young's Modulus;/u><br />within 10% of bulk value<br /><u>Failure strength</u>‡<br/>within 50-200% of bulk <math>\mathsf{ZrO_{2}}</math><br/> within 25% of bulk 316L ||style="width: 25.5em; text-align: left;"|Adjust processing parameters including the uniformity and distribution of nanoparticles (equiaxed distribution should be less than an order of magnitude in breadth). If <math>\mathsf{ZrO_{2}}</math> is not successful then alloy of alpha alumina and tetragonal Zirconia will be used. If 316L is not successful then Co-Cr-Mo will be used.
%%
%%|}
%
%{| border="1px" style="font: 10pt Times; border: 1px solid black;"
%! colspan="3" style="text-align: center" | Schedulers
%|-
%|rowspan="3"| Immediate || RR ||rowspan="4"| Round Robin
%|-
%| EF
%|-
%| LL
%|-
%|rowspan="4" | Batch || MM
%|-
%|colspan="2" | MX
%|-
%| DL || Dynamic Level
%|-
%| RC || Relative Cost
%|-
%|rowspan="4" | Evolutionary || PN || This paper
%|-
%| ZO || Genetic Algorithm
%|-
%| TA || Tabu search
%|-
%| SA || Simlulated Annealing
%|}
%
%{| border="1px" style="font: 10pt Times; border: 1px solid black;"
%! colspan="3" style="text-align: center" | Schedulers
%|-
%|rowspan="3"| Immediate || RR ||rowspan="4"| Round Robin
%|-
%| EF
%|-
%| LL
%|-
%|rowspan="4" | Batch || MM
%|-
%| MX || Max-Min
%|-
%| DL || Dynamic Level
%|-
%| RC || Relative Cost
%|-
%|rowspan="4" | Evolutionary || PN || This paper
%|-
%| ZO || Genetic Algorithm
%|-
%| TA || Tabu search
%|-
%| SA || Simlulated Annealing
%|}
%
%{| border="1px" style="font: 10pt Times; border: 1px solid black;"
%! colspan="3" style="text-align: center" | Schedulers
%|-
%|rowspan="3"| Immediate || RR || Round Robin
%|-
%| EF || Earliest First
%|-
%| LL || Lightest Loaded
%|-
%|rowspan="4" | Batch || MM || Min-Min
%|-
%| MX || Max-Min
%|-
%| DL || Dynamic Level
%|-
%| RC || Relative Cost
%|-
%|rowspan="4" | Evolutionary || PN || This paper
%|-
%| ZO || Genetic Algorithm
%|-
%| TA || Tabu search
%|-
%| SA || Simlulated Annealing
%|}
%
%{| border="1px" style="font: 10pt Times; border: 1px solid black;"
%! colspan="3" style="text-align: center" | Schedulers
%|-
%|rowspan="3"| Immediate ||rowspan="3"| RR || Round Robin
%|-
%| Earliest First
%|-
%| Lightest Loaded
%|-
%|rowspan="4" | Batch || MM || Min-Min
%|-
%| MX || Max-Min
%|-
%| DL || Dynamic Level
%|-
%| RC || Relative Cost
%|-
%|rowspan="4" | Evolutionary || PN || This paper
%|-
%| ZO || Genetic Algorithm
%|-
%| TA || Tabu search
%|-
%| SA || Simlulated Annealing
%|}
%
%
%{| border="1px" style="font: 10pt Times; border: 1px solid black;"
%! colspan="3" style="text-align: center" | Schedulers
%|-
%|rowspan="3"| Immediate || RR ||rowspan="3"| Round Robin
%|-
%| EF
%|-
%| LL
%|-
%|rowspan="4" | Batch || MM || Min-Min
%|-
%| MX || Max-Min
%|-
%| DL || Dynamic Level
%|-
%| RC || Relative Cost
%|-
%|rowspan="4" | Evolutionary || PN || This paper
%|-
%| ZO || Genetic Algorithm
%|-
%| TA || Tabu search
%|-
%| SA || Simlulated Annealing
%|}
%
%%\begin{table}[t]
%%\renewcommand{\arraystretch}{0.2}
%%\small
%%\begin{tabular}{|c|c|c|c|}
%%\hline
%%& {\normalsize Task} & {\normalsize Metrics} & {\normalsize Alternate plans if metrics are not met} \\
%%\hline\hline
%%1 & \parbox[c]{0.75in}{\centering Make Test Coupons} & \parbox[c]{2in}{\centering \underline{Density}\\ greater %than 99\% theoretical} & \parbox[c]{3.75in}{Adjust the concentration of particles in suspension, amount of binder and %cross linking agent, and sintering conditions}\\
%%\hline
%%2 & \parbox[c]{0.75in}{\centering Measure Material Properties} & \parbox[c]{2in}{\centering \underline{Young's %Modulus}\\ within 10\% of bulk value\\ \underline{Failure strength}$^\ddag$ \\ within 50-200\% of bulk %ZrO$_{\mathsf{2}}$\\ within 25\% of bulk 316L} & \parbox[c]{3.75in}{Adjust processing parameters including the %uniformity and distribution of nanoparticles (equiaxed distribution should be less than an order of magnitude in %breadth). If ZrO$_{\mathsf{2}}$ is not successful then alloy of alpha alumina and tetragonal Zirconia will be used. If %316L is not successful then Co-Cr-Mo will be used.}\\
%%\hline
%%3 & \parbox[c]{0.75in}{\centering Design Multifunctional End Effector} & \parbox[c]{2in}{\centering %\underline{Predicted force and deflection}\\ within 10\% of scaled commercial instrument data} & %\parbox[c]{3.75in}{Insufficient force: stiffen end effector by changing cross sectional geometry or using stiffer %material.\\ Insufficient deflection: increase end effector compliance by changing the cross sectional geometry or using %more compliant material.$^\dag$}\\
%%\hline
%%4 & \parbox[c]{0.75in}{\centering Fabricate Prototype} & \parbox[c]{2in}{\centering \underline{Dimensional %tolerance}\\ within 1\%\\ \underline{Density}\\ greater than 99\% theoretical} & \parbox[c]{3.75in}{If dimensional %tolerance is unacceptable, the photoresist and exposure technology used to make the molds will be changed to %interference photolithography. If density is insufficient, processing conditions will be adjusted per \#1.}\\
%%\hline
%% & \parbox[c]{0.75in}{\centering Test in Lab} & \parbox[c]{2in}{\centering \underline{Measured force and
%%deflection}\\ within $\pm$10\% of predicted data} & \parbox[c]{3.75in}{If measured values do not agree with predicted %ones, the loading and boundary conditions will be adjusted to more accurately represent the test condition. If %pull-off force is insufficient, the surface texture of the jaws will be modified to increase the coefficient of %friction.}\\
%%\hline
%%6 & \parbox[c]{0.75in}{\centering Test in Simulator} & \parbox[c]{2in}{\centering \underline{Time to %completion}\\Rosser rope pass, cup drop and intracorporeal suturing, paper cutting\\ \underline{Accuracy, Smoothness}\\ %paper cutting} & \parbox[c]{3.75in}{Insufficient grasping or suturing force: stiffen end effector by changing cross %sectional geometry or using stiffer material.\\ Insufficient deflection: increase end effector compliance by changing %the cross sectional geometry or using more compliant material.$^\dag$\\ Poor cuts: Refine edge sharpness and pressure %between scissor blades.}\\
%%\hline
%%\end{tabular}
%%\caption{Metrics and alternative strategies. $^\ddag$Fracture (ultimate) strength will be used for ZrO$_{\mathsf{2}}$ %and yield strength will be used for 316L. $^\dag$Force-deflection tradeoff is handled using the optimization %procedure.}
%%\label{tab:design2}
%%\end{table}
