[A] That's something I've occasionally wanted as well, especially when I start a review of an artist I've reviewed before but don't remember especially well. I find I often spend considerable time casting about for information I've already researched and written up somewhere. A solution should be a SMOP (small matter of programming), but it's also a huge pile of data. The record compilations in the work directory haven't been updated since 2020, and that alone would probably take me a month. And they wouldn't be any more accessible in .odt documents than they are now. That would just be a preliminary step. Although I wonder if it would be possible to write a python script to explode the files and convert them into some format that could be served up as web pages? (Short answer appears to be yes, but that's probably three more SMOPs.)

The main reason I haven't tried to do this is that I've never been happy with the initial database schema I created for the Christgau website. What I did in 2001 was pretty quick-and-dirty, based on the specific formatting needs of the data. The biggest mistake I made was in excessively normalizing the data: eliminating redundancies by breaking repeat data out into additional tables, like artists and labels. Normalization is generally a good thing in databases, but I ran into problems dealing with Christgau's specific usages, and with real world quirks — like Peter Stampfel's invention of 20+ different artist names, when they're almost all really just him (and note the "almost" there, which is another stumbling block for engineers). So I wanted to devise a new schema, which I could use for both my and his data, and could be used elsewhere. I never managed to do that. Nor was I willing to go as far as have AMG, Discogs, and MusicBrainz (the latter is open source, so follow the link to get a sense of the problem space): all three are track-oriented, whereas I would have been satisfied to just be album-oriented.

At this point, if I had nothing better to do, I'd be inclined to reduce the problem, and focus on artist-oriented views of the data. That may or may not include an album layer (something I need to think about), but wouldn't break albums down to releases let alone tracks. This would really just be for my use, although I could see other people doing similar reviewing might like to have something like that — at that point it becomes considerably more than a SMOP.

Early on, we tried indexing websites using ht://Dig, but they stopped working on it in 2004, and it was too much work to maintain, so I hacked together the current Google search box. It's possible that there are newer and better indexing tools, and that one could write a script that would consult an index and collect the various reviews. Alternatively, because the reviews are in pretty regular formats (famous last words), one could write a python script to index them, and work off that index.

The current Google search widget works pretty well for finding files. I'm just using what they have for free, but they have more commercial packages, which could conceivably make the search info more useful. I'm too cheap to go there, but I can imagine things that might actually be valuable. I've occasionally seen their AI kick in, even on site-limited searches. This suggests another approach, which is to employ AI to straighten out the sprawling mess I've created. That's something I hope to look into, but I expect there will be a fairly steep learning curve.