Not the first person to do this but all the other examples I've seen are either dead or miss the point. Why: I was designing a Eurorack compatible instrument and I did not want to brush up on now 10 years old college electrical engineering knowledge and I just want Claude to make me a PCB board. I realized that all of the sources for electrical component information are PDFs and not very nicely machine readable. That led me to ask why not and one of the gaps I see is a lack of an agreed upon easy to use schema for both extraction and consumption of datasheet information.

So I've been building datasheet-schema. It's an open JSON Schema for the electrical specs in a component datasheet. One of the core idea's is that a number by itself is useless. "VOUT = 3.3V" tells you nothing until know it was measured at 1mA load, 25C, 4.3V in. So every value in the schema carries its test conditions and a pointer back to the page it came from. That last part matters to me because if a model extracts a spec from a PDF, I want the LLM to be able to audit it against the page it claims to have read. Most parametric databases throw the conditions away and leave you a bare number you can't design from.

What's in it right now: Seven component families as dictionaries (LDO, MOSFET, voltage reference, op-amp, DC-DC, diode, BJT), a core schema that stays family agnostic and a test suite. Adding a new family takes no schema change, just a dictionary and a real example.

The prior art: edatasheets is the closest thing and it's unmaintained and stuck on draft-07. JEDEC's version is heavyweight and vendor oriented. Octopart and friends are closed and drop the conditions - none of them keep the value, its conditions, and its provenance together, which is the one thing that makes machine extraction trustworthy.

Would love feedback from anyone who has fought with datasheet data.