Header image: John William Waterhouse, Public domain, via Wikimedia Commons A lot of people smarter than me have been sounding the alarm about the potential threat that AI poses for some time, and I have chosen to ignore it. Until recently, I had never had a conversation with an AI that sounded even halfway plausible.

Several controlled vocabularies and ontologies that aren’t themselves OBO Foundry ontologies use unsanctioned OBO PURLs. This post is about how to use the Bioregistry to identify which resources are doing this and to give some insight into how we arrived in this situation. Background on the OBO Foundry The OBO Foundry is a set of independent, interoperable biomedical ontologies that aspire to using shared development principles.

There's a strange moment that occurs during passionate arguments between close friends, romantic partners, or coworkers when two sides with deeply dug opposing trenches suddenly realize that they agree - almost - about everything at issue. When the key realization is that the two sides differ not so much about the facts, as the paradigm by which they approach those facts.

My recent post on the Starschema blog discusses the need for better data products to tackle future pandemic challenges: Read the full post here.

There’s a notion in artificial intelligence known as Moravec’s paradox: it’s relatively easy to teach a computer to play chess or checkers at a pretty decent level, but near impossible to teach it something as trivial as bipedal motion. (Hassabis 2017) The sensorimotor tasks that our truly wonderful brains have mastered by our second birthday are much harder to teach a computer than something arguably as ‘complex’ as beating a chess grandmaster.

model-memo The things of concern ¹ are materials, processes, measurements, and ingredients. Materials are output by processes and are subject to measurements. A process may take materials as ingredients. Things are recorded in three ways: as templates, as specs, and as runs. You can record a template for a thing – what might be the case. You can also record a spec for a thing – what is intended.

For each layer in the structured-content stack, ¹ from least to most volatile (i.e. domain modeling ⟶ content design ⟶ interface design), draft successive model expressions, ² from most to least ambiguous (as many expressions as needed to move confidently to the next stack layer). Structured-content-stack breakdown: Domain model (object types and relationships) Content content model (content types and attributes) content

The key technical foundations for FAIRifying data are (1) ubiquitous persistent identifiers; (2) rich controlled metadata; and (3) granular programmatic access. These foundations provide a basis for FAIR data infrastructure. This note is inspired by Rory Macneil’s recent interview with Sharif Islam on the FAIR Data Podcast, published on 2022-12-21. In particular, I expand on the Q&A segment starting at PT14M10S.

How does a Research Software Engineer (RSE) — often responsible for developing infrastructure to manage and share digital research objects (data, models, code, notebooks, workflows, etc.) — get from “Yes, FAIR sounds great, but how?” to “I better understand what the FAIR principles really mean and how I can put them into practice.”? I hope the diagram below can help.

I’ve been trying to grok architecture patterns as presented by Percival and Gregory ¹ to support domain-driven design and event-driven microservices with Python. I hope you find the diagram below useful. A microservices approach seems apt for FAIR-enabling services that need to be composed, flexibly, for any given research artifact’s digital lifecycle.