Database Schema Refinements

[YanceyA]

As people have started entering more filaments into the database there are have been some important findings and questions on how to enter some filament specific information. There is also a question on whether this information is important to be included in the data base to allow for categorization.

The goal is to have a bit of architectural discussion, discover additional areas to cover, and hopefully make PRs for a stable JSON schema. It seems that continuously litigating JSON schema changes is risky for database stability, uncertainty for data entry, inconsistent data entry.

As defined on the readme page "A centralized place to store information about 3D printing filaments and their manufacturers." seems to imply, to me, that we are looking for a detailed database with lots of categories and details of filaments. However, this type of detailed database doesn't necessarily align with the core needs of a maker using Spoolman to catalog and maintain their physical spool library and support actual 3D printing.

A non exhaustive list of open questions:

Fills [see https://github.com//pull/21 ]

• How should we handle filled filaments with carbon fibre and glass fibre. Other less popular and uncommon fills include wood, ceramics, kevlar, carbon/glass string, glow particles, metallic fill, glitter.
• Carbon and Glass fiber fills can also be specified in the % of fill and average fiber length.

Glitter [see https://github.com//issues/31 ]

• Glitter is a technically a cosmetic fill.
• Glitter comes in different colors which provide various cosmetic affects.
• As far as i know there are no specifics for glitter size or type as it generally is not considered a benefit to physical properties.

Refillable Spools [ https://github.com//issues/26 ]

Material Names [ https://github.com//pull/15 , https://github.com//pull/9 ]

• Material names ideally should be presented at short names conforming to ISO 11469 and ISO 1043
• Material short names ABS are preferred over the long name "Acrylonitrile Butadiene Styrene" for obvious reasons.
• Can the material name be overloaded to capture other parameters that otherwise would be their own category (tpu hardness, fill, glitter, lightweight).

Distinctive filament properties

• There are some filaments with unique characteristics such as Aero/Lightweight
• Anything on Zack Freedmans cursed filaments list, scented
• Purge, cleaning filaments
• ESD or conductive filaments
• Filaments with flame retardant additives to meet V-0 or similar ratings.
• Recycled filaments
• Support filaments (breakaway, water soluble)
• Chocolate / foods

Nylons or Polyamides [ https://github.com//pull/15 ]

• Nylons come in so many flavors (PA6, PA66, PA6.6, PA11, PA12, PA612....)
• Specific standard ISO 16396 to deal with material marking of these materials
• Only a few nylons are actually used in 3d printing (currently) PA6 and PA12

TPU:

• TPU come in different hardness across different scale ratings. This is a key parameter defining their function.
• Currently the guidance is to overload the material name to include the hardness rating "TPU-90A"

References:

https://www.findoutaboutplastics.com/2020/12/plastic-part-marking-overview-codes-and.html
https://drive.google.com/file/d/1fIG9HlW-9AiyGDQsstiNUaXkKw-1Cyle/view

[Keridos]

I'd add glitter to the fills section. Fills should be an array in case of multiple fills being present.

Fill object should be an object like:

fill-name:
  type: required
  color: optional
  size/length: optional
  fill_ratio: optional (because it can be unknown)

For TPU, I'd propose sticking to one standard and then standardizing it so it is "TPU-##A" to prevent confusion.
Regex that would be something like TPU([0-9]{2}A){1}

Special Filaments I would only broadly categorize those that with f.ex.
cleaning filament
mixed filaments (PC+ABS f.ex.)
flame retardant, though that could simply be an attribute for generic filament
support filaments, though that could be filament types, too
aero/lightweight

I think for the more esoteric filaments users should define them themselves, since you can also add custom attributes.

[StuSerious]

https://regex101.com/r/SedDNb this is the current regex for matching material names, ad you can see it matches both shore A and D ratings ;)

[Donkie]

I think my idea has been to support as much structured data as possible in the database, but only things that are necessary for Spoolman are required fields, such as density and spool weights etc.

At the same time, if we make the structured data too detailed then it just becomes too much of a chore to add. Fill for example could be enough to just specify fill type as we have now, and maybe color. But on the other hand, fill color could be just as well specified in the filament color name itself. Specifying fill size and ratio is just way too detailed and I don't think anyone would search for exact quantities like this.

On another note:

I think having a GUI would make life easier for people to maintain this database, and I've been thinking of ways of doing that but haven't really come up with a good idea. I like the way it works now with people submitting PRs because it means we can utilize Github's built-in review functionality and don't need to create a new one. But then how to make a GUI that lets people edit the .json files and then submit as a PR? This is probably for a separate discussion though...

[Keridos]

At the same time, if we make the structured data too detailed then it just becomes too much of a chore to add. Fill for example could be enough to just specify fill type as we have now, and maybe color. But on the other hand, fill color could be just as well specified in the filament color name itself. Specifying fill size and ratio is just way too detailed and I don't think anyone would search for exact quantities like this.

Well, the ability to define what type of infill it is and assign that specific infill a color would be nice. I agree that we should not overengineer too much, though.

I think having a GUI would make life easier for people to maintain this database, and I've been thinking of ways of doing that but haven't really come up with a good idea. I like the way it works now with people submitting PRs because it means we can utilize Github's built-in review functionality and don't need to create a new one. But then how to make a GUI that lets people edit the .json files and then submit as a PR? This is probably for a separate discussion though...

Github offers codespaces so you can easily make changes in your browser with a web vs code session. Works pretty good for me, when I do not wan't to clone the repos to my computer.

[StuSerious]

I think having a GUI would make life easier for people to maintain this database, and I've been thinking of ways of doing that but haven't really come up with a good idea. I like the way it works now with people submitting PRs because it means we can utilize Github's built-in review functionality and don't need to create a new one. But then how to make a GUI that lets people edit the .json files and then submit as a PR? This is probably for a separate discussion though...

It would be amazing to add a tab to Spoolman's frontend where a user could either automatically submit their library or graphically input values to be converted in the JSON schema format.

Such an implementation is way above my head, as I have little experience with TS, but I could give it a shot. @Donkie if you're fine with a fair amount of hand-holding and reviewing I could try and submit a PR.

[Donkie]

I think having a GUI would make life easier for people to maintain this database, and I've been thinking of ways of doing that but haven't really come up with a good idea. I like the way it works now with people submitting PRs because it means we can utilize Github's built-in review functionality and don't need to create a new one. But then how to make a GUI that lets people edit the .json files and then submit as a PR? This is probably for a separate discussion though...

It would be amazing to add a tab to Spoolman's frontend where a user could either automatically submit their library or graphically input values to be converted in the JSON schema format.

Such an implementation is way above my head, as I have little experience with TS, but I could give it a shot. @Donkie if you're fine with a fair amount of hand-holding and reviewing I could try and submit a PR.

I'm a bit against having people sync their local spoolman library automatically to this database, since the quality of the data can be a bit hit and miss. It also would mean fields like fill type etc won't be added automatically since Spoolman doesn't have such fields built in.

[runtpacket]

I'm a bit against having people sync their local spoolman library automatically to this database, since the quality of the data can be a bit hit and miss. It also would mean fields like fill type etc won't be added automatically since Spoolman doesn't have such fields built in.

agree here unless we have some type of community moderation and polling when conflicting data