In the marketplace, the needs of producers and consumers are often at odds: producers want higher prices, consumers lower ones; producers want easy assembly, consumers easy dis-assembly; producers want flexibility and rapid prototyping, consumers reliability and long-term support.
The same competing needs exist in the world of scientific data management where producers of data and consumers of data often operate in very different worlds with very different sets of tools.
Having recently announced the beakr web framework for R, we have received several questions about context and why we choose beakr over other options for some of our web services. This post will attempt to answer some of those questions by providing a few opinions on beakr and other web frameworks for R.
The comparison will by no means be exhaustive but will attempt to briefly summarize some of the key features each web framework has to offer. While there are some differences in the approach each package takes to developing web services, they all share similar basic functionality. In the end, the choice of a particular framework will come down largely to personal preference.
Have you ever asked yourself whether your telephone number is really a number? It’s got numbers in it but does it measure anything?
How about your credit card number? PO Box? Social Security Number? Zip code? What would happen if you subtracted one of these from another?
As it turns out, many of the “numbers” we deal with every day are actually identifiers and not a measure of something. Sadly, too many data managers do not distinguish between the two even though making this distinction is quite simple.
beakr is an unopinionated and minimalist web framework for developing and deploying web services with R. It is designed to make it as simple as possible for data scientists and engineerings to quickly write web applications, services, and APIs without worrying about lower-level details or high-level side-effects. In other words, beakr is made to be explicit,robust, and scalable – and the batteries are not included.
In a previous post, we looked at error handling in R with the tryCatch() function and how this could be used to write Java style try-catch-finally blocks. This time we’ll look at what can be done with the try() function and how we can easily process warning and error messages to take appropriate action when something goes wrong.
The R language definition section on Exception Handling describes a very few basics about exceptions in R but is of little use to anyone trying to write robust code that can recover gracefully in the face of errors. In fact, if you do a little searching you will find that quite a few people have read through the ?tryCatch documentation but come away just as confused as when they started. In this post we’ll try to clarify a few things and describe how R’s error handling functions can be used to write code that functions similarly to Java’s try-catch-finally construct.
One of the big jokes among people who manage scientific datasets goes like this:
The great thing about standards is … there are so many to choose from!
While this one liner may never make it to late-night TV, there is much truth to it. Many “standards” exist, and many more are invented each month to accommodate the special needs of new types of data or new software for processing data.
One standard, however, stands far above other options and should always be adopted: ISO 8601– the international standard for representing dates and times.
The world of scientific data management, analysis, visualization and public access is changing so rapidly it can be difficult to keep up with developments even in one’s own field. Staying abreast of progress in all areas of science, let alone business, is an impossibility.
Then there are big picture questions about how the whole scientific endeavor is changing:
Does the long tradition of intellectual property rights with respect to science data apply in today’s cut-and-paste world?
How can scientists and policymakers use on-line tools to collaborate across the vast divide that separates them?
What role does the interested, intellegent layman play in the the dissemination and analysis of scientific data?
How can better delivery of data and analysis products improve the utility of publicly sponsored, publicly owned data?
These are the types of questions that occupy us every day at Mazama Science. We spend a tremendous amount of time thinking about them ourselves and seeking answers from others in our broad community of contacts.
In this blog we hope to distill some of that group knowledge in the hopes that it may be useful or inspiring to those attempting to do similar work — supporting a data-focused, scientific approach to society’s pressing issues.