Replies: 8 comments
-
|
Note that to add additional voucher information we would need to add a tag, value type of functionality to projects. For example, "Foray #": ["Joe's Creek", "Lake Nimmo", "Mt. Jason"] |
Beta Was this translation helpful? Give feedback.
-
|
Decided to change the overal concept from "Voucher Slip" to "Field Slip". |
Beta Was this translation helpful? Give feedback.
-
|
Realized yesterday that FieldSlips as currently conceived overlap heavily with the existing CollectionNumbers features. The most significant difference is that FieldSlips can have at most one Observation whereas there is a many-to-many relationship between CollectionNumbers and Observations. Current stats on CollectionNumbers: Total: 12773 A good example of an observation with multiple CollectionNumbers: https://mushroomobserver.org/546746. It has both a number for SOMA Camp and for iNat. The most extreme example at the moment is: https://mushroomobserver.org/317677. The most extreme example of a CollectionNumber with multiple Observations: https://mushroomobserver.org/collection_numbers/5636. These are a set of puffball observations for various different species. This seems like it should be Project. What needs to get resolved to merge the two concept is what to do with the CollectionNumbers with multiple Observations. Creating distinct Projects for each case would be the simplest thing to do. However, I'm not sure this make sense for cases where there are just two Observations. Here's a distribution of the number of CollectionNumbers by the number of associated observation: |
Beta Was this translation helpful? Give feedback.
-
|
Review of CollectionNumbers with the most Observations: As yet unreviewed: |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Looking through the CollectionNumbers with 3 observations, I found that a lot of them are different observations of the same taxon. Often from the same day. E.g., https://mushroomobserver.org/collection_numbers/10273. Should these be different observations if they are going to share the same collection number? |
Beta Was this translation helpful? Give feedback.
-
|
Now that I've dug deep into this, here's a proposed plan:
|
Beta Was this translation helpful? Give feedback.
-
|
After all the above analysis and yet more thinking, I've concluded that Collection Numbers and Fields Slips actually serve different purposes and should be kept separate. The key differentiators are:
|
Beta Was this translation helpful? Give feedback.
-
An important process that happens at mycology related events is vouchering. This typically involves giving each participant a small pad of paper forms that they are expected to either fill out in the field or once they get back to the identification area with their collections. The most important information for the field slip is what day the collection was made, where it was made (often a foray/walk number or a locality near where the event happens), and who made the collection. These days field slips typically have a foray code and a unique number. For example, NAMA-NC23-1729 or TMF-2022-248. There are also often boxes for adding online identifiers such as the observation number for either MO or iNat. Additional information typically on these forms include a name, the initials of the identifier (typically an event mycologist), habitat checkboxes, and a place for notes.
Examples: https://mushroomobserver.org/images/1592453 (NAMA-NC23-1729) and https://mushroomobserver.org/images/1486355 (TMF-2022-248)
At the 2022 Telluride Mushroom Festival, Andy Wilson mentioned that providing a more reliable way to get from the field slip to the online observation would be a significant improvement over the current way that field slips are processed. I played a bit with trying to read field slips like the TMF one as they are and was not particularly successful. I think it could be achieved with optical character recognition and/or barcode reading software, but it wasn't straight forward. We talked a bit about maybe using QR codes, but I didn't really pursue it at the time.
I recently realized that QR codes could in fact very neatly solve the problem. If the QR code was of an MO URL that included the for code and the unique number, we could use it to first create an object in MO (let's call it a FieldSlip) and an associated MO Observation. If such objects already exist, then the QR code could take you to the appropriate page. This would eliminate the need for writing down the MO id entirely. The QR code on the field slip could be used later to get back to the online observation. We could also add the ability to search for the foray identifier from the MO search box.
The huge advantage of QR code is that most mobile phones can automatically read them either from the live camera or from a stored image. In addition they can be easily generated by MO. It would also be relatively easy to add a field slip generator to MO. I've experimented with creating a QR code that contains the URL https://mushroomobserver.org/field_slip/nemf-2024-123. It is readable from printed page using less than a 1 inch x 1 inch square. Reading QR codes from stored images in the MO backend is not simple, but there are good JavaScript libraries that could be utilized to read them as they get uploaded into MO.
Once that functionality exists, we could expand the functionality to allow users to directly fill out additional field slip information directly in MO. This could avoid having to have event mycologist write down ids with pen or pencil helping to make the data more readable and no longer requiring the event recording from transcribing the information. If the code is included with any DNA sample that is taken, this would provide an easy reliable way to find the appropriate place to record the results and get to any potentially relevant information about the collection.
Another interesting question is how the system should act if a field slip from an event is used after the event. I think this could fold into the existing MO Project work where project admins could turn off the ability for non-admins to add field references and observations to a project. We should also give the user the option to not add the resulting field slip reference and observation to any associated project.
Beta Was this translation helpful? Give feedback.
All reactions