After hours with Claude I now have a not-quite-right form-a-matic.js and a very broken test-fam.js
But I think there's enough in place that I can now get those working without Claude.
Clearing a few tabs. I've done 'Save All" into a folder, but some should go somewhere near here. A bit annoying, this is what Strandz should be doing for me.
I've just given myself a headache doing a little bit of real-world admin. I got a little bit of money through yesterday, I've been attempting to direct into the best places...
Including cancelling the €22/month Google One account I'd accidentally signed up for. Grr, only noticed after 3? months. All I need is the €3/m extra storage. I'm actually at 201.03 GB, so am doing a bit of backup in the background right now.
A deeper headache is due to me getting overwhelmed by TODOs again (it's an #ADHD thing).
My long-term solution is the #farelo project. Job One-ish there is capturing descriptions of projects/tasks in #RDF with the Project Vocabulary. (That needs revising, which I've been dipping into occasionally in 2024, but that's not a big issue today).
One way of skipping out of the overwhelmedness kind of task paralysis is doing something new. This is in the distraction, #yak direction, but sometimes that's necessary. If the new thing has clearly defined, nearby, goal, then the sidestep can work.
Form-a-matic
requirements, second pass
Purpose
Generate HTML forms based on RDF shapes1 which, when filled in, will generate RDF instance data. The FOAF-a-matic and DOAP-a-matic being examples.
This will be an application of #Transmissions.
I want to get Claude to do most of the work.
Process
My initial Form-a-matic process is more general than I need right now. Also it would be nicer for the resulting a-matic-form to be relatively self-contained (ie. not involving a SPARQL store).
The input is an example of the target RDF data.
variable fields are identified
HTML form elements are created corresponding to those fields
Javascript is attached to a button on on the form to read the field values
JS functions will generate RDF from the form values
Possibly the quickest way of achieving most of this would be using generic text templating throughout (a la #SPARQLDiamonds). But I reckon it'll be neater, and potential more easily extendable if I use an RDF model in the JS.
I so want to use SPARQL here, but side project in my queue is documenting RDF-Ext. That includes grapoi, a 'Universal RDF/JS graph traverser'. There are also readers/serializers nearby, and I've already been using it around #Transmissions.
So let's :
start with some tweaked Turtle-format FOAF. Give the places of interest keyword-style markers
parse that out and locate those markers with RDF-Ext, recording their path inside the graph
for each marker, generate a form field
The end result form will need boilerplate JS functions for taking the form values and the RDF path, constructing the required triples.
To get Claude to do the drudge work without being stupid I'm going to have to prepare some prompts, some background material to put into a Claude Project and some examples.
The other day I set up Transmissions' CLI so it could use an application from any file path, so I guess this might be a good point to set up yet another GitHub repo : trans-apps
TODO allow applications to be loaded from URLs
Now I'll publish this and then it's dogwalk time, then I'm of out for a coffee & shopping with Mari.
ultimately SHACL is totally in the frame for this, but this quick-and-dirty approach skipping around SHACL should be simpler to implement as first attempt. (There is a SHACL engine in RDF-Ext, see https://www.bergnet.org/2023/03/2023/shacl-engine/) ↩
I did start looking at server XMPP config again but a thunderstorm means the network is up & down.
Back to #Transmissions ConfigMap.
Hmm. Need docs to make sense of these.
Slight diversion : I'm adding code into DirWalker to ignore markdown files with a name start with _ underscore. Hardcoded for now (like accepting .md).