Cleanup Part location with more regular characters

[cjconroy]

Issue Documentation is http://handbook.arctosdb.org/how_to/How-to-Use-Issues-in-Arctos.html

Is your feature request related to a problem? Please describe. When searching for tissues in our collection, we need to know freezer, rack, rack position, box, and position in box. This means downloading the data through the Find Containers interface, flattening the data, then opening in excel or other tool.

Describe what you're trying to accomplish The resulting data, at least in this example, seems longer than necessary. Maybe it makes sense in computer language, but taking this data and transforming it so we can easily find a real, physical object means more work. Splitting columns, doing a lot of replace commands. Could this be simplified?

[ FRZ 3 ] LN2 Freezer 3 (freezer):[ MVZ4166 ] Frz3-G-46 (freezer rack):[ MVZ1679 ] Frz3-G-46-5 (freezer rack position):[ MVZ4905 ] MVZ4905 (freezer box):[ ] 23 (position):[ MVZ267905 ] MVZ267905 (cryovial):[ ] MVZ:Mamm:238000 tissue (95% ethanol) (collection object)

Describe the solution you'd like One thought is just less stuff in there, less redundancy, and perhaps more regular use of symbols, like ":" to offset data so that in Excel you can easily convert one column to multiple based on that.

Describe alternatives you've considered Maybe someone already has an excel tool for quick and easy conversion?

Priority Low.

[campmlc]

Yes, I agree that this is very cumbersome and I spend an inordinate amount of time converting this output to something students can use to pull tissues. Perhaps make the pathway format customizable by collection?

On Wed, Jan 6, 2021 at 5:46 PM cjconroy notifications@github.com wrote:

• [EXTERNAL]*

Issue Documentation is http://handbook.arctosdb.org/how_to/How-to-Use-Issues-in-Arctos.html

Is your feature request related to a problem? Please describe. When searching for tissues in our collection, we need to know freezer, rack, rack position, box, and position in box. This means downloading the data through the Find Containers interface, flattening the data, then opening in excel or other tool.

Describe what you're trying to accomplish The resulting data, at least in this example, seems longer than necessary. Maybe it makes sense in computer language, but taking this data and transforming it so we can easily find a real, physical object means more work. Splitting columns, doing a lot of replace commands. Could this be simplified? [ FRZ 3 ] LN2 Freezer 3 (freezer):[ MVZ4166 ] Frz3-G-46 (freezer rack):[ MVZ1679 ] Frz3-G-46-5 (freezer rack position):[ MVZ4905 ] MVZ4905 (freezer box):[ ] 23 (position):[ MVZ267905 ] MVZ267905 (cryovial):[ ] MVZ:Mamm:238000 tissue (95% ethanol) (collection object)

Describe the solution you'd like One thought is just less stuff in there, less redundancy, and perhaps more regular use of symbols, like ":" to offset data so that in Excel you can easily convert one column to multiple based on that.

Describe alternatives you've considered Maybe someone already has an excel tool for quick and easy conversion?

Priority Low.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/3333, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADQ7JBF6OXM4Q37OLIDZ3VTSYT76PANCNFSM4VYIN5TQ .

[dustymc]

This should probably be tossed back to https://github.com/ArctosDB/arctos/issues/1585

[KyndallH]

So I briefly looked through 1585 - it was long.

What if, instead of just a long string of text, we were able to get each field it's own column? It would have all the data but we could easily delete any columns we didn't need/want. Still trying to think how this would work when things have different # of child/parent relationships - may not work. But I agree, I spend a lot of time with "replace all" to get this manageable to print.

[dustymc]

get each field it's own column?

I think that's the normal situation of the data being more complex than a spreadsheet (or we'd just use something that looks like a spreadsheet to manage them!), and therefore trying to stuff them into a spreadsheet is going to be painful in some way.

[campmlc]

Can we add a " print label" field as distinct from label? I need a searchable label, but for printibg purposes "1" may be sufficient. And can we select which hierarchy categories print in the display?

On Fri, Jan 15, 2021, 10:06 AM dustymc notifications@github.com wrote:

• [EXTERNAL]*

get each field it's own column?

I think that's the normal situation of the data being more complex than a spreadsheet (or we'd just use something that looks like a spreadsheet to manage them!), and therefore trying to stuff them into a spreadsheet is going to be painful in some way.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/3333#issuecomment-761063977, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADQ7JBE7ZATNZPZAPCUIWLTS2BYY5ANCNFSM4VYIN5TQ .

[dustymc]

add a " print label" field as distinct from label?

Plausible

select which hierarchy categories print in the display?

I don't see a realistic path to that, other than removing the things you don't care about from the hierarchy, but maybe I'm not understanding something.

[KyndallH]

Yes on removing things you don't care about! I don't need to know that it is in the building or in the freezer room but I do need the label that tells me that it is on the 5th slot of a rack.

[campmlc]

Agree

On Fri, Jan 15, 2021, 10:20 AM Kyndall Hildebrandt notifications@github.com wrote:

• [EXTERNAL]*

Yes on removing things you don't care about! I don't need to know that it is in the building or in the freezer room but I do need the label that tells me that it is on the 5th slot of a rack.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/3333#issuecomment-761071446, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADQ7JBEPZMA4WOW4INSVFQTS2B2MNANCNFSM4VYIN5TQ .

[dustymc]

removing things you don't care about

So remove them! You're the only user of your object tracking data, if you don't need something then get rid of it.

If there is some reason to retain things you don't need, perhaps the user-supplied label (into which you can put whatever you want) would work.

I don't think any sort of "ignore some stuff" code anywhere in the shared UI can work.

[campmlc]

There is minimal info needed to locate a sample. I take the output such as given above and turn it into something like 5:3:7:31 for freezer: rack:box: position, to fit on my Excel spreadsheet to pull the tissues. This requires tons of search and replace to the original output, and sometimes introduces error.

On Fri, Jan 15, 2021, 10:23 AM Mariel Campbell campbell@carachupa.org wrote:

Agree

On Fri, Jan 15, 2021, 10:20 AM Kyndall Hildebrandt < notifications@github.com> wrote:

• [EXTERNAL]*

Yes on removing things you don't care about! I don't need to know that it is in the building or in the freezer room but I do need the label that tells me that it is on the 5th slot of a rack.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/3333#issuecomment-761071446, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADQ7JBEPZMA4WOW4INSVFQTS2B2MNANCNFSM4VYIN5TQ .

[campmlc]

We need to have labels that are distinct enough to be searchable, but we don't need that explicit info in the printed output.

On Fri, Jan 15, 2021, 10:29 AM dustymc notifications@github.com wrote:

• [EXTERNAL]*

removing things you don't care about

So remove them! You're the only user of your object tracking data, if you don't need something then get rid of it.

If there is some reason to retain things you don't need, perhaps the user-supplied label (into which you can put whatever you want) would work.

I don't think any sort of "ignore some stuff" code anywhere in the shared UI can work.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/3333#issuecomment-761076510, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADQ7JBDD3OQ5QBOVTFXE6LLS2B3QBANCNFSM4VYIN5TQ .

[KyndallH]

We also have to consider that beyond frozen tissue, people are using this data to also locate whole specimens. What I need to locate them in the freezer is different from what I need for a specimen. I don't need to know the room for a frozen tissue but for a specimen, I do.

@campmlc Are you saying don't print the labels and just the barcode? I need the labels in some places and barcode in other places.

[AJLinn]

We typically just need the location code, that is one-up from the label:

That said, I do like seeing the whole hierarchy because it quickly shows me if my students entered the parent-child relationships properly when they input it ~2 years ago (spoiler - they did not always do so).

I don't know about how we might use room codes for items not in our main collections range... the only other place I have a barcode that is not in our main collections room is my lab, but we will eventually be expanding our barcoding wings to other rooms (like exhibit galleries or other rooms in the building).

[campmlc]

That's why a print label would be useful as distinct from a label. I don't want to change the label values. But an abbreviated print label we could select to display or download in a form, ideally with the option of selecting which fields in the hierarchy to display or download in a particular report, would be useful.

On Fri, Jan 15, 2021, 10:52 AM Angela Linn notifications@github.com wrote:

• [EXTERNAL]*

We typically just need the location code, that is one-up from the label: [image: Screen Shot 2021-01-15 at 8 48 36 AM] https://user-images.githubusercontent.com/17605945/104760940-9374dc00-570e-11eb-9063-954cfa55f9f6.png

That said, I do like seeing the whole hierarchy because it quickly shows me if my students entered the parent-child relationships properly when they input it ~2 years ago (spoiler - they did not always do so).

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

[dustymc]

Agree with @campmlc, this is all good support for https://github.com/ArctosDB/arctos/issues/3333#issuecomment-761076510. I can't predict what's useful to any current or future user in any given context.

I still have no objection to "print label" - MAYBE I could develop some periodic script to help populate that, or you can bulk-edit it periodically or etc.

option of selecting which fields in the hierarchy to display or download in a particular report,

First and most importantly, the things you generally see in the UI aren't "fields." (They are, but it's the same field over and over. It looks and acts nothing like a spreadsheet, it's a true hierarchy.)

The reporter accepts container_id - you can develop reports that do WHATEVER, as always I'm happy to help with SQL and such, as long as we stay within the constraints of reality.

Alternatively if we're going to add alternate labels to containers, we could just add lots of them (which might lead to something a bit more complex than a column in a table - there are probably practical limits after which this becomes circular, but two "user label" fields instead of one seems workable).

Alternatively or in addition to that, you can still remove whatever you don't need from any part(s) of the hierarchy.

[campmlc]

We can't remove institution name and division info from the hierarchy, but we don't need it printed in the download, for example.

On Fri, Jan 15, 2021, 11:47 AM dustymc notifications@github.com wrote:

• [EXTERNAL]*

Agree with @campmlc https://github.com/campmlc, this is all good support for #3333 (comment) https://github.com/ArctosDB/arctos/issues/3333#issuecomment-761076510. I can't predict what's useful to any current or future user in any given context.

I still have no objection to "print label" - MAYBE I could develop some periodic script to help populate that, or you can bulk-edit it periodically or etc.

option of selecting which fields in the hierarchy to display or download in a particular report,

First and most importantly, the things you generally see in the UI aren't "fields." (They are, but it's the same field over and over. It looks and acts nothing like a spreadsheet, it's a true hierarchy.)

The reporter accepts container_id - you can develop reports that do WHATEVER, as always I'm happy to help with SQL and such, as long as we stay within the constraints of reality.

Alternatively if we're going to add alternate labels to containers, we could just add lots of them (which might lead to something a bit more complex than a column in a table - there are probably practical limits after which this becomes circular, but two "user label" fields instead of one seems workable).

Alternatively or in addition to that, you can still remove whatever you don't need from any part(s) of the hierarchy.

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

[Jegelewicz]

Just reading through this and it is the same issue we end up with in taxonomic classifications. How hard would it be to look at all of the rows once the data are flattened and first create a list of all of the unique container types, use these as "headers" in the output, then for each leaf node (collection object), put data in the appropriate header field. So for the initial example:

[ FRZ 3 ] LN2 Freezer 3 (freezer):[ MVZ4166 ] Frz3-G-46 (freezer rack):[ MVZ1679 ] Frz3-G-46-5 (freezer rack position):[ MVZ4905 ] MVZ4905 (freezer box):[ ] 23 (position):[ MVZ267905 ] MVZ267905 (cryovial):[ ] MVZ:Mamm:238000 tissue (95% ethanol) (collection object)

output would be

collection object	freezer	freezer rack	freezer rack position	freezer box	position	cryovial
MVZ:Mamm:238000 tissue	LN2 Freezer 3	Frz3-G-46	Frz3-G-46-5	MVZ4905	23	MVZ267905

If the second flattened thing was a loose box in another freezer

[ FRZ 2 ] LN2 Freezer 2 (freezer):[ MVZ4165 ] MVZ4904 (freezer box):[ ] 5 (position):[ MVZ267901 ] MVZ267901 (cryovial):[ ] MVZ:Mamm:238001 tissue (95% ethanol) (collection object)

Then you would get

collection object	freezer	freezer rack	freezer rack position	freezer box	position	cryovial
MVZ:Mamm:238000 tissue	LN2 Freezer 3	Frz3-G-46	Frz3-G-46-5	MVZ4905	23	MVZ267905
MVZ:Mamm:238001 tissue	LN2 Freezer 2			MVZ4904	5	MVZ267901

If necessary, headers could also include the barcodes. I feel pretty confident that an R script could be written to take output from Arctos in the format @dustymc describes here

First and most importantly, the things you generally see in the UI aren't "fields." (They are, but it's the same field over and over.

and convert it to the above. The question is can we create that same functionality within Arctos?

[Jegelewicz]

Of course, this will be complicated by the "magic" positions, but I hope we could deal with that...they must have some sort of identification in the database that would allow us to distinguish between a freezer box position and a freezer position.

[dustymc]

"magic" positions

Not sure what looks magical??

rt of identification in the database t

Not really.

[KyndallH]

Don't we already have this under part detail now?

[Jegelewicz]

Do we? Is everyone happy? If so - please close!

[Jegelewicz]

I think this is handled with part table download - tentatively closing.