Nanosafety data for silver nanoparticles in data.enanomapper.net visualized with ambit.js and d3.js.

The last three weeks featured two meetings around data infrastructures for the NanoSafety Cluster. The first meeting was on January 25-26 in Brussels, and last week the eNanoMapper project held its second year meeting with a subsequent workshop in Basel (see the program with links to course material). Here are some personal reflections on these meetings, and some source code updates based on the latter workshop particularly.

For the workshop in Basel I extended previous work on JavaScript and R client code for the eNanoMapper API (which I previously wrote about and see doi:10.3762/bjnano.6.165).

JavaScript
Nothing much changed for ambit.js (see these two posts) and I only added a method to search nanomaterials based on chemistry rather than names before (release 0.0.3 is pending). That is, given a compound URI, you can now list all substances with this URI, using the listForCompound() function:

var searcher = new Ambit.Substance(
  "https://apps.ideaconsult.net/enanomapper"
);

var compound =
  "https://apps.ideaconsult.net/enanomapper/compound/71/conformer/71"
searcher.listForCompound(compound, processList);

You may wonder how to get the URI used in this code. Indeed, one does rather than hardcode that, as it may be different in other eNanoMapper data warehouse instances. This is where another corner of the eNanoMapper API comes in, which is wrapped by the Compound.search() method. However, I have to play more with this method before I encourage you to use it. For example, this method returns a list of compound matching the search. So, how do we search for fullerene particles?

R package
The renm package for R was demonstrated in Basel too and some 25% in the audience uses R in their research. The README.md has some updated examples, including this one to list all nanomaterials from a PNAS paper (doi:10.1073/pnas.0802878105):

library(renm)
substances <- listSubstances(
    service="http://data.enanomapper.net/",
    search="10.1073/pnas.0802878105", type="citation"
)

The 0.0.3 release made just in time of the workshop fixed a few minor issues. The above JavaScript example cannot be repeated in R yet, but this is scheduled for the next release.

Data quality
For a few materials I have now created summary pages. These should really be considered demonstrations of what a database with an API has to over, but it seems that for some materials we are slowly going towards critical mass. Better, it shows nicely what advantages data integration has: the data from silver materials comes from three different data sources, aggregated in the data.enanomapper.net instance. However, if you look at the above codes, it is easy to see how it could easily pull in data from multiple instances. For example, here is LDH release assay results for two of the JRC Representative Materials:


This, of course, taking advantage of the common language that the eNanoMapper ontology provides (doi:10.1186/s13326-015-0005-5). This ontology is now available from BioPortal, Aber-OWL, and the Ontology Lookup Service (via their great beta). Huge thanks to these projects for their work on making ontologies accessible!

But there is a long way to go. Many people in Europe and the U.S.A. are working on the many aspects of data quality. I would not say that all data we aggregated so far is of high quality; that is, it somewhat depends on the use case. The NanoWiki data that I have been aggregating (see release 2 on Figshare, doi:m9.figshare.2075347.v1) has several goals, but depending on the goal varies in quality. For example, one goal is to index nanosafety research (e.g. give me all bio assays for TiO2) in which case it is left to the user to read the discovered literature. Another goal is to serve NanoQSAR work, where I focused on accurately describing the chemistry, but have varying levels of amount of info on the bioassays (e.g. is there a size dependency for cytotoxicity).

There is a lot of discussion on data quality, as there was two years ago. I am personally of the opinion that eNanoMapper cannot solve the question of data quality. That ultimately depends on the projects recording and dissemination the data. Instead, eNanoMapper (like any other database) is just the messenger. In fact, the more people complain about the data quality, the better the system managed to community the lack of detail. Of course, it is critical to compare this to the current situation: publications in journals, and it seems to me we are well on our way to improve over dissemination of data via journal articles.

Basel
Oh, and the view from my room in the Merian Hotel was brilliant!