Code Table Request - New catalog record attribute "verbatim collection"

[Jegelewicz]

Goal We have been entering this data into "collection remarks"; however, attributes allows this information to be more easily searchable on the search page and visible within the catalog record.

Context "verbatim collection name" is more specific category than "description." We are transcribing labels from the collector labels in the herbarium collection and want to capture how the label is presented (if it's from an exchange collection, university collection, etc.) We will use it for other collections in the future.

Table https://arctos.database.museum/info/ctDocumentation.cfm?table=ctattribute_type

Proposed Value verbatim collection name

Proposed Definition [ Clear, complete, non-collection-type-specific definition of the new value. ]

Collection type Herb

Attribute data type [ "Attributes" may apply to catalog records, parts, localities, and collecting events. You must specify a datatype (free-text, categorical, or number+units) if this request involves attributes. ]

Attribute value [ For categorical attributes, code table controlling value ]

Attribute units [ For number+units attributes, code table controlling units ]

Available for Public View [ Yes | No to indicate whether the proposed value will be available for public view or available only for logged in operators. ]

Priority [ Please choose a priority-label to the right. ]

[Jegelewicz]

"verbatim collection name" is more specific category than "description." We are transcribing labels from the collector labels in the herbarium collection and want to capture how the label is presented (if it's from an exchange collection, university collection, etc.) We will use it for other collections in the future.

This seems more like an other identifier, an agent or an accession. When things come from another institution, do they not also include some kind of number? If not, (because I know people exchanged uncatalogued stuff), then it seems like using an accession to designate the "donor" would make most sense. BUT I realize that accession information is most likely NOT public and in a way, the exchange collection is really just a secondary collector (or even the preparator?). Why not just add that information in the agents section of the record? Use verbatim agent with a remark if you don't want to add a bunch of institutional agents?

[Jegelewicz]

Verbatim collection name is being requested specifically for herbarium sheets. @mvzhuang @camwebb thoughts?

[Jegelewicz]

@wellerjes can you provide a proposed definition? Thanks!

[mvzhuang]

agents sounds like a good idea. We have a bunch of things in remarks. Preparator sounds like a good idea but I'm not sure if it's obvious enough to people that means it was from exchange if that matters.

[wellerjes]

This seems more like an other identifier

It is, but I mainly want to indicate that the information is verbatim from the herbarium label.

Example: Chas:Herb:102 and Chas:Herb:103 are on the same herbarium sheet. (We've found that someone in the early 20th century mounted specimens from the same species, different collecting events, on the same herbarium sheet).

• The label on CHAS:Herb:102 reads “Ex. Herb. W. S. Moffatt, M. D. Chicago, Illinois, U. S. A.”
• The label on CHAS:Herb:103 reads “Flora of Chicago. Herbarium of W. S. Moffatt, M. D.”

Having the verbatim field will allow us to distinguish these two separate collections; it helps draw attention to the fact that even though these specimens are on the same herbarium sheet, the information is different; and it will help us down the line when we dig into Moffatt's archives to find more information about his specimens/collections (103 is more likely to show up in his own notes, while 102 was part of an exchange).

@mkoo's suggestion in #4528

could this be the same as 'series title'? or 'verbatim series title' (compromise of both suggestions?) Let me know what you think since somehow "collection" is a little vague/redundant since this is all part of a "collection" already?

Yes, this makes sense; having the broader collection and then the individual agent collections within makes sense to me, but the terminology (trying to figure out if we're referring to an overall collection--botany--or a collector's personal collection--Moffatt's--may get confusing. I see the object title as "herbarium sheet of plant", whereas the collector's collection name is a more specific detail, not the object itself.

My inclination toward attribute over identifier is that attribute is a better field for this information, as there is more flexibility in the fields (with determiner, date determined, remarks).

[camwebb]

An attribute named 'series title' or 'verbatim series title' would be very useful. Almost all herbarium sheets have a title of this nature, usually in a distinctive font at the top of the label, and there's no other place to put this info (that I know of).

[Jegelewicz]

My inclination toward attribute over identifier is that attribute is a better field for this information, as there is more flexibility in the fields (with determiner, date determined, remarks).

we are working to change this - please see #4101

[Jegelewicz]

Create an other agent - relate to the person agent then add agent of type collector to the appropriate catalog records.

Change definition of collector to include these kinds of things.

Current definition Agent responsible for collecting a specimen and, in the absence of preparator information, preparing it.

Proposed definition Agent responsible for collecting a specimen and, in the absence of preparator information, preparing it. May also apply to an agent who assembled a collection of objects but did not necessarily collect or prepare the objects (e.g., collection of specimens that were acquired through exchange, purchase, or other means); collection name may be written on the original label of an object.

[Jegelewicz]

@wellerjes @camwebb The Code Table Admins talked through this today. We propose that you create an agent of type other agent for the collection, then add that agent as a collector to the appropriate catalog records. This will allow us to summarize all things from a single collection using the agent page. We have adjusted the definition for collector to reflect this usage.

[Jegelewicz]

Needs documentation

[Jegelewicz]

Closing

[camwebb]

@Jegelewicz Just to be sure this is what you intend, please see: Agent 21339709 and GUID UAMb:Herb:43110. Thanks

[Jegelewicz]

@camwebb yes! That is exactly what we intended! Thanks for the documentation example!

[Jegelewicz]

I could not stop thinking about this last night - especially after writing documentation. I just want to register my thought here that this should be an entity. Why do we choose to use an agent for this and not for Kianga? It's bugging me so I just wanted to put my thoughts here in case this comes back to bite me.

[wellerjes]

Based on the handbook definition, entity makes sense to me. Especially since a lot of the herbarium collection titles are similar ("Collection of E. J. Hill" vs "Ex. Collection of E. J. Hill")--I know there's been a lot of discussion about distinguishing very similar agent names. Would changing the collection title name to entity reduce these types of issues?

[Jegelewicz]

I know there's been a lot of discussion about distinguishing very similar agent names. Would changing the collection title name to entity reduce these types of issues?

Possibly. But you could certainly have two agents Collection of E. J. Hill Ex. Collection of E. J. Hill (although I would expand that to Exchange Collection of E. J. Hill)

The solution proposed and accepted works, but it feels like we are setting up two methods for doing the same thing.

It may be a mistake, but I am going to bring it up in our organism/entity meeting on Monday.

[camwebb]

I just want to register my thought here that this should be an entity.

Agree. The naive understanding is surely that a collection series is not an agent but an entity.

[dustymc]

Entities can glue ANYTHING together - they almost can't be wrong, but they do take some (minimal) effort to 'mint' and probably just add complexity rather than clarity in some situations. (Entities are fundamentally just good identifiers, you could do almost the same thing with an ark or almost-ier even a uuid.)

Active collections are Agents (not sure I agree with that, but they are), why would we treat a former collection any differently?

Projects are "stuff assembled for some purpose" so that could work too.

Collections (sometimes?) produce identifier types, those could have been cited, they work just fine for grouping and might do other stuff (lead to old publications) as well.

I suppose I'm not opposed to some "categorized remarks" (=free-text attribute) approach either, but it cannot be actionable - I'm just never going to find all of the ways you didn't quite type "Exchange Collection of E. J. Hill."

None of this seems quite "research grade" (although everything except free text might be "historian grade") - knowing that it was previously in some collection doesn't (always/usually, probably/maybe) influence what I can expect do with it, so I'm not sure we need a normalized/unified approach.

This definitely needs documentation, even if only "given X we did Y because reasons."

distinguishing very similar agent names

I don't think that's at play here - E. J. Hill-->{some relationship}-->Exchange Collection of E. J. Hill is sufficient information to disambiguate them.

[Jegelewicz]

@dustymc E. J. Hill had TWO collections!

Collection of E. J. Hill - their personal collection Ex. Collection of E. J. Hill (although I would expand that to Exchange Collection of E. J. Hill) - the collection they made specifically to exchange with others

This a VERY common thing in herbaria....

[wellerjes]

Projects are "stuff assembled for some purpose" so that could work too.

If this is the case, we'd need to be able to add individual catalog records to a project. Putting all of those catalog records into a loan misrepresents what is happening with the specimens (they're not being loaned, they're being grouped together) and specimens that come in together under one accession do not all necessarily have the same original collector.

the collection they made specifically to exchange with others

Also a way to indicate specimens that they received from other collectors, then put their own label on (which is how some specimens end up with multiple labels, identifications, etc.). Having that distinction is important.

[Jegelewicz]

So, now that I've made a mess - what do you guys think? Agent, Entity, Project, something else?

I think that @dustymc is right, that there doesn't need to be just one method, but laying out the possibilities and why some collections choose what they choose will be helpful to someone making the decision for the first time.

@wellerjes @camwebb @ebraker @ccicero @lin-fred @Nicole-Ridgwell-NMMNHS

[Nicole-Ridgwell-NMMNHS]

I can see different options working for different types of goals. I like the idea of using projects because I like the format of the project page and being able to share that project page with others. I would create a data loan for such a project. But, I can see how adding the information as an agent would make it easier to see/use this data when browsing through records/in a data download, especially if it has come up through several different collections. Creating an entity seems like more complexity than is needed for something like this, but perhaps could be needed in some instances, especially if some kind of relationship between collections needs to be created???

[camwebb]

Just created a 'Flora of Manitoba' project to test/demo the Project route alternative for UAMb:Herb:43110, and discovered that i) the project will not be saved without 100 characters in the description (not just "Minimum 100 characters to show up in search."). I made up some dummy text, but that's a lot of work to do every time one wants to add info about the label series to the specimen. ii) I couldn't work out an easy way to mark a specimen as associated with the project (I know I can cite a specimen in a publication under a project, or add a loan under a project). So I think project is not the way to go. Maybe publication? But creating a label series as an agent and adding as a collector was dead quick and easy.

[Jegelewicz]

I agree that projects don't work here - too much effort for a "project" in which your institution was not involved.

[ebraker]

I'm still a fan of using Agents for these (as "organization" or some new type, e.g. "collection"). Agent Activity nicely collates everything across institutions, and as @wellerjes mentions, meets the need of attaching individual records vs. creating a transaction. The "not the same as" relationship disambiguates collectors with two collections, and most importantly, using Agents makes the collection name easily findable and visible to outside users from the catalog record.

[Jegelewicz]

Agent Activity nicely collates everything across institutions, and as @wellerjes mentions, meets the need of attaching individual records vs. creating a transaction. The "not the same as" relationship disambiguates collectors with two collections, and most importantly, using Agents makes the collection name easily findable and visible to outside users from the catalog record.

Which is pretty much what we are asking entities to do......What I am looking for here are clear reasons to choose between an agent, a project or an entity.

[ebraker]

What I am looking for here are clear reasons to choose between an agent, a project or an entity.

Agents. I'd say the so that a data entry operator can use them without needing additional permissions (unlike projects or entities) and so that e.g., "Edward Royal Warren Collection" shows up right beneath the collector name on a catalog record - seems intuitive to display people names together. People have outlined above why projects aren't workable. And with Entities, the verbatim collection name won't display on catalog records - it will say "Entity:67" vs. "Edward Royal Warren Collection," so Agents just seem all-around more user-friendly.

[dustymc]

clear reasons to choose

Data structure - use whatever does what you want to do (and that you can manage). And note that nothing precludes multiple things from being used simultaneously.

an agent

A human or some human-created "organization" is involved. (I'm not sure precisely what that means, but "Exchange Collection of E. J. Hill" is certainly included.)

a project

Following transaction data is important - projects were created for https://arctos.database.museum/project/15, Native hunters want to know how "their" seals contribute to science (via future loans and publications)

an entity

You want to record the kinds of data an Entity can carry, or you're just looking for a good generic identifier that can be shared across multiple records.

And from above....

identifier types allow maintaining existing identifiers (eg stuff that might be cited somewhere)

"categorized remarks" (=free-text attribute) would allow transcribing labels (but never as faithfully as an image)

[campmlc]

I certainly prefer the simplicity of use, clarity of UI, and existing functionality of agents over what I have seen so far of entities. I also heavily use projects - creating one for almost every loan and accession - but they take more work to create the links - anything we can do to automate or autosuggest more info in projects (e.g is this publication related? click yes or no) would make them even better. I would like to see more UI changes to entities to be more similar to project and agent pages and to create better linkages between projects/agents and entities.

[AJLinn]

I vote Agent, for all the reasons for that are listed in comments.

We already use this for Estates (e.g., Candy Waugaman Estate ) to describe an individual's collection that comes in after their death, we should use a similar structure to mark a similar assemblage of items from when they were alive.

[wellerjes]

If we go with Agents, would it be possible to add a new relationship to the agent_relationship code table? Either "collected by" or "associated with"? (which might be too close too "associate of" and cause confusion). None of the current relationships really represent relationships between people and collections.

[Jegelewicz]

relationships between people and collections

I think associate of would be appropriate, but maybe the definition needs an update?. I use this when I am uncertain if a person was an employee of an institution (person<=>organization relationship).

If you think we need something specific, I suggest

creator of - Used for people who were involved in the creation or development of an organization or other agent.

[wellerjes]

I like "creator of". Plus it leaves "associate of" for the more uncertain relationships.

[Jegelewicz]

Closing - added new code table request issue and updated documentation.