Arctos: Locality (and event) name/nickname labels

Created on 3 Jun 2019 · 29Comments · Source: ArctosDB/arctos

Splitting https://github.com/ArctosDB/arctos/issues/1811#issuecomment-493314961 out here

locality.locality_name and collecting_event.collecting_event_name have been by request (of @DerekSikes maybe??) labeled '... nickname' in most forms. Both use "...name" in the specimen bulkloader (and likely other batch tools). Can we settle on terminology? (My vote is for 'name' but there's no technical reasoning behind that - I'm not very attached to anything.)

@campmlc likes "name" - https://github.com/ArctosDB/arctos/issues/1811#issuecomment-493316120

@DerekSikes likes "nickname" - https://github.com/ArctosDB/arctos/issues/1811#issuecomment-498378748

I still don't much care (aside from not being crazy about differences in field names and labels) but we should be as consistent as possible.

How do we resolve this?

Here's who uses it.

select 
  guid_prefix,
  count(*)
from 
  collection,
  cataloged_item,
  specimen_event,
  collecting_event,
  locality
where
  collection.collection_id=cataloged_item.collection_id and 
  cataloged_item.collection_object_id=specimen_event.collection_object_id and
  specimen_event.collecting_event_id=collecting_event.collecting_event_id and 
  collecting_event.locality_id=locality.locality_id and
  (
    collecting_event.collecting_event_name is not null or
    locality.locality_name is not null
  )
group by guid_prefix
order by count(*) desc
 ;

GUID_PREFIX                            COUNT(*)
------------------------------------------------------------ ----------
UAM:Ento                              91358
MSB:Mamm                              33782
UTEP:ES                               23875
UAMObs:Ento                           12334
UAM:ES                                 1890
MSB:Para                               1645
MSB:Host                                991
MVZ:Mamm                                688
UTEP:Arc                                379
MVZ:Bird                                376
CHAS:Bird                               364
UTEP:Inv                                288
UWYMV:Mamm                              211
MVZ:Herp                                175
UTEP:Ento                               161
UAM:Mamm                                143
DGR:Mamm                                 82
CHAS:Inv                                 71
MSB:Fish                                 65
USNPC:Para                               49
UCM:Herp                                 48
MSB:Bird                                 40
CHAS:Ento                                34
UAM:Bird                                 29
KNWR:Ento                                23
DMNS:Inv                                 20
HWML:Para                                19
UCM:Bird                                 19
UAM:EH                                   15
DMNS:Bird                                12
UTEP:Mamm                                 6
OWU:ES                                    6
MVZObs:Bird                               6
DMNS:Mamm                                 6
UAMb:Herb                                 5
CHAS:Mamm                                 4
UTEP:Herp                                 4
UTEP:Herb                                 4
UAM:Fish                                  3
MSBObs:Mamm                               3
DGR:Bird                                  3
CHAS:Herb                                 2
OWU:Mamm                                  2
OWU:Fish                                  2
UNM:ES                                    1
KNWR:Herb                                 1
UAM:Herb                                  1
CHAS:Teach                                1
UAMObs:Fish                               1
CHAS:Herp                                 1
MVZ:Egg                                   1

51 rows selected.

Help wanted Priority-High Type-ForFunction

Source

dustymc

All 29 comments

Name is inappropriate because it's not an official name of a locality, it's
a code-name or 'informal name' anything that fails to convey the informal,
nick-name nature of these names is bound to cause problems in
interpretation.

-Derek

On Mon, Jun 3, 2019 at 10:57 AM dustymc notifications@github.com wrote:

Splitting #1811 (comment)
https://github.com/ArctosDB/arctos/issues/1811#issuecomment-493314961
out here

locality.locality_name and collecting_event.collecting_event_name have
been by request (of @DerekSikes https://github.com/DerekSikes maybe??)
labeled '... nickname' in most forms. Both use "...name" in the specimen
bulkloader (and likely other batch tools). Can we settle on terminology?
(My vote is for 'name' but there's no technical reasoning behind that - I'm
not very attached to anything.)

@campmlc https://github.com/campmlc likes "name" - #1811 (comment)
https://github.com/ArctosDB/arctos/issues/1811#issuecomment-493316120

@DerekSikes https://github.com/DerekSikes likes "nickname" - #1811
(comment)
https://github.com/ArctosDB/arctos/issues/1811#issuecomment-498378748

I still don't much care (aside from not being crazy about differences in
field names and labels) but we should be as consistent as possible.

How do we resolve this?

Here's who uses it.

select
guid_prefix,
count()
from
collection,
cataloged_item,
specimen_event,
collecting_event,
locality
where
collection.collection_id=cataloged_item.collection_id and
cataloged_item.collection_object_id=specimen_event.collection_object_id and
specimen_event.collecting_event_id=collecting_event.collecting_event_id and
collecting_event.locality_id=locality.locality_id and
(
collecting_event.collecting_event_name is not null or
locality.locality_name is not null
)
group by guid_prefix
order by count() desc
;

GUID_PREFIX COUNT(*)

UAM:Ento MSB:Mamm UTEP:ES UAMObs:Ento UAM:ES MSB:Para MSB:Host MVZ:Mamm UTEP:Arc MVZ:Bird CHAS:Bird UTEP:Inv UWYMV:Mamm MVZ:Herp UTEP:Ento UAM:Mamm DGR:Mamm CHAS:Inv MSB:Fish USNPC:Para UCM:Herp MSB:Bird CHAS:Ento UAM:Bird KNWR:Ento DMNS:Inv HWML:Para UCM:Bird UAM:EH DMNS:Bird UTEP:Mamm OWU:ES MVZObs:Bird DMNS:Mamm UAMb:Herb CHAS:Mamm UTEP:Herp UTEP:Herb UAM:Fish MSBObs:Mamm DGR:Bird CHAS:Herb OWU:Mamm OWU:Fish UNM:ES KNWR:Herb UAM:Herb CHAS:Teach UAMObs:Fish CHAS:Herp MVZ:Egg 91358
33782
23875
12334
1890
1645
991
688
379
376
364
288
211
175
161
143
82
71
65
49
48
40
34
29
23
20
19
19
15
12
6
6
6
6
5
4
4
4
3
3
3
2
2
2
1
1
1
1
1
1
1

51 rows selected.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ArctosDB/arctos/issues/2105?email_source=notifications&email_token=ACFNUM2H3RNK4KJ5BC6W3WTPYVSP7A5CNFSM4HSOJCS2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GXLNXXA,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACFNUM5JM72YNLE4ROLIP5LPYVSP7ANCNFSM4HSOJCSQ
.

+++++++++++++++++++++++++++++++++++
Derek S. Sikes, Curator of Insects
Professor of Entomology
University of Alaska Museum
1962 Yukon Drive
Fairbanks, AK 99775-6960

[email protected]

phone: 907-474-6278
FAX: 907-474-5469

University of Alaska Museum - search 400,276 digitized arthropod records
http://arctos.database.museum/uam_ento_all
http://www.uaf.edu/museum/collections/ento/
+++++++++++++++++++++++++++++++++++

Interested in Alaskan Entomology? Join the Alaska Entomological
Society and / or sign up for the email listserv "Alaska Entomological
Network" at
http://www.akentsoc.org/contact_us http://www.akentsoc.org/contact.php

DerekSikes on 3 Jun 2019

👍1

I'm OK with nickname.

On Mon, Jun 3, 2019 at 2:07 PM DerekSikes notifications@github.com wrote:

Name is inappropriate because it's not an official name of a locality, it's
a code-name or 'informal name' anything that fails to convey the informal,
nick-name nature of these names is bound to cause problems in
interpretation.

-Derek

On Mon, Jun 3, 2019 at 10:57 AM dustymc notifications@github.com wrote:

Splitting #1811 (comment)
https://github.com/ArctosDB/arctos/issues/1811#issuecomment-493314961
out here

locality.locality_name and collecting_event.collecting_event_name have
been by request (of @DerekSikes https://github.com/DerekSikes maybe??)
labeled '... nickname' in most forms. Both use "...name" in the specimen
bulkloader (and likely other batch tools). Can we settle on terminology?
(My vote is for 'name' but there's no technical reasoning behind that -
I'm
not very attached to anything.)

@campmlc https://github.com/campmlc likes "name" - #1811 (comment)
https://github.com/ArctosDB/arctos/issues/1811#issuecomment-493316120

@DerekSikes https://github.com/DerekSikes likes "nickname" - #1811
(comment)
https://github.com/ArctosDB/arctos/issues/1811#issuecomment-498378748

I still don't much care (aside from not being crazy about differences in
field names and labels) but we should be as consistent as possible.

How do we resolve this?

Here's who uses it.

select
guid_prefix,
count()
from
collection,
cataloged_item,
specimen_event,
collecting_event,
locality
where
collection.collection_id=cataloged_item.collection_id and
cataloged_item.collection_object_id=specimen_event.collection_object_id
and
specimen_event.collecting_event_id=collecting_event.collecting_event_id
and
collecting_event.locality_id=locality.locality_id and
(
collecting_event.collecting_event_name is not null or
locality.locality_name is not null
)
group by guid_prefix
order by count() desc
;

GUID_PREFIX COUNT(*)

UAM:Ento 91358
MSB:Mamm 33782
UTEP:ES 23875
UAMObs:Ento 12334
UAM:ES 1890
MSB:Para 1645
MSB:Host 991
MVZ:Mamm 688
UTEP:Arc 379
MVZ:Bird 376
CHAS:Bird 364
UTEP:Inv 288
UWYMV:Mamm 211
MVZ:Herp 175
UTEP:Ento 161
UAM:Mamm 143
DGR:Mamm 82
CHAS:Inv 71
MSB:Fish 65
USNPC:Para 49
UCM:Herp 48
MSB:Bird 40
CHAS:Ento 34
UAM:Bird 29
KNWR:Ento 23
DMNS:Inv 20
HWML:Para 19
UCM:Bird 19
UAM:EH 15
DMNS:Bird 12
UTEP:Mamm 6
OWU:ES 6
MVZObs:Bird 6
DMNS:Mamm 6
UAMb:Herb 5
CHAS:Mamm 4
UTEP:Herp 4
UTEP:Herb 4
UAM:Fish 3
MSBObs:Mamm 3
DGR:Bird 3
CHAS:Herb 2
OWU:Mamm 2
OWU:Fish 2
UNM:ES 1
KNWR:Herb 1
UAM:Herb 1
CHAS:Teach 1
UAMObs:Fish 1
CHAS:Herp 1
MVZ:Egg 1

51 rows selected.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<
https://github.com/ArctosDB/arctos/issues/2105?email_source=notifications&email_token=ACFNUM2H3RNK4KJ5BC6W3WTPYVSP7A5CNFSM4HSOJCS2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4GXLNXXA
,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/ACFNUM5JM72YNLE4ROLIP5LPYVSP7ANCNFSM4HSOJCSQ

.

--

+++++++++++++++++++++++++++++++++++
Derek S. Sikes, Curator of Insects
Professor of Entomology
University of Alaska Museum
1962 Yukon Drive
Fairbanks, AK 99775-6960

[email protected]

phone: 907-474-6278
FAX: 907-474-5469

University of Alaska Museum - search 400,276 digitized arthropod records
http://arctos.database.museum/uam_ento_all
http://www.uaf.edu/museum/collections/ento/
+++++++++++++++++++++++++++++++++++

Interested in Alaskan Entomology? Join the Alaska Entomological
Society and / or sign up for the email listserv "Alaska Entomological
Network" at
http://www.akentsoc.org/contact_us http://www.akentsoc.org/contact.php

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ArctosDB/arctos/issues/2105?email_source=notifications&email_token=ADQ7JBDAA264SG4PDSXAXFTPYVTVDA5CNFSM4HSOJCS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODW2MITY#issuecomment-498385999,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADQ7JBDKL36VZOJRYDBJW3TPYVTVDANCNFSM4HSOJCSQ
.

campmlc on 3 Jun 2019

Progress? Also, can we have the ability to search on nickname (or whatever it ends up being)?

Jegelewicz on 19 Jul 2019

Name is inappropriate because it's not an official name of a locality, it's
a code-name or 'informal name' anything that fails to convey the informal,
nick-name nature of these names is bound to cause problems in
interpretation.

I'm confused then about what nickname is supposed to be. In the documentation it says:

Locality Nickname is a globally-unique human-readable “locality ID” commonly used to unambiguously associate one or more specimens to a locality.

Locality Documentation

I'm getting ready to try to map our data fields for upload and cannot figure out what should be a simple and very important item - where to put our locality numbers. Based on the documentation I thought it should go in locality nickname (in which case nickname is a not a good descriptor of the data). However, based on @DerekSikes description of locality nickname, that field is not where our locality numbers should go.

Nicole-Ridgwell-NMMNHS on 6 Aug 2019

The documentation is correct (but perhaps incomplete - the "globe" of reference is Arctos), and describes what the concept is; how it's used is up to individuals.

If your "numbers" are unique and correspond to Arctos localities (3D places, optionally with geology, no time component) then locality_name seems a suitable target. If they're not that, then examples would be very useful.

I'm not sure what "formal" or "official" might mean in this context.

dustymc on 6 Aug 2019

I would describe our locality numbers as "formal" or "official" and if this field is used for that type of data by some collections, shouldn't the displayed name of the field reflect that?

By official I mean that our locality #s are the primary key for all our locality data. The locality numbers are included in publications about our specimens. Agencies we have permits with use these locality numbers when tracking collecting activity and from there make policy decisions.

Nicole-Ridgwell-NMMNHS on 6 Aug 2019

Where are we on this? As I stated above, we're on the verge of being able to upload our localities and I don't like the idea of putting our official locality numbers into a field called "nickname".

Nicole-Ridgwell-NMMNHS on 16 Sep 2019

field

It's just the label...

UAM@ARCTOS> desc locality
 Name                                  Null?    Type
 ----------------------------------------------------------------- -------- --------------------------------------------
...

 LOCALITY_NAME                                  VARCHAR2(255)
...

I'm not sure how to effectively prioritize this. @Jegelewicz ??

dustymc on 17 Sep 2019

putting our official locality numbers into a field called "nickname"

nickname is the best way to make a locality ID "official". It keeps that locality separate from all others that are otherwise effectively equal AND it is searchable. Nobody likes the term "nickname" but we have yet to decide upon a better term (see #2105). FWIW, this is how I handled all of the site numbers at UTEP. (From the Arctos main menu select Search > Places and put "UTEP:ES:Site%" in Locality Nickname to see them all)

If you really aren't comfortable with that, the next best thing is to load a Locality ID for each specimen as an other identifier. Still searchable, but no longer linked to the locality. This is what I used for ALMNH because their sites were not well defined localities.

Given what you said above about pubs - I would think you would want to use the nickname field!

Jegelewicz on 17 Sep 2019

Nobody likes the term "nickname" but we have yet to decide upon a better term

This is what I would like to see happen so that we are not publicly calling our official locality numbers "nicknames". I agree that that field is the best place to put those numbers.

Nicole-Ridgwell-NMMNHS on 17 Sep 2019

If Locality Name can't work to replace "nickname" how about

Locality Label
Locality Tag
Collection Assigned Locality Name
Locality Unique Name
Locality Identifier

sharpphyl on 18 Sep 2019

👍1

I like Locality Identifier.

Jegelewicz on 18 Sep 2019

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

dustymc on 18 Sep 2019

How about Locality Unique Identifier?

Nicole-Ridgwell-NMMNHS on 19 Sep 2019

👍1

I like that.

On Wed, Sep 18, 2019 at 4:19 PM Nicole-Ridgwell-NMMNHS <
[email protected]> wrote:

How about Locality Unique Identifier?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ArctosDB/arctos/issues/2105?email_source=notifications&email_token=ADQ7JBDOHF6ESI66RWOBPNDQKKSNBA5CNFSM4HSOJCS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7BTZXQ#issuecomment-532888798,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADQ7JBFLIWVOZO7HTYUEIPLQKKSNBANCNFSM4HSOJCSQ
.

campmlc on 19 Sep 2019

Collector Unique Identifier?
Collection Unique Identifier?

ewommack on 19 Sep 2019

Collecting Event unique identifier

On Wed, Sep 18, 2019, 5:33 PM Elizabeth Wommack notifications@github.com
wrote:

Collector Unique Identifier?
Collection Unique Identifier?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ArctosDB/arctos/issues/2105?email_source=notifications&email_token=ADQ7JBHC3DICQBRO2ARYL6TQKK3EPA5CNFSM4HSOJCS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7BX6WY#issuecomment-532905819,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADQ7JBEYU2XZLWHITUBJ2ZLQKK3EPANCNFSM4HSOJCSQ
.

campmlc on 19 Sep 2019

So,
Locality nickname becomes "Locality Unique Identifier"
and
Collecting Event nickname becomes "Collecting Event Unique Identifier"
Good?

But then we should also have the ability to search by these fields:

Where is the locality nickname field?

You can find it here:

but that seems like an odd place for it when it might be a published identifier that people want to find.

The same can be said for the collecting event identifier.

Where is the collecting event nickname field?

Again, it can be found in "search places", but here there is the additional barrier of needing to select "show more options" in the Verbatim Locality section of the search page to find the field.

Jegelewicz on 19 Sep 2019

Locality Unique Identifier

At some level I don't care what the labels are, and this is just a label change that does not affect data or functionality. However, this seems close to, and therefore potentially confused with, https://github.com/ArctosDB/arctos/issues/2210.

Perhaps a hopefully-brief AWG discussion would be useful? I think flipping labels around is somewhat disruptive to users, it would be good to be sure we're sure before changing this.

dustymc on 19 Sep 2019

👍1

Our site names ARE well-defined and we have a catalog of them to document it. I am not responsible for the way they were entered in our data by people who did not understand their use. I will eventually need to enter our extensive site log and be able to search on it as well. And just to add my two-cents worth, what is wrong with "site identifier" ?

mbprondzinski on 25 Nov 2019

Can we come back to this? The label is still locality nickname which is inappropriate for our institution's locality ID numbers in this field. Site identifier is a locality attribute, so whatever we use should not get confused with that. I'm still in favor of "Locality Unique Identifier".

Nicole-Ridgwell-NMMNHS on 4 Aug 2020

We've mostly committed to an API since this conversation started; changing local labels is potentially very confusing to users, this sort of thing should really involve a full replacement. (Or perhaps fancier tools than I really want to use for API-building). I still don't entirely care what we call this thing - "Locality Unique Identifier" is a mouthful and a bit optimistic, but not wrong if you hold your mouth JUST RIGHT - but given the usability implications (there are none), the backlog we're currently facing (plenty!), etc., etc., I'll cast a vote for going back to the design name, "locality_name" (and collecting_event_name). I don't think it's any less informative than anything else that's been proposed, it's apparently more palatable than some, and it requires no core changes, just de-nicknaming the UIs.

If we must change something, then I also have no idea how to prioritize - very low, because there's no functionality here, or very high because the https://github.com/ArctosDB/arctos/issues/2916 seems to be struggling for the top of the pile and I don't want to do that twice.

dustymc on 4 Aug 2020

I'll cast a vote for going back to the design name, "locality_name" (and collecting_event_name). I don't think it's any less informative than anything else that's been proposed, it's apparently more palatable than some, and it requires no core changes, just de-nicknaming the UIs.

I agree locality_name and collecting_event_name are simple, easy to remember and do not conflict with the locality attribute "site identifier". As for @DerekSikes issue with locality_name being "inappropriate because it's not an official name of a locality", if the definitions of these fields are as follows, then we aren't asserting they are official in any way:

locality_name - a globally-unique human-readable “locality ID” commonly used to unambiguously associate one or more specimens to a locality. (see https://handbook.arctosdb.org/documentation/locality.html)

collecting_event_name - human-readable stable “primary key” to collecting events. See https://handbook.arctosdb.org/documentation/collecting-event.html

BUT maybe this would make it more palatable to everyone?

arctos_locality_name - A unique identifier used to unambiguously associate one or more events with a locality. An Arctos Locality Name is useful for locating pre-created localities and may be useful when events share a locality but are not entered sequentially, such as return visits to fossil dig sites. The existence of an Arctos Locality Name will prevent automated merger and deletion of a locality, even if it is not currently associated with any collecting events.

arctos_event_name - A unique identifier used to unambiguously associate one or more object records to an event. An Arctos Event Name is useful for locating pre-created events and may be useful when objects share an event but are not entered sequentially, such as hosts and parasites. The existence of an Arctos Event Name will prevent automated merger and deletion of a collecting event, even if it is not currently associated with any object records.

Side note For me, this really highlights the fact "collecting event" is a misnomer and I think it should just be "event". "Collecting events" include data that are actually collection, depiction, encounter, manufacture, observation, and use. I know this might cause a bunch of changes, but the fact that we call this "collecting event" causes a lot of confusion when trying to explain the locality stack. The event type (collection, depiction, encounter, manufacture, observation, or use) is assigned in the specimen event, which really should be renamed "object event". Lots to think about here and probably needs additional issues, but we should get this cleaned up sooner rather than later....

Jegelewicz on 4 Aug 2020

Works for me. But perhaps we need to change "specimen event" = "object
event" even more? Is this even an event? These are details about an event -
including determiners, confidence, methods, - should we just have multiple
"events" with different event attributes?

On Tue, Aug 4, 2020 at 9:24 AM Teresa Mayfield-Meyer <
[email protected]> wrote:

[EXTERNAL]*

I'll cast a vote for going back to the design name, "locality_name" (and
collecting_event_name). I don't think it's any less informative than
anything else that's been proposed, it's apparently more palatable than
some, and it requires no core changes, just de-nicknaming the UIs.

I agree locality_name and collecting_event_name are simple, easy to
remember and do not conflict with the locality attribute "site identifier".
As for @DerekSikes https://github.com/DerekSikes issue with
locality_name being "inappropriate because it's not an official name of a
locality", if the definitions of these fields are as follows, then we
aren't asserting they are official in any way:

locality_name - a globally-unique human-readable “locality ID” commonly
used to unambiguously associate one or more specimens to a locality. (see
https://handbook.arctosdb.org/documentation/locality.html)

collecting_event_name - human-readable stable “primary key” to collecting
events. See
https://handbook.arctosdb.org/documentation/collecting-event.html

BUT maybe this would make it more palatable to everyone?

arctos_locality_name - A unique identifier used to unambiguously associate
one or more events with a locality. An Arctos Locality Name is useful for
locating pre-created localities and may be useful when events share a
locality but are not entered sequentially, such as return visits to fossil
dig sites. The existence of an Arctos Locality Name will prevent automated
merger and deletion of a locality, even if it is not currently associated
with any collecting events.

arctos_event_name - A unique identifier used to unambiguously associate
one or more object records to an event. An Arctos Event Name is useful for
locating pre-created events and may be useful when objects share an event
but are not entered sequentially, such as hosts and parasites. The
existence of an Arctos Event Name will prevent automated merger and
deletion of a collecting event, even if it is not currently associated with
any object records.

Side note For me, this really highlights the fact "collecting event" is
a misnomer and I think it should just be "event". "Collecting events"
include data that are actually collection, depiction, encounter,
manufacture, observation, and use. I know this might cause a bunch of
changes, but the fact that we call this "collecting event" causes a lot of
confusion when trying to explain the locality stack. The event type
(collection, depiction, encounter, manufacture, observation, or use) is
assigned in the specimen event, which really should be renamed "object
event". Lots to think about here and probably needs additional issues, but
we should get this cleaned up sooner rather than later....

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ArctosDB/arctos/issues/2105#issuecomment-668662337,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADQ7JBAQZGYRAS2QOLQIT6LR7AR3BANCNFSM4HSOJCSQ
.

campmlc on 4 Aug 2020

Your definitions are an improvement.

The arctos_ bit is as problematic as any other core change, and I don't think it's a stretch to infer the "arctos_" part. I'm still at sticking with the concept names.

"collecting event"

No disagreement, but that's Arctos 3.0 or something. Or maybe it's just evidence that we do in fact need to separate database labels and UI-of-any-form labels; nothing a full API transition couldn't do....

dustymc on 4 Aug 2020

I'm fine with just using locality_name and I like the new definitions!

Nicole-Ridgwell-NMMNHS on 4 Aug 2020

The arctos_ bit is as problematic

Maybe just add that to the UI so locality_name looks like "Arctos Locality Name" in the search and results?

evidence that we do in fact need to separate database labels and UI-of-any-form labels

While a part of me agrees - a part of me knows that the more congruent these are, the easier it is to understand Arctos. (All while I am suggesting just such a thing above....)

Could this just be some sort of table?

and so on then we can set things up so that a reference to locality_name displays Arctos Locality Name in a way that means Dusty doesn't have to think about what the display should be and we don't necessarily need to know what the database label is (but we could both easily find out by referring to the table that links them? This would also aid in consistency of terms across pages in Arctos.

Probably just wishful thinking on my part, but hey, I am a dreamer.

Jegelewicz on 4 Aug 2020

I think that is a reasonable dream! Sometimes the best ideas . . .

On Tue, Aug 4, 2020 at 10:19 AM Teresa Mayfield-Meyer <
[email protected]> wrote:

[EXTERNAL]*

The arctos_ bit is as problematic

Maybe just add that to the UI so locality_name looks like "Arctos Locality
Name" in the search and results?

evidence that we do in fact need to separate database labels and
UI-of-any-form labels

While a part of me agrees - a part of me knows that the more congruent
these are, the easier it is to understand Arctos. (All while I am
suggesting just such a thing above....)

Could this just be some sort of table?
database label display term
locality_name Arctos Locality Name
collecting_event Event
specimen_event Event Relationship to Collection Object

and so on then we can set things up so that a reference to locality_name
displays Arctos Locality Name in a way that means Dusty doesn't have to
think about what the display should be and we don't necessarily need to
know what the database label is (but we could both easily find out be
referring to the table that links them? This would also aid in consistency
of terms across pages in Arctos.

Probably just wishful thinking on my part, but hey, I am a dreamer.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ArctosDB/arctos/issues/2105#issuecomment-668691994,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADQ7JBBZHGMM2E2XXI6EKM3R7AYH3ANCNFSM4HSOJCSQ
.