Keywords

[OwenLonsdale]

“Keywords” in the CNC DB are essential to allow us to easily search for specimens associated with specific projects that often involve thousands of specimens. These also allow us to find many different categories of specimens, including those the are lost; fossils; have their genitalia dissected; sampled for DNA; from National or Provincial parks (year-end reporting for access to permits); in a specific curatorial process that must be monitored (eg. PhotoNotDB); or for any other number of reasons. We need these keywords to be associated with specimen records and we need them to be searchable. Thanks. • DNA • Donation • Geocoding Failed • Imported from BOLD • JHS AHE 2019 • JHS AHE Plate 5 • JHS NGS Syrphidae • Lost • NIS • NPP • Ontario Parks • PhotoNotDB • Pip Phylogeny • Question • blank • duplicate • fossil • genitalia dissected • illegible • no keyword • non-blank • on loan • private • public • removed from tissue collection (CPD'ed) • tissue collection • translate • unconfirmed id • unfinished • unidentified

[dshorthouse]

I see a blend of purposes here & so we'll have to reconcile these individual items with how they may be modelled as either tags or particular values with equivalent purposes as modelled in DINA. This too is a migration issue.

[OwenLonsdale]

I agree. We can certainly improve here.

[michellelocke]

I think they mostly get sorted into tags or projects (which is essentially a tag but would be good if they could be handled separately).

Yes a migration issue but we need to see these values populated now so we can test them out (and there is no project yet that I am aware of).

[dshorthouse]

Fair enough though I'd recommend we attempt to partition the kinds of tests we want to do. There's a difference at this stage of development between, "does this term go here?" vs "does this folksonomy/tagging work?", search and consequences when applied notwithstanding. This ticket is a good example of how these two kinds of evaluation overlap. I see notes to self, georeferencing status, material sample types, preparation types, loan status, acquisition/donation, public/private availability, all of which have separate homes in DINA. I suspect code in the CNC db has been written around particular terms here (there's consequences) & so they're not always a simple keyword to filter lists.

[michellelocke]

Blank and public/private are the only two with consequences.

Blank: doesn't count the record toward total number of records in database. These "blank" records are given a unique number but no other data. We make the records, and print the labels. When we add these unique number labels to a legacy specimen, then we populate the record and the blank keyword is automatically removed. The other consequence of the blank keyword is that, when filling in a "blank" record you are given the option to "update and next blank", so that you can automatically move to the next record's editing page, without saving, going to the next record, then opening the edit page. I do not believe this option is available without the tag of "blank". These are the operations that I can see it doing. I don't actually know what the programming says.

Public/Private: functions similar to DINA. Public, available to see by everyone internally and externally. Private, you must have permission to edit the record to see it (not available to all internal users).

No other keywords have a function. They are all purely tags so that we can search on a particular group more easily. Yes, some of these will be able to move to a different functionality in DINA. I am unsure if that will be a migration issue though, or something that we will work to clean after (ie: we would move to DINA as is, and then work to move some of these tags to a functionality later on).

[michellelocke]

The point of these tickets is that we want to see a complete database, with all the fields we need and values within dropdown menus. This is the only way we can know if it works and functions as needed. It is very difficult to imagine how it will function without the fields and values there.

[dshorthouse]

@michellelocke I appreciate that but we'll not all see a complete database until we launch into our first round of migration. It's at that point that we'll discuss and make managed attributes where and when necessary. We can make some now in this demo to play & get a feel for what that process will be like, but these will not be ported to the staging environment once that's built. We'll start from scratch there, with CNC-only data, iterate through focused rounds of migration, and once happy, it will precisely mirror what will be the production environment. That was the proposed plan at least, pending imminent decisions.

[michellelocke]

@dshorthouse I find it very difficult to accurately test the current iteration of DINA when I cannot fit all of my data into fields and see all the values I need. I think that this is a huge source of frustration on our end.

[OwenLonsdale]

Agreed Michelle. And it's not just about how we "feel" about the process - the frustration is a result of not being able to properly test in a methodological fashion. Trying to imagine data in a product with a fraction of the required functionality is hobbling our attempts to properly test and develop ideas, and in the end, it is also hobbling the developers' ability to develop a tool that will work in the real world. We all know the real testing only begins when we have a beta version and we can run with it with a variety of people in real-life situations. We have a workflow that best suits entomology, and it is not simply a situation of being comfortable with an inefficient system. We have refined a workflow through years of trial and error. We need to test using that refined workflow, which in DINA includes functionality not yet in place, and perhaps not yet even yet considered by the development team. Your concerns are valid David, but many of these concerns can be addressed in a subsequent round of development. We absolutely NEED things from DINA, including the above items; their ultimate position in the database can be finessed at a later date and we look forward to your input. We need to prioritize, and time is running out. No point in having a really nice espresso maker in our nice new home if the home doesn't yet have a roof or plumbing.

[dshorthouse]

Am in full agreement and I hope what I wrote was not disparaging. We've gone through the pain of modelling the parts of the foundation and how they connect...and there will be more of that when we discover cracks. What I've attempted to convey is that migration is not one-and-done. That does a disservice to everyone. It's a once in a career event. We will discover that parts of the foundation will need to support different walls. But, as I wrote, it's pending a decision about willingness to devote staff time.