Stephen Downes

This document "introduces the basic concepts of RDF and shows concrete examples of the use of RDF." It's background for the introduction of RDF 1.2 (also known as 'RDF Star'), an important update to the W3C specification. This summary on LinkedIn (sorry) describes the key changes well. "The headline feature is 'triple terms': the culmination of the long-running RDF-star effort. In plain terms: you can now use an RDF triple itself as the object of another triple. Statements about statements, without the old reification gymnastics that everyone quietly hated. Hypergraphs in disguise." In simple terms: if 'P' is the statement that 'Cats like catnip', then now it's much easier to say 'Mary believes P'. This enables a much deeper and expressive semantics. More detail in this presentation.

One issue (out of many, as I'm discovering) with the ATmosphere protocol, used by Bluesky, is that all data in your personal data store (PDS) is public data. There is no private data in the ATsphere. This article reports on ongoing work to change that, but it's work that has implications. "At the end of the day, specifying a new protocol scheme is basically owning up to the fact that, while we may re-use many primitives and roles from the public data protocol, we are specifying a new data and sync protocol, not just an extension to the existing protocol." Personally, I think what is proposed here is over-engineered. But the thinking is not wrong.

This article makes the case that "The scientific paper bundles too many functions into a single artifact, and the bundle is starting to come apart." It outlines several proposals that could replace it, for example, "an Adaptive Knowledge Network, in which the basic unit of scientific contribution is a "knowledge object" rather than a paper." But there are risks; the process of writing the paper is part of the scientific thinking that underlies this, and this might be lost. The article doesn't mention Octopus, the UK project that defines "eight publication types that are aligned with the research process," but this would fit squarely into this discussion. The major issue (in my view) with this sort of disaggregation is that every contribution is locked into the same methodology, and nothing breaks out of what might be called 'normal science' for the discipline.

Maha Bali plans to use this game in an upcoming talk. That's good; something interactive is always fun. My concern here is not that it is AI-generated. The AI did a nice job. My complaint is that it's too easy. It presents each of eight scenarios with three possible answers. It is very easy to pick the 'best' and 'worst' choice, given any degree of background knowledge. And this makes it seem like the actual choices regarding AI are easy. They're not, and the use of this game is a case in point. A critic said it was 'too easy'. Do you go back and ask the AI to make it harder? Do you ask for a justification of the difficulty level? Or do you just go ahead and use it as it?

I've hesitated to cover this story because I have Chrome on my machine and haven't been able to find the 4 gig file where it's supposed to be (or anywhere else, for that matter). Mind you, I use Chrome only for testing; for day-to-day I use Firefox. But I've seen the story from enough sources now, including some that would actually check the data, that I'm inclined to believe it's true. Having said that - I'm sure that this is only the tip of the iceberg. For example, I use Adobe's noise reduction feature in Lightroom and found the other day my C:\ drive filled by a huge 'cr_sdk' file. There's no documentation of this and no way to manage it. Is it AI? No idea. Could it be? Sure - and I'd never know. Are other services running local AI models? Even if not, they probably will in the future.

The Canvas hack, writes Tim Klapdor, was inevitable. "When the decree from management increasingly mandates that all core systems must be off-the-shelf products from established vendors (a policy that sounds like sensible risk mitigation) the result is that all your vendors share the same infrastructural single point of failure. When Canvas went down, it took every system routed through it with it." This argument has been made many times in these pages - a distributed and decentralized system is much more resilient. The push toward optimization and efficiency, if taken too far, greatly increases fragility.