Code Table Request - New identification attribute "title type" (was Additions to nature of ID code table for art collections)

[Jegelewicz]

Issue Documentation is http://handbook.arctosdb.org/how_to/How-to-Use-Issues-in-Arctos.html

Goal Art collections need to track different titles of artwork.

Context They would like to use defined "title type" terms to do so. As titles are stored in the identification portion of the catalog record, the title type would be metadata of an identification. As such, we propose that this information be carried in a new identification attribute. the Nature of ID field. We considered requesting a new identification field, but thought we might be able to use the one in place already.

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

ctidentification_attribute_type

Value title type

Definition A term that indicates the origin of the title

Collection type N/A

Attribute data type categorical

Attribute value A new code table would be needed:

Purpose	Table	Description
Identification: Title Type	ctidentification_title_type	Controlled vocabulary for identification attribute title type

These are the values UAM Art would like added:

Definition term	definition
descriptivetitle	title describes the object
repositorytitle	title assigned by the institutional repository
artist'stitle	title assigned by the artist or creator
inscribedtitle	title inscribed on the object
formertitle	a title previously assigned to the object that is no longer in use (reasons for usage change should be included in identification remarks)
translatedtitle	title that has been translated from another language (to and from languages should be included in identification remarks)

(I removed title as that is evident in the new attribute type)

Attribute units N/A

Part tissue flag N/A

Other ID BaseURL N/A

Priority Please assign a priority-label.

Discussion: 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.

@AJLinn @DellaCHall
https://github.com/orgs/ArctosDB/teams/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)._

• [ ] 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
• [ ] 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
• [ ] DBA - The request is functionally acceptable. The term is not a functional duplicate, and is compatible with existing data and code.
• [ ] 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.

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

Make changes as described above. Ensure the URL of this Issue is included in the definition.

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]

"Inscribed title" is the same idea as the rest of NoID terms - it's a method, it seems like the right kind of data for this concept, but it also seems like another way of saying "features."

The rest of these seem unnecessary; they can be gathered from other data, mostly combinations of agents and acceptedness. An identification attributed to the artist and not accepted is "former artist's title" for example. That also allows for including the functionality of NoID - the artist (or any other agent who might show up here) may call it something based on function and something else based on features, for example.

I do see two potential gaps in that approach.

1. Arctos currently allows only one accepted ID, which may not be sufficient here. (And it's come up before, but I can't remember why - maybe @AJLinn had a use case?) We may need to do something more complicated there (more than binary - "accepted as...." - or binary but allow any number in any state, or ????)

2. "Translated" isn't covered by current data. That could be addressed by a "translator" collector_role, which would be more broadly useful. (And perhaps "inscriber" or something that encompasses it as well.)

Can you elaborate on "requesting a new identification field"? Might be something interesting in there....

[Jegelewicz]

requesting a new identification field

@krgomez first asked for a new field in ID metadata = title type.

[Jegelewicz]

@dustymc your solution seems workable BUT - I would assume any cultural aggregators (assuming there are any) would want to see the terms as suggested - http://www.getty.edu/research/publications/electronic_publications/cdwa/4titles.html#RTFToC3

[marecaguthrie]

It makes sense that titles are part of identifications in Arctos, but they are a different type of identification than Linnean or cultural taxon/object type. Rather than being used to categorize the object, they are assigned to an artwork to provide context for how the artwork can be experienced and understood. Just so we are all on the same page, let me take a step back first just to describe why information about the title is so important for art collections.

Some titles are more literal and descriptive, others more abstract but all titles help provide context for better understanding an artwork. Sometimes the artist decided on the title, sometimes they didn’t have a title or the title was lost and a curator creates a title for an artwork. Sometimes the artist decides the title should be “Untitled”, sometimes the title is in a different language and there are multiple ways to translate it. Some titles and descriptions have language that is racist or derogatory and a museum may decide to change the title, but still keep a clear record of the original language. Museums are always trying to balance artist intent with the needs of the public. Sometimes the title can be determined by the museum by looking at the physical object (if the artist has inscribed the title on the artwork), but often it is a more complicated process of talking with the artist, artist’s family, art historians, or looking at past publications or documents.

An object can end up having multiple titles, and we want to keep track of all of them along with information about what kind of title it is, who made the decision, and why.

We think this would be most clearly accomplished through the use of title type along with remarks in identifications. Intuiting the title type from information elsewhere in the catalog record is likely not precise enough.

On Tue, Dec 8, 2020 at 11:53 AM Teresa Mayfield-Meyer < notifications@github.com> wrote:

@dustymc https://github.com/dustymc your solution seems workable BUT - I would assume any cultural aggregators (assuming there are any) would want to see the terms as suggested - http://www.getty.edu/research/publications/electronic_publications/cdwa/4titles.html#RTFToC3

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/3288#issuecomment-741012933, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJKSRR5W6TSLHOPPMYHAQLDST2G6PANCNFSM4USOUOUQ .

-- Mareca Guthrie (she/her/hers) Curator of Fine Arts & Associate Professor of Art University of Alaska Museum of the North 1962 Yukon Drive P.O. Box 756960 Fairbanks, AK 99775-6960 mrguthrie@alaska.edu

University of Alaska Museum of the North: www.uaf.edu/museum UAF Art Department: https://www.uaf.edu/art/ https://www.uaf.edu/art/

At UAF, we acknowledge the Alaska Native nations upon whose ancestral and unceded lands our six campuses reside. Here in Fairbanks, our Troth Yeddha' Campus is located on the lands of the Dene Athabascan people of the Tanana River.

[dustymc]

@marecaguthrie that all sounds like exactly what biologists do, although the formalities are a bit different. Lots of taxa are represented by inconvenient strings of various kinds. "Higher taxonomy" is essentially an attempt to balance what an involved agent said with the needs of users, including the public. Lots of critters, or groups of them, get different titles over the years. There's plenty of argument over how various things are "translated," how individuals are assigned to groups, etc., etc., etc.

We may in fact need to do more - or something different, or ???? - with identifications, but if so I don't think it will be something that applies only to Art (or any other discipline).

Is this perhaps a case of confounding catalog records (abstract things) and parts (physical things)? I can't quite put my finger on that separation (if there in fact is one) in cultural collections, but I think that physical/virtual division is at least somewhat related to whatever you're trying to sort out here.

[dustymc]

Abandoned?

[krgomez]

I would still like to find a solution for recording "title type" for artworks. I don't know if nature of ID is the right spot for this, but it makes sense to me to try to find a way to record this information in identifications, since that is where we are recording the title of an artwork. The other solution is to continue using the attribute "object title" as well and use method to record the title type, but an artwork's title is then duplicated in two places in the catalog record.

[AJLinn]

Arctos currently allows only one accepted ID, which may not be sufficient here. (And it's come up before, but I can't remember why - maybe @AJLinn had a use case?) We may need to do something more complicated there (more than binary - "accepted as...." - or binary but allow any number in any state, or ????)

This would be another reason to support multiple accepted IDs (see #4779) . I see this issue for art collections being analogous to Indigenous terms provided in different languages, all of which should be viewed as equally valid.

[dustymc]

https://github.com/ArctosDB/arctos/issues/3540 would allow multiple IDs, which is the correct path if these things need their own metadata.

If they're just terms (or maybe require 'light' metadata' depending on how things work themselves out), https://github.com/ArctosDB/arctos/issues/4829 would provide a mechanism for arbitrary assertions (eg, translated title=bla bla whatever or better yet just title=something; title=algos; title=нечто).

Neither require gaming any data, so are better solutions than trying to wedge something that still doesn't look like nature in with nature.

[krgomez]

https://github.com/ArctosDB/arctos/issues/3540 would allow multiple IDs, which is the correct path if these things need their own metadata.

I don't think this is going to help with artworks that have had title changes that we want to keep track of. For example, if a work was given a racist title by the artist (unfortunately, we do have at least one of those), and the curator chooses to give the artwork a new descriptive title. In a case like this, we would have two separate identifications, because we would need to record two text strings. The work type (painting) would not change, just the title of the work which we record as a string.

If they're just terms (or maybe require 'light' metadata' depending on how things work themselves out), https://github.com/ArctosDB/arctos/issues/4829 would provide a mechanism for arbitrary assertions (eg, translated title=bla bla whatever or better yet just title=something; title=algos; title=нечто).

If we actually use nature of ID for recording title type, then it would sometimes be helpful to be able to record two title types, such as "inscribed" and "artist's". Furthermore, because both an artwork's title and its type are recorded in identifications, being able to record both the title type and the method of identification for the work type would I guess be good. In practice though, I would probably be inclined to just start using nature of ID to record the title type and wouldn't even add a nature of ID selection for the work type. Using "features" or "fine features", which I see as being the only functional options in this code table for us, are sort of useless in my opinion (again, for us). At the same time, nature of ID relates to taxonomy (for us, work/object type), and not the title of the work, and so I still wonder if nature of ID is even the right place for the title type.

[dustymc]

we would have two separate identifications

Yes, exactly - and, unlike now, you could treat them as equals.

If we actually use nature of ID for recording title type

I still cannot see how that could be a defensible approach.

record two title types

As attributes of an identification you could record any number of any type, whatever those turn out to be.

"fine features" ... sort of useless

I'd think that would be useful for things like dealing with forgeries.

Sort of 'behind the scenes' I think perhaps there's some confounding of identification and taxonomy, but I'm not sure - we somehow don't seem to be quite on the same page, anyway.

[krgomez]

Yes, exactly - and, unlike now, you could treat them as equals.

I see. That makes sense now.

I still cannot see how that could be a defensible approach.

Do you see a way to record this in identifications outside of nature of ID? Or does it seem like we need to just duplicate the work titles in the object title attribute and use method?

I'd think that would be useful for things like dealing with forgeries.

We just don't have those - as far as I know! When I say useless, I just mean it's sort of the only thing we can use for our collection and doesn't actually tell us anything. Maybe other people would disagree with me. There probably will be cases when we update a work type and want to record why/how. I could see this happening with some more obscure type of photograph, but a painting will remain a painting.

Sort of 'behind the scenes' I think perhaps there's some confounding of identification and taxonomy, but I'm not sure - we somehow don't seem to be quite on the same page, anyway.

I'll point back to the CDWA, where the title or name of a work is generally distinct from the object/work type, though not always. For EH these are most often the same thing, and so there definitely is overlap between title/name and object/work type. However, for the art collection we will only use the work type as the name of an object when the work is more so functional/decorative, such as ceramic plate. If we don't have a title for a painting, we will not call it painting. If the painting is described as Untitled by the artist, we will use that. Otherwise we will construct a title, such as Abstract Composition. Untitled has actually been misused a bit in the collection, and is something we need to clean up.

[krgomez]

I'm now wondering about whether the title of an artwork should even be part of identifications. The Arctos handbook says identifications "apply taxonomic terms to specimens," which does not encompass the titles. I think that the overlap between object name and object type, but the lack of overlap between object title and object type, makes this confusing. For many objects in the EH collection for example, the object name and object type are the same thing. In other words, what we call the object by name is the same as what it physically or functionally is. So it works well and makes sense to have the name and type of object recorded together in the same place in identifications. Whereas with art objects that are titled, the title has nothing at all to do with the object type. It could, but most often a title relates to the subject matter of a work. Titles convey meaning, and when given by the artist are part of the work's creative authorship.

We decided to use identifications for titles because that's where we decided they fit best into Arctos. Is there a better solution though? One that would allow us to more easily record the title's metadata without trying to use nature of ID, which is really about taxonomy, and doesn't actually seem like it's going to work?

[Jegelewicz]

I think that the overlap between object name and object type, but the lack of overlap between object title and object type, makes this confusing.

I have thought this from the first time I heard that this was how things were being done. Even the bio collections occasionally have this issue (See Kianga). A title is a different kind of identification than taxonomy and probably should have metadata including who created the title and when.

We do special things with some attributes like verbatim agents, so why not create an attribute "object title" and give it a special place in the UI just above the identification?

[campmlc]

How about just " title" or "name"? Would that work for art collections? That way we could use it for names like Kianga without referring to them as objects.

On Thu, Oct 27, 2022, 11:24 AM Teresa Mayfield-Meyer < @.***> wrote:

• [EXTERNAL]*

I think that the overlap between object name and object type, but the lack of overlap between object title and object type, makes this confusing.

I have thought this from the first time I heard that this was how things were being done. Even the bio collections occasionally have this issue (See Kianga). A title is a different kind of identification than taxonomy and probably should have metadata including who created the title and when.

We do special things with some attributes like verbatim agents, so why not create an attribute "object title" and give it a special place in the UI just above the identification?

— Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/3288#issuecomment-1293841659, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADQ7JBBJ3LJ5PS4AJ3TAQHLWFK3BLANCNFSM4USOUOUQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[dustymc]

whether the title of an artwork should even be part of identifications

Good question, we've been avoiding it forever.

Arctos handbook

... was written mostly by and for NH users and should never be viewed as gospel, even for whomever wrote it....

lack of overlap between object title and object type,

Exactly. Given a dead rat...

• it is primarily useful as a representative of rats, so it's identified as a rat
• we only really care that it's THAT PARTICULAR rat when something neat (citations, say) happens, and we get there via identifiers.

Is an art (cultural, whatever) object the same, or something else? Maybe the identification should be 'painting' (eg pure taxonomy unless there's some reason to do otherwise) and "The Mona Lisa" should be some sort of identifier? I think that was hard to see/digest when @AJLinn expanded our horizons, but it seems (sorta...) reasonable at the moment. And not that there's much directionality in it, but when someone says "in THIS discipline...." it's almost always been an indicator that SOMEONE (occasionally everyone...) is doing SOMETHING wrong.

nature of ID, which is really about taxonomy

It's a thin line, but NoID is about identification, not taxonomy - it's metadata supporting why someone hypothesizes that a THING is a member of a CONCEPT.

[krgomez]

Maybe the identification should be 'painting' (eg pure taxonomy unless there's some reason to do otherwise)

Yes, I think we should use identifications to record the object type only.

"The Mona Lisa" should be some sort of identifier?

I think it should go somewhere outside of identifications, maybe a special attribute like Teresa suggested. The title needs to have prominence in the UI. If we were cataloging a book, its title would need to be clearly known when viewing its record. The same goes for an artwork. So it doesn't work to have it buried amongst the other attributes. We also need to be able to deal with some complexity. For example, if there is more than one title recorded, we need to be able to say which is preferred.

[Jegelewicz]

I will now offer another idea - maybe we need more than one KIND of identification? One for taxonomy "painting" and one for name "Mona Lisa". One thing I got from the discussion above is that there can be more than one name for a work. Using the functionality of identifications to indicate the many names a work may have and having the ability to mark them as accepted or not also seems like something that might be good to have?

[dustymc]

more than one KIND of identification? can be more than one name for a work

Yes, but they can all be "correct" - https://github.com/ArctosDB/arctos/issues/3540

mark them as accepted

According to whom and for what purposes? That's the sort of thing that keeps leading back to identifications....

[campmlc]

Identification attributes? We have locality and event and part attributes . . Extend this to all tables?

On Thu, Oct 27, 2022, 4:02 PM dustymc @.***> wrote:

• [EXTERNAL]*

more than one KIND of identification? can be more than one name for a work

Yes, but they can all be "correct" - #3540 https://github.com/ArctosDB/arctos/issues/3540

mark them as accepted

According to whom and for what purposes? That's the sort of thing that keeps leading back to identifications....

— Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/3288#issuecomment-1294137896, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADQ7JBAD4VOKKWBRYRMQOITWFL3VNANCNFSM4USOUOUQ . You are receiving this because you commented.Message ID: @.***>

[krgomez]

What's important is that we are able to record metadata specifically for titles and that the title is prominently visible in the UI. If we are to continue to record titles in identifications, there should probably be some work done on the documentation for identifications to encompass titles in addition to taxonomy, as they are two totally different things.

I'm seeing two options:

• Making a new section within an identification for title, where we could have a separate set of metadata.
• Adding a new field called identification type (taxonomy or title), and give two identifications for every work, one for taxonomy and one for title, both of which would be accepted.

[Jegelewicz]

Adding a new field called identification type (taxonomy or title), and give two identifications for every work, one for taxonomy and one for title, both of which would be accepted.

To me, this seems the better choice. There will still be some work required, but the type of identification can mean different things get recorded. A taxonomic ID works as it always has, but a "name" ID allows for free text identification.

[dustymc]

two totally different things.

I'm still not getting it, I think because you are confounding some things, but I could be completely wrong about that (in which case none of the below probably makes any sense).

Identifications ARE NOT TAXONOMY. We know they are "two totally different things" and we've known it for a very long time; that's why they're not all in the same table.

Identifications can optionally use most any kind of taxonomy as metadata.

If that all makes sense and is related to the problem, then there's nothing to add or change. If you want to have 2 (or 86000) identifications, you can. If some or all of them don't want to link to taxonomy, they can. If they want to link to various kinds of taxonomies, that's OK too.

(https://github.com/ArctosDB/arctos/issues/3540 will let you sort them in interesting and not necessarily sequential ways, but that's a different discussion.)

Sorta unrelated but perhaps clarifying, there are surely lots of taxonomies which might be used in support of titles. A certain famous item might end up filed under "things that don't actually start with The" (lots of taxonomies are mostly nonsense...) or "paintings by Da Vinci" (taxonomists love overcomplicating simple problems!) or just 'The Mona Lisa' (circumscriptions don't need to encompass multiple individuals), but that's all sort of beside the point: if there's some taxonomy which you want to use then you can use it, and if you don't want to do that then nothing about the Arctos model forces you to.

[krgomez]

I think because you are confounding some things

It sure seems that I have not had a full understanding of identifications. I appreciate this space to discuss issues like this, and thanks for bearing with me. I get that IDs are not taxonomy, rather they are a way of applying taxonomic/classification terms, right? The conceptual problem I have had is that a title has nothing to do with what the item is classified as, but it works even if it feels awkward to me. The issue remains: we want to record metadata about A and about {string} and can't do that at this time.

there are surely lots of taxonomies which might be used in support of titles

I don't know about this. Maybe.

[Jegelewicz]

Identifications ARE NOT TAXONOMY

No they aren't, but for some reason we have it set up so that EVERY identification has to be linked to some taxonomy. This is not needed for a title in the way it is needed for a biological or object type identification.

[dustymc]

discuss

That's very much a 2-way street, thanks for your patience!

rather they are a way of applying taxonomic/classification terms, right?

Sorta, but I think because of the history of the V in "The MVZ Model" and not because they're actually linked in any reality. "It's an animal" is (impressively) LESS useful than "it's some sort of art object" - we both have a need to tie into some categorizing language, this is just the next step (in this case to an individual).

And FWIW like all things this isn't going to long be something limited to a discipline. https://arctos.database.museum/guid/MSB:Mamm:326441 is a chimp, but also a known individual with a name which has nothing to do with her biology; I think this model will be useful for that. (And for me, I just spend 20 minutes trying to find it, there's a giant wet mess of like 30 different things trying to do something beyond 'Pan troglodytes,' all unsuccessfully. I found the edge of the mess only because I know it exists, and sorta rode the whirlpool in....)

we want to record metadata about A and about {string}

And those aren't necessarily part of the same THING, right? A=painting (= https://arctos.database.museum/name/Painting) + {string}=Mona Lisa (which may or may not eventually get its own taxonomy, which may or may not exist)

I think we need to move on https://github.com/ArctosDB/arctos/issues/3540, we're not going to know if it's a complete solution without trying it (looks like it to me) and it does other things (treat local identifications equally, treat various methodology arriving at the same destination equally, etc.) which will be useful.

[Jegelewicz]

we're not going to know if it's a complete solution without trying it

I don't believe it will solve this problem because a painting may have more than one title and as far as I can tell, the art collections are still going to have to use A {string} for every identification.

[dustymc]

because a painting may have more than one title

??

still going to have to use A {string} for every identification

??

[campmlc]

See https://github.com/ArctosDB/arctos/issues/3288#issuecomment-742005680

[Jegelewicz]

@AJLinn @DellaCHall I have updated this issue in anticipation of #5331 #6171 and #6243 Review the very first comment and let me know if anything doesn't make sense or if anything needs to be adjusted.

Thanks!

[Jegelewicz]

We now have variably ranked acceptableness of identifications. Can we get something useful for our cultural collections here?

The issue remains: we want to record metadata about A and about {string} and can't do that at this time.

Does the revamped request in the first comment accomplish this and is it acceptable? @AJLinn @DellaCHall @wellerjes @droberts49 @brandon-s-thompson

[DellaCHall]

Yes, that looks like it will work! Thanks.

[dustymc]

I can't make sense of the inital comment. Are you asking for a new categorical attribute type? The values in that table all look like methods/determiners, with a fair bit of overlap with https://arctos.database.museum/info/ctDocumentation.cfm?table=ctnature_of_id?!?

Perhaps it would be useful to close this and open a blank-slate Issue that's not all tangled up in a model which no longer exists? (I think that's part of where I'm getting lost.)

[Jegelewicz]

If I opened a new issue, I would copy the first comment and paste it there.

[dustymc]

same as https://arctos.database.museum/info/ctDocumentation.cfm?table=ctattribute_type#object_title

[Jegelewicz]

@ArctosDB/arctos-code-table-administrators yesterday agree this is "nature of ID" but that makes no sense for cultural collections. It was suggested that nature of ID be changed to identification basis, but we need input from cultural collections to make a good decision. This issue will be placed on the cultural collections meeting agenda.