Code Table Request - New Part Attribute = tissue source

[Jegelewicz]

Instructions

This is a template to facilitate communication with the Arctos Code Table Committee. Submit a separate request for each relevant value. This form is appropriate for exploring how data may best be stored, for adding vocabulary, or for updating existing definitions.

Reviewing documentation before proceeding will result in a more enjoyable experience.

• Issue Documentation
• Code Table Documentation
• Video Tutorial - Submit a Code Table Request

---

Initial Request

Goal: Describe what you're trying to accomplish. This is the only necessary step to start this process. The Committee is available to assist with all other steps. Please clearly indicate any uncertainty or desired guidance if you proceed beyond this step.

From work about to commence with tissues in UWBM:Mamm @jebrad and I would like to remove tissue type from part remarks for ease of search.

Proposed Value: Proposed new value. This should be clear and compatible with similar values in the relevant table and across Arctos.

tissue typesource

Proposed Definition: Clear, complete, non-collection-type-specific functional definition of the value. Avoid discipline-specific terminology if possible, include parenthetically if unavoidable.

A description or code designating The organ or part from which a tissue was derived.

Context: Describe why this new value is necessary and existing values are not.

I considered using part modifier, but that is controlled by a code table that would get ridiculously long and would end up mirroring part names if we went that route.

Table: Code Tables are http://arctos.database.museum/info/ctDocumentation.cfm. Link to the specific table or value. This may involve multiple tables and will control datatype for Attributes. OtherID requests require BaseURL (and example) or explanation. Please ask for assistance if unsure.

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

Attribute data type

free-textcategorical

Attribute value

cttissue_source with terms to be copied form current part names used as tissues

Attribute units

N/A

Available for Public View

Yes

Collection type: Some code tables contain collection-type-specific values. collection_cde may be found from https://arctos.database.museum/home.cfm

N/A

Priority: Please describe the urgency and/or choose a priority-label to the right. You should expect a response within two working days, and may utilize Arctos Contacts if you feel response is lacking.

UWBM has a paid person working under a grant - there is some urgency.

Available for Public View: Most data are by default publicly available. Describe any necessary access restrictions.

Yes

Project: Add the issue to the Code Table Management Project.

Done

Discussion: Please reach out to anyone who might be affected by this change. Leave a comment or add this to the Committee agenda if you believe more focused conversation is necessary.

@campmlc @mkoo @acdoll @ebraker @KyndallH

Approval

All of the following must be checked before this may proceed.

The How-To Document should be followed. Pay particular attention to terminology (with emphasis on consistency) and documentation (with emphasis on functionality).

• [ ] Code Table Administrator[1] - check and initial, comment, or thumbs-up to indicate that the request complies with the how-to documentation and has your approval
• [ ] Code Table Administrator[2] - check and initial, comment, or thumbs-up to indicate that the request complies with the how-to documentation and has your approval
• [ ] DBA - The request is functionally acceptable. The term is not a functional duplicate, and is compatible with existing data and code.
• [ ] DBA - Appropriate code or handlers are in place as necessary. (ID_References, Media Relationships, Encumbrances, etc. require particular attention)

Rejection

If you believe this request should not proceed, explain why here. Suggest any changes that would make the change acceptable, alternate (usually existing) paths to the same goals, etc.

1. Can a suitable solution be found here? If not, proceed to (2)
2. Can a suitable solution be found by Code Table Committee discussion? If not, proceed to (3)
3. Take the discussion to a monthly Arctos Working Group meeting for final resolution.

Implementation

Once all of the Approval Checklist is appropriately checked and there are no Rejection comments, or in special circumstances by decree of the Arctos Working Group, the change may be made.

Review everything one last time. Ensure the How-To has been followed. Ensure all checks have been made by appropriate personnel.

Make changes as described above. Ensure the URL of this Issue is included in the definition.

Close this Issue.

DO NOT modify Arctos Authorities in any way before all points in this Issue have been fully addressed; data loss may result.

Special Exemptions

In very specific cases and by prior approval of The Committee, the approval process may be skipped, and implementation requirements may be slightly altered. Please note here if you are proceeding under one of these use cases.

1. Adding an existing term to additional collection types may proceed immediately and without discussion, but doing so may also subject users to future cleanup efforts. If time allows, please review the term and definition as part of this step.
2. The Committee may grant special access on particular tables to particular users. This should be exercised with great caution only after several smooth test cases, and generally limited to "taxonomy-like" data such as International Commission on Stratigraphy terminology.

[dustymc]

I don't understand how your proposed solution addresses your problem. Free-text is free-text, moving it around doesn't change anything.

[ebraker]

I'm fine with moving tissue type to a dedicated field, but I agree, it would be nice if it were a controlled value.

[campmlc]

I believe this would also help MVZ as they currently put their tissue type in remarks? @cjconroy But agree that controlled vocabulary would be important. At MSB, we use tissue type as a part name - can this code table be used? However, I would not support changing our model to convert to part attributes for our institution. Even to consider would require outside funding. But happy for this option to be available for use.

[campmlc]

Consider implications of GGBN publication - I assume it is possible to use either model, as MSB and MVZ currently are doing. However, it may require alteration to the GGBN resource published to VertNet if we add new collections with data in new fields?

[Jegelewicz]

I proposed this because remarks can be messy and include things other than the type of tissue. I can ask UWBM:Mamm to use remarks - but it means a bunch of existing parts will need remarks added, which feels like a pain and Dusty will probably have to do for them. I will not ask them to use the various combo parts.

[jebrad]

A main driver of this request is our hope to encourage our museum's Tissue Collection to fully embrace Arctos. This would be an easier sell if Tissue Type was a bonafide Attribute rather than burled in the remarks with a bunch of other things.
I realize this is a minor problem, and we are open to other solutions. Not sure what @Jegelewicz means about the "various combo parts" but it sounds scary.

[dustymc]

I will not ask them to use the various combo parts.

Yay! (@jebrad you should be scared, great instincts!)

tissue type as a part name

I've proposed using ctspepcimen_part_name as an Attribute a few times. It would allow MSB's "hoof, eyeball, liver' parts to become something generic ('tissue' is nice) and just carry three standardized attributes. (And could be found with the three standard part names plus 'tissue'.)

If everyone-ish can agree to this and we can get all the organs out of part name (high hopes and all...) then that could be revised to a new 'subpartname' code table. (I think that pattern has worked well elsewhere, but IDK maybe it's way too coarse here. I'll take WHATEVER if it's a step towards normalization/discoverability!)

Any of those seem like a pretty simple update from here.

I'll agree that type-sorting is (sorta) useful and keeping one kind of remarks out of the GP mess could be viewed as a slight improvement, and I don't oppose that if it's what's available, but there should be clear expectations (and documentation) - you can still enter 'leevur' and never find it again. If there's any hope of standardization then I'd obviously prefer that.

[campmlc]

Combo parts are things like "heart, liver, muscle" in the same tube. Our collections do that at MSB to save on storage space, and the process goes back decades. Much better to have a single tissue type in a single vial - but that adds up quickly. We are gradually moving to change that, but we have hundreds of thousands of these . . . and current tools make it much easier to track and loan via a single container and barcode as a combo part. Possible to change this going forward, but it will take dedicated time and funding. I fully support the addition of this attribute - is there a reason we can't use a controlled vocab?

[jebrad]

Oh jeeze we have lots of tissue tubes that you would consider combo parts - This is going back decades, and going forward too. I think I need to find a simple way of handling these or else we will never get our GRC to fully embrace Arctos.

I don't think I have a problem with controlled vocab, but I probably wouldn't understand the pros/cons (same with Dusty's 2 suggestions: ctspepcimen_part_name as an Attribute, or "subpartname' code table) so I feel I should let other people figure out what's best for me since you have been spending years figuring out what is best for you. And I have the luxury of setting up the structure before I parse our data into it, so I would like to use your experience to make decisions that our current and future GRC managers will appreciate.

[campmlc]

Do you have a list of the tissue types and combos you would need to migrate? You could just use the part names for each tissue, as we do at MSB. Then if we eventually get consensus to make some change towards splitting combos, it would be consistent across collections.

On Tue, Mar 14, 2023 at 2:18 PM Jeff Bradley @.***> wrote:

• [EXTERNAL]*

Oh jeeze we have lots of tissue tubes that you would consider combo parts

• This is going back decades, and going forward too. I think I need to find a simple way of handling these or else we will never get our GRC to fully embrace Arctos.

I don't think I have a problem with controlled vocab, but I probably wouldn't understand the pros/cons (same with Dusty's 2 suggestions: ctspepcimen_part_name as an Attribute, or "subpartname' code table) so I feel I should let other people figure out what's best for me since you have been spending years figuring out what is best for you. And I have the luxury of setting up the structure before I parse our data into it, so I would like to use your experience to make decisions that our current and future GRC managers will appreciate.

— Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/5810#issuecomment-1468777772, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADQ7JBH6JHHCI6XBHYMG35LW4DG7JANCNFSM6AAAAAAVVWZI6U . You are receiving this because you were mentioned.Message ID: @.***>

[dustymc]

@jebrad wanna set up something that involves them? A maybe-quick chat seems like it might be useful.

We can do what @Jegelewicz initially suggested, but it's a relatively minimal benefit - "find things with the attribute" is really the only question that it can reliably answer (and maybe that's enough, it's a minor 'cost' as well).

You can just use remarks, which is even slightly less organized. I want to say that looks like a terrible idea to me, but MVZ does this and I've gone slogging around in their data looking for messes without much success a few times, so it does seem to be something that can work reasonably (I suspect in conjunction with good procedure).

If you can standardize - agree to spell 'liver' only one way - then we can find a mechanism to help. (And if we pick the wrong one we can flip it to the other - I don't see any scary traps here.) This seems most-defensible, but it may or may not be within reach, usable, etc., etc.

The only think I'm really opposed to is the 'combo part' thing. (And I don't mean the physical arrangement - everybody seems to have parts like that, nobody's got a time machine, oh well - I just don't want to deal with infinite 'heart, nosehair, femur' combopartnames, nor try to tell them from the parts where the stuff after the comma is a modifier, nor to have to write code to things that look like delimiters, nor to try to convince a user that a heart that's been in usually-cold-ish liverjuice for decades can do all the stuff one that's been stored separately can do, nor......)

[jebrad]

Ok - here is a list of most of the tissues we have (I am waiting on Sharon to return from holiday so she can help generate a complete list. But this has probably 98% of mammal tissues) - UWBMmamm_most_tissues.xlsx.zip

Column headings will change (obviously - these existing ones are bad). @Jegelewicz suggested that the current Tissue num will become Part ID, determined by agent "UWBM Genetic Resources Collection" We want this ID to be a single string, instead of prefix + interger (and I have other notes from that conversation with Teresa - including some github issues Teresa set up in [ArctosDB/data-migration].

Column Vials currently shows number of tubes AND tissue type. Separating out the numbers as "Number of parts" seems simple, but how we should handle the tissue type is the origin of this while issue.

Also: minor problems to be tackled later: Prep Type currently shows current temp, we want to make storage temp an attribute and eventually capture its history (eg -20 from Date until Date, then -80 starting at Date), but that would probably require digitization of data from catalogs (or procedural assumptions? can I estimate how long before it went into -80 based on how we probably did things back then?) Accession comments shows location of the part in the collection: that is lowest priority, and may be the last UWBM tissue info to incorporate into Arctos, since her location file also includes bird tissues which are not in Arctos.

Note that we have Elly from our IT office who will be helping us with the big RANGES mobilization work - our plan is that this "tissue fix" is her warmup to get up to speed with Arctos, so we hope to have her do much of the tissue spreadsheet fixing rather than asking Dusty.

Also note: @dustymc I think we should wait to "involve them" until we have more things figured out - it would not help the cause to do that just yet. Thank you!

[Jegelewicz]

UWBM unique tissue types

l m hl lkh lk sh sl klh h hlm hlk fetus hk lhk skin hlk, baculum k lh skh kh slk lkm lk, hm slk, m slk, hm slkhm embryo hklus, l minus 80°C lkhm kslh lkh, lkhm kl lhmk lm hlkm hm feet, tail dried skin lhr hkl brain lhkm

not really cleaned and roughly removed count from the field...

[Jegelewicz]

I have working issues for what @jebrad describes above here.

[jebrad]

@great-blue-heron

[Jegelewicz]

I've proposed using ctspepcimen_part_name as an Attribute a few times. It would allow MSB's "hoof, eyeball, liver' parts to become something generic ('tissue' is nice) and just carry three standardized attributes. (And could be found with the three standard part names plus 'tissue'.)

Once the new bulkloader is done, perhaps this could be an option? I think I would propose simply removing the combo parts from the part table, then just using the parts table as the values for tissue type.

So heart, liver, muscle would become

part= tissue part_attribute_1 = heart part_attribute_2 = liver part_attribute_3 = muscle

Is this palatable?

[campmlc]

This would require a major change in DGR workflows and likely additional modifications to multiple tools. It is not a simple change. If we had a sandbox to play in, I'd love to try it out to see all the ramifications. But doing it in production without evaluation is terrifying. Also don't have bandwidth for another major change in my day to day operations right now. Maybe if we can get all MSB reports fixed first.

On Thu, Jun 29, 2023, 3:50 PM Teresa Mayfield-Meyer < @.***> wrote:

• [EXTERNAL]*

I've proposed using ctspepcimen_part_name as an Attribute a few times. It would allow MSB's "hoof, eyeball, liver' parts to become something generic ('tissue' is nice) and just carry three standardized attributes. (And could be found with the three standard part names plus 'tissue'.)

Once the new bulkloader is done, perhaps this could be an option? I think I would propose simply removing the combo parts from the part table, then just using the parts table as the values for tissue type.

So heart, liver, muscle would become

part= tissue part_attribute_1 = heart part_attribute_2 = liver part_attribute_3 = muscle

Is this palatable?

— Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/5810#issuecomment-1613850077, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADQ7JBF3JAF73FQQ2FZ6YYTXNX2CRANCNFSM6AAAAAAVVWZI6U . You are receiving this because you were mentioned.Message ID: @.***>

[campmlc]

That said, I support adding the attribute. I just can't make the massive conversion of 700,000 samples and all our workflows right now. But my reports first please?

On Thu, Jun 29, 2023, 7:40 PM Mariel Campbell @.***> wrote:

This would require a major change in DGR workflows and likely additional modifications to multiple tools. It is not a simple change. If we had a sandbox to play in, I'd love to try it out to see all the ramifications. But doing it in production without evaluation is terrifying. Also don't have bandwidth for another major change in my day to day operations right now. Maybe if we can get all MSB reports fixed first.

On Thu, Jun 29, 2023, 3:50 PM Teresa Mayfield-Meyer < @.***> wrote:

• [EXTERNAL]*

I've proposed using ctspepcimen_part_name as an Attribute a few times. It would allow MSB's "hoof, eyeball, liver' parts to become something generic ('tissue' is nice) and just carry three standardized attributes. (And could be found with the three standard part names plus 'tissue'.)

Once the new bulkloader is done, perhaps this could be an option? I think I would propose simply removing the combo parts from the part table, then just using the parts table as the values for tissue type.

So heart, liver, muscle would become

part= tissue part_attribute_1 = heart part_attribute_2 = liver part_attribute_3 = muscle

Is this palatable?

— Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/5810#issuecomment-1613850077, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADQ7JBF3JAF73FQQ2FZ6YYTXNX2CRANCNFSM6AAAAAAVVWZI6U . You are receiving this because you were mentioned.Message ID: @.***>

[Jegelewicz]

This is really hitting me hard as I try to get incoming collections to make the best choice for managing tissues.

Here is a summary of my thoughts:

I have suggested a tissue type attribute for use in describing the source of tissue in this issue but the discussion in OGL data migration makes me think that "tissue source" or even more generic "source material" would be better because then it could be used for both tissue parts and DNA parts.

Still, I think the best option is to record the source first as a part, even if you don't have it or never did:

part = liver (disposition = used up) child part = tissue grandchild part = DNA

creates a very clear path as to where the DNA came from and is completely available right now. The argument that this "doesn't translate well into something searchable" may be true to some degree, but I think that is because we need a special search portal for tissues and this would be part of that (find records with "tissue" parts that are children of "liver" parts or "DNA" parts that have a parent part somewhere in the hierarchy that are "liver" parts could be a thing, but nobody has asked for that specifically).

Second best option would be (but is not available) to use a part attribute with a controlled vocabulary (but this would also possibly need to be repeated as child parts are created?):

parent part = tissue parent part attribute = source material; value= liver child part = DNA child part attribute = source material; value = liver

I suppose you could rely on the parent part attribute for the source material, but that takes things steps away and makes search more difficult and would also require a special search option request.

Third best option (and what most collections do now) is to use remarks

parent part = tissue (part remark = liver) child part = DNA

It would probably also pay to put "liver" in the child part remark for discoverability, but I don't think anyone does that. Of course this means that there is no possible way to find all tissues that are derived from liver because: liver, L, l, live, higado....

The real and almost insurmountable challenge is when the "tissue" in a tube is from more than one source part (heart, liver and muscle stuffed into a single tube). You can put all three parts in a container, but a child part cannot have three parents and while we do currently have some "combo" parts, they are not optimal for discoverability (and I would argue for deciding if you can actually dig the "liver" portion out to f the tube...). So any "tissue" created from that tube would need to be assigned to one of the parent parts.

This leads to the last option that is currently available, but I don't recommend it.

parent part = liver child part = DNA

This option does not make it clear that the liver is in fact "tissue". It is entirely possible that someone has a whole liver held for reasons other than "tissue". This confounds putting together "tissue" records for GGBN and makes it nearly impossible for anyone to "find all tissues in Arctos".

I already know that almost everyone hates my preferred solution because it is more work to enter data and creates "parts we don't have", to which I say the disposition of that liver part would be "used up". Arctos is a collection management system but it is also a data management system (and the data may be far richer than the actual physical objects in your care). You may have never even seen that part - but that doesn't matter, it is what your tissue came from and the best way to demonstrate that is this way.

End of my rant - and start of "can we compromise so that we have a single solution for handling tissue"?

The second best option in my opinion is a standard way to report the source of the tissue or DNA and this is what this issue is requesting. If we cannot share a code table between part names and an attribute, then let's make a second code table that has the same terms that we have in parts for the attribute (but PLEASE NO COMPOUND terms - those should be handled as discussed here).

We need to change something because - https://github.com/ArctosDB/arctos/issues/3699 and https://github.com/ArctosDB/arctos/issues/3654 are holding us back from participating in the broader community and finding the things we need to find.

I have written a million Github comments and a Google Doc about this. Can we finally DO something?

[dustymc]

I think "tissue" as a part name is just a synonym of "unknown." "Tissueness" comes from attributes, and will vary (wildly) across all sorts of things - one researcher might be fine with 'tissues' which have spent time in formalin and another might not be interested in anything that wasn't still twitching when it hit the liquid nitrogen. We're just making the data less accessible by trying to label things 'tissues' or 'not tissues.' (But, as mentioned, not having a simple label complicates https://github.com/ArctosDB/arctos/issues/3699)

(And "tissue" makes me think "source of DNA," but that probably doesn't scale very well either.)

If you've got a tube of liver, just call it liver. (Because it is!) If you've got a tube of "whatever you could scrape off" then call it what it is as well. "Tissueness" is a separate thing and should not be confounded with part name. Parentage might make things more useful or trustworthy or traceable or whatever, but also has nothing(ish) to do with pat name.

I don't think any of that has much to do with this issue - if there's some compelling reason to say your 'unknown' (tissue, whole organism, whatever) has some 'sub-part names' then this could go ahead. (But I think so far it's just a way to say "mixed mess" without saying 'mixed mess,' no?)

I definitely like "source material" better than "tissue source" (but 'component part' or something might be more consistent??).

From https://github.com/ArctosDB/arctos/issues/5810#issuecomment-1468655173, MVZ seems to get along fine with their free-text, I don't think they need drug into this (but of course are welcome if they want to play).

Can we finally DO something?

The compound parts are by far the squeakiest wheel, suggest we focus on them - I just can't see how this is going to be clean while those things are pluggin' up the toobs.

I was going to check usage, but I can't really tell 'modified' parts (mostly https://github.com/ArctosDB/arctos/issues/4049) from mixtures. (Can we force that through, such a fundamental thing shouldn't take 2++ years!!)

[campmlc]

Agree with using the actual part name instead of tissue - but I'm biased because that's what we do at MSB already. MVZ uses 'tissue". But yes, "tissueness" is determined by the part name and preservation history, e.g. never in formalin etc. This is how we publish to GGBN.

Agree with "source material" or "source" part attribute!

As for compound parts, here are my concerns based on the MSB genomics collection, which would be drastically affected. If we split a compound part such as "Heart,Kidney,Lung,Spleen", all tissues of which are all in a single cryovial in a single barcode with a single loan history and container history - into four separate parts each with the same barcode - and somehow add to each of these some means of designating that these are in the same cryovial - how exactly will that function for past and future loans and object tracking tools? I need to be able to add parts to a loan using barcodes and the loan item bulkloader. This is easy to do now. But if these are split, to my understanding the bulkloader will have no idea what to do and I lose the ability to bulkload loan items unless I track down the virtual container ID which I cannot see or confirm on a physical object to make sure I am attaching the correct part in the correct container. Also, I don't know what tissue type is being pulled from a vial of composite parts. So how do I know what "split" part to associate the loan with? I don't want the loan to be associated with all 4 parts - but I don't see how that would be avoided? Multiple this by hundreds of thousands of vials all with 4 decades of legacy composite parts and multiple loans per composite part . . . In addition, if I use object tracking tools to find all collection objects in a container, suddenly I get 4 times as many objects in my download, which no longer corresponds to the number of cryovials and can no longer be used for data quality checks?

For my collection, proposing to split composite parts would involve a massive update to completely rework existing tools and workflows with no guarrantee the tools would work and no guarrantee the data would survive the transition. It would require project management level data quality checks. I cannot handle another such process in one year. Am I missing something here?

[Jegelewicz]

I think "tissue" as a part name is just a synonym of "unknown."

OH GEEEEZ and I give up.

That is the truth, but NOT how the world operates? People want to find "tissue" as demonstrated by the incoming collection's comments:

people are more interested in knowing if it's a tissue sample (ie, can be used for genomic work) and then can take their pick of tissue type, when we happen to have multiple kinds (somewhat rare).

users are more likely to search for "tissue."

hard for us to identify our "vouchers" from our "consumable for genomic work samples."

("consumable for genomic work samples" aka tissues)

FWIW the compound parts have no bearing on my immediate need as the plan is to use the MVZ method if all of this discussion continues to fail. However - the incoming collection's preferred choice from my options above is

parent part = tissue parent part attribute tissue type = liver child part = DNA child part attribute tissue type = liver

Yo, I love this. This model is the closest to what we use at the moment. I love the attribute being specifically appended to the parent part. And the absence of the parent part = liver is useful wrt to the diagnostic part issue. My only grumpiness is at having to assign the attribute tissue type twice, but I can get over it.

As for

"Tissueness" comes from attributes, and will vary (wildly) across all sorts of things

Yes - and no two people have the same set of rules but all those people expect to find "tissue". The beauty of the tissue part is that people can start there (or if they prefer, they can start with EVERYTHING) and narrow down the "tissues" using other attributes as they see fit. Also, the tissue part is a signal that "this stuff can be destroyed in order to do research" which can also be a valuable place to begin if that is what you plan to do. Oh, I know that people can get DNA from a toe pad, but people who want to do that are going to search for skins....

[campmlc]

But a study skin of a bird or mammal is also tissue. As is the toe of a frog preserved in ethanol. We had a full task force devoted to defining "tissueness" for GGBN and for Arctos, and the solution is the intersection of part names and preservation. It allows for a lot of flexibility. I get loan requests all the time that include both "liver" samples and toe clips, so people are finding these now.

[dustymc]

@Jegelewicz are you suggesting that using part name "liver" for a tube of liver (and only liver) should be viewed as inappropriate?

People want to find "tissue"

Clearly, but I can't grasp how that's related to part name. If I chuck a rat into my stasis tube there's no defensible thing to call it other than whatever we're calling 'whole rat' when stasis tubes are invented, but it's still a really great source of 'tissues.'

FWIW currently I'm calculating "tissueness" for records - if one part has certain attributes and lacks others then the record can be found with the 'tissues' search option. That could be handled in some other way. (Moving it to individual parts would take a lot more CPU and a lot more storage, but would also make locating individual 'we think tissues' parts easier, which would make generating data for GGBN easier, for example.)

solution is the intersection of part names and

Absolutely not, part name is irrelevant. (Err, probably not, but close enough in collections that deal mostly with bio-stuff.)

[ebraker]

I think having parent/child relationships plus attributes (and adding inevitable preservation attributes on top of this) is way too much burden for data entry. We're pulling three tissues for each specimen and prepping multiple specimens at each sitting generally.

I'm of course fine with the status quo ("tissue") but I agree with Dusty and could go with this approach:

If you've got a tube of liver, just call it liver. (Because it is!) If you've got a tube of "whatever you could scrape off" then call it what it is as well. "Tissueness" is a separate thing and should not be confounded with part name.

Not sure if this gets at @Jegelewicz's original issue but want to deter us from creating a huge dependency tree...

[campmlc]

"close enough in collections that deal mostly with bio-stuff" - that would have to be true, otherwise a mineral preserved in ethanol would technically be tissue . . .

[campmlc]

I think having parent/child relationships plus attributes (and adding inevitable preservation attributes on top of this) is way too much burden for data entry. We're pulling three tissues for each specimen and prepping multiple specimens at each sitting generally.

We do this at MSB Mammals, but we have a data entry supervisor managing a crew of 5 students in addition to a collection manager.

I support creating the part attribute and allowing collections to use it best fits their workflows. As @ebraker says, this depends on individual collection needs and resources. As long as the samples are still discoverable, which would be improved by adding a part attribute so that data don't have to be put into part remarks!

[Jegelewicz]

are you suggesting that using part name "liver" for a tube of liver (and only liver) should be viewed as inappropriate?

This is how the OGL people want to view it - and internally, they could. Everyone else can do whatever they want.

Why do the OGL people want to do it that way? Because their collection is primarily tissue, but they do retain some "diagnostic parts" these are things kept in lieu of an entire organism that allow for morphological identification. These things should NOT be viewed as available for destructive research. The idea is that these parts will be cataloged as what they are (gill), but the stuff up for destructive sampling will be tissue, with the origin of the tissue described in part remark (although more ideally this would be a part attribute with a code table to keep things neat). Note that the diagnostic parts might be in the same preservative as the tissues and whatever we are currently using to decide if something is a "tissue" would flag them as such, placing them up fro grabs at GGBN - not something OGL would like to happen.

If "tissueness" is indeed separate from part name, then we should not have the part name tissue and we should have some way for collections to flag things as tissue or not tissue.

[dustymc]

Everyone else can do whatever they want.

Yes, but there are almost always functional implications to living in the fringes of about any complex model. (At the very least, we should probably have a Best Practices document.)

These things should NOT be viewed as available for destructive research.

So smack a 'not available for destructive research' label of some sort on them, don't hide them from the folks who want to do whatever's allowable!

but the stuff up for destructive sampling will be tissue

IT IS!! I don't think you'll convince me that if someone showed up one liver-but-not-like-that sample away from curing cancer they'd refuse to open up the special tubes!

https://arctos.database.museum/info/ctDocumentation.cfm?table=ctencumbrance_action#restrict_usage exists for this use case, but a new part attribute or disposition or something might work as well.

(How do we avoid sending holotypes out on 'grind it up and then....' loans? This doesn't seem like a novel problem.)

then we should not have the part name tissue

I've been saying that for a very long time....

and we should have some way for collections to flag things as tissue or not tissue.

Been there, done that, it works about as well as you'd think (==not at all, but more cryptic than just doing nothing!). I'm pretty confident that the current model is defensible.

It would be REALLY useful if these conversations could start with a description of the goals - https://handbook.arctosdb.org/how_to/How-to-Use-Issues-in-Arctos.html#pro-tips

[Jegelewicz]

goals

There is one that was placed here when this issue was created (for reasons other than some of the things we have been discussing)

From work about to commence with tissues in UWBM:Mamm @jebrad and I would like to remove tissue type from part remarks for ease of search.

And so I requested a part attribute to make searching for the source of tissue parts easier (and intuitive - who in the world world outside of Arctos would think to search in remarks and add "%" or whatever to find things?). Making it more reliable would have been even better, with a code table to keep the types neat, but that is asking way too much, because Arctos code tables are a HUGE sticking point all across the board.

But the time for that request has passed and all of UWBM:Mamm tissues are in Arctos as part = tissue and the source as some weird code in part remark. Jeff seems happy with that and OGL has agreed that they could work with it as well. Because we cannot make a change that appeases everyone and everyone seems OK with whatever they are doing (or going to do) and because I opened this issue, I think I should just close it and move on to getting something productive completed.

[Jegelewicz]

Closing this as we can just put the information in part name if we like.

[dustymc]

see 2023-09-21 AWG Code Table Committee discussion