This post marks the re-introduction of a feed for each tag on this blog. I want this so that I can post without worrying about contributing to “pollution” of the scholarly record. I can accomplish this by tagging posts as #scholarly when I want them to be e.g. fetched by The Rogue Scholar for DOI minting and for subsequent linking to my ORCiD profile. This post should hopefully be my last act of such pollution.

I think of a community as a state (-ity) of having a purpose in mind (mmun->mean) together (co-), not as an endurable space. I think of a forum as an endurable space, as a doored (from the Latin fores , i.e. door) space of focus (from the French foyer ). How many makes a community? I don’t know.

Don’t archive you assets ¹ — frontier them. Research is a living process. ² Even when a research project is “finished”, is it really?

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.

The “one platform ¹ to rule them all” is unlikely to be realized for scientific research in any domain. Rather, instead of small and numerous on-premises silos for data + code + compute, we are on track to achieve large and somewhat less numerous cloud-based silos. ² What’s the alternative?

I have sought to identify and enumerate core FAIR-enabling services. I attempted a five-week experiment to expand on my tentative list, but I did not complete it. The list wasn’t compelling for me. I have been brewing an updated list of core FAIR-enabling services, which I hope to be less bombastic about.

Don’t. Identifiers should be opaque. If you’re given an owl:sameAs assertion from a party you trust, use that. If you need to mint surrogates because what you’re given aren’t Globally Unique, Persistent and Resolvable Identifiers (GUPRIs) ¹ , either house your inheritance as local parts/suffixes in your global namespace, assert datatype properties to record the historical correspondence, or both.