How do you effectively share a computational process? You could simply share a directory of source code and rely on shared conventions – shared programming language, shared tooling for build and runtime environments, a README.txt convention for communicating setup instructions, etc.

You have a data-intensive research problem. Custom software will help you solve it. Code is written. A dataset is collected to feed the code. Did you just create another silo? What would it mean to be data-centric, with only one data platform and with applications on top, where applications come and go? In your group, who decides what kind of database to use?

“Centralization”. “Mapping”. These are overloaded concepts. They mean different things in different contexts. One hawk-eyed reader has rightly cried Ambiguous! on my usage of these terms in recent notes.

Scientific data is distributed over time. For a given entity of interest, have we already recorded all potentially relevant data on its properties, relationships, and representations? Have we already enumerated all of an entity’s potential attributes for which to slot in such data? Have we already named all possible types of entities of interest in our domain?

Scientific data is fundamentally distributed: physically, conceptually, and temporally. You can’t situate all the data you’ll ever need, once and for all, in one place. There will always be another source of data. And another. Centralization doesn’t work for large, global enterprises like modern science.

I have written a bit about benefits of FAIR; however, a reader rightly pointed out to me that there is no such thing as a free lunch – what are some of the costs of FAIR? Below is my first stab at a diagram that I hope distinguishes some costs and benefits of FAIR, and how they are related, in the case of building an “inside track” for an existing research-information lifecycle.

Findability is making reuse possible. If no one can discover your data, if even basic metadata is hidden in a silo, then reuse is simply not possible. Accessibility is making reuse plausible. People and their designated software agents can not only identify relevant resources via metadata, but they can actually retrieve full data for inspection and evaluation. Interoperability is making reuse probable.

A format describes what your content “is”; a model describes what your content is “about”. Is-ness issues will affect people’s ability to use your data (it’s not informative if it’s not “in formation”), but about-ness is at the core of analysis. CSV and JSON are formats. SQL and RDF describe models.

The seminal article on FAIR defines interoperability as “the ability of data or tools from non-cooperating resources to integrate or work together with minimal effort.” Is the “non-cooperating” part important here?

A “knowledge line”, aka “K-line”, is a representation of knowledge that connects what we know with how it’s used – we keep each thing we learn close to the agents that learn it in the first place. ¹ When a K-line is re-activated, the agents attached to it are re-activated, putting a system in a “mental state” similar to when this thing we know was last generated, used, and/or persisted.