Code Table Request - New identification attribute "title type" (was Additions to nature of ID code table for art collections) #3288
Comments
Jegelewicz
added
Priority-High (Needed for work)
|
"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.
Can you elaborate on "requesting a new identification field"? Might be something interesting in there.... |
@krgomez first asked for a new field in ID metadata = title type. |
|
@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 |
|
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 < ***@***.***> 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
<#3288 (comment)>,
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.*
|
|
@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. |
|
Abandoned? |
|
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. |
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. |
|
#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, Neither require gaming any data, so are better solutions than trying to wedge something that still doesn't look like nature in with nature. |
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 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. |
Yes, exactly - and, unlike now, you could treat them as equals.
I still cannot see how that could be a defensible approach.
As attributes of an identification you could record any number of any type, whatever those turn out to be.
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. |
I see. That makes sense now.
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?
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.
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. |
|
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? |
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? |
|
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
<#3288 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADQ7JBBJ3LJ5PS4AJ3TAQHLWFK3BLANCNFSM4USOUOUQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Good question, we've been avoiding it forever.
... was written mostly by and for NH users and should never be viewed as gospel, even for whomever wrote it....
Exactly. Given a dead rat...
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.
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. |
Yes, I think we should use identifications to record the object type only.
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. |
|
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? |
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. |
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. (#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. |
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.
I don't know about this. Maybe. |
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. |
That's very much a 2-way street, thanks for your patience!
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....)
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. |
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. |
??
?? |
|
See #3288 (comment) |
Jegelewicz
changed the title
|
@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! |
|
We now have variably ranked acceptableness of identifications. Can we get something useful for our cultural collections here?
Does the revamped request in the first comment accomplish this and is it acceptable? @AJLinn @DellaCHall @wellerjes @droberts49 @brandon-s-thompson |
|
Yes, that looks like it will work! Thanks. |
|
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.) |
|
If I opened a new issue, I would copy the first comment and paste it there. |
|
@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. |
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_idctidentification_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:
These are the values UAM Art would like added:
Definition
titletitletitletitletitletitle(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).
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.
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.
The text was updated successfully, but these errors were encountered: