Search by Identification is Linnean centric

[Jegelewicz]

The search page offers all of the options for searching Linnean taxonomy, but only "Species" for minerals and nothing for Culture and Art collections.

Sure, you can search "Identification (scientific name)" for anything, but would an art person search there? Also, it just happens that minerals are also called "species" so they share that field with biological stuff, but art and cultrual collections will not share terms in that way. How can we offer them an appropriate search function for "identification"?

[AJLinn]

Cultural collections searchers are instructed to enter the term for which they are searching in the Identification box, while selecting "contains" from the Match type dropdown... we ignore everything else. All those terms like "family" "tribe" and "subtribe" cause confusion for Indigenous collections so we ask folks to not even look down there. To truly accommodate cultural collections we'd need an entirely different taxonomic structure for searching (akin to AAF or Nomenclature).

[mkoo]

Bumping up on issue list. We talked about a simple way to accommodate cultural/heritage users that will not require a separate search page.

@dustymc can add a second search box that can accommodate cultural searches. So instead of 'Scientific Name' it can use 'Cultural Term' -- or is there something better / preferred?

Perhaps 'contains' can be built into the search box so it's even simpler to use. It will be on the default search page next to the Scientific Name search box.

[AJLinn]

So instead of 'Scientific Name' it can use 'Cultural Term' -- or is there something better / preferred?

Maybe "object term" or "object name" ?
What do you think cultural colleagues? @marecaguthrie @krgomez @sjshirar

Perhaps 'contains' can be built into the search box so it's even simpler to use.

That would be awesome!

[krgomez]

I like "object type" since it's the standard term used by the CDWA and I think would work across cultural/art collections.

[mkoo]

I like 'Object Type' too
it would work for future Archives collection

[marecaguthrie]

Object Type sounds great. I think that is very clear that it is a type of object and not the title of an artwork/object.

On Thu, Dec 3, 2020 at 1:52 PM Michelle Koo ***@***.***> wrote: I like 'Object Type' too it would work for future Archives collection — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3262 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJKSRR5QP2KGFEKQQVB2TULSTAJBJANCNFSM4UMDFO7Q> .

-- Sent from Gmail Mobile

[sjshirar]

Object type sounds great to me, and I think having a 'contains' parameter built-in is also a great idea. On Thu, Dec 3, 2020 at 1:54 PM Mareca Guthrie <notifications@github.com> wrote:

…

Object Type sounds great. I think that is very clear that it is a type of object and not the title of an artwork/object. On Thu, Dec 3, 2020 at 1:52 PM Michelle Koo ***@***.***> wrote: > I like 'Object Type' too > it would work for future Archives collection > > — > You are receiving this because you were mentioned. > > > Reply to this email directly, view it on GitHub > <#3262 (comment)>, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AJKSRR5QP2KGFEKQQVB2TULSTAJBJANCNFSM4UMDFO7Q > > . > -- Sent from Gmail Mobile — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3262 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGWDEEPP5TMRX254RWSP2OTSTAJJBANCNFSM4UMDFO7Q> .

-- Scott Shirar Archaeology Collection Manager University of Alaska Museum of the North 907-474-6943

[Jegelewicz]

Add a new box to search cultural items

@campmlc suggests adding the choice for name type (but that is associated with the name). @dustymc suggests associating with the classification source.

@mkoo suggests a changing list of options depending upon interest.

@dusty suggests Term/Term-type/Source but allow multiple sources (@Nicole-Ridgwell-NMMNHS ) this is good for now! Let's test it Also, allow external sources? Dusty will look into it, if it's too hard, stick with the Arctos local sources, if it's easy, go ahead.

Let's do something in test to see if everyone is OK with it.

[Jegelewicz]

https://www.itis.gov/

[Jegelewicz]

From Issues meeting in December 2020 - related to #3258:

Broad idea - maybe have something that allows you to select which collection you are viewing: scientific, cultural, mineral and that puts in place specific search terms and fields.
What can we do in the short term? Figure out the use of scientific name -> taxon name
Have two different identification search boxes: one for earth and life science and one for cultural/art/people science/cultural heritage and art
More boxes!

[dustymc]

There's some new stuff in test. You can currently search on

• term
• term used as rank
• term used as rank by source

and any term-involving combination thereof.

It's allowing only local classifications - if we continue with #3311 we'll have to add those to the code table or cache from GN or something, and that could be added to this form. (Or I can do it now, but it does require some cache, pulling live source is slow.)

Multiple sources ("according to at least one of these") is allowed.

Name type (https://arctos.database.museum/info/ctDocumentation.cfm?table=cttaxon_name_type) is arbitrary and not useful for this; it only tells who created (or first claimed, for legacy) a name, not how it's used. See https://arctos.database.museum/name/Oar#Arctos and https://arctos.database.museum/name/Oar#NomenclatureviaArctos for example

[Jegelewicz]

It's complicated, but it works (at least for the couple of things I tried). Should we be consistent with our defaults or does "is" just make more sense here?

[Jegelewicz]

OOPS! Spoke too soon. Received this error:

An error occurred while processing this page!
Message: ERROR: canceling statement due to user request Where: SQL function "getlocalityattributesasjson" statement 1 SQL statement "select array_to_json(array_agg(row_to_json(t))) from ( SELECT SPECIMEN_EVENT.SPECIMEN_EVENT_TYPE as ST, getPreferredAgentName(SPECIMEN_EVENT.ASSIGNED_BY_AGENT_ID) as AB, to_char(SPECIMEN_EVENT.ASSIGNED_DATE,'YYYY-MM-DD') as AD, getPreferredAgentName(SPECIMEN_EVENT.VERIFIED_BY_AGENT_ID) VB, SPECIMEN_EVENT.VERIFIED_DATE VD, --SPECIMEN_EVENT.SPECIMEN_EVENT_REMARK, SPECIMEN_EVENT.COLLECTING_METHOD CM, SPECIMEN_EVENT.COLLECTING_SOURCE CS, SPECIMEN_EVENT.VERIFICATIONSTATUS VS, SPECIMEN_EVENT.HABITAT HB, COLLECTING_EVENT.VERBATIM_DATE RD, COLLECTING_EVENT.VERBATIM_LOCALITY RL, --COLLECTING_EVENT.COLL_EVENT_REMARKS, COLLECTING_EVENT.BEGAN_DATE BD, COLLECTING_EVENT.ENDED_DATE ED, LOCALITY.SPEC_LOCALITY SL, CASE WHEN locality.DEC_LAT IS NULL THEN null ELSE locality.DEC_LAT || ',' || locality.DEC_LONG END CD, CASE WHEN locality.MAX_ERROR_UNITS IS NULL THEN null ELSE locality.MAX_ERROR_DISTANCE || ' ' || locality.MAX_ERROR_UNITS END CE, CASE WHEN locality.ORIG_ELEV_UNITS IS NULL THEN null ELSE locality.MINIMUM_ELEVATION || '-' || locality.MAXIMUM_ELEVATION || ' ' || locality.ORIG_ELEV_UNITS END EL, CASE WHEN locality.DEPTH_UNITS IS NULL THEN null ELSE locality.MIN_DEPTH || '-' || locality.MAX_DEPTH || ' ' || locality.DEPTH_UNITS END DP, LOCALITY.MAX_ERROR_DISTANCE, LOCALITY.MAX_ERROR_UNITS, LOCALITY.DATUM DM, --LOCALITY.LOCALITY_REMARKS, LOCALITY.GEOREFERENCE_SOURCE, LOCALITY.GEOREFERENCE_PROTOCOL, LOCALITY.LOCALITY_NAME, --decode(LOCALITY.WKT_POLYGON,NULL,'','data available') hasLocalityWKT, geog_auth_rec.HIGHER_GEOG HG, --decode(geog_auth_rec.WKT_POLYGON,NULL,'','data available') hasGeographyWKT, getLocalityAttributesAsJson(LOCALITY.LOCALITY_id) LY, getCollEvtAttrAsJson(COLLECTING_EVENT.COLLECTING_EVENT_id) EA from SPECIMEN_EVENT, COLLECTING_EVENT, LOCALITY, geog_auth_rec where SPECIMEN_EVENT.collecting_event_id=COLLECTING_EVENT.collecting_event_id and COLLECTING_EVENT.locality_id=locality.locality_id and locality.geog_auth_rec_id=geog_auth_rec.geog_auth_rec_id and not exists (select locality_id from locality_attributes where locality_attributes.locality_id=locality.locality_id and attribute_type='locality access' and attribute_value='private') and SPECIMEN_EVENT.COLLECTION_OBJECT_ID=colObjId ) t" PL/pgSQL function getjsoneventbyspecimen(bigint) line 5 at SQL statement
Detail:
Check the Arctos Handbook for more information on errors.

This message has been logged as 67C339B7-7B23-4A6C-9BDE51FF96A5776F Please contact us with any information that might help us to resolve this problem. For best results, include the error and a detail description of how it came to occur in the Issue.

After this search:

[dustymc]

does "is" just make more sense here?

That's my theory - use the "anything" if you're looking for anything, use this if you're looking for something more specific.

error

Turn some crap off! It's test, I can't install pg_trgm so indexes are dicey, I can't install pg_cron so flat isn't properly caching. https://github.com/ArctosDB/internal/issues/65

[Jegelewicz]

Turn some crap off! It's test, I can't install pg_trgm so indexes are dicey, I can't install pg_cron so flat isn't properly caching.

Roger - that does it.

[ewommack]

Ok I've been playing with it, but I'm afraid I'm still failing to find that bus in the UAM collection. How would I use the new search terms to better find it?

[dustymc]

because

uses

https://arctos.database.museum/name/Bus

which has

[AJLinn]

And until we get more of the Nomenclature implemented in our records, I do this:

[ewommack]

Here's I what I get following @dustymc instructions in test:

and here's what I get following @AJLinn:

The problem is I was in test. I found in the non-test search :). Problem with the loaded data there in the test environment.

[Nicole-Ridgwell-NMMNHS]

Problem with the loaded data there in the test environment.

Same issue here, I was trying to run some test queries but had a hard time figuring out things to test since so little of our data is actually in test.

[dustymc]

Yay? Tentatively closing....