Code Table Request - new specimen part name: epipterygoid

[KatherineLAnderson]

Initial Request

Goal

Add epipterygoid to the specimen part names code table

Context

It doesn't exist in the table currently

Table

(https://arctos.database.museum/info/ctDocumentation.cfm?table=ctspecimen_part_name)

Proposed Value

epiterygoid

Proposed Definition

paired cranial bone found in many tetrapods that connected the pterygoid bone to the outer surface of the braincase. https://en.wikipedia.org/wiki/Epipterygoid

Collection type

paleo, bio

Attribute Extras

Attribute data type

n/a

Attribute controlled values

n/a

Attribute units

n/a

Part preservation attribute affect on "tissueness"

n/a

Priority

high priority--needed for data entry

Example Data

Available for Public View

yes

Helpful Actions

• [x] Add the issue to the Code Table Management Project.

• [ ] Please reach out to anyone who might be affected by this change. Leave a comment or add this to the Committee agenda if you believe more focused conversation is necessary.

@ArctosDB/arctos-code-table-administrators

Approval

All of the following must be checked before this may proceed.

_The How-To Document should be followed. Pay particular attention to terminology (with emphasis on consistency) and documentation (with emphasis on functionality). No person should act in multiple roles; the submitter cannot also serve as a Code Table Administrator, for example._

• [x] Code Table Administrator[1] - check and initial, comment, or thumbs-up to indicate that the request complies with the how-to documentation and has your approval
• [x] Code Table Administrator[2] - check and initial, comment, or thumbs-up to indicate that the request complies with the how-to documentation and has your approval
• [x] DBA - The request is functionally acceptable. The term is not a functional duplicate, and is compatible with existing data and code.
• [x] DBA - Appropriate code or handlers are in place as necessary. (ID_References, Media Relationships, Encumbrances, etc. require particular attention)

Rejection

If you believe this request should not proceed, explain why here. Suggest any changes that would make the change acceptable, alternate (usually existing) paths to the same goals, etc.

1. Can a suitable solution be found here? If not, proceed to (2)
2. Can a suitable solution be found by Code Table Committee discussion? If not, proceed to (3)
3. Take the discussion to a monthly Arctos Working Group meeting for final resolution.

Implementation

Once all of the Approval Checklist is appropriately checked and there are no Rejection comments, or in special circumstances by decree of the Arctos Working Group, the change may be made.

• [x] Review everything one last time. Ensure the How-To has been followed. Ensure all checks have been made by appropriate personnel.

• [x] Add or revise the code table term/definition as described above. Ensure the URL of this Issue is included in the definition. URLs should be included as text, separated by spaced pipes. Do not include HTML in definitions.

Close this Issue.

DO NOT modify Arctos Authorities in any way before all points in this Issue have been fully addressed; data loss may result.

Special Exemptions

In very specific cases and by prior approval of The Committee, the approval process may be skipped, and implementation requirements may be slightly altered. Please note here if you are proceeding under one of these use cases.

1. Adding an existing term to additional collection types may proceed immediately and without discussion, but doing so may also subject users to future cleanup efforts. If time allows, please review the term and definition as part of this step.
2. The Committee may grant special access on particular tables to particular users. This should be exercised with great caution only after several smooth test cases, and generally limited to "taxonomy-like" data such as International Commission on Stratigraphy terminology.

[dustymc]

I'm not a fan of adding every tiny structure, I think that's better handled in condition (partial cranium) or modifier (maybe), but parts are mostly collection-specific now so I don't think that's a hard block.

We've talked about a minimum usage threshold from time to time, can you give us an idea of how much use this would get?

This decision should be less-arbitrary, https://handbook.arctosdb.org/documentation/parts.html could use help.

[KatherineLAnderson]

It is a distinct, defined bone in the skull. No different than other bones of the skull already in the specimen parts table (E.g., basioccipital, basisphenoid, ectopterygoid, exoccipital, etc.). For consistency, it should be included where these other bones are listed, yes?

[KatherineLAnderson]

@Jegelewicz @dustymc I'm waiting to reply on the other similar threads (see #7668 and #7671 ) based on this discussion.

For consistency, shouldn't all skull bones be included where some skull bones are currently included?

[dustymc]

shouldn't all skull bones be included where some skull bones are currently included?

That's the question!

If we're going there then we're also 100% going to end up with every structure that anyone's ever named from anything. (Remember that we have busses and meteorites in Arctos.) Can anyone realistically use (for entry or discovery) a vocabulary that could theoretically just be a list of every thing? If so, can we somehow plan for that? If not, what are the alternatives? If we can't answer that, do we keep doing arbitrary things, or do we stop, or somehow slow down, or ??? What do any of the options mean for an incoming collection? How's our recent inability to clean up even the most trivial and unambiguously WRONG data weigh on any of that?

I (clearly!) have no answers, but I'd also prefer to stop trying to dig our way out of this hole, and I've come to absolutely dread arbitrary grayness.

I don't think this request is "wrong" in any way, it just seems a bit "edge case" (and maybe that's just my ignorance shining through), I could be convinced to check boxes.

@mkoo help!?

[ebraker]

@dustymc maybe we could think about a part identification? Part name stays on some agreed-upon meta-level (skull, limb, element, etc.) then a more refined ID could be applied? This could probably be stored as a part attribute(?). I imagine delimiting meta-structure from component structures may prove difficult (and it creates a bit more data entry work), but It sort of begins to create that ontology we always dream of...

[dustymc]

Yes, we could fire up some new 'substructure' part attribute in which someone who really wants to take a deep dive into carburetor adjustment needle seats or feather microstructure could be as specific as necessary. (That could be controlled or free text, maybe merged into some existing part attribute, whatever - lots of options in the details.)

data entry work

Perhaps some of that could be mitigated with UI (in general or specialized entry apps or WHATEVER).

Or maybe the cost of lots of things in one place is easier to pay than the cost of dealing with more-but-simpler things, I don't know!

[campmlc]

The worst case scenario for both of the above strategies: 1) we have a part name for every part in biology and beyond. This is what people in different disciplines expect to find, because each discipline has specific terminology for a reason . 2) We dumb everything down to level that all parts are called "part" and we shove everything of use and value into some attribute or remarks. I hate the idea of 2.

Ideally, we allow collections and search interfaces to use collection specific terminology somehow. I should be able to add part name "strobila" to a parasite collection, along with all the explicitly definied part attributes and record attribute s (life stages etc) terminiology that is appropriate for a tapeworm, and a paleo collection should be able to have explicit part names and related attributes for specific bone bits, without either of us causing problems for the other. I assume this is limited by "resources"? If we have to err, I'd rather allow more vocabulary that is difficult to maintain rather than force cars and houses and fossils and tapeworms to somehow come up with common terminology, which benefits precisely no one. What are our options? If we could create ontologies or synonomies for every possible term, could that reduce the overwhelmingness of option 1?

[dustymc]

dumb everything down

Nobody's suggesting that (although there's clearly some fuzzy unseeable between parts and identifications).

difficult to maintain

That's true but I think manageable, at least under goals/guidelines/something. It's the difficulty of use that I see. Given enough THINGs of kinda any type, some of them will end up carrying incorrect or nonsensical data. (https://github.com/ArctosDB/arctos/issues/7691 for some recent examples.) It's a bit harder to find the data which might have frustrated a user, but it's also not too hard to imagine someone getting lost in something like....

... even before they can get lost in the idea of a bare-naked 2 as a value of abundance.

Complexity should DO STUFF. I think there are probably lots of people looking for skulls and tissues so dealing with the complexity seems worthwhile. Is the same true of feet legs limbs appendages and epiterygoids? (Maybe...)

somehow

There's a whole IDEA behind that; perhaps we should write a proposal to get some of the folks from that community to help us out, see if any of their ideas can survive exposure to reality.

[KatherineLAnderson]

This could probably be stored as a part attribute(?). I imagine delimiting meta-structure from component structures may prove difficult (and it creates a bit more data entry work), but It sort of begins to create that ontology we always dream of...

I think this makes sense-- part name=skull part condition=partial part attribute= ?sub-part name part attribute value=epipterygoid

I don't know what we'd want to call the part attribute that would make the most sense to the most people ("?sub-part name" is just a better placeholder than my initial thought of bits n pieces). But this would put all the sub-parts of the skull in one place, which is the part of this that I think I have the biggest issue with. (Context: It's difficult to instruct a curator/student/volunteer to enter one skull bone in field X, and a different skull bone in field Y.)

But it would create an issue of having sub-parts of any part name in the same spot which could be overwhelming if you've got bits of skulls, parasites, etc all in one place. Could these be coded by collection type so I don't see all the parasite parts if I only want the skeletal parts?

As someone who just cleaned up mispellings of difficult-to-spell part names, I really like controlled vocabulary.

[dustymc]

bits n pieces

You've got my support!

sense

Maybe something that sounds right when the part is "tissues" and the BnP is 'liver' (or "liver" and "lung" and "toenail") - I'm not sure anyone will use it, but the idea has come up a bunch of times and would provide a mechanism to address a recent usability complaint.

coded by collection type

I'm killing that whole idea right now, but for something better/finer-grained - see https://arctos.database.museum/info/ctDocumentation.cfm?table=ctspecimen_part_name for the idea.

controlled vocabulary

My only (slight) reservation is that this might end up a huge mess, but I think that's still an improvement (especially if we can get rid of some parts by doing this) - surely 'skull' will be chosen, and if they get lost in the sea of epi-things there's still SOME discoverability. If you like controlled then I like controlled....

one skull bone in field X, and a different skull bone in field Y

Yes, consistency is kinda always awesome. If we start this we should have a plan to finish.

[KatherineLAnderson]

I'm all for improving the system overall and continuing this conversation, but I don't want to delay loading parts because of it. So, how do I deal with this in the short term so these epipterygoids (and other skull bones not in the specimen part names table) don't get lost between now and whenever we reach the epitome of ontology (or closer to it, anyway)?

[campmlc]

I vote to add epipterygoids and any other skull bones not in the table to the parts table. That way we know at least what terminology is being used, and it is all in one place.

[dustymc]

short term

IDK, https://github.com/ArctosDB/arctos/issues/7667#issuecomment-2067094093 still seems right (and I'd still like to hear from @mkoo )

I'd be more happy with a temporary solution if we had recently been more able to make any sort of change without (what seems from here like) disproportionate resistance.

If "part-parts" seems like a good idea to 2 other CT-folks, I'm pretty confident that I could have that going next week. It's a pretty old idea, a few of us have spent some time thinking about it, I don't think there are any scary corners (if it doesn't survive reality we just elevate BnP to parts and figure out how to deal with that), if you're willing to use it then I'm willing to do whatever I can to make it happen.

[KatherineLAnderson]

I vote to add epipterygoids and any other skull bones not in the table to the parts table. That way we know at least what terminology is being used, and it is all in one place.

Thank you! This would be helpful and I could get my work done (yay). But....

If "part-parts" seems like a good idea to 2 other CT-folks, I'm pretty confident that I could have that going next week.

If this can be done in the next week or so, I could wait. Who do we need to tag here to get this rolling???

[dustymc]

@Jegelewicz is back in town...

[campmlc]

So what is the proposal here? the part is "skull" and the part of the part is "epipterigoid"? I'm worried this will double the effort and quality control required for data entry and result in tons of loan requests for skulls we don't have. Am I misunderstanding?

[Jegelewicz]

I'm worried this will double the effort and quality control required for data entry and result in tons of loan requests for skulls we don't have. Am I misunderstanding?

yep - disposition is for the part, people will easily ignore the "part-part" because what is that anyway? Only Arctos knows and that's no good....

[Jegelewicz]

Until someone is being paid to work on this, I checked a box. Precedent is that we add individual bones.

[dustymc]

Only Arctos knows

Would you say the same for other stuff at the same level? I'm not sure there's a functional difference between "all the things" and "all the things, some with modifiers."

individual bones

Things! I don't think we can add all the things without being willing to add all the things.

I think that's probably the wrong direction, but I'm totally willing to consider about anything.

checked a box

And I'm still not willing to be the blocker on this, https://github.com/ArctosDB/arctos/issues/7667#issuecomment-2067094093, I'll somewhat-reluctantly check my boxes if that becomes the holdup.

[campmlc]

I don't think any of us has the bandwidth right now for developing some new part part system that we cant test out and discuss the full consequences of as a community. This is holding up work. I vote to go with precedent, just add the bone, and wait until we can try to get funding for ontology development.

[KatherineLAnderson]

I vote to go with precedent, just add the bone, and wait until we can try to get funding for ontology development.

Thanks Mariel!

I will reference this in the other similar requests.

[dustymc]

Boxes checked, see https://github.com/ArctosDB/arctos/discussions/7737

[Jegelewicz]

Added search terms

cranium, skull

[KatherineLAnderson]

Spelling in the code table is missing a P!

epiterygoid --> epipterygoid

[Jegelewicz]

update complete