|Nanosafety data for silver nanoparticles|
in data.enanomapper.net visualized
with ambit.js and d3.js.
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(
var compound =
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?
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):
substances <- listSubstances(
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.
Oh, and the view from my room in the Merian Hotel was brilliant!