Maastricht University

Egon Willighagen

Readers of my blog know I have been using the Citation Typing Ontology,
CiTO
(doi:[10.1186/2041-1480-1-S1-S6](http://dx.doi.org/10.1186/2041-1480-1-S1-S6)).
I allows me to see [how the
CDK](http://chem-bla-ics.blogspot.com/2010/02/citing-chemistry-development-kit.html)
is [cited and
used](http://chem-bla-ics.blogspot.com/2010/10/citeulike-cito-use-case-1-wordles.html).
CiteULike is currently adding more CiTO more functionality, which they
[started](http://chem-bla-ics.blogspot.com/2010/09/list-of-things-i-miss-in-citeulike.html)
doing almost one and a half years ago.

One of the things, is that the CiTO data added via a certain account,
can be downloaded as triples:

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

The second is that they are improving the graphics of how it is
visualized. E.g. they added an 'Expand' link, which I found when they
[tweeted](https://twitter.com/#!/citeulike/status/172446830666321921)
they had hidden drag-n-drop, which I haven't found yet, though. Clicking
that action, will show you the following:

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

Because CiteULike takes advantage of the [inverse
function](http://www.w3.org/TR/owl-ref/#InverseFunctionalProperty-def)
of the CiTO predictates, they show up with the cited paper too, which is
less suitable for the top-down flow graphics:

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

To make this advertorial a bit balanced, not all [my
wishes](http://chem-bla-ics.blogspot.com/2010/09/list-of-things-i-miss-in-citeulike.html)
have been implemented yet, and the next up from my perspective should be
Linked Data. There is some Linked Data embedded as RDFa, but the latter
is not turning out to be the killer I had hoped, and regular RDF entry
points should be used.

Each CiteULike entry (post) should get a unique
[IRI](http://en.wikipedia.org/wiki/Internationalized_Resource_Identifier)
(or [URI](http://en.wikipedia.org/wiki/Uniform_resource_identifier)) and
opening that link should give RDF about that post ([wish
\#10](http://www.citeulike.org/groupforum/2191)). That's is
[dereferencibility](http://en.wikipedia.org/wiki/Dereferenceable_Uniform_Resource_Identifier).
The RDF can be, for example, in [BIBO](http://bibliontology.com/) but
there are many alternatives, and I have not been keeping up with which
is the best (please leave a comment, if you have an opinion on that).

But I like where this is going! Thanx, CiteIReallyLikeThis!

#### References

- [10.1186/2041-1480-1-S1-S6](https://doi.org/10.1186/2041-1480-1-S1-S6)


Readers of my blog know I have been using the Citation Typing Ontology, CiTO (doi:10.1186/2041-1480-1-S1-S6). I allows me to see how the CDK is cited and used. CiteULike is currently adding more CiTO more functionality, which they started doing almost one and a half years ago.

CiTO / CiteULike: publishing innovation

[Web of Science](http://en.wikipedia.org/wiki/Web_of_Science) is my de
facto standard for citation statistics (I need these for
[VR](http://vr.se/) grant applications), and defines the lower limit of
citations (it is pretty clean, but I do have to ping them now and then
to fix something). The public front-end of it is [Researcher
ID](http://www.researcherid.com/rid/C-6136-2008). There is an [Microsoft
initiative](http://academic.research.microsoft.com/Author/2893110/egon-l-willighagen),
which looks clean but doesn't work on Linux for the nicer things, but
the coverage of journals is pretty bad in my field, giving a biased
(downwards) [H-index](http://en.wikipedia.org/wiki/H-index). And
[CiteULike](http://www.citeulike.org/user/egonw) and
[Mendeley](http://www.mendeley.com/profiles/egon-willighagen/) focus
more on your publications than on citations (though the former has
[great CiTO
support](http://opencitations.wordpress.com/2010/10/21/use-of-cito-in-citeulike/)!).

Then [Google Scholar
Citations](http://googlescholar.blogspot.com/2011/07/google-scholar-citations.html)
(GSC) shows up. While it does not look as pretty as competing products,
it compensates that with a wide coverage of literature (for example, it
supports the [JChemInf](http://jcheminf.com/), which Web-of-Science
currently does not; and I happen to publish a lot in that journal
recently), books, and reports, while keeping false positives fairly low.
Thus, it provides an upper limit of my citations statistics, but one I
am pretty happy confident about. And my H-index is quite comparable
anyway. This is what [my
profile](http://scholar.google.com/citations?user=u8SjMZ0AAAAJ) looks
like:

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

So, these statistics have two purposes to me: 1. grant applications, and
2. I like to know what people based theirs on my research. (Well, OK, 3.
it helps me understand why I work so hard on too many things.)

Now the question is, will GSC take off. Will it replace
[ORCID](http://orcid.org/)? Will they join ORCID? Will GSC get a good
API? Who will write the first
[userscript](http://www.biomedcentral.com/1471-2105/8/487) to make the
GUI fancier? Will GSC support CiTO? Will GSC start using microformats or
RDFa? What mashups can we expect between bibliographic databases? Will
new entries automatically be posted to Google+? Will it have a button to
autocreate a blog post when a paper gets cited 100, 500, or a 1000
times? Will GSC support
[\#altmetrics](http://friendfeed.com/search?q=%23altmetrics)?

#### References

- [10.1186/1471-2105-8-487](https://doi.org/10.1186/1471-2105-8-487)


Web of Science is my de facto standard for citation statistics (I need these for VR grant applications), and defines the lower limit of citations (it is pretty clean, but I do have to ping them now and then to fix something). The public front-end of it is Researcher ID. There is an Microsoft initiative, which looks clean but doesn’t work on Linux for the nicer things, but the coverage of journals is pretty bad in my field, giving a biased

My Google Scholar Citations profile arrived

Last month I reported a [few things I
missed](http://chem-bla-ics.blogspot.com/2010/09/list-of-things-i-miss-in-citeulike.html)
in [CiteULike](http://www.citeulike.org/). One of them was support for
CiTO (see
doi:[https://doi.org/10.1186/2041-1480-1-S1-S6](10.1186/2041-1480-1-S1-S6)),
a great Citation Typing Ontology.

I promised the CiTO author,
[David](http://www.zoo.ox.ac.uk/staff/academics/shotton_dm.htm), my use
cases, but have been horribly busy in the past few weeks with my new
position, wrapping up my past position, and thinking on my position
after Cambridge. But finally, here it is. Based on source code I [wrote
and released earlier](http://github.com/egonw/groovy-citeulike), the
first use case I represent is the [Wordle](http://www.wordle.net/) one,
which I [showed with manual work in
February](http://chem-bla-ics.blogspot.com/2010/02/wordle-of-titles-of-20-most-recent.html).

Now that all the data is semantically marked up in CiteULike, I can
easily extract all paper titles (or whatever is available in CiteULike)
for all papers that cite the first [CDK](http://cdk.sf.net/) paper
(doi:[10.1021/ci025584y](http://dx.doi.org/10.1021/ci025584y)). Using
the JSON interface, I have [this Groovy
script](http://github.com/egonw/groovy-citeulike/blob/master/cul2wordleInput.groovy)
to extract all titles:

:::: {.language-groovy .highlighter-rouge}
::: {.highlight}
``` highlight
import groovyx.net.http.HTTPBuilder
import groovyx.net.http.Method
import static groovyx.net.http.ContentType.JSON

culUrl = "http://www.citeulike.org/";

citotags = [
  "cito--cites",
  "cito--usesMethodIn",
  "cito--discusses",
  "cito--extends"
// there are more, but these are all
// I use right now
]

papers = [
  "1073448",
  "423382"
]

http = new HTTPBuilder(culUrl)

papers.each { paper ->
  println "# Processing $paper..."
  citotags.each { tag ->
    citation = "$tag--$paper".toLowerCase()
    http.request(Method.valueOf("GET"), JSON) {
      uri.path = "/json/user/egonw/tag/$citation"

      response.success = { resp,json ->
        json.each { article ->
          tripleCount = 0;
          article.tags.each { artTag ->
            if (artTag.startsWith(tag)) tripleCount++
          }
          if (tripleCount > 0) {
            title = article.title
            title = title.replaceAll("\\{","")
            title = title.replaceAll("\\}","")
            println "$title"
          }
        }
      }
    }
  }
}
```
:::
::::

The output is two blocks which I can easily copy/paste into Wordle. Now,
I think I heard one can actually download the java code, so I am tempted
to integrate it later, but for now copy/paste will do fine, after the
data handling is mostly automated: with a few lines extra I can make
such visualizations for any paper I annotated in CiteULike with CiTO.

**The CDK I paper**

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

**The CDK II paper**

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

Interesting differences... more statistics will soon follow. See
[Further statistics on the papers citing the
CDK](http://chem-bla-ics.blogspot.com/2010/02/further-statistics-on-papers-citing-cdk.html)
for the kind of analyses I have in mind.

#### References

- [10.1186/2041-1480-1-S1-S6](https://doi.org/10.1186/2041-1480-1-S1-S6)
- [10.1021/CI025584Y](https://doi.org/10.1021/CI025584Y)


Last month I reported a few things I missed in CiteULike. One of them was support for CiTO (see doi:https://doi.org/10.1186/2041-1480-1-S1-S6), a great Citation Typing Ontology. I promised the CiTO author, David, my use cases, but have been horribly busy in the past few weeks with my new position, wrapping up my past position, and thinking on my position after Cambridge.

CiteULike CiTO Use Case #1: Wordles

AJCann posted a blog today about what [he doesn't like about
Mendeley](http://scienceoftheinvisible.blogspot.com/2010/09/long-list-of-things-i-dont-like-about.html).
Abhishek replied that he does not like people complain about one tool,
instead of pointing out a good alternative.
[Mendeley](http://www.mendeley.com/) has two alternatives,
[Zotero](http://www.zotero.org/) and
[CiteULike](http://www.citeulike.org/) (there is also
[Connotea](http://connotea.org/), but got behind in evolution).

Agreeing with [@citeulike](http://twitter.com/citeulike) and
[@abhishektiwari](http://twitter.com/abhishektiwari), as a service
provider any bad news is good news too: they provide opportunities to
improve. So, as encouraged to do so, I reported my long list of things I
miss in CiteULike:

- @citeulike ok, one more. wish \#18: get readermeter.org to also
  support citeulike
- @citeulike wish \#17: allow people linking between papers in their
  libs using CiTO to annotate how they cite papers, see
  http://ur.ly/lBUO
- @citeulike wish \#16: I think I saw images from some papers, right?
  how about doing that for \#biomedcentral journals too?
- @citeulike wish \#15: at the same http://ur.ly/lIGn page, the tag
  cloud should reflect tag use with font sizing
- @citeulike wish \#14: upon 'post url', the first page with extraced
  information should allow marking as 'I am author' (cannot find that)
- @citeulike (new) wish \#12: clicking an account name should get me to
  a public portal, rather than just his paper list
- @citeulike good point, wish \#13: be more strong on requiring people
  to tag papers... and use article keywords as default tags
- @citeulike wish \#11: remove 'no-tag' from tag clouds
- @citeulike wish \#10: support \#RDF export with BIBO and/or PRISM
- @citeulike wish \#9: use \#foaf for the RDFa for account pages, and to
  mark up friends
- @citeulike wish \#8: and more generally, make \#citeulike part of the
  \#linkeddata network (provide an \#rdf API)
- @citeulike wish \#7: start using RDFa, e.g. with the PRISM ontology
- @citeulike wish \#6: on an article page (like http://ur.ly/lvWk)
  summarize the network that bookmarked that article, not just the acc
  names
- @citeulike wish \#5: don't show the 'copy' button for papers that are
  already in my archive (really a bug)
- @citeulike indeed, but don't or do it right... wish \#4: allow people
  to have that link automatically point to an external blog
- @citeulike wish \#3: provide summaries of lists, like article count
  per journal and article count per year
- @citeulike well, I'll use the blog functoinality to summarize... wish
  \#2: do not try to be a blogging platform
- @citeulike (new) wish \#1: put automatically focus on text field after
  clicking search and select all text for easy deletion

The reports are now also available in the [fora of
CiteULike](http://www.citeulike.org/groupfunc/3124/forums).

#### References


AJCann posted a blog today about what he doesn’t like about Mendeley. Abhishek replied that he does not like people complain about one tool, instead of pointing out a good alternative. Mendeley has two alternatives, Zotero and CiteULike (there is also Connotea, but got behind in evolution).  Agreeing with @citeulike and @abhishektiwari, as a service provider any bad news is good news too: they provide opportunities to improve.

A list of things I miss in CiteULike

Cameron Neylon

*The second installment of the paper ([first part
here](http://cameronneylon.net/blog/a-personal-view-of-open-science-part-i/))
where I discuss building tools for Open (or indeed any) Science.*

**Tools for open science -- building around the needs of scientists**

It is the rapid expansion and development of tools that are loosely
categorised under the banner of 'Web2.0' or 'Read-write web' that makes
the sharing of research material available. Many of the generic tools,
particularly those that provide general document authoring capabilities,
have been adopted and used by a wide range of researchers. Online office
tools can enable collaborative development of papers and proposals
without the need for emailing documents to multiple recipients and the
resultant headaches associated with which version is which. Storing
spreadsheets, databases, or data online means that collaborators have
easy access to the most recent versions and can see how these are
changing. More generally the use of RSS feed readers and bookmarking
sites to share papers of interest and, to some extent, to distribute the
task of triaging the literature are catching in in some communities. The
use of microblogging platforms such as Twitter and aggregation and
conversational tools such as Friendfeed have recently been used very
effectively to provide coverage of conferences in progress, including
collaborative note-taking. In combination with streamed or recorded
video as well as screencasts and sharing of presentations online the
idea of a dstributed conference, while not an everyday reality, is
becoming feasible.

However it is often the case that,while useful, generic web based
services do not provide desired functionality or do not fit well into
the existing workflows of researchers. Here there is the opportunity,
and sometime necessity, to build specialised or adapated tools.
Collaborative preparation of papers is a good example of this.
Conventional web bookmarking services, such as del.icio.us provide a
great way of sharing the literature or resources that a paper builds on
with other authors but they do not automatically capture and recognise
the necessary metadata associated with published papers (journal, date,
author, volume, page numbers). Specialised services such as citeulke and
Connotea have been developed to enable one click bookmarking of
published literature and these have been used effectively by for example
using a specific tag for references associated with a specific paper in
progress. The problem with these services as they exist at the moment is
that they don't provide the crucial element in the workflow that
scientists want to aggregate the references for, the formatting of the
references in the finalised paper. Indeed the lack of formatting
functionality in GoogleDocs, the most widely used collaborative writing
tool, means that in practice the finalised document is usually cut and
pasted into Word and the references formatted using proprietary software
such as Endnote.The available tools do not provide the required
functionality.

A number of groups and organisations have investigated the use of Blogs
and Wikis as collaborative and shareable laboratory notebooks. However
few of these systems offer good functionality 'out of the box'. While
there are many electronic laboratory notebook systems sold by commercial
interests most are actually designed around securing data rather than
sharing it so are not of interesthere. While the group of Jean-Claude
Bradley has used the freely hosted WikiSpaces as a [laboratory
notebook](http://usefulchem.wikispaces.com) without further
modification, much of the data and analysis is hosted on other services,
including YouTube, FlickR, and GoogleDocs. The OpenWetWare group has
made extensive modifications to the MediaWiki system to [provide
laboratory notebook
functionality](http://openwetware.org/wiki/Lab_Notebook) whereas Garret
Lisi has adapted the TiddlyWiki framework as a way of [presenting his
notebook](http://deferentialgeometry.org). The [Chemtools
collaboration](http://chemtools.chem.soton.ac.uk/) at the University of
Southampton has developed a specialised Blog platform . Commercial
offerings in the area of web based lab notebooks are also starting to
appear. All of these different systems have developed because of the
specialised needs of recording the laboratory work of the scientists
they were designed for. The different systems make different assumptions
about where they fit in the workflow of the research scientist, and what
that workflow looks like. They are all, however, built around the idea
that they need to satisfy the needs of the user.

This creates a tension in tool building. General tools, that can be used
across a range of disciplines, are extremely challenging to design,
because workflows, and the perception of how they work, are different in
different disciplines. Specialist tools can be built for specific fields
but often struggle to translate into new areas. Because the market is
small in any field the natural desire for designers is to make tools as
general as possible. However in the process of trying to build for a
sufficiently general workflow it is often the case that applicability to
specific workflows is lost. There is a strong argument based on this for
building interoperable modules, rather than complete systems, that will
allow domain specialists to stich together specific solutions for
specific fields or even specific experiments. Interoperability of
systems and standards that enable it is a criteria that is sometimes
lost in the development process, but is absolutely essential to making
tools and processes shareable. The use of workflow management tools,
such as [Taverna](http://en.wikipedia.org/wiki/Taverna_workbench),
[Kepler](http://en.wikipedia.org/wiki/Kepler_scientific_workflow_system),
and [VisTrails](http://www.vistrails.org/index.php/Main_Page) have an
important role to play here.

While not yet at a stage where they are widely configurable by end users
the vision behind them has the potential both to make data analysis much
more straightforward for experimental scientist but also to solve many
of the problems involved in sharing process, as opposed to data. The
idea of visually wiring up online or local analysis tools to enable data
processing pipelines is compelling. The reason most experimental
scientists use spreadsheets for data analysis is that they do not wish
to learn programming languages. Providing visual programming tools along
with services with clearly defined inputs and outputs will make it
possible for a much wider range of scientists to use more sophisticated
and poweful analysis tools. What is more the ability to share, version,
and attribute, workflows will go some significant distance towards
solving the problem of sharing process. Services like
[MyExperiment](http://myexperiment.org) which provide an environment for
sharing and versioning Taverna workflows provide a natural way of
sharing the details of exactly how a specific analysis is carried out.
Along with an electronic notebook to record each specific use of a given
workflow or analysis procedure (which can be achieved automatically
though an API) the full details of the raw data, analysis procedure, and
any specific parameters used, can be recorded. This combination offers a
potential route out of the serious problem of sharing research processes
if the appropriate support infrastructure can be built up.

Also critical to successful sharing is a shared language or vocabulary.
The development of ontologies, controlled vocabularies, and design
standards are all important in sharing knowledge and crucial to
achieving the ulitmate goals of making this knowledge machine readable.
While there are divisions in the technical development and user
communities over the development and use of controlled vocabularies
there is little disagreement over the fact that good vocabularies
combined with good tools are useful. The disagreements tend to lie in
how they are best developed, when they should be applied, and whether
they are superior to or complementary to other approaches such as text
mining and social tagging. An integrated and mixed approach to the use
of controlled vocabularies and standards is the most likely to be
successful. In particular it is important to match the degree of
structure in the description to the natural degree of structure in the
object or objects being described. Highly structured and consistent data
types, such as crystal structures and DNA sequences, can benefit greatly
from highly structured descriptions which are relatively straightforward
to create, and in many cases are the standard outputs of an analysis
process. For large scale experimental efforts the scale of the data and
sample management problem makes an investment in detailed and structured
desriptions worth while. In a small laboratory doing unique work,
however, there may be a strong case for using local descriptions and
vocabularies that are less rigorous but easier to apply and able to grow
to fit the changing situation on the ground. Ideally designed in such a
way that mapping onto an external vocabulary is feasible if it is
required or useful in the future.

Making all of this work requires that researchers adopt these tools and
that a community develops that is big enough to provide the added value
that these tools might deliver. For a broad enough community to adopt
these approaches the tools must fit well in their existing workflow and
help to deliver the things that researchers are already motivated to
produce. For most researchers, published papers are the measure of their
career success and the basis of their reward structures. Therefore tools
that make it easier to write papers, or that help researchers to write
better papers, are likely to get traction. As the expectations of the
quality and completeness of supporting data increase for published
papers, tools that make it easier for the researcher to collate and
curate the record of their research will become important. It is the
process of linking the record of what happened in the laboratory, or
study, to the first pass intepretation and analysis of data, through
further rounds of analysis until a completed version is submitted for
review, that is currently poorly supported by available tools, and it is
this need that will drive the development of improved tools. These tools
will enable the disparate elements of the record of research, currently
scattered between paper notebooks, various data files on multiple hard
drives, and unconnected electronic documents, to be chained together.
Once this record is primarily electronic, and probably stored online in
a web based system, the choice to make the record public at any stage
from the moment the record is made to the point of publication, will be
available. The reason to link this to publication is to tie it into an
existing workflow in the first instance. Once the idea is embedded the
steps involved in making the record even more open are easily taken.

*[Part
III](http://cameronneylon.net/blog/a-personal-view-of-open-science-part-iii-social-issues/)
covers social issues around Open Science.*


<em>
 The second installment of the paper (first part here) where I discuss building tools for Open (or indeed any) Science.
</em>
<strong>
 Tools for open science – building around the needs of scientists
</strong>
It is the rapid expansion and development of tools that are loosely categorised under the banner of ‘Web2.0’ or ‘Read-write web’ that makes the sharing of research material available.

Messaggi di Rogue Scholar

CiTO / CiteULike: publishing innovation

My Google Scholar Citations profile arrived

CiteULike CiTO Use Case #1: Wordles

A list of things I miss in CiteULike

A personal view of Open Science – Part II – Tools