You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
From the 6 July notes, each working group is submitting 10 to 20 terms toward a v1.0 and roughly 250 candidates are being reviewed in the unified spreadsheet with a consensus column. taxonomy/taxonomy-data.js has been deliberately empty since 56c50d0 cleared the slate on 13 June, so at some point the agreed rows need to become entries in that file.
I could not find an issue covering that step, so raising it rather than assuming.
Why the step is worth planning
The schema in docs/data-schemas.md asks for nine fields per term, including broaderTerm, relatedTerms and contrastsWith links that only make sense if both sides agree, and a workgroups list.
As a sense of scale for what hand transcription costs at volume, I checked the 28 terms archived in git history against the schema as it reads today. Twelve used categories outside the five approved ones (Data and Privacy, Agentic Controls, Security Practices), four put category names such as Capabilities & Interfaces into the workgroups array, two pointed broaderTerm at a concept that has never had an entry, one contrastsWith pair was declared by only one side, and one contrastsWith value named a term that does not exist. None of that reflects badly on anyone, it is simply what happens when a structured file is filled in by hand. Doing the same at 250 terms across many pull requests would produce more of it, and each instance costs a reviewer's attention rather than a machine's.
What I am offering
A converter that takes a CSV export of the agreed sheet and emits schema conforming entries. It would fill in the reciprocal direction of relatedTerms and contrastsWith automatically, normalise the category and working group values against the approved lists, and print a report of every row it could not place, so a human sees exactly which rows need a decision rather than reading all 250.
To build it I need only the column headers, or a CSV export of a handful of example rows. I do not need access to the sheet itself, and I would rather not guess at the column names.
I have also written a schema checker for taxonomy-data.js that runs in CI with no dependencies, covering the required fields, the approved category list, duplicate terms and aliases, references that point at nothing, one sided contrast pairs and hierarchy cycles. It passes clean on the empty file as it stands today. I have held it back rather than opening a PR nobody asked for, so say the word if a check on the way in would be useful alongside the converter.
Questions
Is an importer wanted, or is manual entry by each working group's delegate the intended path?
If it is wanted, who can share the column headers?
From the 6 July notes, each working group is submitting 10 to 20 terms toward a v1.0 and roughly 250 candidates are being reviewed in the unified spreadsheet with a consensus column.
taxonomy/taxonomy-data.jshas been deliberately empty since 56c50d0 cleared the slate on 13 June, so at some point the agreed rows need to become entries in that file.I could not find an issue covering that step, so raising it rather than assuming.
Why the step is worth planning
The schema in
docs/data-schemas.mdasks for nine fields per term, includingbroaderTerm,relatedTermsandcontrastsWithlinks that only make sense if both sides agree, and aworkgroupslist.As a sense of scale for what hand transcription costs at volume, I checked the 28 terms archived in git history against the schema as it reads today. Twelve used categories outside the five approved ones (
Data and Privacy,Agentic Controls,Security Practices), four put category names such asCapabilities & Interfacesinto theworkgroupsarray, two pointedbroaderTermat a concept that has never had an entry, onecontrastsWithpair was declared by only one side, and onecontrastsWithvalue named a term that does not exist. None of that reflects badly on anyone, it is simply what happens when a structured file is filled in by hand. Doing the same at 250 terms across many pull requests would produce more of it, and each instance costs a reviewer's attention rather than a machine's.What I am offering
A converter that takes a CSV export of the agreed sheet and emits schema conforming entries. It would fill in the reciprocal direction of
relatedTermsandcontrastsWithautomatically, normalise the category and working group values against the approved lists, and print a report of every row it could not place, so a human sees exactly which rows need a decision rather than reading all 250.To build it I need only the column headers, or a CSV export of a handful of example rows. I do not need access to the sheet itself, and I would rather not guess at the column names.
I have also written a schema checker for
taxonomy-data.jsthat runs in CI with no dependencies, covering the required fields, the approved category list, duplicate terms and aliases, references that point at nothing, one sided contrast pairs and hierarchy cycles. It passes clean on the empty file as it stands today. I have held it back rather than opening a PR nobody asked for, so say the word if a check on the way in would be useful alongside the converter.Questions