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 - Indigenous Term Attribute #4805

Closed
sjshirar opened this issue Jul 6, 2022 · 18 comments
Closed

Code Table Request - Indigenous Term Attribute #4805

sjshirar opened this issue Jul 6, 2022 · 18 comments
Assignees
Labels
Accessibility Issue is related to Arctos accessibility. Function-CodeTables Priority-High (Needed for work) High because this is causing a delay in important collection work..

Comments

@sjshirar
Copy link

sjshirar commented Jul 6, 2022

@AJLinn @camwebb

I believe all the needed info is here but please let me know if I missed anything.

Goal
As part of a grant project through the UA Museum archaeology department we are correlating object names and material types with their Inupiaq language counterpart. As part of this project we also want to find a spot within Arctos catalog records to preserve this information. We would like to make this an option as an attribute to provide a place to record all the metadata associated with each native language term such as who made the determination, when it was made, and what method was used.

Context
There is no existing attribute to input native language terms for objects and material types.

Table
This attribute can use the same code table as ctculture: https://arctos.database.museum/info/ctDocumentation.cfm?table=ctculture

Proposed Value
Indigenous Term

Proposed Definition
Indigenous language term for a given object and/or material type.

Collection type
Arc, Art, EH

Attribute data type
Free-text

Attribute value
https://arctos.database.museum/info/ctDocumentation.cfm?table=ctculture

Attribute units
None

Available for Public View
Yes

Other ID BaseURL
None

ID_References
None

Priority
Normal

@Jegelewicz
Copy link
Member

This attribute can use the same code table as ctculture

But you are proposing a free text attribute?

Attribute data type
Free-text

So there will be no code table. BUT I can see how you would want to use the culture terms to relate whatever is in this value to a language or culture.

However, this seems more complicated than that?

correlating object names and material types with their Inupiaq language counterpart.

By object names, do you mean taxa or (A of the A {string}) or specific names ({string} of the A {string})? If taxa - add a common name (but I think we need to talk about adding a language to our common names). If the specific name, add an identification using the Inupiaq term in the string and provide the language in identification remark (eventually we might need to talk about tying string in identification to a language as well, and we will definitely need to discuss allowing more than one accepted identification).

By material types, do you mean the materials attribute? Again, couldn't you just use this attribute, but make the value the indigenous term (it is a free text attribute) and add the language in the attribute remark?

I guess I don't see where adding:

attribute_1 attribute_value_1 attribute_units_1 attribute_remarks_1 attribute_date_1 attribute_det_meth_1 attribute_determiner_1
Indigenous Term nanuq Inupiaq 2022-06-06 https://uaf.edu/anlc/languages/inupiaq.php jegelewicz

to every catalog record that is about or has a reference to polar bear would be super useful - especially once someone accidentally adds this

attribute_1 attribute_value_1 attribute_units_1 attribute_remarks_1 attribute_date_1 attribute_det_meth_1 attribute_determiner_1
Indigenous Term nanuq Iñupiaq 2022-06-06 https://uaf.edu/anlc/languages/inupiaq.php jegelewicz

If using this attribute does feel right to you guys, then how about making the ctculture table the units for this? Then at least you would have

attribute_1 attribute_value_1 attribute_units_1 attribute_remarks_1 attribute_date_1 attribute_det_meth_1 attribute_determiner_1
Indigenous Term nanuq Iñupiaq 2022-06-06 https://uaf.edu/anlc/languages/inupiaq.php jegelewicz

Still - that doesn't in any way let me know how this term relates to the stuff in the catalog record. Is it the taxon, the material or both - or heck, maybe it is the indigenous name for the place of collection!

This is a complicated thing - translations, I think we need to make sure you get what you need, but also that we are thinking ahead to other possible uses.

@Jegelewicz Jegelewicz added Accessibility Issue is related to Arctos accessibility. Priority-Normal (Not urgent) Normal because this needs to get done but not immediately. labels Jul 6, 2022
@Jegelewicz Jegelewicz added this to the Needs Discussion milestone Jul 6, 2022
@sjshirar
Copy link
Author

sjshirar commented Jul 6, 2022 via email

@AJLinn
Copy link

AJLinn commented Jul 6, 2022

Here was my suggestion to Scott when we initially discussed it as an attribute:

Value: Indigenous term (free text)
Unit: code table culture
Remarks: Description/definition of what the word means
Det. Date: date word provided to museum
Det. Meth: add how you got the word, including things like dictionary search, linguist provided, Indigenous language speaker, other publication source, etc.
Determiner: agent who provided you the name (person, organization, author of publication, etc.

@AJLinn
Copy link

AJLinn commented Jul 6, 2022

And to reiterate, this would be a further explanation of the term that is entered into the A {string} identification, where I've been using the English Term / Indigenous Term, and then using the Nomenclature designation for the taxonomy.

Screen Shot 2022-07-06 at 3 05 53 PM

https://arctos.database.museum/guid/UAM:EH:UA70-307-0001
Screen Shot 2022-07-06 at 3 07 33 PM

@dustymc
Copy link
Contributor

dustymc commented Jul 18, 2022

Value: Indigenous term (free text)
Unit: code table culture

That would require significant changes; currently all unit-having Attributes are required to be numeric.

I don't think I quite fully understand what's going on here, but would this be better implemented as #3540, which would allow two (or more) equally-accepted identifications (in two languages, but that's not the only use case)? That would structurally keep the metadata associated with the correct data object; I don't believe this request does.

@AJLinn
Copy link

AJLinn commented Jul 18, 2022

That would require significant changes; currently all unit-having Attributes are required to be numeric.

Is there something linked between the two that requires a numerical figure in the value field or just the way we do things?

I'd like to include this on our next issues meeting (2022-08-10), assuming @sjshirar can attend, so we can discuss what the problems are with the attribute approach vs the identification. Where would the culture code table be included so we have a consistency entering the name of the language used for the ID? Would all the other information get put into the remarks field or would we create new values or fields for nature of ID, source (often not a published source), definition of the term, etc.?

I'm not totally opposed to the ID, assuming we can make more than one acceptable, but prioritize which shows up in the search results? I think it will help clarify the problems/advantages if we discuss.

@dustymc
Copy link
Contributor

dustymc commented Jul 18, 2022

something linked

Yes, the datatype comes from the link itself. I don't think changing that would be an insurmountable obstacle, but I'm not sure we have valid reasons to attempt the crossing yet either. #3452 should be involved if we decide to refactor something this fundamental.

culture code table be included so we have a consistency entering the name of the language

I'm not sure those are the same. (I'm not sure they're not either, but I think that needs a hard look before being accepted as fact.)

name of the language

Something like https://glottolog.org/ seems useful - no reason to reinvent any wheels if we can just use someone else's. (That said, that still doesn't include the language my family speaks at home so maybe it's just not useful.)

prioritize which shows up in the search results?

Yes, that's a constant problem - we NEED complex data, but we refuse to deal with UI in which complex data can exist (or something, I'm not sure). Finding some sort of bigger-than-this solution would be fabulous.

@AJLinn
Copy link

AJLinn commented Jul 18, 2022

Something like https://glottolog.org/ seems useful - no reason to reinvent any wheels if we can just use someone else's. (That said, that still doesn't include the language my family speaks at home so maybe it's just not useful.)

This resource is totally inaccurate for Alaska Native languages and therefore not a useful tool for us at this time.

culture code table be included so we have a consistency entering the name of the language

I'm not sure those are the same. (I'm not sure they're not either, but I think that needs a hard look before being accepted as fact.)

In Alaska they mostly are. I can't speak for outside of Alaska. See Alaska Native Language Center for the authority in AK:
https://uaf.edu/anlc/languages-move/languages.php

@sjshirar
Copy link
Author

sjshirar commented Jul 20, 2022 via email

@Jegelewicz Jegelewicz added Priority-High (Needed for work) High because this is causing a delay in important collection work.. and removed Priority-Normal (Not urgent) Normal because this needs to get done but not immediately. labels Jul 20, 2022
@Jegelewicz
Copy link
Member

Jegelewicz commented Aug 18, 2022

Value: Indigenous term (free text)
Unit: code table culture

That would require significant changes; currently all unit-having Attributes are required to be numeric.

This is the same problem we are having with verbatim agent #4934 . Maybe attributes need another field so that a free text attribute can have a coded qualifier? OR can we drop the "all unit-having Attributes are required to be numeric" requirement? Why is that a requirement anyway?

@sjshirar
Copy link
Author

sjshirar commented Oct 11, 2022 via email

@dustymc
Copy link
Contributor

dustymc commented Nov 2, 2022

I'm about 99% sure this is solved - eloquently, with all the bits having full metadata and not reinforcing bits to which they're not linked and etc. - by #3540.

@dustymc
Copy link
Contributor

dustymc commented Jan 5, 2023

Duplicate of #4779

@dustymc dustymc marked this as a duplicate of #4779 Jan 5, 2023
@dustymc dustymc closed this as completed Jan 5, 2023
@Jegelewicz
Copy link
Member

AWG approved - please add

@Jegelewicz Jegelewicz reopened this Jan 5, 2023
@Jegelewicz
Copy link
Member

@AJLinn @sjshirar I was just about to add this, but would it be OK for me to use indigenous term instead of Indigenous Term to be consistent with the way other attributes are capitalized?

@AJLinn
Copy link

AJLinn commented Jan 6, 2023

Indigenous is a proper noun when referring to people, so should be capitalized, but you could do Indigenous term.
Thanks!

@Jegelewicz
Copy link
Member

Added. It will probably take an hour or so before you can see/use it.

@Jegelewicz Jegelewicz removed this from the Needs Discussion milestone Jan 6, 2023
@sjshirar
Copy link
Author

sjshirar commented Jan 6, 2023 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Accessibility Issue is related to Arctos accessibility. Function-CodeTables 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

5 participants