Goon
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).
While thinking about foaf-retro, making a Form-a-matic seemed a good idea.
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.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
<#URI>
a foaf:Person ;
foaf:name "LITERAL" ;
foaf:mbox <#URI> ;
foaf:homepage <#URI> ;
foaf:nick "LITERAL" ;
foaf:depiction <#URI> ;
foaf:interest <#URI> ;
foaf:knows [
a foaf:Person ;
foaf:name "LITERAL"
] .
Footnotes
-
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/) ↩