Replies: 16 comments
-
I greatly dislike "Verbatim Event Details" - that "node" is much more than that. The rest I could live with, I think, but it's extremely verbose. We should also be looking at APIs - they will not share this terminology. (And the above doesn't cover all non-API usage). Please do not make arbitrary changes; this needs planned.
It is remarks regarding the intersection of specimens - "catalog records" - and the event stack.
|
Beta Was this translation helpful? Give feedback.
-
OK - I have had a few nights of sleep to dream about this and here are some thoughts. First - I think that if the data entry screen were structured in the same way the catalog record is, there would be less confusion. (and I know it sort-of is, but in a different order) Beyond that, let's talk about the "event stack" I'm going to start with the top of the stack - the part where we assign an event to a catalog record, currently known as the "specimen/event" (I have been trying to rid us of specimen) Here is a comparison of all the ways we refer to sections of this part of the event stack:
So I can see why there is confusion but before we start changing stuff, I think we need to take a hard look at what this information is meant to convey and make sure that the labels fit. I'd like to see this whole part of the stack better reflect what it is actually doing - recording information about who, when, and why the associated event/locality are assigned to the object(s) or observation(s) this catalog record describes. If that is a poor description of what is going on, please give me a better one! FWIW documentation says this (and needs to get rid of "specimen")
A few other musings:
|
Beta Was this translation helpful? Give feedback.
-
It won't be - one has a fixed structure (with some "extras"), the other is purely data driven and has no limitations.
The entry screen has no order at all (and maybe some day other screens will be similar).
https://arctos.database.museum/tblbrowse.cfm?tbl=specimen_event
That's one of the original use cases for field-level documentation, but we don't follow it (nor do we have the tools to make that mostly-realistic). Maybe that should be merged with the table browser in some way. Also, context - which varies from UI to UI - matters, unless we want to be very verbose everywhere (which brings on a whole new batch of usability problems). In any case, I'd like to keep more of the very core documentation - "this table does THAT, this field means THING" - in the database itself, where it's available to APIs (including local UI). That's probably yet another Issue....
That's reflective of a lack of precision in recording events; events end up as "today, within a mile of here" and habitat within that event is "under a rotting log" and "bare vertical rock" and .... I doubt we can do much for legacy data, but we can certainly make recommendations to GPS-equipped collectors going forward.
Same as above, but also things like host being collected in a pitfall and parasites being collected in a Number Whatever Sieve (so not "fixable" via more precise place-time data). |
Beta Was this translation helpful? Give feedback.
-
I just mean the same order - right now locality is where collectors and identifiers are in the catalog record. If we could keep to the same general order, this would help, I think - but this is just one person's opinion. |
Beta Was this translation helpful? Give feedback.
-
... ever a user put it. |
Beta Was this translation helpful? Give feedback.
-
Fair enough. OK, here is the comparison for "collecting event" which is a misnomer, because it can also represent any of the other event types in https://arctos.database.museum/info/ctDocumentation.cfm?table=ctspecimen_event_type
A few thoughts on this:
|
Beta Was this translation helpful? Give feedback.
-
No argument, but that's Major Surgery (and I'm not sure I have better names).
@campmlc had some compelling reason, and the merge does handle the bulkloader (but not some spreadsheet on your desktop, of course).
https://arctos.database.museum/tblbrowse.cfm?tbl=coll_object_remark
No - but it should be moved to specimen_event, I think. Just a migration miss IIRC.
You cannot: https://arctos.database.museum/tblbrowse.cfm?tbl=bulkloader
Maybe plausible, certainly open for discussion, a few could be flattened as well, I think I'd prefer to pre-create named events and just use them (but IDK how that aligns with reality). |
Beta Was this translation helpful? Give feedback.
-
UMMMM |
Beta Was this translation helpful? Give feedback.
-
"extras" - if you see it in the builder, it's not an extra. |
Beta Was this translation helpful? Give feedback.
-
Sorry for my poor use of "extras" - my argument is still the same, if I can do this for a locality, it seems that I should also be able to do it for an event, either directly or via "extras". |
Beta Was this translation helpful? Give feedback.
-
And finally - comparison for locality
I need to add in the names for bulkload locality - but the tool 404s for me right now. See #4053 A few things here.
|
Beta Was this translation helpful? Give feedback.
-
>Datum is not included on the catalog record > who georeferenced and when t File a CT request
There's only one possibility, we gain nothing by recording it. |
Beta Was this translation helpful? Give feedback.
-
Get a template - there is no higher geography in it. |
Beta Was this translation helpful? Give feedback.
-
Screen Shot 2021-10-28 at 4 31 54 PM HMMMM I swear I saw one with coordinates but no datum - is it possible that it gets hidden when it is "unknown"? Guess not, I'm blaming that on late lunch... |
Beta Was this translation helpful? Give feedback.
-
A revised summary Locality
Event
Event Assignment
|
Beta Was this translation helpful? Give feedback.
-
But I think this has always been a problem what exactly does specimen/event remark mean? It has never been clear.
Anyway, change this to "Collection Object Remark" to match data entry
Change this to "Verbatim Event Details" to match catalog record (but see below)
Change this to "Verbatim Event Details" to match data entry
Change this to "Catalog Record Event Remark" on the catalog record
Change this to "Catalog Record Event Remark" in data entry
And also make appropriate changes to search. I can do all of this and let everyone see it in test.
Originally posted by @Jegelewicz in #3691 (comment)
Beta Was this translation helpful? Give feedback.
All reactions