so many parts....

[dustymc]

For the same reasons as #6179, lots of parts cause problems. (So do not enough parts, and I don't think anyone knows what "just right" looks like.)

Current issues include:

#7668
#7671
#7733
and #7667, which includes some discussion

#7667 (comment) is basically this issue, a plea for help and guidance

#7667 (comment) / #7667 (comment) suggests one solution, which has come up (wrt 'tissues' mostly) a few times before. (And #7667 (comment) suggests it's more novel than I think it is - we've done this, a lot, I don't see much/any 'developing' or 'new' or need for testing in this.)

#7667 (comment) suggests we're not being radical enough (??!) and - need to bring modifiers and such back into part name?? - I don't know....

#7667 (comment) suggests this won't be fixed without funding.

One possible "real solution" would be an ontology, I'm not aware of any being used in nontheoretical ways (someone enlighten me!), that's probably non-infrastructure proposal territory.

#7736 (a very recent and convenient example of the messes we have in parts) suggests I may regret this, but not wanting to be the holdup and not having better ideas, I'm going to very reluctantly go check my 'won't break the system (too much more, I hope...)' boxes.

HELP!!!!

[dustymc]

A compounding factor is our inability to undo or even adjust things: https://github.com/ArctosDB/arctos/milestone/31. Anything we don't get exactly right the first time around is nearly impossible to get rid of or make better. A very liberal policy of addition and a very conservative policy of correcting seem entirely unsustainable.

[dustymc]

Just trying to consolidate some discussions in case there's a higher-level discussion.

---

AWG resolved to add only general parts, to be more specific in attributes, remarks, etc.: https://docs.google.com/document/d/1mTWY6HRlC3TSrAb38W2HOQHiVO2F1tA1m5jaLstYMS8/edit#heading=h.w0tvdqpqd23q

See eg #7627 (comment) does not seem clear how we can (perhaps if we want to??) follow that

#7805 - if we are to follow, we seem to need a mechanism to update current data

#7753 - we really need an ontology, not clear what this thing is, communication is not easy

#7752 - just an outright refusal to do part-things in parts by The Community, with a bonus clear demonstration that this is preventing access

#3080 - more impossible cleanup

#7763 - "first-stage simplification" idea

[dustymc]

Is there a minimum usage threshold? (Everyone seems to think there should be - until they don't...) - see #7823 (comment) among many others.

Should being consistent overrule all else? Discussion in #7667 (and maybe @KatherineLAnderson can elaborate, should this somehow become more than me talking to myself....)

[KatherineLAnderson]

Should being consistent overrule all else? Discussion in #7667 (and maybe @KatherineLAnderson can elaborate, should this somehow become more than me talking to myself....)

I like the idea of parts-parts (bits'n'pieces), but I do think that is a longer term goal and will take funding to get off the ground--or at least a considerable amount of someone's time.

That being said, in the short term, I have 2 priorities: getting the data into Arctos, and consistency as it impacts both data discoverability and Arctos backend user experience (specifically data entry). My pitch to the Burke paleo team in making this migration included the fact that Arctos would make our data more consistently formatted, so I have a bit of a stake in the game on making sure that holds true (how it holds true is another discussion--see b'n'p above). I really don't want to hear about why everyone (everyone who isn't involved in these nitty gritty discussions) hates Arctos because one skull bone goes here, and another goes there. We already see that in another collection (edit: perhaps one person) at the Burke, so the poison is in the well so to speak.

Until we can figure out the long term vision, the discussion in #7667 led to a conclusion that parts, where consistent with what's already in the code table, should be added to the code table. So I would like to operate on that premise moving forward until we can figure out a longer term plan, because otherwise we're having the same discussion in every code table request.

[dustymc]

funding

FWIW, and I could totally be wrong, but my big-picture take is that we could:

1. Do part-parts (eg something slightly different that uses existing structure) ~today, BUT it'll end up a giant mess unless someone (not it!) pushes through with the social issues, or
2. Decide to add "all the things" (eg set social guidelines) ~today, it will maybe-inevitably end up as a giant mess (I'd love to be pleasantly surprised!), but maybe not one we have to deal with right now, or
3. If we're going to fund something, let's find some ontology willing to expose themselves to reality and go all in on what we've all been hearing pitched as the next big thing for the last decade or two.

Maybe we're going to pick one of the first two until we can do something like (3) whether we like it or not....

priorities

I think we're all on the same page there, which is very nice to see from time to time.

led to a conclusion

And the AWG discussion (mentioned above) lead to just about the opposite conclusion, so I hope everyone can appreciate that I feel like I'm being pulled in entirely incompatible directions. I can support most anything....

consistent with what's already in the code table,

... MOST anything - at least some of the existing data is just WRONG (it ain't even THINGS, it's CONCEPTS!!), what from here feels like outright vandalism, etc. "But someone already did horrible thing!" doesn't feel like much of a guiding principle.

I would VERY much like to have a consistent, big-picture direction (because we ain't gonna accomplish those common goals without). @mkoo can we maybe declare an emergency (I think that's what I'm hearing) and find some way to set some guidelines-or-something ASAP?

[Nicole-Ridgwell-NMMNHS]

If we go with #1, just please, please, please make it possible to add more part attributes in single record entry.

[dustymc]

See relevant comments from @javanveldhuizen in https://github.com/ArctosDB/data-migration/issues/1963#issuecomment-2231710436

[dustymc]

Code table committee discussed, tendency is towards "functional units" eg many specific parts, but only specific parts.

It is realized that many current parts do not meet this criteria. A cleanup plan was not discussed. DLM hopes we can at least not use the not-parts to justify more not-parts.

Universal agreement that fewer THINGS/simpler structure is the most usable option; people will get less-lost in lots of parts vs. eg parts and sub-parts. Search terms can (somewhat) help and should be used.

@KatherineLAnderson suggested a "category" (or ??) to help guide users. (Seems useful - maybe a few of them! - but why not just write a proposal for an ontology if that's what we really want?)

@dustymc had the realization that while ontology terms can't do ontology-things or carry ontological meaning outside of context, they can help with things like duplicate detection - eg help determine if a new (possibly specialized and obscure) thing is a new kind of functional unit, or a new way of spelling an existing part, or not a recognized thing at all.

It was realized that sources should be of a certain quality (dictionary definitions are confusing, not helpful), but that's hard to quantify.

Docs:

• https://docs.google.com/spreadsheets/d/1-QC9L8jbOzaG7vstp5iHyx8ivlyvr3BrtiCY_GBimAg/edit?gid=0#gid=0
• https://docs.google.com/document/d/1eZ_S8VTp-m5Wrbb6cAK96ODPZpt2-Hvnvt6yfU9qVwg/edit

@ccicero @mkoo @Nicole-Ridgwell-NMMNHS @KatherineLAnderson @WaigePilson what'd I miss or mangle?

[mkoo]

I think you captured the gist of it. Thx for summary after the meeting. I think it's imperative now we have a definition to determine future proposals to see if it meets everyone's needs and then we can tackle legacy clean-up.

Here's the working definition now:

Controlled vocabulary for part name. A physical unit of a catalog record that is a singular term and is managed in the database. 
A Catalog Record may have more than one part. Terms require an external reference, e.g., ontology or wikipedia link. 
Provide alternatives terms to maximize discoverability if available.

We may want to adjust the reference requirement to specify it has to be a broadly recognized reference to avoid a random reference like grandma's website!