Blog

Yesterday, in their ambitious new Land Use Framework for England, the Government announced that they would be opening up the Land Registry.

Guy Shrubsole: Revealing Who Owns England Just Became Government Policy

Guy Shrubsole has campaigned for this for years - he deserves recognition for his efforts to reclaim access to land in England.

This is a big deal I think. The current UK (Labour) government is quietly doing some big and potentially consequential reforms like this. UK mainstream media fails to report on this, except when it attacks it. There is also the recently opened England Coast Path, a project which was begun by the previous Labour government. This was only made possible by the the The Marine and Coastal Access Bill, also passed by that government in 2009, which among other things improved "rights of access to land near the English coast".

There is (slow) progress being made on reclaiming the original “commons” - the land beneath us - and establishing our shared "right to roam".

I’m feeling encouraged by something the government is doing for once! :-)

Inspired by Alan Levine (AKA Cogdog) I added a human.json to this website:

{  
  "version": "0.1.1",  
  "url": "https://www.paulwalk.net",  
  "vouches": [  
    {  
      "url": "https://cogdogblog.com/",  
      "vouched-at": "2026-03-23"  
    }  
  ]  
}

This is a machine-readable file designed to indicate to the world that the content here (all of it!) is written by a human - me - and not generated by a so-called "AI" system.

Beto Dealmeida, the creator of this new protocol, says:

One of the problems with the internet today is that a lot of the content is AI generated. There's no way to know for sure if a site is maintained by a real human or if it's just slop. The only way to know for sure is by getting to know the authors, which usually takes time and requires developing a relationship with them through other channels, like email or social media. But what if we could expand that trust by building a web of vouches between sites?

Beto Dealmeida: The human.json Protocol

This idea feels very "web-like" to me - in the sense that it works as the web was designed to work in the beginning. Indeed, it has something in common with older initiatives such as as blog-rolls and web-rings.

Since I learned about this via Alan's blog, it seemed only polite to make his blog the first that I "vouch" for in my human.json file.

This protocol is very new, and the author is inviting feedback. In fact, I already found a small issue with the protocol: it requires me to assert the canonical identifier (URL) for my website in the form of a prefix - allowing anything with that prefix to be covered by this assertion. So, the prefix I would like to use for this site is https://paulwalk.net, which is what I would consider to be the canonical URL for this website. However, the URL https://www.paulwalk.net is the one most likely to be used by others, and my website generator software (Hugo) is configured to use this - so this is the one I have used in my human.json file.

I notes that someone else had raised this issue, and that the next version of the protocol will support adding multiple canonical URLs to solve this problem.

A library is a civic statement: that knowledge is a commons, that stewardship matters, that quiet matters, that you can wander without being sold to. In an age of synthetic text, it may become even more important as a site of provenance – of “where did this come from?” – and of human guidance that is not optimised for engagement.

Shaun Bell: Making breakfast on a burning planet: a parent’s perspective on a GenAI future – Education Express

This idea that a library is a civic statement really resonates with me. I began my working life in a public library many years ago and I have never shaken the feeling that the public library is a hallmark of the kind of society I want for the world. In a world where our information is increasingly polluted with misinformation, disinformation and AI "slop", libraries might yet be seen for the treasures of civilisation that they are.

Update: This no longer seems to work. Although I enjoyed a few days of Rust compilation artefacts under */target/debug/ not being synchronised, I am now seeing these files synchronising as before :-(

Update2: This started working again. I guess it's just buggy :-(

Dropbox has finally introduced the equivalent of .gitignore . Go to your Dropbox Preferences settings and find the "Sync" section: in here you may (depending on your version of Dropbox) find a "Set ignore rules" command.
This command will create a file called rules.dropboxignore in your root Dropbox folder (unlike .gitignore, this file only works at the root of your Dropbox folders).
The syntax for rules in this file is explained in comments in the file itself - although I have found that it is possible to use wild cards in slightly more sophisticated ways than are explained in the file.
One problem this solves for me with Dropbox is that it was difficult to prevent Dropbox from synchronising incidental files generated by software compilation processes, such as the files under tmp/cache/* in a Rails project, or those under target/* in a Rust project. The following snippet successfully prevents these from being needlessly shared with Dropbox, at any level of your file-system:

**/target/debug/
**/target/release/
**/target/bench/
**/tmp/cache/

Figshare, a repository hosting service, implements OAI-PMH... kinda.

Repositories hosted on Figshare are forced to use the same OAI-PMH Base URL. As far as I can tell, Figshare uses OAI-PMH sets to differentiate between metadata records belonging to particular repositories. So, to use an example documented on the Figshare site, this is how you might harvest some OAI_DC formatted records from a particular repository:

https://api.figshare.com/v2/oai?verb=ListRecords&metadataPrefix=oai_dc&set=portal_63

It seems logical to guess that "portal_63" represents a repository hosted on Figshare. However, I have no idea how you would determine the correct set to use for a given repository, or vice versa, how you would determine the repository for a given set. I could find nothing in the documentation about this.

This means that OAI-PMH's Identify verb is now useless in terms of being able to convey any information about a particular repository hosted on Figshare. Identify on the Figshare BaseURL does work properly:

https://api.figshare.com/v2/oai?verb=Identify

However, passing a set parameter is illegal in the OAI-PMH specification when combined with the Identify verb:

https://api.figshare.com/v2/oai?verb=Identify&set=portal_63

And, indeed, this gives an error on Figshare.

The Identify verb is an important part of the specification. It is commonly used not only to gather some basic information about a repository - such as its name & contact details, but also simply to check that the repository's OAI-PMH interface is functioning. For example, the International Repositories Directory (IRD) automatically checks that repositories have a working OAI-PMH interface by sending a verb=Identify request. This will currently fail for all Figshare hosted repositories.

This could have been avoided by making the "portal_63" component part of the OAI-PMH Base URL path for each repository, instead of over-loading the OAI-PMH sets feature, something like:

https://api.figshare.com/v2/oai/portal_63?verb=Identify

It just occurred to me how even the term "RAG (Retrieval Augmented Generation)" is a product of the AI-bullshit-marketing hype machine.

It ought to be "GAR (Generation Augmented Retrieval) since the indispensable part of the operation is the "retrieval", not the "generation"....

But no - accurate search which works properly is somehow "augmenting" the natural language processor part...

I went to see Throwing Muses play the Electric Ballroom in Camden last night.

This is the third time I have seen them play (I have also seen Kristin Hersh play solo gigs a couple of times). So I guess you could say I'm a fan.

I first saw Throwing Muses at the Portsmouth Polytechnic in 1989. I'm startled to realise this is thirty six years ago. Fast forward to last night, I assumed the crowd would be ageing indie-kids of my generation, and I was mostly right. But standing next to me, as we waited for the band to come on, were a couple of much younger lads. I told them I had been roughly their age when I first saw the band. It turned out 1989 was a dozen years before they were even born! They had been introduced to Throwing Muses by an uncle, so I guess the band is still finding new audiences after all this time.

It was great to see the band again, even if three-quarters of its members have changed (the lineup has always been quite fluid). The heart of Throwing Muses is, and has always been, Kristin Hersh. She is a mesmerising performer - perhaps because she doesn't overtly perform so much as just share her weird, intricate, fascinating songs with us. She is also a great and original guitarist. Her son, Dylan, played bass (he's really good!) and I guess he too wasn't even born in 1989....

I didn't plan to go into this gig thinking about the passing of time, but those were the thoughts that somehow crept up on me. The songs of Throwing Muses and Kristin Hersh have been a constant for me since my mid-teens. It was weird to hear Soap and Water - introduced by Kristin last night as "an old song, and kind of a stupid one!". I can vividly remember hearing that for the first time, in the bedroom of a friend, who had just bought an early EP called The Fat Skier. That EP grabbed my attention like few records have ever done - I think I knew straightaway that I had discovered something special.

Anyway - a great gig, covering decades of songs from a prolific songwriter. Many just sounded great on the night, especially the higher energy songs - Sunray Venus near the start, Slippershell, and Bright Yellow Gun as the perfect final encore. Other songs had a more personal impact - I actually had a little shiver when I recognised the opening of Colder, a song I used to play over and over the summer I bought the vinyl of House Tornado. And similarly - hearing Bea played live and remembering that one from the 1989 gig.

It makes me happy to realise that there are some young folk discovering this music for the first time and, like me nearly forty years ago, realising that its something special.

Here's the crowd-sourced set-list in case you're interested.

The legal right to wild camp on Dartmoor has been upheld by the Supreme Court in a decision that is likely to reignite the debate over public access to land in England.

Judges unanimously rejected an appeal by landowners Alexander and Diana Darwall who said people should not be able to camp without permission from landowners.

Miles Davis & Jonathan Morris: Supreme Court backs wild camping on Dartmoor

Some good news for a change - we have been waiting for this decision for months. For once, the decision went in favour of the common people, and against the acquisitive billionaires.

(I was always going to continue wild camping on Dartmoor anyway 😊)

This is a good result for England!

https://bibwild.wordpress.com/2025/01/16/using-cloudflare-turnstile-to-protect-certain-pages-on-a-rails-app/

There is a growing problem of so-called "bots" harvesting content from repositories in an aggressive manner. They are often poorly designed and have no care for the bandwidth or processing capacity they demand from the repository as they attempt to "hoover" up all available content (increasingly to use for AI training purposes). The result of this is to impact - sometimes severely - on the performance of the repository.

This piece by Jonathan Rochkind describes approaches to mitigating this problem. In particular, it describes an interesting approach to blocking only certain resources - e.g the search function - from machine processes, while leaving content resources freely available for machine processes to access.

This guide is for everyone who seeks advice for creating stable, secure, and persistent Uniform Resource Identifiers (URIs) in order to publish their data in accordance to the FAIR principles. The use case does not matter. It could range from publishing the results of a small research project to a large knowledge graph at a big corporation. The FAIR principles apply equally and this is why it is important to put extra thought into the URI selection process. The title aims to extend the tradition of "Cool URIs don't change" and "Cool URIs for the Semantic Web". Much has changed since the publication of these works and we would like to revisit some of the principles. Many still hold today, some had to be reworked, and we could also identify new ones

Andreas Thalhammer: Cool URIs for FAIR Knowledge Graphs

Refreshing my knowledge/memory of some of these (sometimes contested) issues with URL management. I’m still more sceptical than the author about how well Content Negotiation works in practice, but this is useful nonetheless