Maastricht University

Egon Willighagen

::: {.altmetric-embed badge-details="right" badge-type="donut" doi="10.1186/1758-2946-5-23" style="float: right;"}
:::

**Update**: Mark wrote up a [blog
post](http://chembl.blogspot.co.uk/2013/05/chembl-chembl-rdf.html) on
the RDF that the ChEMBL team itself.

Yesterday, the paper "The ChEMBL database as linked open data"
(doi:[10.1186/1758-2946-5-23](https://doi.org/10.1186/1758-2946-5-23))
by Andra Waagmeester ([@andrawaag](https://twitter.com/andrawaag)), Ola
Spjuth ([@ola_spjuth](https://twitter.com/ola_spjuth)), Peter Ansell
([@p_ansell](http://twitter.com/p_ansell)), Antony Williams
([@chemconnector](https://twitter.com/chemconnector)), Valery Tkachenko,
Janna Hastings, Bin Chen
([@binchenindiana](http://twitter.com/binchenindiana)), David J Wild
([@davidjohnwild](http://twitter.com/davidjohnwild)), and me appeared in
the OA
[JChemInf](http://en.wikipedia.org/wiki/Journal_of_Cheminformatics)
journal.

I am also indebted to the [ChEMBL](https://www.ebi.ac.uk/chembl/) team
([@chembl](http://twitter.com/chembl)) for both providing such valuable
data under a liberal Open Access license and their critical reading of
the manuscript! **Additionally, I would like to stress that the ChEMBL
team will create their own RDF version of ChEMBL and that this paper is
not describing the version they will release.**

BTW, the [source of the
paper](https://github.com/egonw/chembl-rdf-paper/) is available from
GitHub. And the [(original) scripts to create RDF from the MySQL dump of
ChEMBL](https://github.com/egonw/chembl.rdf) are also on GitHub.

![](https://media.springernature.com/lw685/springer-static/image/art%3A10.1186%2F1758-2946-5-23/MediaObjects/13321_2012_Article_469_Figa_HTML.gif)

This paper outlines the [RDF](http://www.jcheminf.com/content/3/1/15) as
it has evolved from various earlier projects. The above diagram
visualizes the basic structure (red), various Linked Data resources
linked too (blue) and illustrates how various ontologies are used, such
as the
[CHEMINF](http://www.plosone.org/article/info:doi/10.1371/journal.pone.0025513),
[BIBO](http://bibliontology.com/), and
[CiTO](http://www.jbiomedsem.com/content/1/S1/S6) ontologies.

Additionally, various applications and links are described developed by
various co-authors. For example, Peter worked on the use in
[Bio2RDF](http://bio2rdf.org/) and Bin and David on
[Chem2Bio2RDF](http://cheminfov.informatics.indiana.edu:8080/). Andra
developed an extension for his (#altmetric)
[CitedIn](http://citedin.org/) resource, giving credit to a paper when
data in it is extracted into ChEMBL. Ola, Valery, and Anthony developed
a [Bioclipse Decision
Support](http://www.bioclipse.net/decision-support) extension, which
supports a nearest neighbor search in ChEMBL using
[ChemSpider](http://chemspider.com/). Of course, Ola also hosts [the
SPARQL end point](http://rdf.farmbio.uu.se/chembl/snorql/) of which you
can monitor the uptime at the also cool [mondeca.com
service](http://labs.mondeca.com/sparqlEndpointsStatus/details/farmbio-chembl.html):

![](/assets/images/mondecaUptime.png)

(Yes, I think I have all the cool buzzwords covered in this paper.
Sadly, marketing is needed nowadays as a scientist. Where is the time
that you could rant on page after page in all your domain specific
jargon, not having to worry if your reader would understand it
immediately, or without a university degree...)

What this paper does not describe, is all the things I did with
ChEMBL-RDF in the [Open PHACTS](http://www.openphacts.org/) project
([@Open_PHACTS](https://twitter.com/open_phacts)), which includes the
use of [QUDT](http://qudt.org/) and the
[jQUDT](https://github.com/egonw/jqudt) library for unit normalization
outlined in [this document](http://www.bigcat.unimaas.nl/~egonw/units/)
and the use of VoID for link sets as described in [this
document](http://www.openphacts.org/specs/2012/WD-datadesc-20121019/).

#### References

- [10.1186/1758-2946-5-23](https://doi.org/10.1186/1758-2946-5-23)
- [10.1186/1758-2946-3-15](https://doi.org/10.1186/1758-2946-3-15)
- [10.1371/JOURNAL.PONE.0025513](https://doi.org/10.1371/JOURNAL.PONE.0025513)
- [10.1186/2041-1480-1-S1-S6](https://doi.org/10.1186/2041-1480-1-S1-S6)


The Chemical Information Ontology: Provenance and Disambiguation for Chemical Data on the Biological Semantic Web

CiTO, the Citation Typing Ontology

<strong>
 Update
</strong>
: Mark wrote up a blog post on the RDF that the ChEMBL team itself. Yesterday, the paper “The ChEMBL database as linked open data” (doi:10.1186/1758-2946-5-23) by Andra Waagmeester (@andrawaag), Ola Spjuth (@ola_spjuth), Peter Ansell (@p_ansell), Antony Williams (@chemconnector), Valery Tkachenko, Janna Hastings, Bin Chen (@binchenindiana), David J Wild (@davidjohnwild), and me appeared in the OA JChemInf journal.

New Paper: "The ChEMBL database as linked open data"

University of Glasgow

Roderic Page

I\'m back from Copenhagen and [GBIC2012](http://www.gbic2012.org). The
meeting spanned three fairly intense days (with the days immediately
before and after also working days for some of us), and was run by a
group of facilitators lead by Natasha Walker, who were [described
us](http://natashafacilitator.wordpress.com/2012/07/05/gbic2012-100-biodiversity-informatics-experts-on-their-way-to-changing-the-game/)
as \"an interesting (and delightfully brainy, if sometimes scatty) group
of academics, researchers, museum managers and people close to
policy\...\". I\'ve attempted to capture tweets about the meeting using
[Storify](http://storify.com/rdmpage/gbic-2012/).  
  
There will be a document (perhaps several) based on the meeting, but
until then here are a few quick thoughts. Note that the comments below
are my own and you shouldn\'t read into this anything about what
directions the GBIC document(s) will actually take.  
  

## Microbiology rocks

  
Highlight of the first day was [Robert J.
Robbin\'s](http://www.esp.org/rjr/) talk which urged the audience to
consider that life was mostly microbial, that the the things most people
in the room cared about were actually merely a few twigs on the tree of
life, that the tree of life didn\'t actually exist anyway, and many of
the concepts that made sense for multicellular organisms simply didn\'t
apply in the microbial world. Basically it was a homage to Carl Woese
(see also Pace et al. 2012
[doi:10.1073/pnas.1109716109](http://dx.doi.org/10.1073/pnas.1109716109))
and a wake up call to biodiversity informaticians to stop viewing the
world through multicellular eyes. (You can find all the keynotes from
the first day [here](http://www.gbic2012.org/documents.html/)).  
  
![F1
large](http://lh4.ggpht.com/-oF-sNj4wiQM/T_b9ufDofjI/AAAAAAAABeQ/l0AcUL9H-Pw/F1.large.jpg?imgmax=800 "F1.large.jpg"){style="display:block; margin-left:auto; margin-right:auto;"
border="0" width="460" height="600"}

<div>

From Pace, N. R. (1997). A Molecular View of Microbial Diversity and the
Biosphere. Science, 276(5313), 734--740.
[doi:10.1126/science.276.5313.734](http://dx.doi.org/10.1126/science.276.5313.734)

</div>

## Sequences rule

  
The future of a lot of biodiversity science belongs to sequences, from
simple DNA barcoding as a tool for species discovery and identification,
metabarcoding as a tool for community analysis, to comparisons of
metabolic pathways and beyond. The challenge for classical biodiversity
informatics is how to engage with this, and to what extent we should try
and map between, say sequences and classical taxa, or whether it might
make more sense (gasp) to abandon the taxonomic legacy and move on.
Perhaps are more nuanced response is that the point of connection
between sequences and classical biodiversity data is unlikely to be at
the level of taxonomic names (which are mostly tags for collections of
things that look similar) but at the level of specimens and
observations.  
  

## Ontologies considered harmful

  
This is my own particular hobby horse. Often the call would come \"we
need an ontology\", to which I respond read [Ontology is Overrated:
Categories, Links, and
Tags](http://www.shirky.com/writings/ontology_overrated.html). I have
several problems with ontologies. The first is that they are too easy to
make and distract from the real problem. From my perspective a big
challenge is linking data together, that is going from  
  
![a](http://lh6.ggpht.com/-hDCN7_a6py4/T_b9vTqS8nI/AAAAAAAABeY/uHVUD8_5MuA/a.png?imgmax=800 "a.png"){style="display:block; margin-left:auto; margin-right:auto;"
border="0" width="390" height="104"}  
  
to  
  
![b](http://lh4.ggpht.com/-_5ym0xM25Pg/T_b9wYL02JI/AAAAAAAABeg/CSgGcKLY5jQ/b.png?imgmax=800 "b.png"){style="display:block; margin-left:auto; margin-right:auto;"
border="0" width="390" height="104"}  
  
Let\'s leave aside what \"A\" and \"B\" are (I suspect it matters less
than people think), once we have the link then we can can start to do
stuff. From my perspective, what ontologies give us is basically this:  
  
![c](http://lh3.ggpht.com/-yijoX2Ce3jA/T_b9yIUcJxI/AAAAAAAABeo/6Ff2dyz3Zxs/c.png?imgmax=800 "c.png"){style="display:block; margin-left:auto; margin-right:auto;"
border="0" width="390" height="181"}  
  
So now we know the \"type\" of the link (e.g., \"is a part of\", \"cites
approvingly\", etc.). I\'m not arguing that this isn\'t useful to have,
but if you don\'t have the network of links then typing the links
becomes an idle exercise.  
  
To give an example, the web itself can be modelled as simply nodes
connected by links, ignoring the nature of the links between the web
pages. The importance of those links can be inferred later from
properties of the network. To a first approximation this is how Google
works, it doesn\'t ask what the links \"mean\" it simply investigates
the connections to determine how important each web page is. In the same
way, we build citation networks without bothering to ask the nature of
the citation (yes I know there are ontologies for citations, but anyone
willing to bet how widely they\'ll be adopted?).  
  
My second complaint is that building ontologies is easy, \"easy\" in the
sense that get a bunch of people together, they squabble for a long time
about terminology, and out comes an ontology. Maybe, if you\'re lucky,
someone will adopt it. The cost of making ontologies, and indeed of
adopting them is relatively low (although it might not seem like it at
the time). The cost of linking data is, I\'d argue, higher, because it
requires that you trust someone else\'s identifiers to the extent that
you use them for things you care about deeply. Consider the citation
network that is emerging from the widespread adoption of DOIs by the
publishing industry. Once people trust that the endpoints of the links
will survive, then the network starts to grow. But without that trust,
that leap of faith, there\'s no network (unless you have enough
resources to build the whole thing internally yourself, which is what
happened with the closed citation network owned by Thomson Reuters).
It\'s much easier to silo the data using unique identifiers than it is
to link to other data (it\'s a variant of the \"not invented here\"
syndrome).  
  
Lastly, ontologies can have short lives. They reflect a certain world
view that can become out of date, or supplanted if the relationships
between things that the ontology cares about can be computed using other
data. For example, biological taxonomy is a huge ontology that is
rapidly being supplanted by phylogenetic trees computed from sequence
(and other) data (compare the classification used by flagship
biodiversity projects like GBIF and EOL with the Pace tree of life shown
above). Who needs an ontology when you can infer the actual
relationships? Likewise, once you have GPS the value of a geographic
ontology (say of place names) starts to decline. I can compute if I\'m
on a mountain simply by knowing where I am.  
  
I\'m not saying ontologies are always bad (they\'re not), nor that they
can\'t be cool (they can be), I\'m just suggesting that they aren\'t the
first thing you need. And they certainly aren\'t a prerequisite for
linking stuff together.  
  

## Google flu trends

  
Perhaps the most interesting idea that emerged was the notion of
intelligently detecting changes in biodiversity (which is the kind of
thing a lot of people want to know) in the way analogous to
[Google.org\'s Flu Trends](http://www.google.org/flutrends/) uses
flu-related search terms to predict flu outbreaks:  
  
Ginsberg, J., Mohebbi, M. H., Patel, R. S., Brammer, L., Smolinski, M.
S., & Brilliant, L. (2008). Detecting influenza epidemics using search
engine query data. Nature, 457(7232), 1012--1014.
[doi:10.1038/nature07634](http://dx.doi.org/10.1038/nature07634)  
  
Could we do something like this for biodiversity data? For various
reasons this suggestion become known at GBIC2012 as the \"Heidorn
paradigm\".  
  

## Thinking globally

  
One challenge for a meeting like GBIC 2012 is scope. There\'s so much
cool stuff to think about. From my perspective, a useful filter is to
ask \"what will happen anyway?\" In other words, there is a lot of stuff
(for example the growth of metabarcoding) that will happen regardless of
anything the biodiversity informatics community does. People will make
taxon-specific ontologies for organismal traits, digitise collections,
assess biodiversity, etc. without necessarily requiring an entity like
GBIF. The key question is \"what won\'t happen at a global scale unless
GBIF (or some other entity) gets involved?\"  
  

## A Vast Machine

![51OttqQDcVL SL500
AA300](http://lh4.ggpht.com/-GM83pvpJdtg/T_b9sH3hCRI/AAAAAAAABeI/zng5aiGH4QQ/51OttqQDcVL._SL500_AA300_.jpg?imgmax=800 "51OttqQDcVL._SL500_AA300_.jpg"){border="0"
width="128" height="128" style="float:right;"}Lastly, in one session Tom
Moritz mentioned a book that he felt we could learn from ([A Vast
Machine: Computer Models, Climate Data, and the Politics of Global
Warming](http://www.amazon.com/Vast-Machine-Computer-Climate-Politics/dp/0262013924)).
The book recounts the history of climatology and its slow transition to
a truly global science. I\'ve started to read it, and it\'s fascinating
to see the interplay between early visions of the future, and the
technology (typically driven by military or large-scale commercial
interests) that made possible the realisation of those visions. This is
one reason why predicting the future is such a futile activity, the
things that have the biggest effect come from unexpected sources, and
effect things in ways it\'s hard to anticipate. On a final note, it took
about a minute from the time from the time Tom mentioned the book to the
time I had a copy from Amazon in the Kindle app on my iPad. Oh that
accessing biodiversity data were that simple.


Post GBIC2012 thoughts

Update: this work is now described in this paper.

**Update**: this work is now described in [this
paper](https://chem-bla-ics.blogspot.com/2013/05/new-paper-chembl-database-as-linked.html).

Last week, ChEMBL 13 was
[released](http://chembl.blogspot.com/2012/02/chembl-13-released.html),
with even more data, data fixes,
[etc](ftp://ftp.ebi.ac.uk/pub/databases/chembl/ChEMBLdb/releases/chembl_13/chembl_13_release_notes.txt).
Since my RDF for [ChEMBL
09](http://chem-bla-ics.blogspot.com/2011/04/chembl-09-as-rdf.html) my
workflow has become [more
solid](https://github.com/egonw/chembl.rdf/commits/master) and uses more
common ontologies, started using more common ontologies and ontologies I
just like, such as
[CHEMINF](http://www.plosone.org/article/info:doi/10.1371/journal.pone.0025513)
and [CiTO](http://www.jbiomedsem.com/content/1/S1/S6). Below is an
overview of the resource types present in the RDF: activities (almost 7M
now), chemical entities, assays, targets, and documents.

![](/assets/images/relations.png)

The [data on
Kasabi](http://chem-bla-ics.blogspot.com/2011/10/chembl-rdf-uploading-data-to-kasabi.html)
will be updated soon, and the [SPARQL end
point](http://rdf.farmbio.uu.se/chembl/sparql) hosted by Uppsala
University was updated yesterday, including the [SNORQL
frontend](http://rdf.farmbio.uu.se/chembl/snorql/):

![](/assets/images/chemblRDF13.png)

The new data is not fully backwards compatible. The changes to the RDF
include the use of `cito:citesAsDataSource`{.language-plaintext
.highlighter-rouge}, more typing using existing ontologies, e.g. with
`cheminf:CHEMINF_000000`{.language-plaintext .highlighter-rouge} and
`pro:PR_000000001`{.language-plaintext .highlighter-rouge} from the
[PRotein Ontology](http://pir.georgetown.edu/pro/).

A paper dedicated to the ChEMBL-RDF is in preparation. Existing use
cases can be found [here](http://www.jbiomedsem.com/content/2/S1/S6).

#### References

- [10.1371/JOURNAL.PONE.0025513](https://doi.org/10.1371/JOURNAL.PONE.0025513)
- [10.1186/2041-1480-1-S1-S6](https://doi.org/10.1186/2041-1480-1-S1-S6)
- [10.1186/2041-1480-2-S1-S6](https://doi.org/10.1186/2041-1480-2-S1-S6)


<strong>
 Update
</strong>
: this work is now described in this paper. Last week, ChEMBL 13 was released, with even more data, data fixes, etc. Since my RDF for ChEMBL 09 my workflow has become more solid and uses more common ontologies, started using more common ontologies and ontologies I just like, such as CHEMINF and CiTO.

ChEMBL 13 as RDF

Cameron Neylon

This is the second of two posts discussing the talk I gave at the
[Science 2.0
Symposium](http://pyre.third-bit.com/blog/archives/2710.html) organized
by [Greg Wilson](http://pyre.third-bit.com) in Toronto in July. As I
described in the last post [Jon Udell](http://blog.jonudell.net) pulled
out the two key points from my talk and tweeted them. [The
first](http://twitter.com/judell/statuses/2913879832) suggested some
ideas about what the limiting unit of science, or rather science
communication, might be. [The
second](http://twitter.com/judell/statuses/2914112488) takes me in to
rather more controversial areas:

> @cameronneylon uses tags to classify records in a bio lab wiki. When
> emergent ontology doesn't match the standard, it's useful info.
> \#osci20

It may surprise many to know that I am a great believer in ontologies
and controlled vocabularies. This is because I am a great believer in
effectively communicating science and without agreed language effective
communication isnâ€™t possible. Where I differ with many is that
assumption that because an ontology exists it provides the best means of
recording my research. This is borne out of my experiences trying to
figure out how to apply existing data models and structured vocabularies
to my own research work. Very often the fit isnâ€™t very good, and more
seriously, it is rarely clear why or how to go about adapting or
choosing the right ontology or vocabulary.

What I was talking about in Toronto was the use of key-value pairs
within the [Chemtools LaBLog](http://blogs.chem.soton.ac.uk) system and
the way we use them in templates. To re-cap briefly the templates were
initially developed so that users can avoid having to manually mark up
posts, particularly ones with tables, for common procedures. The fact
that we were using a one item-one post system meant that we knew that
important inputs into that table would have their own post and that the
entry in the table could link to that post. This in turn meant that we
could provide the user of a template with a drop down menu populated
with post titles. We filter those on the basis of tags, in the form of
key-value pairs, so as to provide the right set of possible items to the
user. This creates a remarkably flexible, user-driven, system that has a
strong positive reinforcement cycle. To make the templates work well,
and to make your life easier you need to have the metadata properly
recorded for research objects, but in turn you can create templates for
your objects that make sure that the metadata is recorded correctly.

The effectiveness of the templates clearly depends very strongly on the
organization of the metadata. The more the pattern of organization maps
on to the realities of how substances and data files are used in the
local research process, and the more the templates reflect the details
of that process the more effective they are. We went though a number of
cycles of template and metadata re-organization. We would re-organize,
thinking we had things settled and then we would come across another
instance of a template breaking, or not working effectively. The
motivation to re-organize was to make the templates work well, and save
effort. The system aided us in this by allowing us to make
organizational changes without breaking any of the previous schemes.

Through repeated cycles of modification and adaption we identified an
organizational scheme that worked effectively. Essentially this is a
scheme that categorizes objects based on what they can be used for. A
sample may be in the material form of a solution, but it may also be
some form of DNA.Â  Some procedures can usefully be applied to any
solution, some are only usefully applied to DNA. If it is a form of DNA
then we can ask whether it is a specific form, such as an
oligonucleotide, that can be used in specific types of procedure, such
as a PCR. So we ended up with a classification of DNA types based on
what they might be used for (any DNA can be a PCR templates, only a
relatively short single stranded DNA can be used as a â€" conventional
â€" PCR primer). However in my work I also had to allow for the fact
that something that was DNA might also be protein; I have done work on
protein-DNA conjugates and I might want to run these on both a protein
gel and a DNA gel.

We had, in fact, built our own, small scale laboratory ontology that
maps onto what we actually do in our laboratory. There was little or no
design that went into this, only thinking of how to make our templates
work. What was interesting was the process of then mapping our terms and
metadata onto designed vocabularies. The example I used in the talk was
the [Sequence Ontology](http://www.sequenceontology.org/) terms relating
to categories of DNA. We could map the [SO term
plasmid](http://www.sequenceontology.org/miso/current_cvs/term/SO:0000155)
on to our key value pair
[DNA:plasmid](http://biolab.isis.rl.ac.uk/camerons_labblog/meta/DNA/value/plasmid),
meaning a double stranded circular DNA capable in principle of
transforming bacteria.
[SO:ss_oligo](http://www.sequenceontology.org/miso/current_cvs/term/SO:0000441)
maps onto
[DNA:oligonucleotide](http://biolab.isis.rl.ac.uk/camerons_labblog/meta/DNA/value/oligonucleotide)
(kind of, I've just noticed that [synthetic
oligo](http://www.sequenceontology.org/miso/current_cvs/term/SO:0001247)
is another term in SO).

But we ran into problems with our type
[DNA:double_stranded_linear](http://biolab.isis.rl.ac.uk/camerons_labblog/meta/DNA/value/double_stranded_linear).
In SO there is more than one term, including [restriction
fragments](http://www.sequenceontology.org/miso/current_cvs/term/SO:0000412)
and [PCR
products](http://www.sequenceontology.org/miso/current_cvs/term/SO:0000006).
This distinction was not useful to us. In fact it would create a
problem. For our purposes restriction fragments and PCR products were
equivalent in terms of what we could do with them. The distinction the
SO makes is in where they come from, not what they can do. Our schema is
driven by what we can do with them. Where they came from and how they
were generated is also implicit in our schema but it is separated from
what an object can be used for.

There is another distinction here. The drop down menus in our templates
do not have an â€œorâ€? logic in the current implementation. This drives
us to classify the possible use of objects in as general a way as
possible. We might wish to distinguish between â€œflat endedâ€? linear
double stranded DNA (most PCR products) and â€œsticky endedâ€? or
overhanging linear ds DNA (many restriction fragments) but we are
currently obliged to have at least one key value pair places these
together as many standard procedures can be applied to both. In ontology
construction there is a desire to describe as much detail as possible.
Our framework drives us towards being as general as possible. Both
approaches have their uses and neither is correct. They are built for
different purposes.

The bottom line is that for a structured vocabulary to be useful and
used it has to map well onto two things. The processes that the user is
operating and the inputs and outputs of those processes. That is it must
match the mental model of the user. Secondly it must map well onto the
tools that the user has to work with. Most existing biological
ontologies do not map well onto our LaBLog system, although we can
usually map to them relatively easy for specific purposes in a post-hoc
fashion. However I *think* our system is mapped quite well by some
[upper
ontologies](http://en.wikipedia.org/wiki/Upper_ontology_%28information_science%29).

Iâ€™m currently very intrigued by an idea that I heard from [Allyson
Lister](http://themindwobbles.wordpress.com/), which matches well onto
some other work Iâ€™ve recently heard about that involves â€œjust in
timeâ€? and â€œper-useâ€? data integration. It also maps onto the
argument I made in my recent paper that we need to separate the issues
of capturing research from those involved in describing and
communicating research. The idea was that for any given document or
piece of work, rather than trying to fit it into a detailed existing
ontology you build a single-use local ontology based on what is
happening in this specific case based on a more general ontology,
perhaps [OBO](http://www.obofoundry.org/), perhaps something even [more
general](http://en.wikipedia.org/wiki/Upper_ontology_%28information_science%29).
Then this local description can be mapped onto more widely used and more
detailed ontologies for specific purposes.

At the end of the day the key is effective communication. We donâ€™t all
speak the same language and weâ€™re not going to. But if we had the
tools to help us capture our research in an appropriate local dialect in
a way that makes it easy for us, and others, to translate into whatever
lingua franca is best for a given purpose, then we will make progress.


This is the second of two posts discussing the talk I gave at the Science 2.0 Symposium organized by Greg Wilson in Toronto in July. As I described in the last post Jon Udell pulled out the two key points from my talk and tweeted them.

Reflections on Science 2.0 from a distance &#8211; Part II

Interesting conversation yesterday on [Twitter](http://twitter.com) with
[Evgeniy Meyke](http://twitter.com/emeyke) of
[EarthCape](http://www.earthcape.com/) prompted in part by my [last
post](http://blog.openwetware.org/scienceintheopen/2009/08/11/the-trouble-with-business-models-facebook-buys-friendfeed/).
We started talking about what a [Friendfeed](http://friendfeed.com)
replacement might look like and how it might integrate more directly
into scientific data. Is it possible to build something general or will
it always need to be domain specific. Might this in fact be an
advantage? Evgeniy
[asked](http://twitter.com/emeyke/statuses/3243368657):

> @CameronNeylon do you think that "something new" could be more
> vertically oriented rather then for "research community" in general?

His thinking being, as I understand it that to get at domain specific
underlying data is always likely to take local knowledge. As he said in
his [next tweet](http://twitter.com/emeyke/statuses/3243639868):

> @CameronNeylon It might be that the broader the coverage the shallower
> is integration with underlining research data, unless api is good

This lead me to thinking about integration layers between data and
people and recalled something that I said in jest to someone some time
ago;

> "If you're using a human as your API then you need to work on your
> user interface."

Thinking about the way Friendfeed works there is a real sense in which
the system talks to a wide range of automated APIs but at the core there
is a human layer that firstly selects feeds of interest and then when
presented with other feeds selects from them specific items. What
Friendfeed does very well in some senses is provide a flexible API
between feeds and the human brain. But Evegeniy [made the
point](http://twitter.com/emeyke/statuses/3243726876) that this "works
only 4 'discussion based' collaboration (as in FF), not 4 e.g. collab.
taxonomic research that needs specific data inegration with taxonomic
databases".

Following from this was an [interesting
conversation](http://search.twitter.com/search?q=emeyke+cameronneylon)
\[[Webcite Archived Version](http://www.webcitation.org/5j06npMEY)\]
about how we might best integrate the "human API" for some imaginary
"Science Stream" with domain specific machine APIs that work at the data
level. In a sense this is the core problem of scientific informatics.
How do you optimise the ability of machines to abstract and use data and
meaning while at the same time fully exploiting the ability of the human
scientist to contribute their own unique skills, pattern recognition,
insight, lateral thinking. And how do you keep these in step with each
other so both are optimally utilised? Thinking in computational terms
about the human as a layer in the system with its own APIs could be a
useful way to design systems.

Friendfeed in this view is a peer to peer system for pushing curated and
annotated data streams. It mediates interactions with the underlying
stream but also with other known and unknown users. Friendfeed seems to
get three things very right: 1) Optimising the interaction with the
incoming data stream; 2) Facilitating the curation and republication of
data into a new stream for consumption by others, creating a virtuous
feedback look in fact; and 3) Facilitating discovery of new peers.
Friendfeed is actually a bittorrent for sharing conversational objects.

This conversational layer, a research discourse layer if you like, is at
the very top of the stack, keeping the humans to a high level abstracted
level of conversation, where we are probably still at our best. And my
guess is that something rather like Friendfeed is pretty good at being
the next layer down, the API to feeds of interesting items.Â  But
Evgeniy's question was more about the bottom of the stack, where the
data is being generated and needs to be turned into a useful and
meaningful feed, ready to be consumed. The devil is always in the
details and vertical integration is likely to help her. So what do these
vertical segments look like?

In some domains these might be lab notebooks, in some they might be
specific databases, or they might be a mixture of both and of other
things. At the coal face it is likely to be difficult to find a way of
describing the detail in a way that is both generic enough to be
comprehensible and detailed enough to be useful. The needs of the data
generator are likely to be very different to those of a generic data
consumer. But if there is a curation layer, perhaps human or machine
mediated, that partly abstracts this then we may be on the way to
generating the generic feeds that will be finally consumed at the top
layer.Â  This curation layer would enable semantic markup, ideally
automatically, would require domain specific tooling to translate from
the specific to the generic, and provide a publishing mechanism. In
short it sounds (again) quite a bit like [Wave](http://wave.google.com).
Actually it might just as easily be
[Chem4Word](http://research.microsoft.com/en-us/projects/chem4word/default.aspx)
or any other domain specific semantic authoring tool, or just a
translation engine that takes in detailed domain specific info and
correlates it with a wider vocabulary.

One of the things that appeals to me about Wave, and Chem4Word, is that
they can (or at least have the potential to) hide the complexities of
the semantics within a straightforward and comprehensible authoring
environment. Wave can be integrated into domain specific systems via
purpose built Robots making it highly extensible. Both are capable of
"speaking web" and generating feeds that can be consumed and processed
in other places and by other services. At the bottom layer we can chew
the problem off one piece at a tim, including human processing where it
is appropriate and avoiding it where we can.

The middleware is of coures, as always, the problem. The middleware is
agreed and standardised vocabularies and data formats. While in the past
I have thought this near intractable actually it seems as though many of
the pieces are actually falling into place. There is still a great need
for standardisation and perhaps a need for more meta-standards but it
seems like a lot of this is in fact on the way. I'm still not convinced
that we have a useful vocabulary for actually describing experiments but
enough smart people disagree with me that I'm going to shut up on that
one until I've found the time to have a closer look at the various
things out there in more detail.

These are half baked thoughts -- but I think the idea of where we
optimally place the human in the system is a useful question. It also
hasn't escaped my notice that I'm talking about something very similar
to the architecture that [Simon Coles](http://elnblog.com/) of [Amphora
Research Systems](http://www.amphora-research.com/) always puts up in
his [presentations on Electronic Lab
Notebook](http://www.amphora-research.com/resources/index.html)[s](http://www.amphora-research.com/resources/index.html).
Fundamentally because the same core drivers are there.


Interesting conversation yesterday on Twitter with Evgeniy Meyke of EarthCape prompted in part by my last post. We started talking about what a Friendfeed replacement might look like and how it might integrate more directly into scientific data. Is it possible to build something general or will it always need to be domain specific. Might this in fact be an advantage?

Where is the best place in the Research Stack for the human API?

OK, just back from the [first German Chemoinformatics
Conference](http://www.cic-workshop.de/), which I enjoyed very much. A
rather interesting program, and lots of interesting posters too. You can
read the programme online, and will not spend too many words on that (at
least not now). But what I will do is point out some interesting posters
here.

One poster was on the Molecular Query Language (MQL) by Ewgenij Proschak
from [Frankfurt](http://gecco.org.chemie.uni-frankfurt.de/). You can
read more on this in the latest [CDK
News](http://almost.cubic.uni-koeln.de/cdk/cdk_top/cdk_news/) as it is
implemented for the CDK too. The opensource implementation is expected
next year.

Another interesting poster was on the use of [ontologies to connect
chemistry and biology](http://www.biowisdom.com/ontology/faq_q3.htm).
This poster was by Juergen Harter from
[BioWisdom](http://www.biowisdom.com/), a Cambridge, UK based company.

[Marc Zimmermann](http://www.scai.fraunhofer.de/209.0.html?&L=1) had a
poster on the chemical OCR variant, called chemical structure
recognition (CSR). This process converts images, for example scanned
from literature, into a connectivity table. Difficult task, indeed.
[This
page](http://www.ercim.org/publication/Ercim_News/enw60/zimmermann.html)
contains some information about this project.

There were other interesting posters too, so will probably report on
those later too. But do feel free to leave comments to this blog post,
discussing other interesting posters.

#### References


OK, just back from the first German Chemoinformatics Conference, which I enjoyed very much. A rather interesting program, and lots of interesting posters too. You can read the programme online, and will not spend too many words on that (at least not now). But what I will do is point out some interesting posters here. One poster was on the Molecular Query Language (MQL) by Ewgenij Proschak from Frankfurt.

Postagens de Rogue Scholar

New Paper: "The ChEMBL database as linked open data"

Post GBIC2012 thoughts

ChEMBL 13 as RDF

Reflections on Science 2.0 from a distance – Part II

Where is the best place in the Research Stack for the human API?

Back from the 1st GCC