search

ArctosDB / arctos

Arctos is a museum collections management system
https://arctos.database.museum
60 stars 13 forks source link

Feature Request - part metadata #6823

Closed dustymc closed 11 months ago

dustymc commented 11 months ago

Is your feature request related to a problem? Please describe.

I'm prioritizing https://github.com/ArctosDB/arctos-dev/issues/23 because https://github.com/ArctosDB/internal/issues/286. I think I'll accommodate https://github.com/ArctosDB/arctos/issues/3452#issuecomment-782455840 by just adding a column to the code table, which opens the doors to experimenting with https://github.com/ArctosDB/arctos/discussions/6742#discussioncomment-7203287. Are there other 'part metadata columns' that might be useful for some reason?

Describe what you're trying to accomplish

Awesomeificate parts while I'm rebuilding everything anyway. Add to code table following list-type 'fields'

Are there others?

Describe the solution you'd like

Knowing what sort of 'part name metadata' might make something neater.

Describe alternatives you've considered

Do nothing.

Additional context

This will likely guide revisions to other code tables (certainly those which are not currently unique).

Priority

Happening.

Jegelewicz commented 11 months ago

@dustymc I think this is progress of a sort - but I fail to see how it fixes the heart, liver, muscle problem in the part name code table itself. I feel like the solution you are developing sets us up for a part name free-for-all which may help data curators, but isn't going to be friendly to people searching all of Arctos for "heart". Maybe I'm wrong?

dustymc commented 11 months ago

progress of a sort

This will allow a keyed relationship between the data and the authority, which is definitely "progress" - even if that is (I hope!) invisible/not something that any user will notice. That's the ultimate goal of https://github.com/ArctosDB/arctos/issues/3452; everything else is icing.

fail to see how it fixes

It does not. That problem has been presented as unfixable (or desirable or something - I'm hearing that we can't or won't stop, whatever the reasons). This addresses - not fixes! - the problem by allowing collections who want to deal in "pure" parts to exclude not-parts (eg niche descriptors, or whatever 'ectoparasite' is) and parts+attributes (eg our many ways of saying 'skin') and three parts in a trenchcoat (your example) and whatever from their picks/data. That is, mammalCollectionA can allow thisBone but not thatBone while mammalCollectionB allows both (or neither, or whatever).

which may help data curators

I think probably the opposite, but maybe there's some goal that I can't see for some reason or ??

isn't going to be friendly to people searching all of Arctos for "heart"

This will/may make things slightly more discoverable by adding search terms, but that would also require some data-fixing. (Eg search terms will be structured as 'authority' so changing them will require an Issue.)

As above, an individual collection will be better able to control their own data (and won't need to go through the issue process to make something available to themselves, or at least that's the plan at the moment), which will hopefully result in overall cleaner data, and can definitely make individual collections more discoverable.

That said, discoverability is very intimately tied to normalization, and mixing various THINGs in one 'bucket' and having various ways of saying 'that thing' are failures to normalize. Collections choosing that path are also choosing to be less discoverable.