Stephen Downes

Colin Beer is usually sharper than this, so while I agree that knowledge and skills (as he defines them) are not enough, I think we need some clarity regarding what he calls 'dispositions' (it's not that he's wrong so much as he's fuzzy). He writes, "Dispositions represent the values, tendencies, and attitudes, such as motivation, mindset, professional identity and agency, that dictate how a professional actually navigates the "swampy lowlands" of practice. In simple terms, dispositions are the habits of mind and heart that shape how we show up when work gets hard." Dispositions are best described as tendencies, which may result from habits, or which may be subconscious tics. They should be contrasted with attitudes, which are states of mind regarding such things as values and truth. Expertise (in, say, the Dreyfus sense) is a matter of disposition, while professionalism is a matter of attitude. It's certainly arguable that an education should (help) shape both, but they are very distinct things, and are approached very differently.

I spent some time thinking about this short article that explores "the difference between good relationships and good transactions" where a 'good relationship' is "unique, organic, and empathetic, helping us understand when to invest in building relationships versus when a transaction suffices." What made me think wasn't the distinction itself, which seems straightforward, but the terminology used. The way 'relationship' is defined blends elements of different constructs - we have 'unique' and 'sustained', which to me describes a 'connection', but in addition there is the presumption that relationships are embodied, as evidenced by 'organic' and 'empathetic'. The connection describes the relationship itself, while the embodied element describes the thing that is related. The transaction side, meanwhile, describes the exchange that happens between two entities, as opposed to the connections between them. The world view of this article doesn't grant (or doesn't require?) embodiment for transactions to occur. I would ask whether the author intended to distinguish between embodied and non?-embodied entities here, or whether it's just phrasing.

The current issue of The Batch introduces readers to Context Hub, Andrew Ng's new tool to provide API documentation to your coding tools. The purpose of this is to make the tool aware of new tools and updates to existing tools, so they're not depending on out-of-date models. "Chub is built to enable agents to improve over time. For example, if an agent finds that the documentation for a tool is incomplete but discovers a workaround, it can save a note so as not to have to rediscover it from scratch next time." It's available on GitHub and installed using the node package manager (npm). It's the lead article in this issue; you can also read other AI news from the week.

This is a good article, I'll grant it that. I resist its main thesis; ultimately the argument is not successful. But it's worth state here. The thesis - as suggested by the title - is that life is inherently different from non-life. "Organisms are more than just machines, and minds are more than just computers." The main argument, which Adam Frank draws from Hans Jonas, is that "living systems are not stable collections of atoms like a rock. Instead, they are stable patterns that persist through time... a specific kind of organization through which matter and energy pass." And because life is a type of organization, and not reducible to matter and energy, it has special needs, for example, "interiority and individuality." Also, "every organism must actively maintain itself against the continuous threat of its own dissolution" and "life always has purpose." There is additionally the argument from Robert Rosen that "metabolic systems could be viewed as a special kind of organization where networks of processes close back on themselves" and hence "not Turing computable."

This is a clear and well-written account of what an application programming interface (API) is. We read about APIs all the time, from xAPI for learning records to MCP as an API for artificial intelligence. This article describes in an accessible way what we mean by API, exactly. "When engineers build modules of code to do specific things, they clearly define what inputs those modules take and what outputs they produce: that's all an API really is."

OK, it started as a joke, and it's a bit of a joke article: "Breakfast is a vector space. You can place pancakes, crepes, and scrambled eggs on a simplex where the variables are the ratios between milk, eggs, and flour. We have explored too little of this manifold. More breakfasts can exist than we have known." The concept here is that we have names for different vectors of the three basic ingredients. For example, 'Pancake' = {milk:0.5, flour:0.25, egg:0.25}. The vector space is the combination of all possible values of these three items. Why does this matter? A vector space allows us to make inferences. For example, if we're using three eggs, what are we probably making? If we're not using any eggs, what then? A vector space is also a probability space. This article goes in a different direction, searching for 'dark breakfast', where the probabilities of it being anything are low (think omelette with flour added). If you understand this, you're on the way to understanding machine learning. Via Data Science Weekly.