Separate Part Name from Part Preservation

[campmlc]

Proposal to separate part name (e.g. "tissue") from part preservation (e.g. "frozen"). Posting this as new issue related to repeated earlier discussion.

From email string: These are clearly part attributes - they apply to parts, there can be many of them, they're determinations, they're time-dependent, etc. You can add them with the "add more" widget on data entry. We'll need to set up code table values before you can use them - that's fairly trivial, you can do it under edit code tables.

They can be bulkloaded with the parts bulkloader, and are in partdetail in specimen results/downloads.

I agree that preservation should not be confounded with part name. Getting it out affects lots of things (labels, the "tissues" search, data entry, etc.) so will need some discussion. Issue please.

---

Current status: https://docs.google.com/spreadsheets/d/1AY1EXQzKUSAg9EvZFjayTXcCBciXd_syCxt0GSX2tww/edit#gid=485619714 will serve as a migration path on 2021-07-01

[campmlc]

Previous issues: ArctosDB/arctos#212, ArctosDB/arctos#319, ArctosDB/arctos#352, ArctosDB/arctos#991, ArctosDB/arctos#1020, ArctosDB/arctos#1084, ArctosDB/arctos#1119, ArctosDB/arctos#1131, ArctosDB/arctos#1203, ArctosDB/arctos#1384

[dustymc]

Thanks @campmlc !

This isn't (yet...) a technical issue, so I'm unassigning me. The structure to do this all exists, I think we just have to work out how to use it (and/or decide if we can use it).

I think a model in which attributes of a physical object are in a 1-->many relationship with that object is "correct" (more correct, anyway) from a data modeling standpoint, but I'm also not entirely sure it's usable. Given the choice between correct and usable, I'll always (try to!) take usable.

ArctosDB/arctos#212, ArctosDB/arctos#991, ArctosDB/arctos#1020: maybe we should toss the whole part model and start blank-slate - the current model has known problems with no clear solutions.

Also for any developing wish-list: find all the ribs. They're currently under "rib" and "body" and "whole organism" and "embryo" and (sorta/maybe) "fossil" and ....

ArctosDB/arctos#319 got revived for and implemented as https://github.com/ArctosDB/arctos/issues/800. It's clearly "more correct" as preservation history than what we're proposing here (eg, "frozen" is ambiguous, TEMPERATURE at TIME isn't) but I think we decided it wasn't usable as part of the GGBN work.

ArctosDB/arctos#352 introduced the structure which allowed this.

ArctosDB/arctos#1084: https://github.com/ArctosDB/arctos/issues/1084#issuecomment-334190059 is the summary (we can't articulate what a "tissue" is).

ArctosDB/arctos#1119 is pretty much this and ArctosDB/arctos#319.

ArctosDB/arctos#1131 and https://github.com/ArctosDB/arctos/issues/1203 are a bit like https://github.com/ArctosDB/arctos/issues/1084#issuecomment-334190059 - we did some stuff, things definitely got better for it, but "is this a part?" still has a very arbitrary answer.

https://github.com/ArctosDB/arctos/issues/1384 just looks like another symptom of ArctosDB/arctos#319 to me - qualitative labels (excellent, rotten) for what is essentially quantitative data (time at temperature) are weird (albeit perhaps necessary if anyone's going to interact with the data!).

[dustymc]

find/make example in test, post here

[Jegelewicz]

AWG agrees separation would be better. Use a part attribute to maintain history. Add part attributes to data entry and bulkloader. Controlled vocabulary unless someone has a good reason not to. @dustymc ? put an example here for us to see how it will look.

[dustymc]

http://arctos-test.tacc.utexas.edu/guid/CHAS:Bird:17187

[Jegelewicz]

This doesn't look any different from what we have now.

I think we were expecting part=DNA preparation=frozen

[campmlc]

What this issue refers to is splitting "DNA" from "frozen", or any physical part from it's fixation or preservation medium. This means everything in parentheses needs to be transferred to one or more controlled vocabulary fields. In many cases, we will need more than one ("liver (95% ethanol, frozen)" = part name "liver"; fixation "95% ethanol", storage: "frozen".

If we use part attributes for this, I'd like them to be in an expandable dropdown so that we don't have to look at the entire list for each part unless we click "expand".

On Wed, Aug 1, 2018 at 1:33 PM, Teresa Mayfield notifications@github.com wrote:

This doesn't look any different from what we have now.

[image: image] https://user-images.githubusercontent.com/5725767/43544115-33fe1b4e-958f-11e8-9585-543e74540c20.png

I think we were expecting part=DNA preparation=frozen

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/1460#issuecomment-409694849, or mute the thread https://github.com/notifications/unsubscribe-auth/AOH0hHA_ZUeQBJBXB7ng9WSbeIuIIt0Rks5uMgKSgaJpZM4SXYNg .

[dustymc]

doesn't look any different

It's not, which is why I've been saying "go for it!" for some time now.

part=DNA preparation=frozen

That's just data and doesn't change any functionality. I'm happy to help with updates and such, if you want to do something in your collection or can convince other collections to come along or whatever.

expandable dropdown so that we don't have to look at the entire list for each part unless we click "expand".

I'm not sure what this means.

[campmlc]

Great. I believe we have consensus to make this a global change. So we would need you to split out everything in parentheses, and add a separate part preparation field that allows multiple concatenated searchable values into the parts view. This would need to be on same line as disposition, condition, etc. as follows: Part Name: "liver" Part Preparation: "95% ethanol; frozen" Part Disposition: "in collection" Part Condition: "good"

The last comment refers to the part attributes display. I am requesting to make this an expandable drop-down visible only when clicked, to reduce the overwhelming visual clutter on the page.

On Aug 1, 2018 2:00 PM, "dustymc" notifications@github.com wrote:

doesn't look any different

It's not, which is why I've been saying "go for it!" for some time now.

part=DNA preparation=frozen

That's just data and doesn't change any functionality. I'm happy to help with updates and such, if you want to do something in your collection or can convince other collections to come along or whatever.

expandable dropdown so that we don't have to look at the entire list for each part unless we click "expand".

I'm not sure what this means.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/1460#issuecomment-409702539, or mute the thread https://github.com/notifications/unsubscribe-auth/AOH0hE1zZNCQ_DX0tCTAGF4bnOaG_TGrks5uMgjJgaJpZM4SXYNg .

[dustymc]

consensus

I hope so, but this should definitely go to the group.

add a separate part preparation field

That is a part attribute; there's nothing to add.

multiple concatenated searchable values

Hu? http://arctos-test.tacc.utexas.edu/guid/CHAS:Bird:17187 has change over time.

You'd concatenate it into "postcranial skeleton (rotten, spiffy, rotten, spiffy)"??

part attributes display...visible only when clicked

I think that's a huge problem. The thing people actually look at just says "liver" so they request tissue samples or etc - the DATA are liver (in formalin, which you can't see). That seems like it's going to cause usability problems.

[campmlc]

The preservation is just as important as condition and disposition, so it should display on the main line of the part field. I don't care if is an attribute in the underlying data table. The data structure does not have to determine the visual display. I'm suggesting, as others have previously done, that having all the part attributes visible for all parts makes the visual display virtually impossible. So, add preservation as one of the cells in the top row, and if there is more than one value, concatentate them, as we do with the json string in part location path. Keep it in the attribute table too, if necessary, with the dates etc. But make the part attribute table optionally visible with an expand function. We could actually do the same with condition -and just show the most recent attribute value . . .

Happy to discuss this with the AWG, but we already have had multiple people complain about the messiness of the current attribute display.

On Wed, Aug 1, 2018 at 3:54 PM, dustymc notifications@github.com wrote:

consensus

I hope so, but this should definitely go to the group.

add a separate part preparation field

That is a part attribute; there's nothing to add.

multiple concatenated searchable values

Hu? http://arctos-test.tacc.utexas.edu/guid/CHAS:Bird:17187 has change over time.

[image: screen shot 2018-08-01 at 2 53 56 pm] https://user-images.githubusercontent.com/5720791/43551126-c2a679c6-959a-11e8-87b6-e1ec184f6e1f.png

You'd concatenate it into "postcranial skeleton (rotten, spiffy, rotten, spiffy)"??

part attributes display...visible only when clicked

I think that's a huge problem. The thing people actually look at just says "liver" so they request tissue samples or etc - the DATA are liver (in formalin, which you can't see). That seems like it's going to cause usability problems.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/1460#issuecomment-409737178, or mute the thread https://github.com/notifications/unsubscribe-auth/AOH0hMKA_dSDjpS8MnUIqtfmsiTA-PB_ks5uMiOpgaJpZM4SXYNg .

[dustymc]

preservation is just as important as condition and disposition

Moreso maybe, but it's a different type of data.

concatentate them, as we do with the json string in part location path

Those are different things - JSON is capable of carrying the "this is not the current determination" data and would satisfy my concerns.

In any case I think that's details - we're all merged on storing the data as part attributes, correct?

[acdoll]

I think we are asking to separate 'preservation' out as a different type of data so that we can have something like this:

That will allow multiple concurrent preservation types (and also could be tracked over time).

[campmlc]

Yes, that is my understanding. Thanks for the demo, Andy.

On Wed, Aug 1, 2018 at 6:49 PM, Andrew Doll notifications@github.com wrote:

I think we are asking to separate 'preservation' out as a different type of data so that we can have something like this: [image: image] https://user-images.githubusercontent.com/12507297/43556164-8e6b63a8-95bb-11e8-8dc5-f7187eb79083.png

That will allow multiple concurrent preservation types (and also could be tracked over time).

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/1460#issuecomment-409770092, or mute the thread https://github.com/notifications/unsubscribe-auth/AOH0hM06A2TYhbMYv1uLq1ln5MGOtKcMks5uMkyhgaJpZM4SXYNg .

[dustymc]

AWG:

• we DO want to do this for all Arctos
• minimize default info - add expand button - remember last action??
• default part name (latest attribute inf) [clicky2expand]

[campmlc]

Separate part from preservation; use part attributes, but show preservation as most recent preservation in part attributes. All/none expand/collapse of part attributes. Default is that they are not visible. AWG 8-9-18

[KyndallH]

Where are we with this??

[dustymc]

If we're forcing this on everyone, we need to let them know and I need a lookup table to make changes.

If you just want to use it, go ahead - this changes nothing in the model and has always been possible.

[Jegelewicz]

this changes nothing in the model and has always been possible.

I disagree. Parts are currently named "part (preservation)". This would be a pretty big change and it is one we have been asking for since I think June or July. I don't think any of us believe we have seen a demonstration of the requested change in action and perhaps this needs a committee to get it done.

[dustymc]

That is not a model change, it's just data (and perhaps accompanying authorities).

This may end up requiring a new "part preservation" (and maybe other stuff) code table(s) under http://arctos.database.museum/info/ctDocumentation.cfm?table=CTSPECPART_ATTRIBUTE_TYPE.

This may lead to form changes, but as always I very strongly prefer to build that around existing data - I'll tackle that after someone's used this.

If this involves controlled vocabulary, then it will work exactly the same was as "tissue quality." Tissue quality uses http://arctos.database.museum/info/ctDocumentation.cfm?table=CTTISSUE_QUALITY because http://arctos.database.museum/info/ctDocumentation.cfm?table=CTSPEC_PART_ATT_ATT.

If it involves free text, it will work exactly the same as "part location."

http://arctos-test.tacc.utexas.edu/guid/CHAS:Bird:17187 contains many controlled and uncontrolled part attributes, and should adequately demonstrate any possible arrangement that this could take.

[KyndallH]

It would be controlled text.

Pretty much what currently is in () in the part code table would become preservation. So blood (flash-frozen) would be blood with flash-frozen in preservation. Blood would simply be blood.

[dustymc]

preservation

There's an eternal argument about what's preservation and what's storage and etc. in there, but I'm pretty happy to ignore that for now if ya'll are.

currently is in ()

create table temp_pn_has_parens as select distinct part_name,
regexp_substr(part_name, '\(([^\)]+)\)', 1,1,NULL,1) stuff_from_parens
from ctspecimen_part_name where part_name like '%(%';

temp_pn_has_parens.csv.zip

create table temp_pn_parendata as select distinct stuff_from_parens from temp_pn_has_parens;

temp_pn_parendata.csv.zip

If you want to add and populate a description column to that I can create a code table.

Some of these should (probably?) be multiple attributes - "formalin-fixed, 55% isopropanol," "70% ethanol, frozen," etc.

[campmlc]

We want to get away from the multiple attributes, as that causes the exponential expansion of the code table. I had thought we'd use part attributes to track history and multiple fixation/preservation categories, and only have the most recent in the "preservation" display field. We are trying to simplify something with a complex history. Or, can we concatenate all the terms, so they can be chosen separately at data entry and added to over time in part attributes, but display as a concatenated preservation field when more than one term exists?

On Tue, Oct 30, 2018 at 4:44 PM dustymc notifications@github.com wrote:

preservation

There's an eternal argument about what's preservation and what's storage and etc. in there, but I'm pretty happy to ignore that for now if ya'll are.

currently is in ()

create table temp_pn_has_parens as select distinct part_name, regexp_substr(part_name, '(([^)]+))', 1,1,NULL,1) stuff_from_parens from ctspecimen_part_name where part_name like '%(%';

temp_pn_has_parens.csv.zip https://github.com/ArctosDB/arctos/files/2531928/temp_pn_has_parens.csv.zip

create table temp_pn_parendata as select distinct stuff_from_parens from temp_pn_has_parens;

temp_pn_parendata.csv.zip https://github.com/ArctosDB/arctos/files/2531931/temp_pn_parendata.csv.zip

If you want to add and populate a description column to that I can create a code table.

Some of these should (probably?) be multiple attributes - "formalin-fixed, 55% isopropanol," "70% ethanol, frozen," etc.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/1460#issuecomment-434496947, or mute the thread https://github.com/notifications/unsubscribe-auth/AOH0hEAynCLvSiVaPypSjq6q_IAS-Wzfks5uqNZWgaJpZM4SXYNg .

[dustymc]

multiple

If you mean "this and that" as one thing, agreed - that should be two attributes, "this" and "that" (and maybe some accompanying metadata that we can probably ignore most of the time).

most recent

I'm still not very comfortable with that - there'd be no obvious distinction between "55% isopropanol" and "55% isopropanol - but oh yea it was in formalin for years." It's not my data/this isn't my decision, but it still strikes me as wrong.

simplify

That's how we got to stuffing it all into a string!

concatenated preservation field

That seems better, although it's likely to be a little weird for some things. In any case, yes, I think we can abstract some stuff through interfaces.

(Oracle 12 speaks JSON natively and might be useful to simplify that sticking together and pulling apart, if we can figure out an upgrade.)

[Jegelewicz]

Started definitions in Google Drive: https://drive.google.com/open?id=1MyOtB1zrQHpO63pxMILDTUJgaTyZNEuC

[campmlc]

Here are my edits to the Part/Preservation split table. With a few exceptions as noted, I would agree with the recommendations to split multiple preservation types as separate part attributes, and to concatenate preservation types in the part preservation field in display field next to part condition and part disposition per Andy Doll's comment on Aug 1. @acdoll @KyndallH @Jegelewicz

https://docs.google.com/spreadsheets/d/1d-5cNQzhh5o2H9UrSNI-yfOAcgAAdwIlKuRhC5cDmus/edit#gid=997912679

[Jegelewicz]

Looks good, now I'll throw in my wrench. Should we just call the attribute "conservation" or should we have two attributes: "preservation" and "fixation"? Just want to think through this all the way before we combine stuff under a label that doesn't represent everything we are talking about.

[dustymc]

That wrench has been flopping around for a decade or so - https://github.com/ArctosDB/arctos/issues/1460#issuecomment-434496947.

Something similar is part of what got us here. There's an incredibly fuzzy line between a few relevant components - I think the old was "part modifier" and "part preservation" or similar. Condition is always hanging around and hurling rusty wrenches as well, and now part attribute "tissue quality" is involved too. There are terms which can defensibly be placed in any of those "fields." Using something arbitrary results in a factorial of the number of fields ways of saying something. (And the number of fields is now dynamic, so we're not limited to ONLY 24 ways of saying the same thing across 4 fields - with a couple attributes on a couple of them we can easily get to 6!=720 ways of saying the same thing.)

"Correct" is almost certainly separating preservation, storage, conservation, part modifier, etc. "Usable" may mean not doing that, or at least not doing that without drawing some sort of uncrossable line between the values we'll store in the various components. Given the choice between "correct" and "usable," I'll sort of always vote for usable.

[campmlc]

Ideally all of this would be most "correctly" tracked through object tracking/part history, where we'd have all the above - fixtation, preservation, storage, location, refill/topoff/remount/reframe/check dates and by whom, plus history of freezer temp logs or humidity levels etc etc. And then we could have a reciprocal link to this info from the parts table, rather than a full display. Regardless of where the data are being added and to what field, it would be most "usable" to have a single field on the parts table with some sort of summary, eg from the current edited table, with concatentated info.

For future, maybe we should require all parts to have a label, and all parts to feed through object tracking and check history?

On Fri, Nov 9, 2018 at 9:50 AM dustymc notifications@github.com wrote:

That wrench has been flopping around for a decade or so - ArctosDB/arctos#1460 (comment) https://github.com/ArctosDB/arctos/issues/1460#issuecomment-434496947.

Something similar is part of what got us here. There's an incredibly fuzzy line between a few relevant components - I think the old was "part modifier" and "part preservation" or similar. Condition is always hanging around and hurling rusty wrenches as well, and now part attribute "tissue quality" is involved too. There are terms which can defensibly be placed in any of those "fields." Using something arbitrary results in a factorial of the number of fields ways of saying something. (And the number of fields is now dynamic, so we're not limited to ONLY 24 ways of saying the same thing across 4 fields - with a couple attributes on a couple of them we can easily get to 6!=720 ways of saying the same thing.)

"Correct" is almost certainly separating preservation, storage, conservation, part modifier, etc. "Usable" may mean not doing that, or at least not doing that without drawing some sort of uncrossable line between the values we'll store in the various components. Given the choice between "correct" and "usable," I'll sort of always vote for usable.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/1460#issuecomment-437421231, or mute the thread https://github.com/notifications/unsubscribe-auth/AOH0hJU5KcGy827DhO4h4yDeYrvuB8cLks5utbJHgaJpZM4SXYNg .

[dustymc]

most "correctly" tracked through object tracking

Absolutely, but there was a decision to denormalize to part attributes.

reciprocal link to this info f

That's always been there.

require all parts to have a label, and all parts to feed through object tracking and check history

I don't think that's realistic - it would just make Arctos unusable for a bunch of collections.

[Jegelewicz]

Ideally all of this would be most "correctly" tracked through object tracking/part history, where we'd have all the above - fixtation, preservation, storage, location, refill/topoff/remount/reframe/check dates and by whom, plus history of freezer temp logs or humidity levels etc etc.

This would still be problematic for legacy data where none of that was ever recorded. I am totally OK with what has been agreed to in the Google sheet, just wanted to make sure we discussed this now rather than later. Sounds like the most usable method for now and will accomplish what is needed.

[campmlc]

Yes, I think we go with what we have for now. I do like the idea of incorporating more info via object tracking/history at some point - but honestly don't have any idea how that can be better integrated to be more usable.

On Fri, Nov 9, 2018 at 10:11 AM Teresa Mayfield-Meyer < notifications@github.com> wrote:

Ideally all of this would be most "correctly" tracked through object tracking/part history, where we'd have all the above - fixtation, preservation, storage, location, refill/topoff/remount/reframe/check dates and by whom, plus history of freezer temp logs or humidity levels etc etc.

This would still be problematic for legacy data where none of that was ever recorded. I am totally OK with what has been agreed to in the Google sheet, just wanted to make sure we discussed this now rather than later. Sounds like the most usable method for now and will accomplish what is needed.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/1460#issuecomment-437427871, or mute the thread https://github.com/notifications/unsubscribe-auth/AOH0hDfhPeOKmnVolbzzoMRAep6shxECks5utbckgaJpZM4SXYNg .

[dustymc]

To Do (& please make my terminology better!):

1) New code table ctpart_preservation (part_preservation NOT NULL, description NOT NULL) 2) Populate with part_preservation=EDITED, description=Definition from https://docs.google.com/spreadsheets/d/1d-5cNQzhh5o2H9UrSNI-yfOAcgAAdwIlKuRhC5cDmus/edit#gid=997912679 3) New entry "preservation" in https://arctos.database.museum/info/ctDocumentation.cfm?table=CTSPECPART_ATTRIBUTE_TYPE 4) New entry in https://arctos.database.museum/info/ctDocumentation.cfm?table=CTSPEC_PART_ATT_ATT (to make the attribute value-controlled) 5) pull MSB parts, separate part and preservation, update

• Map should mostly be in https://docs.google.com/spreadsheets/d/1d-5cNQzhh5o2H9UrSNI-yfOAcgAAdwIlKuRhC5cDmus/edit#gid=997912679 but there will probably be some stuff to deal with manually, multiple preservation, etc. 6) MSB will use, see if we need any additional forms/tools/whatever 7) update for all collections

[Jegelewicz]

Populate with part_preservation=EDITED, description=Definition from https://docs.google.com/spreadsheets/d/1d-5cNQzhh5o2H9UrSNI-yfOAcgAAdwIlKuRhC5cDmus/edit#gid=997912679

See my edits.

[dustymc]

Can we get rid of "unknown"? I don't think we need to go out of our way to say we don't know....

[Jegelewicz]

Hmmmm. It seems odd, but in a way may be useful. If we really don't know then it might be good to say so, otherwise the lack of a preservation attribute might be a red flag that we need to enter one (low quality data).

[dustymc]

Certainly not stopping anything, and this is an incredibly common thing, but it's still denormalization. If I find a "widget" I can't know anything about how it's preserved (despite the various "as is traditional..." and "the normal thing..." and etc. documentation floating around). If I find a "widget (pres=unknown)" I can't know anything about how it's preserved (despite someone telling me they have nothing to tell me). Two ways of saying one thing==>bad.

Oh well...

[dustymc]

Do NOT edit the spreadsheet - edits from now on will be ignored.

[dustymc]

Is there some distinction between

desiccated having all moisture removed using either heat or silica

and

mummified embalmed and wrapped in cloth or allowed to shrivel or dry up

??

[dustymc]

1-4 in https://github.com/ArctosDB/arctos/issues/1460#issuecomment-453289966 are implemented; this is usable in production.

formalin, 5% buffered and formalin, 4% buffered fell out due to having no definition - they can be added to the code table manually.

Is "fluid preserved" somehow usefully different than unknown/NULL?

[Jegelewicz]

Is "fluid preserved" somehow usefully different than unknown/NULL?

Sure! you know it isn't desiccated or mummified....

Not sure about keeping those two as separate terms, but others may have good reasons....I know that there is at least one "mummy" that was made naturally in the UTEP collections so really neither of those definitions apply to it.

[dustymc]

isn't desiccated or mummified....

I suppose that depends if air fits in your definition of fluid or not...

I think @KyndallH @amgunderson have some naturally-desiccated stuff too.

[dustymc]

isn't desiccated or mummified....

I suppose that depends if air fits in your definition of fluid or not...

I think @KyndallH @amgunderson have some naturally-desiccated stuff too.

@campmlc @Jegelewicz there's a new spreadsheet of MSB parts at https://docs.google.com/spreadsheets/d/1jTgHlcdu_bptiHx7FTK17PYUFfpHsrixfX_favM1kGc/edit#gid=25221597

PAREN_BIT - ignore PART_NAME - original part name - don't touch this, it's my path back BARE_PART - new part name, I'll probably need to create some of these PRES1 - preservation (from the last spreadsheet) PRES2 - preservation (because some will need two - feel free to add more columns if necessary)

http://arctos.database.museum/info/ctDocumentation.cfm?table=CTPART_PRESERVATION should be complete for preservation, but we can add stuff if necessary.

Vague plan from here:

1. update MSB specimens to this vocabulary
2. throw up a temporary trigger disallowing parentheses in parts for MSB (so you'll have to separate preservation)
3. do whatever we have to do to make this work for you
4. push to everyone else
5. delete parts with parentheses (and disallow them in the code table)

[Jegelewicz]

Soooooo. Let me complicate things.

For anything that cuurently has "YYYY, XXXX-fixed" should we have two attributes: "fixation" with the value "XXXX" "preservation" with the value "YYYY"

or are we going with two preservation attributes: "preservation" with the value "XXXX" "preservation" with the value "YYYY"

[dustymc]

fixation/preservation

https://github.com/ArctosDB/arctos/issues/1460#issuecomment-437421231

That's probably "correct" but I'd rather avoid the eternal "which is THIS?" debate (which inevitable ends up as a little of this, a little of that, and nobody can find anything).

The second option works for me.

[campmlc]

We could do second option and put "fixed" in attribute remarks.

On Mon, Jan 14, 2019 at 4:13 PM dustymc notifications@github.com wrote:

fixation/preservation

ArctosDB/arctos#1460 (comment) https://github.com/ArctosDB/arctos/issues/1460#issuecomment-437421231

That's probably "correct" but I'd rather avoid the eternal "which is THIS?" debate (which inevitable ends up as a little of this, a little of that, and nobody can find anything).

The second option works for me.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/1460#issuecomment-454199894, or mute the thread https://github.com/notifications/unsubscribe-auth/AOH0hPuMk-mk_NR8LcJLPAA_1oKeeo9Nks5vDQ8QgaJpZM4SXYNg .

[dustymc]

remarks

Why would anyone care? If the answer could possibly involve searching, remarks (free-text in general) isn't the solution. If people only care after they've found the specimen, that might work (even when you've inadvertently and inevitably entered "fxied").

I still need the spreadsheet in https://github.com/ArctosDB/arctos/issues/1460#issuecomment-453707026 filled out.

[KyndallH]

Dessicated is more a plant term and it is different because they actively dry their samples. If you just let it dry out by itself, it actually reduces the quality of the tissue. And yes, I think Aren has some mummified stuff.

[KyndallH]

Though I wouldn't mind mummified going away. That is a horrible term.

[campmlc]

how about "air-dried" vs "freeze-dried"? vs just "dry" which is - we don't know the exact method.

As for why anyone would care about remarks, yes, people may only care after they've found the specimen. For collection managers, this is the info I need to determine suitability of material for loans.

On Tue, Jan 15, 2019 at 12:37 PM Kyndall Hildebrandt < notifications@github.com> wrote:

Though I wouldn't mind mummified going away. That is a horrible term.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/1460#issuecomment-454522731, or mute the thread https://github.com/notifications/unsubscribe-auth/AOH0hB2856TTLMDl5lwjkcEDtwYk51uCks5vDi37gaJpZM4SXYNg .