arctos 🚀 - Nomenclature 4.0 for Man-Made Items

Added to AWG Agenda. I see no reason why you couldn't work with Dusty to at least find out if a collaboration is possible! This would be really awesome...

Jegelewicz on 10 Oct 2018

I see two obstacles here:

1) The names don't look like Linnean taxonomy. "Ball, Nesting" will not pass our current checks. There are a LOT of attempts to insert garbage (identifications, stuff that contains authors, just weird random non-standard ways of saying things we already say in predictable ways), and the checks prevent most of them. Opening up taxon names to more formats is going to require better human data quality control (eg, training) on our end. https://github.com/ArctosDB/arctos/issues/745.

2) The classification loader requires term-type as column headers, just so people can deal with spreadsheets. We'll need a new hierarchical loader if we pull these data locally, and that also has the potential to introduce low-quality data.

As always, my preference is to do this through GlobalNames. That would, assuming the data are something you can manage a collection with, completely negate (2) above - the classification data would just appear in Arctos. It might provide a pathway around (1) as well. I have no idea if that's possible, but I can't see any technical barriers from here.

In any case, the Arctos model was built in anticipation of data like these and they will fit. Some test data would be incredibly useful, and I should be able to work with most any format for that.

dustymc on 10 Oct 2018

http://id.loc.gov/vocabulary/genreFormSchemes/nmc.html
@dustymc This isn't a link to the nomenclature is it? I'm about to write to the Nomenclature people and this came up in my google search...

AJLinn on 12 Dec 2018

I think that's just the publication itself.

dustymc on 12 Dec 2018

Okay - I'm cc-ing you on the email to the CHIN folks right now. You should get the message soon.

AJLinn on 12 Dec 2018

👍1

OK, I have some demo data, it's no problem to unroll JSON-LD, and the core data seem to be a simple hierarchy. So questions:

Most important I think, # 1 up ^there:

The names don't look like Linnean taxonomy. "Ball, Nesting" will not pass our current checks. There are a LOT of attempts to insert garbage (identifications, stuff that contains authors, just weird random non-standard ways of saying things we already say in predictable ways), and the checks prevent most of them. Opening up taxon names to more formats is going to require better human data quality control (eg, training) on our end. #745.

There's a steady stream of users trying to introduce taxon names which are rejected by https://github.com/ArctosDB/DDL/blob/master/functions/isValidTaxonName.sql. I think this is a compelling reason to relax the formatting rules. Can we somehow address that conflict? Maybe revoke taxonomy from everyone and deal with new names via Issue while we work on a solution?

Second, do we want to make some attempt to treat these as the linked data they purport to be, or do we just want the hierarchy? FWIW I have not found a functional link yet. (And maybe licensing will dictate an answer?)

There are (sometimes) multiple formats in English. I flip-flop back and forth on which one I like....

UAM@ARCTOS> select e_trm,alt_trm,f_trm from temp_c_t where rownum<10;

E_TRM
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
ALT_TRM
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
F_TRM
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sugar Refinery
Refinery, Sugar
Raffinerie de sucre

Pottery

Poterie

Tannery

Tannerie

Industrial Mine
Mine, Industrial
Mine industrielle

Pumphouse

Station de pompage

Quarry

Carrière

Workshop

Atelier

Cabinetmaking Shop
Shop, Cabinetmaking
Atelier d'ébénisterie

Dressed Stone
Stone, Dressed
Pierre façonnée

whichever one is not made into taxonomy (and any other alternatives) can serve as common names, I think - better ideas appreciated.

I think (if licensing allows??) we should clean some of this up. Eg, the root node is "Category 01: Built Environment Objects" and I see no reason we'd care about the "Category 01:" bit. There's similar - stuff that looks like remarks and administrative data - scattered around in the terms (but not too much).

Here are the data as a hierarchy:

temp_c_t.csv.zip

Here's "hierarchical strings:"

demo.txt

And the original:

pp_subtree_category01builtenvironmentobjects.jsonld.zip

dustymc on 8 Feb 2019

whichever one is not made into taxonomy (and any other alternatives) can serve as common names, I think - better ideas appreciated.

synonyms?

Jegelewicz on 8 Feb 2019

There's a steady stream of users trying to introduce taxon names which are rejected by https://github.com/ArctosDB/DDL/blob/master/functions/isValidTaxonName.sql. I think this is a compelling reason to relax the formatting rules. Can we somehow address that conflict? Maybe revoke taxonomy from everyone and deal with new names via Issue while we work on a solution?

Wait, do you think it is a compelling reason to relax the rules or NOT relax them? It might not be a bad idea for taxonomy to pass through a committee. There is so much junk in there already and clean-up after the fact always takes longer than doing it right the first time. However, I could see that becoming an obstacle to data entry unless the committee was VERY responsive. As a short term measure, it might help us focus on taxonomy and the #1852 issue. I am a huge fan of incorporating Nomenclature 4.0. I'll help in any way I can!

How many people are actively adding names today (over the last few weeks)? I don't know if taking away the easy add will really disrupt anyon'e work or not...

Jegelewicz on 8 Feb 2019

synonyms

That crossed my mind as well, but it's weird. We are absolutely stuck with having 30 ways to say "red-backed vole" and when one of them is used we may be forced to use it in identifications - eg, for type material. That spawns a whole bunch of complexity involving relationships, taxon status, preferred name, etc. If we can avoid the situation of having three identical items wearing three non-identical taxon names, I think we should. @AJLinn is it correct to assume that "Mine, Industrial," "Industrial Mine," and "Mine industrielle" are wholly interchangeable, or are they more like Myodes/Clethrionomys (where there's a "correct" way to say "red-backed vole" and a century or so of "Obscure Taxonomy Rule Number 67 requires us to use THAT one" back and forth has been trying to find it)?

"Linnean" taxonomy is also different in that it's standardized around a language - the cultural nomenclature does not seem to share that, and I REALLY don't want to contemplate the possibility of repeating all of the above for every language that anyone might ever care about - there are literally thousands of ways of saying "Industrial Mine!"

We COULD have three classifications...

taxon_name: Industrial Mine
classifications:

/Category 01: Built Environment Objects/Structures/Industrial Structures/Industrial Mine
////Mine, Industrial
/Catégorie 01 : Objets de l’environnement bâti/Constructions/Constructions industrielles/Mine industrielle

dustymc on 8 Feb 2019

to relax the rules or NOT relax them

yes....

Avoiding the garbage is a compelling reason to keep the rules.

Allowing non-Linnean taxonomies is a compelling reason to revise the rules.

I think we have to allow the cultural need to win, but I don't want to give up the fight of having a source of "pure" taxonomy, unpolluted by identification terms and arbitrary formatting and all the other stuff the rules stop.

https://github.com/ArctosDB/arctos/issues/1852 isn't completely related - it still needs clean names. (I don't really care what ya'll type in classifications - although you should!)

actively adding names

UAM@ARCTOS> select getPreferredAgentName(CREATED_BY_AGENT_ID) ||  ' @ ' || count(*) from taxon_name where CREATED_DATE>sysdate-30 group by getPreferredAgentName(CREATED_BY_AGENT_ID) order by getPreferredAgentName(CREATED_BY_AGENT_ID);

GETPREFERREDAGENTNAME(CREATED_BY_AGENT_ID)||'@'||COUNT(*)
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Anna Chinn @ 18
Carol L. Spencer @ 1
Carolyn L. Parker @ 1
Christopher J. Conroy @ 1
Derek S. Sikes @ 13
Dustin Perriguey @ 14
James L. Patton @ 4
Katherine L. Anderson @ 2
Mariel L. Campbell @ 4
Mingna Zhuang @ 17
Phyllis Sharp @ 56
Sara V. Brant @ 1
Teresa J. Mayfield-Meyer @ 339
unknown @ 3601

14 rows selected.

The "unknown" are my scripts making names from WoRMS - about ~30% of those attempts are stopped by the rules.

dustymc on 8 Feb 2019

HAHAHAHA! So, I would be the one complaining that I couldn't add a name...

It seems like we could create a fairly small group of people authorized to create names who must pinky promise to "keep to the code" as it goes in Pirates of the Caribbean...and still keep everyone happy? Breaking the code means getting thrown overboard?

Jegelewicz on 8 Feb 2019

"Linnean" taxonomy is also different in that it's standardized around a language - the cultural nomenclature does not seem to share that, and I REALLY don't want to contemplate the possibility of repeating all of the above for every language that anyone might ever care about - there are literally thousands of ways of saying "Industrial Mine!"

We COULD have three classifications...

taxon_name: Industrial Mine
classifications:

/Category 01: Built Environment Objects/Structures/Industrial Structures/Industrial Mine
////Mine, Industrial
/Catégorie 01 : Objets de l’environnement bâti/Constructions/Constructions industrielles/Mine industrielle

That seems like it would work until some incoming collection prefers to see "Mine, Industrial" as the identification on their object....Although maybe that isn't a problem.

While I hear you on the thousands of ways, apparently there are only 3 according to Nomenclature 4.0? If we are sticking to that as a data quality standard, then perhaps the synonyms would work?

Jegelewicz on 8 Feb 2019

@AJLinn is it correct to assume that "Mine, Industrial," "Industrial Mine," and "Mine industrielle" are wholly interchangeable

I'm not sure... in principle, I've always learned, and taught, that the "proper" way is the "General, Specific" in naming. This allows these general terms to be our sorting mechanism when we have our search results. But maybe we don't have to worry about it?

some incoming collection prefers to see "Mine, Industrial" as the identification on their object..

This _will_ be what they prefer if they're using Nomenclature 4.0.

FWIW, the French version of everything in there is because this is coming from CHIN, which is Canadian and therefore must have English and French for all official governmental products. We would not be held to the same requirements.

I'm not totally sure if I can provide any help on how the Nomenclature 4.0 fits or breaks taxonomy rules. I can just show you how it looks in the book version, which is what we've all been trained to use:

AJLinn on 8 Feb 2019

pinky promise

Yea, that might be all we can do.

I don't think there are any Codes at all for cultural stuff - it's standardization, that's it, the crazy rules imposed by the various Codes just don't seem to exist. AFAIK an Arabic translation could be considered "valid" where google translating Myodes to Arabic would not be "taxonomy" according to anyone (although it would be valuable in finding specimens).

I only found 3 terms in these data, but their structure is set up to support any number of "alternates". The no-comma English version is "the data" and the rest are structured as metadata - I'm not sure if that's some sort of assertion or just arbitrary organization.

dustymc on 8 Feb 2019

some incoming collection prefers to see "Mine, Industrial" as the identification on their object..

This _will_ be what they prefer if they're using Nomenclature 4.0.

Based upon my limited knowledge of this, I agree with Angie - those using the Nomenclature 4.0 will use the comma separated terms and that is what we should put into Arctos as names. For the time being, I think we could use those names with their related classification hierarchies and then see if anyone complains and wants the French or some other version.

We do need to get buy in from the community to limit addition of names though...

Jegelewicz on 8 Feb 2019

👍1

small group of people authorized to create names

https://github.com/ArctosDB/arctos/issues/745

I advocate limiting "authorities" to people who are actively involved in the AWG and willing to read the notification emails, or something of the sort. That's probably best addressed in another Issue?

    ACDOLL (OPEN)
    ACHINN (OPEN)
    ACOTTER (OPEN)
    AECARRIER (LOCKED)
    AEROCHILD (OPEN)
    AKLECKNER (OPEN)
    ALANBATTEN (OPEN)
    ANDRES_LOPEZ (OPEN)
    AREN (OPEN)
    ARGASTALDI (OPEN)
    ATROX (OPEN)
    BJOHNSON_DMNS (OPEN)
    CAMPMLC (OPEN)
    CARLSLIEB (OPEN)
    CAROLYN (OPEN)
    CCICERO (OPEN)
    CDARDIA (LOCKED)
    CEMYERS (LOCKED)
    CMCCORD (OPEN)
    DEMBOSKI (OPEN)
    DLM (OPEN)
    DPERRIGUEY (OPEN)
    DROBERTS (OPEN)
    EBRAKER (OPEN)
    EJBROCK (OPEN)
    EKRIMMEL (OPEN)
    FFDSS (OPEN)
    FRIEL (LOCKED)
    GARTHSPELLMAN (OPEN)
    GORDON (LOCKED)
    HKBERRIOS (OPEN)
    JBWILLIAMSON (OPEN)
    JEGELEWICZ (OPEN)
    JEMA9330 (OPEN)
    JLDUNNUM (OPEN)
    JLUNDQUI (OPEN)
    JMALANEY_1 (LOCKED)
    JMALEY1 (OPEN)
    JMETZGAR (LOCKED)
    JOSECOOK (LOCKED)
    JTGIERMAK (OPEN)
    JULIANCHAVEZ449 (OPEN)
    KATHERINELANDERSON (OPEN)
    KMDALY (OPEN)
    LAM (OPEN)
    LBROSKEY (LOCKED)
    LJMULLEN2 (OPEN)
    LORRICO (OPEN)
    MAKAYLAMQZ (OPEN)
    MBOWSER (OPEN)
    MBPRONDZINSKI (OPEN)
    MJANDERSEN (OPEN)
    MKOO (OPEN)
    MLMOODY (LOCKED)
    MPORTALA (OPEN)
    OPHIS (OPEN)
    PATTON (OPEN)
    PDRUCKEN (LOCKED)
    RROVELLI (LOCKED)
    SARA (OPEN)
    SHARPPHYL (OPEN)
    SKANIE (LOCKED)
    STEFFI (OPEN)
    TIMO_SP (LOCKED)
    VOLEGUY (OPEN)
    VTHILL (OPEN)

dustymc on 20 Feb 2019

small group of people authorized to create names

745

I advocate limiting "authorities" to people who are actively involved in the AWG and willing to read the notification emails, or something of the sort. That's probably best addressed in another Issue?

I agree. This new taxonomy (Nomenclature) is sure to get sticky. The community that manages the print copy (https://aaslh.org/resources/affinity-communities/nomenclature/) helps to determine when new names are able to be added, much of that is regionally-based. It would be good for us to have a sort of sub-group of the taxonomy committee perhaps, who are able to act in this capacity for Arctos. I would certainly like to be one of those people.

AJLinn on 20 Feb 2019

The community that manages the print copy (https://aaslh.org/resources/affinity-communities/nomenclature/) helps to determine when new names are able to be added

The current restrictions are enforced by a trigger on INSERT. We shouldn't drop sorting out who has access to scary things in general, but if updates to this are published I could, at least as a workaround until we figure something better out, lock the table, disable the trigger, and insert. That won't work for normal users so if there's any need to insert terms one at a time it's probably not worth pursuing.

Can that community also definitively answer our "what's data and what's metadata?" question? These data are structured such that Industrial Mine should be "data" but it looks like the book and tradition would use Mine, Industrial.

dustymc on 20 Feb 2019

I agree with this as well- The taxonomy committee or a subgroup to be
responsible for adding names, with representatives of each collection type?
Also agree with following the nomenclatural standard of "Mine,Industrial".
This is what we are trying to do with part names as well, for similar
reasons.

On Wed, Feb 20, 2019 at 9:12 AM Angela Linn notifications@github.com
wrote:

small group of people authorized to create names

745 https://github.com/ArctosDB/arctos/issues/745

I advocate limiting "authorities" to people who are actively involved in
the AWG and willing to read the notification emails, or something of the
sort. That's probably best addressed in another Issue?

I agree. This new taxonomy (Nomenclature) is sure to get sticky. The
community that manages the print copy (
https://aaslh.org/resources/affinity-communities/nomenclature/) helps to
determine when new names are able to be added, much of that is
regionally-based. It would be good for us to have a sort of sub-group of
the taxonomy committee perhaps, who are able to act in this capacity for
Arctos. I would certainly like to be one of those people.

—
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/1732#issuecomment-465644574,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AOH0hKdpW2mIO0Gl6Us6gzsnGbfMflXDks5vPXPWgaJpZM4XV_Hg
.

campmlc on 20 Feb 2019

following the nomenclatural standard of "Mine,Industrial".

That is NOT the standard according to the data they provided - that's the problem. Their data are structured such that Industrial Mine must exist and Mine, Industrial is but one of zero-or-more alternatives. If they publish "Some New Thing" in the next version, there's no reason it has to be accompanied by a "New Thing, Some" version.

Parts are arbitrary - nobody's doing anything useful so we're forced to do our own thing. This is not; the whole point of this is to embrace a "standard" so we can talk to other resources and all that jazz. For that to work, we (users of these data) all need to be on the same page.

dustymc on 20 Feb 2019

That is NOT the standard according to the data they provided - that's the problem. Their data are structured such that Industrial Mine must exist and Mine, Industrial is but one of zero-or-more alternatives. If they publish "Some New Thing" in the next version, there's no reason it has to be accompanied by a "New Thing, Some" version.

Let me reach out to the Nomenclature folks (both the Canadians doing the electronic version and the AASLH who manage the print version) and see i we can figure out what's going on with the order of things.

AJLinn on 20 Feb 2019

👍1

but if updates to this are published I could, at least as a workaround until we figure something better out, lock the table, disable the trigger, and insert. That won't work for normal users so if there's any need to insert terms one at a time it's probably not worth pursuing.

Once we get this figured out and are ready to add the taxonomy, @ArctosDB/taxonomy recommends relaxing the name rules for import of Nomenclature 4.0, then reinstating restrictions. If there are a lot of requests for new man-made item names, we can re-visit.

Jegelewicz on 21 Feb 2019

@AJLinn any news?

Jegelewicz on 15 Mar 2019

From Heather at PCH:

Nomenclature and other standards (like the Getty’s Art & Architecture Thesaurus) have adopted “natural” order (e.g. Rocking Chair) as their preferred form - but both these standards include the “Inverted” order as an alternate (but equally valid) form of the term, whenever the term consists of two or more words. We don’t populate the “Inverted” order field when the term consists of only one word, just to avoid data redundancy and to reduce risk of editorial errors. So although natural order is “preferred” (we had to pick a preferred form), the inverted order is just as valid as an “alternate” for multi-word terms. So museums can use either one. Both orders will always stay in Nomenclature – to ensure that whatever order museums are using, their concept can be found in Nomenclature. Any new multi-word terms that are added to Nomenclature will always also have their inverted version added as an alternate.

"We don’t populate the “Inverted” order field when the term consists of only one word" is sufficient reason to treat the "natural" order as the name - to follow the structure of their data.

dustymc on 10 Apr 2019

Using "natural order" can we proceed to set up a taxonomy source in Arctos?

Jegelewicz on 11 Apr 2019

Technically, yea sure no problem.

Legally - @AJLinn ?? I think that probably falls under "testing" but ??

dustymc on 11 Apr 2019

Yeah, I don't think we can implement fully until we get the complete nomenclature from CHIN when it's released in January 2020 under the Open Data Commons license. If we want it now it will cost $150 to buy the license from Rowman & Littlefield (the publishers of the last update in hard copy).

AJLinn on 12 Apr 2019

released in January 2020 under the Open Data Commons license. If we want it now it will cost $150 to buy the license from Rowman & Littlefield (the publishers of the last update in hard copy).

Seems like we will have to wait because I'm not sure the $150 would cover the fact that we would be making the entire thing public in our taxonomy tables...?

Jegelewicz on 13 Apr 2019

/remind @ArctosDB/taxonomy to review January 01, 2020

Jegelewicz on 14 Apr 2019

@Jegelewicz set a reminder for Jan 1st 2020

reminders[bot] on 14 Apr 2019

Not sure of the best practice for linking between issues but just wanted to make a note that I'd like to consider the open source data for Getty Vocabularies (http://www.getty.edu/research/tools/vocabularies/lod/index.html) in this discussion as well because the Nomenclature 4.0 isn't a great fit for art collections and Dusty has commented that our current "taxon" structure for categorizing our objects is leading to difficulties with searches.

marecaguthrie on 24 Apr 2019

:wave: @ArctosDB/taxonomy, review

reminders[bot] on 1 Jan 2020

Nomenclature has been officially released as free open data:
https://aaslh.org/open-data-nomenclature/
https://app.pch.gc.ca/sgc-cms/nouvelles-news/anglais-english/?p=10515
https://www.nomenclature.info/

AJLinn on 19 Jan 2020

@dustymc could we download this and get it going before PG? We will be looking at something similar for art collections using the Getty AAT eventually (although that one will probably be more of a "WoRMS via Arctos" situation). I envision this as a new taxonomy source, but we will also need some new classification taxon terms and I'd like to think about how to keep them organized so that they don't get mixed up in the biological taxonomy classification terms. We could name them all starting with N4.0?

From https://www.nomenclature.info/mode_d_emploi-user_guide.app?lang=en#H2.2

N4.0 Category
N4.0 Class
N4.0 Sub-class
N4.0 Primary object term
N4.0 Secondary object term
N4.0 Tertiary object term

Jegelewicz on 20 Jan 2020

Strong "not unless it's literally on fire" vote from me, but ya'll are driving...

There will be some structural changes required (particularly if we're creating terms with periods in them), that would be difficult at this point, and I'm looking at a whole bunch of "we've outgrown everything" issues from the weekend; I suggest PG remain the priority.

dustymc on 21 Jan 2020

I'm totally fine with that, given the workload implementation will take on many.

I think I'd like to prepare a grant proposal for trial implementation in the UAM:EH and UAM:Arc collections, given that it doesn't work so much for the UAM:Art collections. I'll look to see what funding sources might be best for this and then work with @dustymc and @Jegelewicz re: the Arctos integration back-side of things vs the operator-side of things. I'd like to be sure we have $$ to put to someone on the back end who will be asking the right questions for integration into the taxonomy part of Arctos, which i have ZERO knowledge of or experience in using. That would give us time to migrate to PG before worrying about N4.0 integration. Okay with you-all?

AJLinn on 21 Jan 2020

I'm OK if you are, but also I am thinking about potential new collections who would be impacted by this. If we had a working taxonomy for art and ethnology collections we would have a much more powerful argument for it's usefulness in museums with all three kinds of collections.

Jegelewicz on 21 Jan 2020

Yes some $$ to talk about the details would be awesome.

We need to figure out how to get these data in without letting Linnean not-taxonomy in. (Easy solution: this would be a one-time load not editable by users. Not sure how long-term workable that is, maybe not very.)
The dots in terms would break CSV and maybe Arctos. (If we're not allowing that then it doesn't matter.)

I think we can do this now (~few days) but it MIGHT break something, fixing that in PG would be (maybe MUCH) easier, deciding precisely what we're doing before we do it could save some frustration for everyone.

I'm up for anything, but I think the sooner we're in PG the happier everyone will be, even disregarding the catastrophic possibilities.

I think this could be useful in art collections - perhaps not as "A" identifications, but the "A {string}" formula could be used to link string-IDs to formal taxonomy.

dustymc on 21 Jan 2020

The dots in terms would break CSV and maybe Arctos.

We don't need those - taht was just a stab at creating terms explicitly different from the linnean terms. They could also be:

N4 Category
N4 Class
N4 Sub-class
N4 Primary object term
N4 Secondary object term
N4 Tertiary object term

Jegelewicz on 21 Jan 2020

I think this could be useful in art collections - perhaps not as "A" identifications, but the "A {string}" formula could be used to link string-IDs to formal taxonomy.

Art collections will want to use Getty AAT. See Top Arctos Priorities for Art Collections

Jegelewicz on 21 Jan 2020

Those will break the same things. See http://arctos.database.museum/info/ctDocumentation.cfm?table=CTTAXON_TERM for current terms (all lower ASCII + underbar).

None of that matters if we're not managing those data in the same way we do the Linnean (minus WoRMs, sorta) stuff.

dustymc on 21 Jan 2020

None of that matters if we're not managing those data in the same way we do the Linnean (minus WoRMs, sorta) stuff.

They will be managed in the same way and the Getty AAT could(should) function just like WoRMS via Arctos.

Jegelewicz on 21 Jan 2020

just like WoRMS

That's one of those details we need to work out, preferably before I start writing code. "Just like WoRMS"--->giant pain requiring integrating data being changed in two places, and full functionality in both of them. "Like WoRMS should work"--->much easier, just pull data. I don't have any idea what the reality is here.

dustymc on 21 Jan 2020

It is possible that for identifications just using AAT will work, but I am not 100% sure and they may end up wanting to add their own terms...

Jegelewicz on 21 Jan 2020

Here is a link to the object/work types that we would want to add as taxonomy: https://drive.google.com/open?id=18f5tnysAmj09hqUUZvfXIqbmmPpwVDDRW6UxfnMZOdg We do not envision needing to add in any other terms not from the AAT. One thing about this list is that the terms are all plural, in line with the AAT terms. However what we have most often seen recorded in other collections for object/work type are singular terms. And some of these collections are clearly also using the AAT. Each AAT term appears to have a singular version of that term in the terms list, so maybe using the singular is fine?

krgomez on 22 Jan 2020

I will contact the Getty AAT folks to inquire about this singular/plural
discrepancy before we make a decision about how to move forward. It is
important that if we are able to hookup Arctos to the AAT in the future
that our tables will be friendly to each other.

On Tue, Jan 21, 2020 at 3:27 PM Karinna Gomez notifications@github.com
wrote:

Here is a link to the object/work types that we would want to add as
taxonomy:
https://drive.google.com/open?id=18f5tnysAmj09hqUUZvfXIqbmmPpwVDDRW6UxfnMZOdg
We do not envision needing to add in any other terms not from the AAT. One
thing about this list is that the terms are all plural, in line with the
AAT terms. However what we have most often seen recorded in other
collections for object/work type are singular terms. And some of these
collections are clearly also using the AAT. Each AAT term appears to have a
singular version of that term in the terms list, so maybe using the
singular is fine?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ArctosDB/arctos/issues/1732?email_source=notifications&email_token=AJKSRRYJRFDUO4SLBH642ATQ66HH7A5CNFSM4F2X6HQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJRZIDA#issuecomment-576951308,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJKSRR47CYWA577EDH3ATZLQ66HH7ANCNFSM4F2X6HQA
.

--
Mareca Guthrie
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
[email protected]

University of Alaska Museum of the North: www.uaf.edu/museum
UAF Art Department: https://www.uaf.edu/art/ https://www.uaf.edu/art/
Colors of Nature: http://www.colorsofnature.org/

marecaguthrie on 22 Jan 2020

👍1

We got confirmation from the Getty Vocabulary Program's Managing Editor
that the singular version of the noun for object/work type is indeed the
standard and our spreadsheet now reflect this.

On Tue, Jan 21, 2020 at 3:33 PM Mareca Guthrie mrguthrie@alaska.edu wrote:

I will contact the Getty AAT folks to inquire about this singular/plural
discrepancy before we make a decision about how to move forward. It is
important that if we are able to hookup Arctos to the AAT in the future
that our tables will be friendly to each other.

On Tue, Jan 21, 2020 at 3:27 PM Karinna Gomez notifications@github.com
wrote:

Here is a link to the object/work types that we would want to add as
taxonomy:
https://drive.google.com/open?id=18f5tnysAmj09hqUUZvfXIqbmmPpwVDDRW6UxfnMZOdg
We do not envision needing to add in any other terms not from the AAT. One
thing about this list is that the terms are all plural, in line with the
AAT terms. However what we have most often seen recorded in other
collections for object/work type are singular terms. And some of these
collections are clearly also using the AAT. Each AAT term appears to have a
singular version of that term in the terms list, so maybe using the
singular is fine?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ArctosDB/arctos/issues/1732?email_source=notifications&email_token=AJKSRRYJRFDUO4SLBH642ATQ66HH7A5CNFSM4F2X6HQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJRZIDA#issuecomment-576951308,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJKSRR47CYWA577EDH3ATZLQ66HH7ANCNFSM4F2X6HQA
.

--
Mareca Guthrie
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
[email protected]

University of Alaska Museum of the North: www.uaf.edu/museum
UAF Art Department: https://www.uaf.edu/art/ https://www.uaf.edu/art/
Colors of Nature: http://www.colorsofnature.org/

--
Mareca Guthrie
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
[email protected]

University of Alaska Museum of the North: www.uaf.edu/museum
UAF Art Department: https://www.uaf.edu/art/ https://www.uaf.edu/art/
Colors of Nature: http://www.colorsofnature.org/

marecaguthrie on 23 Jan 2020

👍1

@dustymc I've been thinking about this and wondering if a code table like we have in geology attributes with parents and children would be best. Perhaps having non-biological collections use identification as they do now, but with the addition of a new field "Getty AAT attribute" (attributes for identifications?). If the code table is arranged like geology, they would only need to select the appropriate most specific term, then their stuff could be found with a search of anything higher up in the hierarchy.

There actually might be uses for this in biological collections which could make those items accessible to art collections (natural history specimens)

Thoughts?

Jegelewicz on 23 Jan 2020

@Jegelewicz there's definitely some weird overlap between "identifications" and - well, something! - in "cultural" collections. Some (perhaps even all) of that's just a matter of perspective - it's an otter (that happens to be in the shape of a hat), or it's a hat (that happens to be made of otter skin) depending on who's doing the cataloging. I think there's some big-picture THING that we (just me?) are not quite grasping, and we should try to figure out what that is before we start modeling data.

It is interesting that this 'classification' stops about where Linnean taxonomy starts, and that does make me think that these might be some sort of not-quite-taxonomy data.

dustymc on 23 Jan 2020

not-quite-taxonomy data.

I actually think it IS taxonomy, it is just that these guys actually have a hierarchy that is useful and I don't see a reason to take apart that hierarchy by putting it in the classification model we have now. It would work there, but could easily be made inconsistent with the way our taxonomy model works.

Jegelewicz on 23 Jan 2020

I'm not quite sure I'm following the discussion, but from what you both are
saying I think we should probably include our need for a "Classification"
category in this discussion as well (we have a table for this too to
share).
I propose that I make a separate GitHub about the larger analysis that
Karinna and I have just finished that compares the gold standard for art
museum database best practices- the Getty's CDWA (Categories for the
Descriptions of Works of Art) to what we currently have in Arctos. From the
larger assessment we were able to determine what our primary needs are as a
collection. Karinna and I are taking one last look look through our
documents and we will share them in a GitHub post later today.

On Thu, Jan 23, 2020 at 8:05 AM Teresa Mayfield-Meyer <
[email protected]> wrote:

not-quite-taxonomy data.

I actually think it IS taxonomy, it is just that these guys actually have
a hierarchy that is useful and I don't see a reason to take apart that
hierarchy by putting it in the classification model we have now. It would
work there, but could easily be made inconsistent with the way our taxonomy
model works.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ArctosDB/arctos/issues/1732?email_source=notifications&email_token=AJKSRRZXHKHD3CXWGHHEKXLQ7HE55A5CNFSM4F2X6HQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJYCRAY#issuecomment-577775747,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AJKSRR5EHOYT2W563FSDIUDQ7HE55ANCNFSM4F2X6HQA
.

--
Mareca Guthrie
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
[email protected]

University of Alaska Museum of the North: www.uaf.edu/museum
UAF Art Department: https://www.uaf.edu/art/ https://www.uaf.edu/art/
Colors of Nature: http://www.colorsofnature.org/

marecaguthrie on 23 Jan 2020

Whatever we do structurally on the back end, we need to be able to maintain our ability to use the taxonomy in the ID section to include those animals/plants that are included in our objects as "materials" while also being able to index our collections using the nomenclature / AAT. My sense is that many databases have an ID field for the "Object Name" (our Scientific Name) and then a field for "Other name" (the preferred name in the Nomenclature that is standardized). It would be great to have the option to have many "other names" (to include Indigenous names for items).

(You can watch this YouTube video to see how PastPerfect integrates Nomenclature: https://www.youtube.com/watch?v=xAIBHuC8uCc)

Both improve the discoverability of our collections for all users of Arctos (be they biologists who are wanting to get access to examples of skins used by Russians in the 1780s on clothing because there are no samples in natural history collections that old, or members of source communities interested in learning more about how the resource use has changed in their community over time).

AJLinn on 23 Jan 2020

👍1

it IS taxonomy

Could be - I still don't know! - but it's still functionally different eg, in *ology the lowest classification term and the "name" are identical (_Sorex cinereus_) except in weird situations. Cultural object often have another layer - 'painting' (and parents) is useful (I think!), but thats often not the "name" - "The Mona Lisa." At the very least, I think that sort of thing is worth consideration.

easily be made inconsistent with the way our taxonomy model works

This is no different than any other classification; our model is built to accept hierarchical data (and a lot of other stuff). It's not great for MANAGING hierarchical data, but lots of things are and ideally we'd just plug in and let these sources manage.

great to have the option to have many "other names"

New Issue. There are a few possibilities, all of which would likely require some UI rewiring but that's comparatively trivial.

Use the current functionality to hook many taxa objects to a string identification. Super easy, but not terribly formal/controlled.
Introduce more complex ID formae. "A and B and C and (D or E) and ... Z" should work just fine. Probably not much fun to maintain though.
Allow multiple "accepted" IDs. Probably most formal/correct, certainly most powerful, absolutely most likely to melt GBIF and random streadsheetification attempts. (And I have vague memories of this maybe being handy elsewhere for some reason....)

dustymc on 24 Jan 2020

I have nomenclature 4.0 ready to load, working on getting it into test for review. See #2501

Jegelewicz on 12 Nov 2020

@dustymc There will be the same issues in the cultural terms as there were in minerals with "banned" characters. Can we allow cultural terms to use the same rules as the mineral terms? I think that should do it...but I'm sure I'll still run into something!

Jegelewicz on 3 Dec 2020

Cultural and mineral are now sharing the check. _Maybe_ worth splitting them up at some point, or calling the function something more generic than isValidMineralTaxonName, or something.

dustymc on 3 Dec 2020

👍1

Already found one we need to add

/

Jegelewicz on 3 Dec 2020

Added, but are you sure that's taxonomy?

dustymc on 3 Dec 2020

Yep - it is a 33 1/3 album (unless you are too young to know what that is....)

Jegelewicz on 3 Dec 2020

We also need to allow "and"

Arts and Crafts Set

Jegelewicz on 3 Dec 2020

Now listen here whippersnapper....

Done.

dustymc on 3 Dec 2020

😄2

Also need "or"

Trick or Treat Bag

Jegelewicz on 4 Dec 2020

done

dustymc on 4 Dec 2020

@dustymc attempting a test load of classifications for Nomenclature 4.0 and getting an error of "class_term_type_8 is invalid" for source_authority. What am I missing?

Jegelewicz on 4 Dec 2020

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

source_authority is noclass

dustymc on 4 Dec 2020

DOH! Thanks!

Jegelewicz on 4 Dec 2020

Closing - terms and classifications requested are in Arctos.

Jegelewicz on 18 Dec 2020

Thank you for all your work on this! Now to figure out how to use it and to remember to use it! :-)

AJLinn on 18 Dec 2020

@AJLinn probably the first step is to get the names used in all of your "unidentifiable" identifications. You can probably chat with @marecaguthrie and @krgomez about what they are doing in art - also see our conversations in #2501

Jegelewicz on 18 Dec 2020

Well... everything is unidentifiable, since that's how we catalog. I've got 17000 records and probably 16,990 are unidentifiable! No worries, I'll take my time, which I don't have right now! We'll use it going forward with new entries.

AJLinn on 18 Dec 2020

👍1

@AJLinn I could probably help you update them in bulk if you are interested....

Jegelewicz on 19 Dec 2020

Arctos: Nomenclature 4.0 for Man-Made Items

Most helpful comment

All 71 comments

745

745 https://github.com/ArctosDB/arctos/issues/745

Related issues