Do we need directly-attached stable part identifiers?

[Jegelewicz]

Picking a specific part out of the pile is a lot of work. Once that happens, you can

• give it a unique identifier so you don't ever have to deal with any ambiguity again, or
• don't, and dig it out again the next time you need it

Barcodes, real or otherwise, serve nicely as unique identifiers. In this case, giving everything a barcode would mean you can add the attributes later, gives you a super-easy way to eventually add to the loan, and probably provides a pathway to whatever you mean by "loan subsamples in the same virtual container."

(I've been wondering if we need directly-attached stable part IDs for a while, and maybe we do - new Issue - but they're not available NOW and barcodes are.)

Originally posted by @dustymc in #3627 (comment)

[dustymc]

Thanks @Jegelewicz

Yay: every part could have a way of being uniquely identified, I could avoid some semi-expensive joins, having multiple parts in a "base" container wouldn't necessarily mean they can't still be individually identified.

Maybe not-so-yay: Barcodes are used for lots of things in addition to part IDs, this could be confusing when those are separated (or unstable - so useful only at limited scale - if that's somehow synchronized/maintained).

The "workaround" is containers which exist only for the purposes of serving as part identifiers (for which I'd recommend a dedicated container type). That's nice because it fits into all existing workflows and requires no development, but it also requires some setup (getting the parts into the containers). Perhaps some of that could somehow be automated.

[campmlc]

So we could auto assign all parts to a virtual container with an autogenerated stable identifier?

…

On Wed, Jun 2, 2021, 10:24 AM dustymc ***@***.***> wrote: * [EXTERNAL]* Thanks @Jegelewicz <https://github.com/Jegelewicz> Yay: every part could have a way of being uniquely identified, I could avoid some semi-expensive joins, having multiple parts in a "base" container wouldn't necessarily mean they can't still be individually identified. Maybe not-so-yay: Barcodes are used for lots of things in addition to part IDs, this could be confusing when those are separated (or unstable - so useful only at limited scale - if that's somehow synchronized/maintained). The "workaround" is containers which exist only for the purposes of serving as part identifiers (for which I'd recommend a dedicated container type). That's nice because it fits into all existing workflows and requires no development, but it also requires some setup (getting the parts into the containers). Perhaps some of that could somehow be automated. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3630 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADQ7JBDZPRSQZHYFCD55EQLTQZLNRANCNFSM457B2RAQ> .

[dustymc]

So we could auto assign all parts to a virtual container

Yes.

autogenerated

No, but maybe we could fake it by semi-automating containering uncontainerized parts in your collection(s) or something.

stable

That's up to you, but nothing in Arctos would change your containers (same as any other containers).

[Jegelewicz]

autogenerated

No, but maybe we could fake it by semi-automating containering uncontainerized parts in your collection(s) or something.

stable

That's up to you, but nothing in Arctos would change your containers (same as any other containers).

I think we should lean toward autogeneration and stability. Isn't this a path to the ultimate "material sample" that GGBN seeks?

[dustymc]

autogeneration and stability.

That's probably an argument for something more specialized than containers. I think my concerns all center around usability, as above. Nothing good documentation can't bridge....

If we're going there, some sort of resolvable ID - URLs, ARKs, some short Arctos alternate URL that we could buy (and which I'd use for things like JSON), or whatever - would be cool.

material sample

The "DWC community" seems to remain at least partially convinced that institution_acronym + collection_cde can do something (it can't) so I'm not really holding my breath, but there is a materialSampleID (https://dwc.tdwg.org/terms/#materialSampleID) with a sane definition in the "core" (extension?? IDK, and IDK how to know!).

GGBN

GGBN apparently has their own thing (https://terms.tdwg.org/wiki/GGBN_Material_Sample_Vocabulary), it does NOT carry an ID (that I can find).

In either case, I believe there's at least the presumption of dependence - I don't think it could ever be "correct" to show DWC:MaterialSample data without also showing DWC:Occurrence data (but I'm not DWCologist, maybe I'm not understanding something).

Arctos has no such inherent limitations, and it's common (at least in entomology) to just "cite" whatever's scribbled on the tube/pin/part no matter what else has been specified or agreed upon. This could be an opportunity for us to make "whatever's scribbled on the tube" something that browsers can use to get to the catalog record (or a subset of it). That comes back to the usability question - are CM's going to be able to use barcodes up to some point and then switch to "part IDs," or can we find a way to sync those so they don't have to (and what's that do for the possibility of buying pre-printed containers if so), or ???????????????????

[campmlc]

We have an incoming collection that wants to assign guids and separate part identifiers in the field at time of collection. They want to know if they can use their tissue identifiers for part barcodes. It would be ideal if we could somehow incorporate this, giving a stable material sample ID at collection, associated with a guide/url organism ID and occurrence ID . . . Right now the closet thing we have for this is barcodes, and they mostly work. But they are not / cannot be universally applied due to cost and resources. If Arctos could provide a list of stable part identifiers that could be downloaded and made into labels in advance and applied in the field, and linked to an organism ID, maybe we could bypass NK numbers and externally supplied barcodes?

…

On Wed, Jun 2, 2021, 11:33 AM dustymc ***@***.***> wrote: * [EXTERNAL]* autogeneration and stability. That's probably an argument for something more specialized than containers. I think my concerns all center around usability, as above. Nothing good documentation can't bridge.... If we're going there, some sort of resolvable ID - URLs, ARKs, some short Arctos alternate URL that we could buy (and which I'd use for things like JSON), or whatever - would be cool. material sample The "DWC community" seems to remain at least partially convinced that institution_acronym + collection_cde can do something (it can't) so I'm not really holding my breath, but there is a materialSampleID ( https://dwc.tdwg.org/terms/#materialSampleID) with a sane definition in the "core" (extension?? IDK, and IDK how to know!). GGBN GGBN apparently has their own thing ( https://terms.tdwg.org/wiki/GGBN_Material_Sample_Vocabulary), it does NOT carry an ID (that I can find). In either case, I believe there's at least the presumption of dependence - I don't think it could ever be "correct" to show DWC:MaterialSample data without also showing DWC:Occurrence data (but I'm not DWCologist, maybe I'm not understanding something). Arctos has no such inherent limitations, and it's common (at least in entomology) to just "cite" whatever's scribbled on the tube/pin/part no matter what else has been specified or agreed upon. This could be an opportunity for us to make "whatever's scribbled on the tube" something that browsers can use to get to the catalog record (or a subset of it). That comes back to the usability question - are CM's going to be able to use barcodes up to some point and then switch to "part IDs," or can we find a way to sync those so they don't have to (and what's that do for the possibility of buying pre-printed containers if so), or ??????????????????? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3630 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADQ7JBFB7YSEQGHKFD4R3RTTQZTOTANCNFSM457B2RAQ> .

[dustymc]

assign guids and separate part identifiers in the field at time of collection.

I haven't seen that work yet, but as long as they can keep their numbers straight it's not a problem for Arctos.

use their tissue identifiers for part barcodes

Sure, that's always been possible/recommended, and it (along with good procedures) might be an actual way to "keep their numbers straight."

they are not / cannot be universally applied due to cost and resources

You've lost me and that seems to conflict with above - explain, please.

If Arctos could provide a list of stable part identifiers

I'm still missing a big piece of the puzzle, but ARKs might be an easy way to get those.

If you'll settle for a bit less stable, grab a series of barcodes of whatever format you want and do WHATEVER with them - get them printed, print them yourself, attempt to transcribe them, ....

[Jegelewicz]

OK, this is probably crazy-talk because it occurred to me in the middle of night, but Arctos is cataloging occurrences (identification at a place and time) NOT collections (I have this thing from this occurrence). @dustymc is always hammering home that we are not cataloging the "item of interest" and this is absolutely true. Almost every prospective institution asks about catalog numbers like 12345.1 so that they can track the various parts associated with some thing (usually a plant or animal, but other stuff too with catalog number 12345) that they are managing. Because we are so focused on the event, the parts are secondary in the system.

The problem comes from the fact that for the majority of our collection managers, the parts are really the focus, but we don't number/track them well. We have now created the "part identifier" attribute to get around this, but it only creates more work for collections.

Barcodes are great - but they apply to containers, not parts and I think we need to keep that distinction.

I think we need to look at MaterialSampleID:

In the absence of a persistent global unique identifier, construct one from a combination of identifiers in the record that will most closely make the materialSampleID globally unique.

Would it be possible to construct such an ID with the object url + Arctos part number? Or should parts be assigned a "GUID" equal to the Catalog record "GUID" + part number? (Perhaps we need both, one for humans, the other for machines)

If Arctos could do this for us in a way that makes it easy for us, that would be GREAT. I think the thing we need to figure out is what this "part number" should be. While the part number assigned in the parts code table is nice, it isn't known until the part is entered. How can we best accomplish this?

[dustymc]

Because we are so focused on the event

That's mostly "just UI" - Arctos is truly normalized, seeing it as a part management system (with catalog records as metadata) is a valid viewpoint. (So is seeing it as an event system, if you want to go there.)

but they apply to containers, not parts

Again, parts are 100% containers. The current level of container that can have an exposed identifier isn't in a 1:1 relationship with parts so I'm not suggesting what we have fully does what we should be doing, but there is always and inevitably a container that is in the correct relationship with parts, and it might serve this purpose (depending on what precisely that turns out to be).

We have now created the "part identifier" attribute

The origins of that are a case study in how to not do science. Strongly suggest just avoiding that situation in exploring how to move forward.

one for humans, the other for machines

I don't think there's anything exactly wrong with that, but it will inevitably get used in the wrong context so I'd rather avoid it.

what this "part number" should be.

We need to figure out what it DOES before we think about what it looks like. Eg deleting catalog records (==destroying GUIDs) is fairly difficult (it would be impossible if I had my way) because those are "citable" - minting them comes with some implicit (it would be explicit in my little fantasy world) promise that they'll be suitable for certain purposes, and that demands certain behavior from the creators. "Minting" UUIDs (or internal keys, etc.) is an act of convenience - once they've served whatever purpose they've been created to serve they can be deleted and nobody cares. I think the first question is, which of those situations is more analogous to what should be done here?

If that answer turns out to be what I think, the second question involves our ability to live without (or with limited access to) 'delete part' buttons.