SWAT4LS was once again a great meeting. I doubt I will find time soon enough to write up notes, but at least I can post the eNanoMapper poster I presented, which is available from F1000Research:

In 2010 Samuel Lampa and I started a pet project: collecting pK _a data: he was working on RDF extension of MediaWiki and I like consuming RDF data. We started DrugMet. When you read this post, this MediaWiki installation may already be down, which is why I am migrating the data to Wikidata. Why?

Last week the huge, bi-annual ACS meeting took place (#ACSSanDiego), during which commonly new drug (leads) are disclosed.

Adding chemical compounds to Wikidata is not difficult. You can store the chemical formula (P274), (canonical) SMILES (P233), InChIKey (P235) (and InChI (P234), of course), as well various database identifiers (see what I wrote about that here ]). It also allows storing of the provenance, and has predicates for that too. So, to enter a new structure for a compound, you should enter the compound information to Wikidata.

Source: Wikipedia. CC-BY-SA April this year I blogged about an important SPARQL query for many chemists: getting CAS registry numbers from Wikidata. This is relevant for two reasons: CAS works together with Wikimedia on a large, free CAS-to-structure database Wikidata is CCZero The original effort validated about eight thousand registry numbers, made available via Wikipedia and the Common Chemistry website.

If you are a scientist you have heard about the ORCID identifier by now. If not, you have been focusing on groundbreaking research and isolated yourself from the rest of the world, just to make it perfect and get that Nobel prize next year.

I have promised my Twitter followers the SPARQL query you have all been waiting for. Sadly, you had to wait for it for more than two months. I’m sorry about that.

The Royal Society of Chemistry and Wikipedia just released an interesting press release: This leaves me with a lot of questions. I asked these in a comment awaiting moderation: Details on how to apply to access can be found here.

I previously wrote about the JavaScript Object Notation (JSON) which has become a de facto standard for sharing data by web services. I personally still prefer something using the Resource Description Framework (RDF) because of its clear link to ontologies, but perhaps JSON-LD combines the best of both worlds. The Open PHACTS API support various formats and this JSON is the default format used by the ops.js library.

Debugging is the process find removing a fault in your code (the etymology goes further back than the moth story, I learned today). Being able to debug is an essential programming skill, and being able to program flawlessly is not enough; the bug can be outside your own code.

I think the authors of the Open PHACTS proposal made a right choice in defining a small set of questions that the solution to be developed could be tested against. The questions being specific, it is much easier to understand the needs. In fact, I suspect it may even be a very useful form of requirement analysis, and makes it hard to keep using vague terms. Open PHACTS has come up with 20 questions (doi:10.1016/j.drudis.2013.05.008;