Drupal - MyLabBook ELN

Moving to WordPress

The Reasons for MyLabBook Moving from Drupal to WordPress

The major reasons for moving from the Drupal CMS to the WordPress CMS can be summarized in the following points.

Significantly larger market share of WordPress – The market share of WordPress is about 20X of Drupal as of 2023. The large market share better suits the Sustainability criteria of being a S.A.F.E. ELN Research Platform.
The robust ecosystem of premium plugins for WordPress – Unlike WordPress and Joomla, Drupal has very few if any extensions (modules) that require payment. The disadvantage to Drupal’s approach is that individual developers or development teams are less incentivized to support a module beyond what it might contribute to their consulting practice or unless it is a key component of their support (e.g., for Open Social).
The Drupal code base is much more complex to work with – Drupal’s approach to custom content types from a site builder perspective is elegant and powerful. However, it has added to the complexity and made modules and extensions more difficult to build and to use.
BuddyBoss – The turning point came when we found that BuddyBoss was much easier to use and integrate with than Drupal’s Open Social. We see this as a consequence of the availability of premium extensions mentioned above.

We have enjoyed the development with Drupal for the last decade or so, but the experience with WordPress has given us greater flexibility and sustainability. Those qualities have made WordPress the obvious choice for the future of the MyLabBook approach for building ELNs and research platforms .

An Easily Installable Demo

Category: Drupal

An Installable MyLabBook Demo with Simple Examples Built Upon a Robust Foundation

We have implemented an initial demo version of a Drupal based Electronic Lab Notebook (ELN) which shows some of the unique capabilities of this approach.

The Flexibility of a Drupal Approach

The overall approach is based on the use of custom content types, which allow us to attach fields as needed to the standard Drupal content type of a node. In this case, we only need two custom content types – the Experiment and the Protocol Step. The Experiment stores the information pertaining to a given experiment as a whole. The Experiment then usually references one or more Protocol Steps. Each Protocol Step then contains the appropriate sets of data fields where the researcher can store the data for the procedure that they are performing. The sets of data fields are then displayed using separate tabs for the given Protocol Step.

By using appropriate Drupal modules, we are able to accommodate numerous different types of data fields, including the following.

Task List – Customizable list of tasks to be done in any Protocol Step
Rich Text Fields – Using HTML formatting tags for variations in styled text
Data Tables – Configurable HTML tables to store and display data
Geolocation Data – Can be shown on a Google map or other maps with appropriate freely available keys. This can be used in conjunction with the Address fields for automatic lookup of coordinates
Image and File Uploads – You can designate what file extensions are allowable for upload (e.g., xlsx, docx, pdf, png, jpg)
URLs – you can record one URL or a list of URLs with website names that may be relevant to the protocol step
Tables of Specific Value Types – If you wish to capture a group of a given data type, then there are tabs that contain given types of data along with an associated label for each data item. The types of data that are available using this approach include integers, decimal values, floating point values, plain text values and date values.
Videos – Videos can either be uploaded to your server and displayed or they can be displayed from YouTube.

Easy Installation from a Repository

This is the first demo version of this approach where we have released the full source code on our GitHub repository. This repository is set up to allow you to easily install your own version of a Drupal based ELN. This uses an approach that is similar to the approach that many Drupal theme developers use to deliver an installable version of Drupal that uses their theme along with demo content. The installation steps are shown on the home README.md file of the GitHub repository.

Continued Improvements

It is our hope that this initial version can be useful for many situations where someone may want to use this freely available ELN approach for their research. With the flexibility of having access to multiple different data types, a fairly easy installation and thousands of additional freely available Drupal modules, there are a great many possibilities for customizing this ELN to a researcher’s needs without too much time or effort involved. With continued input and feedback and the resulting continued refinements, perhaps this approach can result in lower costs and improved functionality for researchers as they continue to bring about appropriate scientific and other research advancements.

Drupal and the Semantic Web Layer Cake

Category: Drupal, Semantic Web

How Drupal Implements the Semantic Web Layers

While working on a paper about Drupal as an Electronic Lab Notebook that utilizes Semantic Web technologies, a graduate student asked me for more visuals about what I was trying to do. In response, I came up with the graphic above to describe how Drupal currently relates to the Semantic Web. To me, it presents an interesting focal point for thinking about Drupal as a platform for the Semantic Web. How much is really implemented at this point? And how much of the layer cake does it really make sense to implement with Drupal?

First of all, I think it is important to take into account the strengths and weaknesses of Drupal in the context of an ELN.

Strengths of Drupal

The Drupal platform has tremendous momentum. It is strong in the areas of education and government, which will probably not be changing platforms in many cases, and so will continue to be a part of and improve upon the Drupal platform. And the commercial sector is growing and will no doubt continue to provide new modules and innovation. This is significant for any application based on Drupal, like our ELN, because it bodes well for a continually thriving ecosystem where different applications can harvest and adapt from one another for relatively little effort. A rising tide will lift all boats.
The Drupal architecture is adaptable and elegant. This is no doubt one of the reasons for its success and it continues to improve with every iteration.
Ease of use due to the PHP scripting language and the ubiquity of that and the relative ease of setup and modification.

We could talk around those points at length, mentioning the plethora of modules, the ever-improving security, the great community support as well as commercial offerings for support and so forth. But I believe that in one sense those are derivatives of these major advantages of Drupal listed above.

Weaknesses of Drupal (IMHO)

The relative slowness of the PHP scripting language. Here is one write-up that explains how PHP lags all of the others in performance.
Although this is just my opinion, I also find the PHP language less elegant and fun than most of the other scripting languages. It is not a big deal, except that it is more fun to write more object oriented code in Ruby or Python where I can also run and debug the code from the command line and then easily adapt it to a website or a desktop app as needed.
As a result of the first two, I believe, there are many more code libraries and artifacts written in Ruby, Python, C++ or Java for scientific and technical purposes than there are for PHP. In terms of the Semantic Web, this is probably most relevant for reasoners, but for an ELN this has wider implications.

So for a semantic ELN based on Drupal, what does this mean? How much of the Semantic Web stack should be implemented in Drupal and how much should not? I would suggest the following approach.

Reasonable Compromise

Implement the layers of the Semantic Web that do not require strong computational capabilities in Drupal. These include the parts that are already implemented in Drupal 7 (RDF, RDFa, SPARQL), as well as the upper parts of the diagram like trust (related to social networking) as well the user interface and applications (areas where Drupal already excels).
For computationally intensive aspects of the Semantic Web stack (e.g., reasoners), use web services or some wrapper for integration of native code (e.g., for rApache) to obtain the functionality while not experiencing the relatively slow execution speeds of PHP (compared to C++ or Java).
This would seem to be the most feasible approach going forward for how to use Drupal as an ELN, building on its strengths and compensating for its weaknesses by using web services. A little semantics goes a long way, and the contribution that Drupal can make in this area can thus be significant, including as a platform for an ELN that is useful in many situations. It is just important to stay real about what makes sense.

Open Source Alternatives

Category: Drupal, ELN

Open Source Alternatives for an Electronic Lab Notebook

According to some recent articles in the science technology press, ELNs are a growing market. For example, a 2006-2007 article at Scientific Computing estimated that the market was about 50 million USD in 2005 and was growing at 20% to 30% per year. This makes a great deal of sense when we take into account the growing complexity of science and the massive amount of data that is collected and needs to be analyzed. This is true especially in the life sciences, and several of the commercial ELN offerings are targeted primarily at that market (e.g., CERF by Rescentris, Inc.).

What does this mean for non-commercial ELNs, however? And what does it mean for academic institutions who desire to prepare their students for a future where ELNs will be more and more common place? Of course, it is obvious from this website where we think at least one good solution to these questions lie. But let’s take a step back and see why we have chosen the particular solution that is presented on this website. What are the alternatives? What are the criteria to use in developing an ELN appropriate for an academic setting?

Let’s tackle the last question first and then see what kind of alternatives can satisfy our criteria. Some of the main criteria are as follows.

Cheap or preferably free – because most academic institutions are constrained by budgets and would have difficulty justifying spending much money on an ELN for students
Able to be customized for different scientific or technical contexts – the nature of scientific experiments is that although there are some commonalities, it would be advantageous for an ELN to be adaptable enough to provide differences for, say, physics experiments versus biology experiments versus mathematical simulations
Open source and supported by a viable community – this is a variation on the first point, but if the ELN is open source, then it is usually free. This makes it also much easier to justify with a funding agency because of the minimal cost and the likelihood that research funds will result in a contribution back to the community. Ideally, a viable community is also present, which will imply continuity regardless of whether one person contributes or not in the future.
Social networking capabilities would be nice – with today’s students becoming more and more in tune with social networking sites like Facebook and mySpace, it would be advantageous to utilize these capabilities in an ELN as well.
Fairly easy to set up, maintain and extend – while not strictly necessary, the easier it is to set up (everything else being equivalent), then the more widespread that we can expect the adoption of such a platform.

So using these criteria, we can narrow our choices. Criteria 3 suggests that the choice should be a popular open source platform. Criteria 4 suggests that it should run primarily on the web versus on the desktop. And criteria 2 suggests that it be fairly mature or robust so that people will have developed add-on components that can be re-purposed for scientific purposes. Criteria 5 suggests the use of a scripting language versus the use of Java, C or C++, at least for the mainstream of web developers.

Django – web framework based on the Python scripting language
Plone – web content management system (CMS) based on the Python scripting language
Joomla – web CMS based on the PHP scripting language
Ruby on Rails – web CMS based on the Ruby scripting language
Drupal – web CMS based on the PHP scripting language

Django has the advantage of being written in Python, which is also a relatively elegant scripting language with an even larger support community than has Ruby. It also shows itself to run at about twice the speed of Ruby or PHP and can be run simply on the desktop as well as the web in a straightforward manner. There are also numerous Python modules written for scientific purposes on the desktop that can be repurposed for the web as needed. However, Django itself is a web framework instead of a CMS. And for the CMS platforms built upon Django, then there do not seem to yet be a mature set of modules available “out of the box” for many capabilities.

Plone is probably the most mature of the CMS platforms built with Python, and is relatively easy to set up as long as one has full access to server configurations. However, like Django, it is not as widely supported by internet service providers and thus becomes less available in many cases.

Joomla is a popular web framework also, and has thousands of add-on modules and some very nice looking templates available.

Ruby on Rails has the advantage of being written in Ruby, which is a relatively elegant scripting language and growing in its use. The framework itself lends to great productivity as well because of its standardized approaches. The myExperiment project has taken this approach.

In the end, though, we chose Drupal because of the following reasons.

The elegance of Drupal’s architecture – while the PHP scripting language is not very elegant as compared to Python or Ruby, the Drupal architecture is very elegant and flexible. The structure is very well thought out and lends itself to tremendous flexibility.
Incorporation of the Semantic Web technologies – Drupal has been the first of the popular web platforms to incorporate Semantic Web technologies on a wide scale. These technologies are being incorporated into the core in the upcoming version 7 of Drupal, and have been available as modules for version 6 for some time. This approach holds tremendous potential for scientific communication and research. We believe that someday in the future, perhaps the not too distant future, that Semantic Web capabilities will be expected for an ELN. With Drupal, we will be getting this “out of the box”, so to speak, before anyone else.
Breadth of available modules – as is documented in other areas on this site, the number of possible Drupal modules for an ELN is outstanding, ranging from plotting to spreadsheets to Google maps and many, many more. While Joomla may have some more mature modules in certain areas, they are often commercial as well, unlike Drupal. And Drupal seems to have a wider overall breadth of modules available.
Practical reasons – then we have the very practical reasons that the primary developer of this ELN is familiar with the PHP scripting language and with the Drupal platform. So that minimizes the learning curve for this approach and helps us to roll things out more quickly and easily. This is not a definitive reason, but given the other advantages, it gives us cause enough not to look further.

So that is some of the reasoning that went into the choice of the Drupal platform for our ELN. We continue to be happy with the choice, but also are interested in any feedback, pro or con.