Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
4 tasks
Jegelewicz opened this issue Dec 8, 2020 · 38 comments
Assignees
Labels
Collection Type - Cultural Collections Art, Ethnography, etc collection related Function-CodeTables Function-Taxonomy/Identification Priority-High (Needed for work) High because this is causing a delay in important collection work..

Comments

@Jegelewicz
Copy link
Member

Jegelewicz commented Dec 8, 2020

Issue Documentation is https://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.
@Jegelewicz Jegelewicz added Priority-High (Needed for work) High because this is causing a delay in important collection work.. Function-Taxonomy/Identification Function-CodeTables Collection Type - Cultural Collections Art, Ethnography, etc collection related labels Dec 8, 2020
@Jegelewicz Jegelewicz added this to the Needs Discussion milestone Dec 8, 2020
@dustymc
Copy link
Contributor

dustymc commented Dec 8, 2020

"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
Copy link
Member Author

requesting a new identification field

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

@Jegelewicz
Copy link
Member Author

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

@marecaguthrie
Copy link

marecaguthrie commented Dec 9, 2020 via email

@dustymc
Copy link
Contributor

dustymc commented Dec 18, 2020

@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 dustymc modified the milestones: Needs Discussion, Tabled Feb 16, 2022
@dustymc
Copy link
Contributor

dustymc commented Feb 16, 2022

Abandoned?

@dustymc dustymc closed this as completed Feb 16, 2022
@krgomez krgomez reopened this Oct 23, 2022
@krgomez
Copy link

krgomez commented Oct 23, 2022

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
Copy link

AJLinn commented Oct 23, 2022

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
Copy link
Contributor

dustymc commented Oct 24, 2022

#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), #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
Copy link

krgomez commented Oct 24, 2022

#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), #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
Copy link
Contributor

dustymc commented Oct 24, 2022

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
Copy link

krgomez commented Oct 24, 2022

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
Copy link

krgomez commented Oct 27, 2022

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
Copy link
Member Author

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
Copy link

campmlc commented Oct 27, 2022 via email

@dustymc
Copy link
Contributor

dustymc commented Oct 27, 2022

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
Copy link

krgomez commented Oct 27, 2022

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
Copy link
Member Author

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?

@Jegelewicz
Copy link
Member Author

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
Copy link
Contributor

dustymc commented Nov 2, 2022

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 #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
Copy link
Member Author

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
Copy link
Contributor

dustymc commented Nov 2, 2022

because a painting may have more than one title

??

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

??

@campmlc
Copy link

campmlc commented Nov 2, 2022

See #3288 (comment)

@Jegelewicz Jegelewicz changed the title Code Table Request - Additions to nature of ID code table for art collections Code Table Request - New identification attribute "title type" (was Additions to nature of ID code table for art collections) May 10, 2023
@Jegelewicz Jegelewicz modified the milestones: Tabled, Needs Discussion May 10, 2023
@Jegelewicz
Copy link
Member Author

@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
Copy link
Member Author

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
Copy link

Yes, that looks like it will work! Thanks.

@dustymc
Copy link
Contributor

dustymc commented Jun 7, 2024

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
Copy link
Member Author

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

@dustymc
Copy link
Contributor

dustymc commented Jun 20, 2024

@Jegelewicz
Copy link
Member Author

@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.

@DellaCHall
Copy link

The Cultural Collections Working Group discussed this today and unanimously agreed that Nature of Identification is appropriate, and that we'd like the above listed terms and definitions added to the code table (I think this might have been what was originally proposed?):

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

Tagging Cultural Collections Working Group Members @AJLinn @droberts49 @wellerjes @mkoo @brandon-s-thompson @sjshirar @Jegelewicz

@Jegelewicz
Copy link
Member Author

I have submitted issues for the new terms. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Collection Type - Cultural Collections Art, Ethnography, etc collection related Function-CodeTables Function-Taxonomy/Identification Priority-High (Needed for work) High because this is causing a delay in important collection work..
Projects
None yet
Development

No branches or pull requests

10 participants