You can find last week's inaugural post here: https://news.ycombinator.com/item?id=49293169

This week we have artifacts and attributes. A little background from the README:

    ## Sequences

    A sequence is a user generated grammar definition for arbitrary string sequences. It supports 'choice', for selectable literals within a string, 'branch' for a grammar that requires more than one definition, 'range' for values that span ranges such as 0-99 -- as well as padding out those ranges, 'rangeradix' for ranges that require position dependent radices (not radishes :D), and so on.

    A sequence definition can parse a value OR generate a new value, something like `mySeq.Parse("a123")` or `mySeq.Next('a123') -> "a124"`.

    ## Taxonomy

    A taxonomy tree applies labels to a sequence, so we can give some degree of meaning to each segment of a sequence.

    This all builds up to `PartNumber`, which possesses a part number literal, and the accompanying taxonomy tree so you can see what categories a given part number occupies.

    From `PartNumber`, we jump to the recursive DAG that is a BOM: `PartNumber + Revision -> BOM -> []LineItem(PartNumber, Revision)`, and the cycle continues.

---

Attributes build on this core set of models by adding typed key-value-pairs to taxonomy nodes (and soon other core data types). This means that we can say 'all parts that live below X taxonomy node have Y field that can be filled. For example, resistors can have a 'resistance value' attribute that gets filled in during part creation.

I came upon this idea while trying to think about how Digikey and McMaster handle their part taxonomies. Digikey has excellent filtering by various attributes, and as you drill down in the taxonomy tree of parts, some of those fields appear or disappear depending on where in the tree you are viewing from.

Artifacts are just binary blobs imported from some external source. We store an artifact for every part number + revision combination. This is all boring ETL pipeline stuff (except the pipeline right now is just 'store data some place and link to appropriate record in UBOM').

---

I'm still thinking about where to go next. The core data models have been built, and I think it might be time to commit to git as an artifact source, and maybe a kicad 10+ integration (BOM extraction :D).

Something else I've considered is having a KiCAD part library exporter. The idea is that your org can have a canonical KiCAD library of parts, layouts, schematics, assemblies, and so on, and you would be able to share those across workstations in a relatively seamless manner (probably with a small app that runs on each workstation and pulls the latest changes from UBOM). This seems like it might not fit the core premise of UBOM, though.

I'd love to hear your thoughts! Thanks for taking a look.

God bless.