To explain a FAIR research platform, we have to show how they are built from mindless stuff, smaller and simpler than anything we’d consider smart. What could these simpler particles be – the “agents” that compose the platform? There are many questions to answer: Function: How do agents work? Embodiment: What are they made of? Interaction: How do they communicate? Learning: How do we make new agents and change old ones?

“Self-describing” data products include/contain/link to any “knowledge products” (schema, ontology, etc.) they were informed by. In the sense of the data-information-knowledge-wisdom (DIKW) conceptualization, are there information products ? Perhaps self-describing information products include/contain/link to any “wisdom products” (usage context!

How do FAIR data resources work? How can you build a FAIR resource from many little parts, each non-FAIR by itself? Minsky’s The Society of Mind tries to explain how minds can work, how intelligence can emerge from non-intelligence, how you can build a mind from many little mindless parts. In the “society of mind” scheme, a mind is made of many smaller agents . Each agent plays a simple role that needs no mind at all.

Not documenting failures causes them to be repeated. This repetition is waste because no new information is generated. Only new failures generate information. There is an optimum failure rate. ¹ We can avoid oversimplifications like “embrace failures” or “avoid failures”. We maximize information gain by making outcomes equally likely. Thus, for a test with two outcomes, seek a 50% failure rate.

Inside black boxes you find programs. There are a lot of programming languages. You may not care how black box \(A\) works as a substitute for black box \(B\) if it’s observationally equivalent to black box \(B\). How do the boxes interact? What’s inside the arrows that connect the boxes? Inside arrows you find protocols. There are a lot of protocols.

URIs are great for namespacing terms. However, the local names — after the last / — could be a free-for-all. One common convention — but not typically a contract — is to use upper camel case for rdfs:Class instances and lower camel case for rdf:Property instances. Is it useful to systematize the construction of local names? Emily Riederer argues yes.

What is the “killer use case” for Reasoning, i.e., inferencing over a semantic graph database? Data in a relational database “knows nothing.” Data in a graph database “knows how it is connected” – you can ask an entity to tell you who its neighbors are 3 hops out, or if two pieces are connected up to 20 hops. Data with Reasoning “knows how to think.” But what does that mean exactly? What do you get?

I recently came across a procedure for achieving a flow state: One activity at a time. The activity is meaningful to you. You work at the edge of your abilities. I can’t recall the source of this. So, dear reader, please send me something I can cite if you have encountered this 3-step procedure elsewhere. In this post, I relate the above procedure to my recent post on mean-ing.

It is better to have a large variety of firm rulers that feed into selection pressure for utility in some environment, than to have a few flexible ones for which your measurements aren’t consistent. Generate and test. Conjecture and refute. May there be a flowering of crisp attribute and entity specs. A flexible schema is like a rubber ruler.

A traditional postdoc filler seeks to transition to a different role, that of professor or staff. What if someone were to specialize in this kind of role, e.g. for a certain kind of project in a certain kind (e.g. group size) of research environment? Such a position would be akin to the modern \(\approx\) 1-3 yr startup position specialized to a certain growth stage of a startup.