Request - ctid_references - merge various things into associated with?

[dustymc]

Help us understand your request (check below):

• other

Describe what you're trying to do

https://github.com/ArctosDB/code-table-work/issues/87 has introduced a new term. I'm not sure how it's separate from some existing terms. We should merge anything that's the same and clarify anything that's not.

After pulling these data, I'm wondering if we don't actually need much more merge than I initially thought - this looks a lot like arbitrary usage, or very confusing definitions, or ???? - upping priority accordingly.

same collection as [ link ]

Accumulated groups of objects or materials having a focal characteristic and that have been brought together by an individual or organization. A collection comprises multiple items that are conceptually or physically arranged together for the purpose of cataloging or retrieval.Getty AAT For cultural collections, possibly a group of items purchased or collected from a single artist or culture-bearer at the same time.

temp_same_collection_as.csv.zip

 guid_prefix | count 
-------------+-------
 UWBM:PR     |   250
 DMNS:Bird   |     2
 UAM:Herb    |  3486
 UWBM:PB     |  3606
 DMNS:Mamm   |     8
 UAMb:Herb   |     1
 BYU:Edu     |     2
 UAM:Ento    |    31

@WaigePilson
@camwebb
@DerekSikes
@acdoll
@StefanieBond

same set as [ link ]

Part of an assembly of items that the creator intended to be kept or seen together, such as a tea set, a desk set, or a pair of terrestrial and celestial globes. A set differs from a collection in that it is typically smaller and it was intended by the creator to be grouped together.Getty AAT

temp_same_set_as.csv.zip

 guid_prefix | count 
-------------+-------
 UAM:Art     |   464
 ALMNH:EH    |    50
 DMNS:Egg    |     2

@acdoll
@DellaCHall
@brandon-s-thompson

same assemblage as [ link ]

Groups of objects found in association with each other, as from one level, activity area, or site, regardless of their material or type. Getty AAT This would be useful in paleo collections where there are often cataloged items with the notation "may be associated with".

temp_same_assemblage_as.csv.zip

 guid_prefix | count 
-------------+-------
 NMMNH:Paleo |   556
 OWU:Rept    |     6
 UWBM:PB     |    46
 MSB:Mamm    |     1
 UWBM:Mamm   |     6
 OWU:Bird    |     2
 MVZ:Herp    |     2
 MSB:Herp    |     2
 UNM:MET     |     6
 UAM:EH      |    14
 OGL:Genomic | 33811
 OWU:Amph    |    28
 MSB:Para    |    16

@Nicole-Ridgwell-NMMNHS
@mkoo
@AJLinn
@campmlc
@WaigePilson
@atrox10
@jtgiermakowski
@jebrad
@jrpletch
@AdrienneRaniszewski
@jldunnum
@happiah-madson
@msbparasites
@falco-rk

[AJLinn]

UAM:EH | 14

These seem to legitimately be "same assemblage as" per the published definition. Things like a pair of parkas made by the same artist as a "his & hers" set, two cribbage boards made from the same walrus tusk and decorated in the same way, steering wheels & signs for the same riverboat, etc.

I haven't used 'the same set as" though I do have a whole set of dishes with the same pattern that could fit that definition, nor "same collection as" since i normally do that at the accession level but in a less formal way.

Perhaps all of these could be subsumed under "associated with" and explained how in the remarks.

[happiah-madson]

OGL:Genomic | 33811

The vast majority of these (perhaps even all?) are a function of our migration. Because we moved records over first before making accessions, our accession numbers were associated to records via "same assemblage as." I think I've done all the work to get everything over to (although there are still ~3000 records in accession L00000, so clearly I still have some cleanup to do), but once that is done, there isn't any need for us to store data there and we could potentially remove that from our records. But not until that migration is done.

[Nicole-Ridgwell-NMMNHS]

in same matrix as

Is important for paleo collections

same assemblage as

I think all NMMNH:Paleo using this relationship would be better as associated with.

[dustymc]

subsumed under "associated with" and explained how in the remarks.

If they're being used interchangeably, then having more than one just means that no user will find what they're looking for. I think that's (vastly) more-evil than nearly any alternative (eg making a very specialized user sort through remarks). If there's truly some 'research grade' distinction then we should probably just try to clarify the definition or figure out why it's not being understood or something. If the distinction is more subtle (I have no idea where that line might be!), then merger makes sense from here.

migration

Would 'associated with' somehow not serve that purpose? (And do we need an again-expanded definition if so?)

important

Removed from consideration.

[jebrad]

We do not have a strong opinion for UWBM:Mamm, We only use "same assemblage as" for a small number of wolves which have a known pack name. Packs are named by state DFW and sometimes include range maps, so we want to keep it someplace. "Associated with" would work.

[dustymc]

we want to keep it someplace

If you want to be super-fancy (and have a place to attach shared data, like those range maps), you could catalog the pack in https://arctos.database.museum/collection/Arctos:Entity - it's about 2 clicks if the members share an identifier, happy to help/demo. That would un-factorial the number of relationships necessary to paint the full picture and summon nifty GBIF UI-magic (see for example https://www.gbif.org/occurrence/2562029383 - "5 occurrences"). https://arctos.database.museum/info/ctDocumentation.cfm?table=ctcoll_other_id_type#organism_id (no id_references necessary) is appropriate for that (https://dwc.tdwg.org/terms/#organism).

[WaigePilson]

I admit that I have not been as careful as I should be about the definitions of these different terms, but there are a few major (and very important for my collection) use cases of these distinct id_references terms:

• Sediment samples collected in a stratigraphic sequence along an outcrop for e.g., fossil phytolith or pollen content. Each sample is a unique specimen and collected at a unique geographic point so a unique locality by our standards. However I need some way for researchers to be able to quickly and easily see that e.g., these 400 sediment samples are all from the Argentina Gran Baranca profile collected in 2014. I haven't used an id_references to link these records yet, but would like to do so in the future.
• Multiple fossil plants that are on the same physical block of rock, unable to be separated. This is an obvious use of the "in same matrix as"
• Field locality numbers--some of our collections have cryptic or other institution locality numbers on them. While they don't necessarily correspond 1:1 to what I use as the locality name, I'd like to link specimens with those ids as they are assumed to come from the same area/field site/locality. In this case I use "same assemblage as".
• Collections which are accessioned at another institution but HIT at my institution. I have used "same collection as" to link the accession numbers of that other institution to my catalog records. I suppose in this case I could create accession records for that other institution's accessions and link via an accession, so long as catalog records can have multiple accession numbers associated with them.

I guess what I am saying is that I am okay with merging some of these terms, as long as there remains a distinct term to apply for "same matrix as" (sounds like there isn't an appetite to get rid of this one, thank goodness), and something for cataloged objects collected from the same area/section/outcrop (I could use "associated with" for all and be happy).

[jrpletch]

For the OWU ones, the birds are mounted together but it doesn't look like that was an option when I catalogued them. The reptiles and amphibians are all cases where we have specimens with different species & localities in the same jar and "same assemblage as" seemed to be the most appropriate.

[dustymc]

Argentina Gran Baranca profile collected in 2014

Possibly another use for an Entity (in which you could elaborate on the scope/define the whole). (And I'm not really sure that identifier references, the wolf IS the pack/the fossil IS the assemblage as much as it references the thing which only exists because the 'component' exists - or I need more coffee, IDK.)

Field locality numbers

I think that's maybe an even clearer case of not needing a reference, but rather just being a part of the thing and so wearing its identifier? (Or I'm not understanding the situation.)

accessioned at another institution

https://arctos.database.museum/info/ctDocumentation.cfm?table=ctid_references#same_individual_as is the concept (which may or may not need a better name) for that, assuming I'm not totally lost.

same jar

Is that somehow "research grade" or admin? (Do we need some other structure?) Does the relationship carry some information the container/part location can't?

[Jegelewicz]

We do not have a strong opinion for UWBM:Mamm, We only use "same assemblage as" for a small number of wolves which have a known pack name. Packs are named by state DFW and sometimes include range maps, so we want to keep it someplace. "Associated with" would work.

@jebrad My current recommendation (in the Misc migration) is to add the Pack name as an identifier (type identifier) with "Pack" in the remark.

[jebrad]

UWBM:Mamm have been fixed (count said 6 but only 5 in the temp csv). Pack name was already an identifier, but I changed relationship from "same assemblage as" to "self", and added remark "pack name"
I like the @dustymc idea of creating an entity for each pack and getting the range maps and data archived there, because I doubt the State will keep them very long, but I will prioritize that a little lower.

[DellaCHall]

For UAM:Art:

The "same set as" can be merged into "associated with" for our records.

The ones that are "mounted with" are legitimately mounted together, which is information we need to retain somehow. So either we keep "mounted with" or, if they are merged into "associated with," they'll need a remark that they are mounted together. I don't really have a preference so long as that information is retained.