The single-value field constraint on some performer metadata fields undermines their accuracy. This will depend on what data a stash-box catalogs, but when there’s a single-value field constraint for data that can have multiple important values, it forces the data to arbitrarily catalog one option.
An analogy here would cataloging baseball players on a hypothetical baseball stash-box, and the team drop down select field has all available teams to chose from, but only one can be chosen to represent their entire career.
The most egregious offender for conventional stash-box’s is Breast Type. Over the course of a career it’s not uncommon for a performer to have both Natural and Augmented. Unlike high-variance attributes (body weight, body measurements), this field consists of only two states of which both could be true over time. Accommodating fields like this with multiple-selection values would improve the accuracy of the metadata.
To avoid getting sidetracked here, some users propose a more elaborate schema that includes cataloging multiple attribute states + date range, but that approach introduces a lot more complexity, seems like it has a single specialized purpose that doesn’t scale beyond breast type, and its feasibility is unclear. So I’d prefer to say on the topic of the simpler tractable option here: multiple-select fields.
I really wanted to avoid the overkill date range concept.
A lot of these open up a can of worms and more debate. It’s why I wanted to avoid the date range concept from this thread about a non-date range concept. My goal is inquiry about a simple and tractable concept that could be implemented without controversy or paradigm shifts.
Tattoos/Piercings
These are fundamentally different entities from what I’m referring to. Multiple-selection values are like a flat list of multiple valued attributes. While tattoos/piercings are structured multiple-value entities. So it wouldn’t map. Visually with pseudo-JSON:
I don’t know that there is a desire to document dates of naturalization or whatever, nor do I know if it’s realistic that editors are able to obtain the naturalization dates. There’s a low amount I’ve come across that seem to have dual “nationalities” - of those a lot are down to errors and speculation - from the subset that are legit, that’s a hell of an edge-case.
Trans
I was under the impression that if they’ve transitioned during their career they receive multiple entries per gender. If they haven’t transitioned during their career then why are we documenting it and how is it pertinent to their adult career (akin to things like non-career related names/aliases being out of bounds).
I suppose one can claim that every stash-box can be different, with different rules. But again, this is why I wanted to avoid the date range concept by preemptively mentioning that I wanted to avoid it. It’s another FR entirely for someone else’s tread.