Hi there,
I completely agree with Owen and Julia on this. In my case, my organization has complex application profiles for some of our systems, in many cases with hundreds of possible metadata fields. If all metadata fields were used (which never occurs in a single dataset), theoretically we could get a .csv from a submitting repository with a completely unmanageable number of columns–I would make an analogy to requiring a submitter to include all possible Wikidata properties or every field / subfield in the MARC bibliographic standard in their spreadsheet, even if they are just using a limited profile of properties / metadata fields within these standards. It would be madness to require partners across my institution to submit .csv’s containing hundreds or thousands of columns if they only need to use 20 of them to support their project. For about a decade, I had happily maintained a set of transformation operations that work with this reality in OpenRefine, but with the strict validation requirements implemented in OpenRefine 3.9+, I can no longer use these json operation histories to process metadata, and would be forced to create a new set of json operations for each project under the validation routine implemented with OpenRefine 3.9+. A simple solution would be allow an option to ignore invalid operations, as Owen suggests. I don’t think I can attach a .json file to this message, so I have bundled a sample json operation history and a sample .csv with relevant data in to a zip file, attached here.
OpenRefine-ApplyOpHist-BugReport-2025-10-16.zip (39.5 KB)
The json operation works fine in OpenRefine 3.8, but runs into the validation problem in 3.9 due to missing columns in the csv data.