Tracking georeferenced by and date georeferenced #1705
Comments
|
The "assigned..." fields in specimen event exist for this purpose. Verified... are a different sort of thing. |
|
Gotcha, that definitely helps. http://handbook.arctosdb.org/documentation/specimen-event.html
To me, the documentation is saying that "assigned" fields refer to asserted relationships between a specimen and the place/time stack, rather than an asserted relationship between the coordinates and a given locality. I think it would still be nice to record the latter. While Georeferenced By and Event Determiner might at many times be the same person, if, for example, I wanted to assign my specimen's collecting event to a locality that had been georeferenced by someone else, Georeferenced By and Event Determiner are different agents. |
Yea, probably - it's always a tradeoff between clarity and screen real estate and I'm always up for better ideas. There's a lot more discussion about the locality model in #752 |
|
I've made this case before. While a single locality might have MANY
different people verifying the specimens associated with it (from many
different collections/ institutions), there is currently no indication on
the locality record page to know who assigned the current geocoordinates
with that locality.
Below the locality geocoordinates are metadata fields like "Datum" - the
person who fills those fields out and assigned the geocoordinates to that
locality should be listed as part of that metadata (along with the date).
…-Derek
On Fri, Sep 21, 2018 at 12:59 PM dustymc ***@***.***> wrote:
camouflaged
Yea, probably - it's always a tradeoff between clarity and screen real
estate and I'm always up for better ideas.
There's a lot more discussion about the locality model in #752
<#752>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1705 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AIraM1c6MVi3HftlGmEXQKyc1kiaLZpPks5udVMzgaJpZM4W0xJD>
.
--
+++++++++++++++++++++++++++++++++++
Derek S. Sikes, Curator of Insects
Professor of Entomology
University of Alaska Museum
1962 Yukon Drive
Fairbanks, AK 99775-6960
dssikes@alaska.edu
phone: 907-474-6278
FAX: 907-474-5469
University of Alaska Museum - search 400,276 digitized arthropod records
http://arctos.database.museum/uam_ento_all
<http://www.uaf.edu/museum/collections/ento/>
+++++++++++++++++++++++++++++++++++
Interested in Alaskan Entomology? Join the Alaska Entomological
Society and / or sign up for the email listserv "Alaska Entomological
Network" at
http://www.akentsoc.org/contact_us <http://www.akentsoc.org/contact.php>
|
Agree. This is driving me crazy right now as I attempt to bulkload a bunch of stuff that was georeferenced after the fact by someone other than the person who I consider to be the Specimen Event Assigner (the collector). If I could just put the georeferencer's name in a dedicated field in the locality, everything would be so much easier. Right now I am struggling with how to get the original information in, then go back and add the georeference without creating somewhat duplicate localities (one with and one without coordinates). |
|
It would also be nice to have a field for Georeference remarks. Some of my georeferencers made detailed notes about how they converted from a description to coordinates. These could be very useful for anyone fact-checking... |
|
I don't really have objections to going to a less-normalized model, but we should all be aware of the functional implications of denormalization. Given a GPS firmly affixed to the planet, you and me reading it at the same time is two localities, you reading it now and {something outside the precision of your temporal data} later is two localities, remarks "Remark" and "remarks" are two localities, etc. That makes it that much harder for users to find specimens, and it means that much more work when a bunch of specimens from what should be the same place are scattered across many localities. I'm happy to talk about locality models that better do whatever ya'll are trying to do if that seems like an acceptable tradeoff. If we're adding "georeference..." stuff, we should also add whatever the opposite is called. One of the fatal flaws of the old model was the structural assumption that spatial data comes only in string form, and coordinates can only be derived from that. That is not true and cannot be reintroduced in any form. You are not limited to "the" event assigner. Enter the data as you got them and attribute that to whoever made them, add another determination for the georeference and attribute that to the georeferencer. In many cases georeferences are wrong and tossing out the original data (or mixing it up with derived data) permanently reduces the usability of the specimen. I don't think any of us would throw out "50 people looked at this thing using 50 techniques and they all agree it's {taxon}" data - why throw out the same sort of information in spatial data? |
|
Yeah, I hear you and that is what I did for a bunch of stuff previously. It makes sense, it's just so much work! Which is why it's probably better.... I'll suck it up. |
|
From #729
I think this is something that we need to continue discussing. |
|
Not having a solid model is blocking #1357, so I'm elevating priority. Points for consideration:
|
Is there a DWC term for a more general geospatial coordinate determiner? Being able to associate an agent to coordinates for a locality--no matter if the coordinates are native to that locality or derived from a string--would be useful in vetting data quality. Being able to record whether or not coordinates are derived would also add curatorial value. Maybe this is just a matter of making the locality determination history more explicit on the locality editing page? For example, display a "last edited by" field and have it searchable using Find Locality. |
Not that I'm aware of
once upon a time GEOREFERENCE_SOURCE was things like "GPS (download)" and "collector notes" but it became free-text (so not searchable) somewhere along the way. We could probably do more with http://arctos.database.museum/info/ctDocumentation.cfm?table=CTGEOREFERENCE_PROTOCOL.
From the perspective of specimens, the specimen event determiner asserts that the locality and the specimen have something to do with each other in both models, and that's the place where I'd consider people in the context of data quality - although I'm obviously not understanding SOMETHING. |
|
Dusty,
Imagine a data table of just locality place names but no specimens linked
to them.
Now imagine that I go through that list of place names and add
geocoordinates to each (ie I georference them).
I also record max error, datum, georeference source, and georeference
protocol but there are no specimens *so how do I record that I was the one
who did all this work*?
Is such a scenario plausible? Of course - imagine one sets up a project and
designates 100 different collection localities before collecting any
specimens. One wants to enter into Arctos those localities so they're ready
for specimens when they arrive.
Whatever explanations have been offered as to why we don't record the agent
name of who did the georeferencing and the date it was done have never made
sense to me.
See my vision attached. I didn't create a fake georeferenced date field but
it should be there too of course.
…-Derek
On Thu, Oct 11, 2018 at 4:19 PM, dustymc ***@***.***> wrote:
more general geospatial coordinate determiner
Not that I'm aware of
record whether or not coordinates are derived would also add curatorial
value
GEOREFERENCE_SOURCE VARCHAR2(4000)
GEOREFERENCE_PROTOCOL VARCHAR2(255)
once upon a time GEOREFERENCE_SOURCE was things like "GPS (download)" and
"collector notes" but it became free-text (so not searchable) somewhere
along the way.
We could probably do more with http://arctos.database.museum/
info/ctDocumentation.cfm?table=CTGEOREFERENCE_PROTOCOL.
last edited by
From the perspective of specimens, the specimen event determiner asserts
that the locality and the specimen have something to do with each other in
both models, and that's the place where I'd consider people in the context
of data quality - although I'm obviously not understanding SOMETHING.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1705 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AIraMyXgE8sAfcjvK9b2sQLqMuW0aawxks5uj-ANgaJpZM4W0xJD>
.
--
+++++++++++++++++++++++++++++++++++
Derek S. Sikes, Curator of Insects
Professor of Entomology
University of Alaska Museum
1962 Yukon Drive
Fairbanks, AK 99775-6960
dssikes@alaska.edu
phone: 907-474-6278
FAX: 907-474-5469
University of Alaska Museum - search 400,276 digitized arthropod records
http://arctos.database.museum/uam_ento_all
<http://www.uaf.edu/museum/collections/ento/>
+++++++++++++++++++++++++++++++++++
Interested in Alaskan Entomology? Join the Alaska Entomological
Society and / or sign up for the email listserv "Alaska Entomological
Network" at
http://www.akentsoc.org/contact_us <http://www.akentsoc.org/contact.php>
|
|
@DerekSikes the attachment didn't make it. You've described what MaNIS (and a bunch of later initiatives) do/did. Those data have been repatriated as full localities with the georeferencer as specimen-event determiner. http://arctos.database.museum/guid/UAMb:Herb:20997 currently looks like this:
The georeference (from a TCN) is off by a continent or two and has a lichen hovering over saltwater, but note how they provided the georeference, the string that was georeferenced (pulled from OCR, I think), elevation, etc. - the model can support a lot more than simply adding coordinates to strings. http://arctos.database.museum/guid/CHAS:Bird:15397 (georefed by Ornis, I think) is a little closer to how that's supposed to work, and came with a determiner. Locality (nick)name exists in part to make pre-creating localities easy - I don't foresee any changes there no matter what model we ultimately end up in. My concerns in this are that I have to explain it to new collections, and perhaps clean up their data. Cleaning up any data is likely to be more work under a denormalized model just because there will be more rows, but I can roll with that. I'm struggling to see any functional benefits to denormalizing; I'm not opposed to the idea, but I do need to better understand what we're trying to do here before I can design a model that does whatever ya'll are trying to do, write interfaces to it, or explain it to anyone. @AdrienneRaniszewski - I think you've probably spent more time chasing almost-duplicates (minor variations in date, jumping around between several members of an expedition as georeferencer, etc.) than anyone else - thoughts on this? |
|
why does adding georeferencedby and georeferenced date denormalize?
…On Fri, Oct 12, 2018 at 7:49 AM, dustymc ***@***.***> wrote:
@DerekSikes <https://github.com/DerekSikes> the attachment didn't make it.
You've described what MaNIS (and a bunch of later initiatives) do/did.
Those data have been repatriated as full localities with the georeferencer
as specimen-event determiner.
http://arctos.database.museum/guid/UAMb:Herb:20997 currently looks like
this:
[image: screen shot 2018-10-12 at 7 51 24 am]
<https://user-images.githubusercontent.com/5720791/46876615-aa237e80-cdf3-11e8-8d51-285173eac40a.png>
The georeference (from a TCN) is off by a continent or two and has a
lichen hovering over saltwater, but note how they provided the
georeference, the string that was georeferenced (pulled from OCR, I think),
elevation, etc. - the model can support a lot more than simply adding
coordinates to strings.
http://arctos.database.museum/guid/CHAS:Bird:15397 (georefed by Ornis, I
think) is a little closer to how that's supposed to work, and came with a
determiner.
Locality (nick)name exists in part to make pre-creating localities easy -
I don't foresee any changes there no matter what model we ultimately end up
in.
My concerns in this are that I have to explain it to new collections, and
perhaps clean up their data. Cleaning up any data is likely to be more work
under a denormalized model just because there will be more rows, but I can
roll with that. I'm struggling to see any functional benefits to
denormalizing; I'm not opposed to the idea, but I do need to better
understand what we're trying to do here before I can design a model that
does whatever ya'll are trying to do, write interfaces to it, or explain it
to anyone.
@AdrienneRaniszewski <https://github.com/AdrienneRaniszewski> - I think
you've probably spent more time chasing almost-duplicates (minor variations
in date, jumping around between several members of an expedition as
georeferencer, etc.) than anyone else - thoughts on this?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1705 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AIraM9DoeQF3jOwInmKozmj8nK5_OxUMks5ukLn5gaJpZM4W0xJD>
.
--
+++++++++++++++++++++++++++++++++++
Derek S. Sikes, Curator of Insects
Professor of Entomology
University of Alaska Museum
1962 Yukon Drive
Fairbanks, AK 99775-6960
dssikes@alaska.edu
phone: 907-474-6278
FAX: 907-474-5469
University of Alaska Museum - search 400,276 digitized arthropod records
http://arctos.database.museum/uam_ento_all
<http://www.uaf.edu/museum/collections/ento/>
+++++++++++++++++++++++++++++++++++
Interested in Alaskan Entomology? Join the Alaska Entomological
Society and / or sign up for the email listserv "Alaska Entomological
Network" at
http://www.akentsoc.org/contact_us <http://www.akentsoc.org/contact.php>
|
|
Do we all agree that a georeference doesn't necessarily have to have anything to do with an or any event or specimen? I think this is where our disconnect is happening. |
|
Yes, that was my question. Can't the georeferencing info be in a separate
table that links to locality, so "locality" per se does not have to be
denormalized?
…On Fri, Oct 12, 2018 at 11:37 AM Teresa Mayfield-Meyer < ***@***.***> wrote:
Do we all agree that a georeference doesn't necessarily have to have
anything to do with an or any event or specimen? I think this is where our
disconnect is happening.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1705 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AOH0hM3a2ZkW3OHjAc_YHUbSuSFdoaIOks5ukNNtgaJpZM4W0xJD>
.
|
(And "temporal data" would be georeferenceDate - day-precision if we make it a DATE field, some flexibility if we go with ISO8601.) It's basically a question of what a locality IS. I think it's a fact - the shape and strings complement each other and define something real, you can go there, etc. (Some of them aren't so factual - Bildesbucht probably isn't off the coast of Somalia - but still...). What's being proposed would make localities determinations - we'd have to care WHY Bildesbucht maps off the coast of Somalia, and who says so, and when they say it. If you feed Bildesbucht to whatever broken script came up with those coordinates and it returns the same coordinates every day for a month, you've got 30 localities. When you notice the map, you'll need to fix all 30. If you and I do that simultaneously, we've got 60 localities to clean up. In both cases there's a determination between the specimen and the locality stack (unless we do something drastic with specimen_events, which doesn't seem possible in the context of hosts/parasites, cultural data, etc.). Arctos is primarily a specimen database, so I think that's the important place - I want to know who says a specimen is from {PLACE}, {PLACE} itself just exists (or not, in which case I'd just not use it). Our actual model is somewhere in the middle - GEOREFERENCE_SOURCE and GEOREFERENCE_PROTOCOL are there to get at "why" (maybe that lichen really was hovering out there, GPS coordinates were provided, and Bildesbucht is the erroneous data - that should be in source and protocol). Those affect whether you'd want to select that locality for another specimen or not, so I think that's a reasonable compromise. What I'm struggling with is how knowing that {AGENT} on {DATE} created those data would influence you choosing to (or not to) assign specimens to that locality. |
#1490 makes the answer "sorta" - georeferences can be out of context (but that leads to polar bears "from Barrow" having the same error as house mice from Barrow), but localities which are out of context get merged and deleted. I think this change would involve giving up any idea that localities CAN be duplicates, so the answer would change if we go there.
That's the old model, and it was evil. We'd have dumped those lichen coordinates back in the original locality, which is not where they came from. And we'd have done it as the one accepted georeference, which would discard the only true data we have. That also reintroduces structural directionality - downloading GPS coordinates and adding string data to them doesn't fit in the model I'm imagining. That is, coordinates are NOT strictly metadata of string data; the reverse can be true. |
|
Weighing in now-- I think a lot of the issues arise from our conception of
locality as Dusty correctly describes: info in the Locality table is either
an interpretation or it's empirically determined (in Dusty's words 'a
fact').
I just finished a lecture on spatial data and determinations in natural
history museums as well as describing the efforts of past NSF's (Manis,
Ornis, Herpnet, vertnet) so this is somewhat fresh in my head. But the most
revealing thing to this debate is the lesson I just gave to newly minted
curatorial assistants. The way we're treating locality information (ie
stuff in the Locality table specifically) is really an interpretation since
everything brought to the values is human-mediated, even the GPS
coordinates. Ask a random collector if s/he knows their datum? If not, too
bad I'm giving you a larger uncertainty than someone who does.
If I know the georeferencer and date, that is valuable information on
whether or not I have confidence in their interpretation of a spatial
description.
Right now, I'd argue we have denormalized data since some of us are using
locality remarks for georeferencing remarks or georeferencing
determinations.
If we really want to use Localities as a gazetteer then we should have it
separated from specimen event determinations which can be completely
independent activities.
So I advocate (as I have in the past) for bring BACK georeferencing by and
date fields (the DwC field equivalents) to the locality table. I dont see a
down side to the overall Arctos model to be honest. Specimen event
determiner can remain and stay in the specimen detail UI but curators
should be able to see locality georeferencers.
…On Fri, Oct 12, 2018 at 10:43 AM dustymc ***@***.***> wrote:
why does adding georeferencedby and georeferenced date denormalize?
Given a GPS firmly affixed to the planet, you and me reading it at the
same time is two localities, you reading it now and {something outside the
precision of your temporal data} later is two localities, remarks "Remark"
and "remarks" are two localities, etc.
(And "temporal data" would be georeferenceDate - day-precision if we make
it a DATE field, some flexibility if we go with ISO8601.)
It's basically a question of what a locality IS. I think it's a fact - the
shape and strings complement each other and define something real, you can
go there, etc. (Some of them aren't so factual - Bildesbucht probably isn't
off the coast of Somalia - but still...).
What's being proposed would make localities determinations - we'd have to
care WHY Bildesbucht maps off the coast of Somalia, and who says so, and
when they say it. If you feed Bildesbucht to whatever broken script came up
with those coordinates and it returns the same coordinates every day for a
month, you've got 30 localities. When you notice the map, you'll need to
fix all 30. If you and I do that simultaneously, we've got 60 localities to
clean up.
In both cases there's a determination between the specimen and the
locality stack (unless we do something drastic with specimen_events, which
doesn't seem possible in the context of hosts/parasites, cultural data,
etc.). Arctos is primarily a specimen database, so I think that's the
important place - I want to know who says a specimen is from {PLACE},
{PLACE} itself just exists (or not, in which case I'd just not use it).
Our actual model is somewhere in the middle - GEOREFERENCE_SOURCE and
GEOREFERENCE_PROTOCOL are there to get at "why" (maybe that lichen really
was hovering out there, GPS coordinates were provided, and Bildesbucht is
the erroneous data - that should be in source and protocol). Those affect
whether you'd want to select that locality for another specimen or not, so
I think that's a reasonable compromise. What I'm struggling with is how
knowing that {AGENT} on {DATE} created those data would influence you
choosing to (or not to) assign specimens to that locality.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1705 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACZ_0fxjPiuESNo_R0CxMb6IxAOzn7qOks5ukNTLgaJpZM4W0xJD>
.
|
Agree and although you might be able to figure that out now, the way we record it via a specimen event makes it opaque and not necessarily something we are all doing in the same way. |
See #832
Agreed, it's just different. It's denormalization - there will be more STUFF to sort through (and maybe fix). If there's a reason to keep those data there (eg, we want to act as a gazetteer) then that may be a cost well worth paying. |
|
Ah, so Dusty wants an example!
https://arctos.database.museum/guid/MVZ:Herp:145531
Here's one from the webinar-- note the angry red box around the geoference.
I see that the determiner is Shugart from 2002. This tells me it was
accomplished during the Herpnet project and it says in remarks that it's
part of his batch processing. Fine. Coordinates gets me to the river so to
speak so I can refine. But I'd like to reassign the specimen event--> mark
that as me. New coordinates should be the student I'll ask to redo. Let's
not delete the locality actually since it's been out in the wild for 16
years. How many other things are now mapped to that?
Sure verified gives me some clue that someone has to check it out but I
want to know more and I can make use of the georeferencer info. Make sense?
…On Fri, Oct 12, 2018 at 11:02 AM Michelle S. Koo ***@***.***> wrote:
Weighing in now-- I think a lot of the issues arise from our conception of
locality as Dusty correctly describes: info in the Locality table is either
an interpretation or it's empirically determined (in Dusty's words 'a
fact').
I just finished a lecture on spatial data and determinations in natural
history museums as well as describing the efforts of past NSF's (Manis,
Ornis, Herpnet, vertnet) so this is somewhat fresh in my head. But the most
revealing thing to this debate is the lesson I just gave to newly minted
curatorial assistants. The way we're treating locality information (ie
stuff in the Locality table specifically) is really an interpretation since
everything brought to the values is human-mediated, even the GPS
coordinates. Ask a random collector if s/he knows their datum? If not, too
bad I'm giving you a larger uncertainty than someone who does.
If I know the georeferencer and date, that is valuable information on
whether or not I have confidence in their interpretation of a spatial
description.
Right now, I'd argue we have denormalized data since some of us are using
locality remarks for georeferencing remarks or georeferencing
determinations.
If we really want to use Localities as a gazetteer then we should have it
separated from specimen event determinations which can be completely
independent activities.
So I advocate (as I have in the past) for bring BACK georeferencing by and
date fields (the DwC field equivalents) to the locality table. I dont see a
down side to the overall Arctos model to be honest. Specimen event
determiner can remain and stay in the specimen detail UI but curators
should be able to see locality georeferencers.
On Fri, Oct 12, 2018 at 10:43 AM dustymc ***@***.***> wrote:
> why does adding georeferencedby and georeferenced date denormalize?
>
> Given a GPS firmly affixed to the planet, you and me reading it at the
> same time is two localities, you reading it now and {something outside the
> precision of your temporal data} later is two localities, remarks "Remark"
> and "remarks" are two localities, etc.
>
> (And "temporal data" would be georeferenceDate - day-precision if we make
> it a DATE field, some flexibility if we go with ISO8601.)
>
> It's basically a question of what a locality IS. I think it's a fact -
> the shape and strings complement each other and define something real, you
> can go there, etc. (Some of them aren't so factual - Bildesbucht probably
> isn't off the coast of Somalia - but still...).
>
> What's being proposed would make localities determinations - we'd have to
> care WHY Bildesbucht maps off the coast of Somalia, and who says so, and
> when they say it. If you feed Bildesbucht to whatever broken script came up
> with those coordinates and it returns the same coordinates every day for a
> month, you've got 30 localities. When you notice the map, you'll need to
> fix all 30. If you and I do that simultaneously, we've got 60 localities to
> clean up.
>
> In both cases there's a determination between the specimen and the
> locality stack (unless we do something drastic with specimen_events, which
> doesn't seem possible in the context of hosts/parasites, cultural data,
> etc.). Arctos is primarily a specimen database, so I think that's the
> important place - I want to know who says a specimen is from {PLACE},
> {PLACE} itself just exists (or not, in which case I'd just not use it).
>
> Our actual model is somewhere in the middle - GEOREFERENCE_SOURCE and
> GEOREFERENCE_PROTOCOL are there to get at "why" (maybe that lichen really
> was hovering out there, GPS coordinates were provided, and Bildesbucht is
> the erroneous data - that should be in source and protocol). Those affect
> whether you'd want to select that locality for another specimen or not, so
> I think that's a reasonable compromise. What I'm struggling with is how
> knowing that {AGENT} on {DATE} created those data would influence you
> choosing to (or not to) assign specimens to that locality.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <#1705 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ACZ_0fxjPiuESNo_R0CxMb6IxAOzn7qOks5ukNTLgaJpZM4W0xJD>
> .
>
|
|
If you FIX (change) that, it'll eventually start to look like the georeferencer produced something they didn't. If you keep it and add another specimen-event (#1357 was intended to make that easy) you've got the historical data from herpnet (which might be fun for all sorts of things) and the specimen maps where it should. If we knew what was georeferenced - if we'd added an entire locality stack (which wasn't possible at the time) to hold the data they used in creating the coordinates - we might know why the box is red. Was herpnet's county data broken, or was the specloc-interpreter to blame, or is the specloc really not in the county, or ??? Knowing that might lead to more problems, or easy fixes, or etc. I think that's all mostly irrelevant for this discussion - I'd advocate adding events and keeping all that no matter what the locality table looks like - but I'm still not really seeing what having Shugart in the locality can do (at least in the context of that specimen) that having Shugart as event determiner cannot do. |
|
Shugart has no relationship to the specimen thus it's really hacky to have
him as a specimen event determiner. He only had access to the locality.
We have this scenario ALL THE TIME which is what I am hearing from all the
other curators on this thread. Only one person has the biological or
curatorial background to make the most appropriate connection between a
specimen and the locality, but the locality and its georeference will be
done separately and appropriately by someone who doesnt need to know the
species or specimen info. I have students in this capacity every semester;
ideally they will with someone to clean up data who knows the specimens and
species. Why would I not want to track that appropriately?
…On Fri, Oct 12, 2018 at 11:24 AM dustymc ***@***.***> wrote:
If you FIX (change) that, it'll eventually start to look like the
georeferencer produced something they didn't. If you keep it and add
another specimen-event (#1357
<#1357> was intended to make
that easy) you've got the historical data from herpnet (which might be fun
for all sorts of things) and the specimen maps where it should.
If we knew what was georeferenced - if we'd added an entire locality stack
(which wasn't possible at the time) to hold the data they used in creating
the coordinates - we might know why the box is red. Was herpnet's county
data broken, or was the specloc-interpreter to blame, or is the specloc
really not in the county, or ??? Knowing that might lead to more problems,
or easy fixes, or etc. I think that's all mostly irrelevant for this
discussion - I'd advocate adding events and keeping all that no matter what
the locality table looks like - but I'm still not really seeing what having
Shugart in the locality can do (at least in the context of that specimen)
that having Shugart as event determiner cannot do.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1705 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACZ_0agor5cg_9iAjIPo6V95jsOjfcP1ks5ukN5ygaJpZM4W0xJD>
.
|
|
What about managing geocoordinates & their associated metadata incl. who &
when the same way we track identifications of specimens. The specimen is a
fact but it's ID is an opinion. The locality name "Fairbanks" is a fact but
the geocoordinates (& assoc metadata) are an opinion because different
people may disagree on things like how much error to use etc.
This way there's only 1 locality record for Fairbanks but there's possibly
many different georeferences of it. Of course we'd be left with the problem
of which one of these to use - the most recent?
Just brainstorming.
…-Derek
On Fri, Oct 12, 2018 at 10:24 AM, dustymc ***@***.***> wrote:
If you FIX (change) that, it'll eventually start to look like the
georeferencer produced something they didn't. If you keep it and add
another specimen-event (#1357
<#1357> was intended to make
that easy) you've got the historical data from herpnet (which might be fun
for all sorts of things) and the specimen maps where it should.
If we knew what was georeferenced - if we'd added an entire locality stack
(which wasn't possible at the time) to hold the data they used in creating
the coordinates - we might know why the box is red. Was herpnet's county
data broken, or was the specloc-interpreter to blame, or is the specloc
really not in the county, or ??? Knowing that might lead to more problems,
or easy fixes, or etc. I think that's all mostly irrelevant for this
discussion - I'd advocate adding events and keeping all that no matter what
the locality table looks like - but I'm still not really seeing what having
Shugart in the locality can do (at least in the context of that specimen)
that having Shugart as event determiner cannot do.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1705 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AIraM010R9IIWrbVulWS2hS2fOZhncYjks5ukN5zgaJpZM4W0xJD>
.
--
+++++++++++++++++++++++++++++++++++
Derek S. Sikes, Curator of Insects
Professor of Entomology
University of Alaska Museum
1962 Yukon Drive
Fairbanks, AK 99775-6960
dssikes@alaska.edu
phone: 907-474-6278
FAX: 907-474-5469
University of Alaska Museum - search 400,276 digitized arthropod records
http://arctos.database.museum/uam_ento_all
<http://www.uaf.edu/museum/collections/ento/>
+++++++++++++++++++++++++++++++++++
Interested in Alaskan Entomology? Join the Alaska Entomological
Society and / or sign up for the email listserv "Alaska Entomological
Network" at
http://www.akentsoc.org/contact_us <http://www.akentsoc.org/contact.php>
|
|
I added coordinates to a locality today. The georeference was performed by Carl Lieb in 2015, but the world believes that I did this in 2019:
I still feel like we are not properly recording WHO came up with the coordinates, WHEN they did it and HOW, especially since the coordinates Carl provided were in degrees decimal minutes which are saved nowhere in this edit. |
|
@anna-chinn georeferenced some localities shared with MSB, and we received the notification and can use the view edit archive to see that Anna added the coordinates. However, I'm concerned because the specimen event does not show who did the georeferencing. One event was assigned by Robert L. Rausch in 1952, but then we have coordinates with no source displayed. .Is there a way to add this to the specimen record display? https://arctos.database.museum/guid/MSB:Host:18692. I realize the alternative would have been for Anna to create a new georeferenced locality for her specimens, with her name as the specimen event determiner, and then we'd all supposedly add this new event to all our different specimen records. But that defeats the purpose of having shared localities, doesn't it? I am happy to have Anna georeference some of our old localities, just would like to see that she did so and how.
|
|
To make things even more interesting with that previous example, it is a host record linked to parasites from the same locality. But the parasite records were georeferenced at MSB in 2016 and have a different higher geography. |
That's "just" UI so there's not much technical issue. A locality could have a billion edits though (and the event might have a billion more), so I'm not sure HOW to display it.
Yes, you'd have to do the same work without the sharing.
If you're talking about the gray boxes on Edit Locality, those are OTHER localities that don't, but probably should, share higher geography. Eg, if I search "Beaver" + "North America, United States, Alaska" I'll get one set of specimens, "Beaver+North America, United States, Alaska, Beaver Quad" will get me more (with no overlap), and "beaver+ North America, United States, Alaska, Beaver Quad, Yukon Flats National Wildlife Refuge" will find yet another set with no overlap with the other 2. Those are all the same place, we're just horribly inconsistent in how we assign geography to specimens and so users who search by geography don't find what they're looking for. http://handbook.arctosdb.org/documentation/higher-geography.html#guidelines-for-assigning-geography-to-specimens
Not really, other than accurate entry (and you may just not have the data for that). I think I can find things in relationships that don't share localities, but that would be complicated by things like http://arctos.database.museum/guid/MSB:Mamm:292063 (which claims it was killed twice) and parasites collected from living hosts and the 'experimental' thing and .... - I'm not sure what I could do from such a report. New Issue I think. |
|
When are we going to have proper 'georeferenced by' data? GBIF is misinterpreting our data. Note that this record http://arctos.database.museum/guid/UAM:Ento:284204 in GBIF has the collector listed as the agent for 'Georeferenced by' https://www.gbif.org/occurrence/1146075287 but I happen to know that it was my lab techs who georeferenced this. Which one? I don't know and I don't even know how I might find out. |
|
GBIF isn't interpreting anything, they're just using what you provide.
That may not be a perfect map to DWC:georeferencedBy but what we're doing does fit very well with GBIF's label "Location according to." The history of the locality is here:
although that one hasn't changed since we started tracking. |
|
hmmm I see that the collector is listed as the event determiner for that
record, which is wrong. I wonder how many similar mistakes have been made
by data entry techs who didn't understand what 'event determiner' meant?
hmmm... also seems I have no way to make bulk changes to event determiners.
The manage specimen event tool doesn't include that field. Can that be
added? There are over 90 records from that one locality that all have wrong
event determiners.
A simple query would be to see how many records with lat/longs have the
collectors as event determiners and the year of collection before 1990
(obviously there are actual lat/longs on labels from before this time
period but I'd be the majority of records with such coordinates have
non-verbatim coordinates.
…-Derek
On Tue, Apr 9, 2019 at 9:17 AM dustymc ***@***.***> wrote:
GBIF isn't interpreting anything, they're just using what you provide.
[image: Screen Shot 2019-04-09 at 10 10 50 AM]
<https://user-images.githubusercontent.com/5720791/55820360-d3298100-5aaf-11e9-889a-e44ef9696423.png>
That may not be a perfect map to DWC:georeferencedBy but what we're doing
does fit very well with GBIF's label "Location according to."
The history of the locality is here:
[image: Screen Shot 2019-04-09 at 10 11 54 AM]
<https://user-images.githubusercontent.com/5720791/55820452-010ec580-5ab0-11e9-88b6-20e510fc6b9f.png>
[image: Screen Shot 2019-04-09 at 10 12 04 AM]
<https://user-images.githubusercontent.com/5720791/55820457-04a24c80-5ab0-11e9-94e4-a0a7d0607e2c.png>
[image: Screen Shot 2019-04-09 at 10 12 11 AM]
<https://user-images.githubusercontent.com/5720791/55820465-0704a680-5ab0-11e9-8a4e-25a57c5d8156.png>
although that one hasn't changed since we started tracking.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1705 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AIraM0hP9vFMMQIsBY_b6pfvRvd_UGLqks5vfMtCgaJpZM4W0xJD>
.
--
+++++++++++++++++++++++++++++++++++
Derek S. Sikes, Curator of Insects
Professor of Entomology
University of Alaska Museum
1962 Yukon Drive
Fairbanks, AK 99775-6960
dssikes@alaska.edu
phone: 907-474-6278
FAX: 907-474-5469
University of Alaska Museum - search 400,276 digitized arthropod records
http://arctos.database.museum/uam_ento_all
<http://www.uaf.edu/museum/collections/ento/>
+++++++++++++++++++++++++++++++++++
Interested in Alaskan Entomology? Join the Alaska Entomological
Society and / or sign up for the email listserv "Alaska Entomological
Network" at
http://www.akentsoc.org/contact_us <http://www.akentsoc.org/contact.php>
|
|
Bulk-tool adjustments should be pushed off to #1357 @DerekSikes here's your data AWG consensus
|
|
D,
Thanks for that list!
Could you do the following:
For any records in UAM:Ento, KWP:Ento, and UAMObs:Ento
That have the georeference source containing the term Google
and the specimen was collected in the year 2000 or earlier
and have the collector as the event determiner
Could you change the event determiner to equal the enteredby agent?
thanks,
Derek
…On Thu, Apr 11, 2019 at 12:31 PM dustymc ***@***.***> wrote:
Bulk-tool adjustments should be pushed off to #1357
<#1357>
@DerekSikes <https://github.com/DerekSikes> here's your data
create table temp_uam_ent_evt as
select guid from flat , specimen_event, collecting_event, locality, collector where flat.collection_object_id=specimen_event.collection_object_id and
specimen_event.collecting_event_id=collecting_event.collecting_event_id and collecting_event.locality_id=locality.locality_id and
flat.collection_object_id=collector.collection_object_id and
locality.dec_lat is not null and
to_number(substr(collecting_event.ended_date,1,instr(collecting_event.ended_date,'-')-1))<1990 and
collector.agent_id=specimen_event.ASSIGNED_BY_AGENT_ID and
flat.guid like 'UAM:Ento:%'
;
temp_uam_ent_evt.csv.zip
<https://github.com/ArctosDB/arctos/files/3070455/temp_uam_ent_evt.csv.zip>
AWG consensus
- we won't make drastic concept-altering changes to locality
- we need better documentation re: what type of thing a locality IS
(facts vs determinations) so we can better understand what would change that
- make locality edit history public
- add direct links from specimendetail to locality edit history
proceed with #1270 <#1270> then
#1357 <#1357>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1705 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AIraM4gsnUJllzRRgbAozC1YazRie_E3ks5vf5udgaJpZM4W0xJD>
.
--
+++++++++++++++++++++++++++++++++++
Derek S. Sikes, Curator of Insects
Professor of Entomology
University of Alaska Museum
1962 Yukon Drive
Fairbanks, AK 99775-6960
dssikes@alaska.edu
phone: 907-474-6278
FAX: 907-474-5469
University of Alaska Museum - search 400,276 digitized arthropod records
http://arctos.database.museum/uam_ento_all
<http://www.uaf.edu/museum/collections/ento/>
+++++++++++++++++++++++++++++++++++
Interested in Alaskan Entomology? Join the Alaska Entomological
Society and / or sign up for the email listserv "Alaska Entomological
Network" at
http://www.akentsoc.org/contact_us <http://www.akentsoc.org/contact.php>
|
I'd bet A LOT of our event determiners are incorrect because some of us didn't get this (and maybe still don't?) |
|
@DerekSikes confirm that this looks like them and I'll switch event determiner. |
|
Thanks,
checking these and I see this one
http://arctos.database.museum/guid/KWP:Ento:11083
has verbatim coordinates in DM format which were assigned by the collector
(Ken Philip) in 1987 but has new coordinates in DD and google earth is
listed as the georef source which was presumably used by the Entered By
agent: Dusty L. McDonald on 2004-09-22.
So, if we go ahead with this switch, will it preserve the history? That is,
will Ken Philip, current event determiner for this record, be preserved
somehow? It would be nice to keep track of the fact that the DM data came
from Ken somehow.
Also, am I correct that the event determiner should be whomever most
recently took responsibility for changing *anything* in the locality stack?
in which case making this switch from Ken to Dusty would be the correct
thing to do (even though the verbatim coordinates came from Ken, not Dusty).
…-Derek
On Thu, Apr 11, 2019 at 2:28 PM dustymc ***@***.***> wrote:
@DerekSikes <https://github.com/DerekSikes> confirm that this looks like
them and I'll switch event determiner.
create table temp_uam_ent_evt_d as
select
guid,
collecting_event.ended_date,
specimen_event.specimen_event_id,
specimen_event.ASSIGNED_BY_AGENT_ID,
getPreferredAgentName(specimen_event.ASSIGNED_BY_AGENT_ID) eventassignedby,
coll_object.ENTERED_PERSON_ID,
getPreferredAgentName(coll_object.ENTERED_PERSON_ID) enteredby,
locality.GEOREFERENCE_SOURCE
from
flat ,
specimen_event,
collecting_event,
locality,
collector,
coll_object
where
flat.collection_object_id=specimen_event.collection_object_id and
specimen_event.collecting_event_id=collecting_event.collecting_event_id and
collecting_event.locality_id=locality.locality_id and
flat.collection_object_id=collector.collection_object_id and
flat.collection_object_id=coll_object.collection_object_id and
locality.dec_lat is not null and
to_number(substr(collecting_event.ended_date,1,instr(collecting_event.ended_date,'-')-1))<=2000 and
collector.agent_id=specimen_event.ASSIGNED_BY_AGENT_ID and
(
flat.guid like 'UAM:Ento:%' or
flat.guid like 'KWP:Ento:%' or
flat.guid like 'UAMObs:Ento:%'
) and
lower(locality.GEOREFERENCE_SOURCE) like '%google%'
;
temp_uam_ent_evt_d.csv.zip
<https://github.com/ArctosDB/arctos/files/3070816/temp_uam_ent_evt_d.csv.zip>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1705 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AIraMyaMO3gNCuTeoTaYpi_akQg6cqTeks5vf7cjgaJpZM4W0xJD>
.
--
+++++++++++++++++++++++++++++++++++
Derek S. Sikes, Curator of Insects
Professor of Entomology
University of Alaska Museum
1962 Yukon Drive
Fairbanks, AK 99775-6960
dssikes@alaska.edu
phone: 907-474-6278
FAX: 907-474-5469
University of Alaska Museum - search 400,276 digitized arthropod records
http://arctos.database.museum/uam_ento_all
<http://www.uaf.edu/museum/collections/ento/>
+++++++++++++++++++++++++++++++++++
Interested in Alaskan Entomology? Join the Alaska Entomological
Society and / or sign up for the email listserv "Alaska Entomological
Network" at
http://www.akentsoc.org/contact_us <http://www.akentsoc.org/contact.php>
|
|
I've checked over the data and they look good to make this switch -
assuming my prior email doesn't pose a problem.
…-Derek
On Thu, Apr 11, 2019 at 3:00 PM Derek Sikes ***@***.***> wrote:
Thanks,
checking these and I see this one
http://arctos.database.museum/guid/KWP:Ento:11083
has verbatim coordinates in DM format which were assigned by the collector
(Ken Philip) in 1987 but has new coordinates in DD and google earth is
listed as the georef source which was presumably used by the Entered By
agent: Dusty L. McDonald on 2004-09-22.
So, if we go ahead with this switch, will it preserve the history? That
is, will Ken Philip, current event determiner for this record, be preserved
somehow? It would be nice to keep track of the fact that the DM data came
from Ken somehow.
Also, am I correct that the event determiner should be whomever most
recently took responsibility for changing *anything* in the locality stack?
in which case making this switch from Ken to Dusty would be the correct
thing to do (even though the verbatim coordinates came from Ken, not Dusty).
-Derek
On Thu, Apr 11, 2019 at 2:28 PM dustymc ***@***.***> wrote:
> @DerekSikes <https://github.com/DerekSikes> confirm that this looks like
> them and I'll switch event determiner.
>
>
> create table temp_uam_ent_evt_d as
> select
> guid,
> collecting_event.ended_date,
> specimen_event.specimen_event_id,
> specimen_event.ASSIGNED_BY_AGENT_ID,
> getPreferredAgentName(specimen_event.ASSIGNED_BY_AGENT_ID) eventassignedby,
> coll_object.ENTERED_PERSON_ID,
> getPreferredAgentName(coll_object.ENTERED_PERSON_ID) enteredby,
> locality.GEOREFERENCE_SOURCE
> from
> flat ,
> specimen_event,
> collecting_event,
> locality,
> collector,
> coll_object
> where
> flat.collection_object_id=specimen_event.collection_object_id and
> specimen_event.collecting_event_id=collecting_event.collecting_event_id and
> collecting_event.locality_id=locality.locality_id and
> flat.collection_object_id=collector.collection_object_id and
> flat.collection_object_id=coll_object.collection_object_id and
> locality.dec_lat is not null and
> to_number(substr(collecting_event.ended_date,1,instr(collecting_event.ended_date,'-')-1))<=2000 and
> collector.agent_id=specimen_event.ASSIGNED_BY_AGENT_ID and
> (
> flat.guid like 'UAM:Ento:%' or
> flat.guid like 'KWP:Ento:%' or
> flat.guid like 'UAMObs:Ento:%'
> ) and
> lower(locality.GEOREFERENCE_SOURCE) like '%google%'
> ;
>
>
> temp_uam_ent_evt_d.csv.zip
> <https://github.com/ArctosDB/arctos/files/3070816/temp_uam_ent_evt_d.csv.zip>
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#1705 (comment)>,
> or mute the thread
> <https://github.com/notifications/unsubscribe-auth/AIraMyaMO3gNCuTeoTaYpi_akQg6cqTeks5vf7cjgaJpZM4W0xJD>
> .
>
--
+++++++++++++++++++++++++++++++++++
Derek S. Sikes, Curator of Insects
Professor of Entomology
University of Alaska Museum
1962 Yukon Drive
Fairbanks, AK 99775-6960
***@***.***
phone: 907-474-6278
FAX: 907-474-5469
University of Alaska Museum - search 400,276 digitized arthropod records
http://arctos.database.museum/uam_ento_all
<http://www.uaf.edu/museum/collections/ento/>
+++++++++++++++++++++++++++++++++++
Interested in Alaskan Entomology? Join the Alaska Entomological
Society and / or sign up for the email listserv "Alaska Entomological
Network" at
http://www.akentsoc.org/contact_us <http://www.akentsoc.org/contact.php>
--
+++++++++++++++++++++++++++++++++++
Derek S. Sikes, Curator of Insects
Professor of Entomology
University of Alaska Museum
1962 Yukon Drive
Fairbanks, AK 99775-6960
dssikes@alaska.edu
phone: 907-474-6278
FAX: 907-474-5469
University of Alaska Museum - search 400,276 digitized arthropod records
http://arctos.database.museum/uam_ento_all
<http://www.uaf.edu/museum/collections/ento/>
+++++++++++++++++++++++++++++++++++
Interested in Alaskan Entomology? Join the Alaska Entomological
Society and / or sign up for the email listserv "Alaska Entomological
Network" at
http://www.akentsoc.org/contact_us <http://www.akentsoc.org/contact.php>
|
|
any update on this?
…On Thu, Apr 11, 2019 at 3:07 PM Derek Sikes ***@***.***> wrote:
I've checked over the data and they look good to make this switch -
assuming my prior email doesn't pose a problem.
-Derek
On Thu, Apr 11, 2019 at 3:00 PM Derek Sikes ***@***.***> wrote:
> Thanks,
>
> checking these and I see this one
> http://arctos.database.museum/guid/KWP:Ento:11083
>
> has verbatim coordinates in DM format which were assigned by the
> collector (Ken Philip) in 1987 but has new coordinates in DD and google
> earth is listed as the georef source which was presumably used by the
> Entered By agent: Dusty L. McDonald on 2004-09-22.
>
> So, if we go ahead with this switch, will it preserve the history? That
> is, will Ken Philip, current event determiner for this record, be preserved
> somehow? It would be nice to keep track of the fact that the DM data came
> from Ken somehow.
>
> Also, am I correct that the event determiner should be whomever most
> recently took responsibility for changing *anything* in the locality stack?
> in which case making this switch from Ken to Dusty would be the correct
> thing to do (even though the verbatim coordinates came from Ken, not Dusty).
>
> -Derek
>
>
>
> On Thu, Apr 11, 2019 at 2:28 PM dustymc ***@***.***> wrote:
>
>> @DerekSikes <https://github.com/DerekSikes> confirm that this looks
>> like them and I'll switch event determiner.
>>
>>
>> create table temp_uam_ent_evt_d as
>> select
>> guid,
>> collecting_event.ended_date,
>> specimen_event.specimen_event_id,
>> specimen_event.ASSIGNED_BY_AGENT_ID,
>> getPreferredAgentName(specimen_event.ASSIGNED_BY_AGENT_ID) eventassignedby,
>> coll_object.ENTERED_PERSON_ID,
>> getPreferredAgentName(coll_object.ENTERED_PERSON_ID) enteredby,
>> locality.GEOREFERENCE_SOURCE
>> from
>> flat ,
>> specimen_event,
>> collecting_event,
>> locality,
>> collector,
>> coll_object
>> where
>> flat.collection_object_id=specimen_event.collection_object_id and
>> specimen_event.collecting_event_id=collecting_event.collecting_event_id and
>> collecting_event.locality_id=locality.locality_id and
>> flat.collection_object_id=collector.collection_object_id and
>> flat.collection_object_id=coll_object.collection_object_id and
>> locality.dec_lat is not null and
>> to_number(substr(collecting_event.ended_date,1,instr(collecting_event.ended_date,'-')-1))<=2000 and
>> collector.agent_id=specimen_event.ASSIGNED_BY_AGENT_ID and
>> (
>> flat.guid like 'UAM:Ento:%' or
>> flat.guid like 'KWP:Ento:%' or
>> flat.guid like 'UAMObs:Ento:%'
>> ) and
>> lower(locality.GEOREFERENCE_SOURCE) like '%google%'
>> ;
>>
>>
>> temp_uam_ent_evt_d.csv.zip
>> <https://github.com/ArctosDB/arctos/files/3070816/temp_uam_ent_evt_d.csv.zip>
>>
>> —
>> You are receiving this because you were mentioned.
>> Reply to this email directly, view it on GitHub
>> <#1705 (comment)>,
>> or mute the thread
>> <https://github.com/notifications/unsubscribe-auth/AIraMyaMO3gNCuTeoTaYpi_akQg6cqTeks5vf7cjgaJpZM4W0xJD>
>> .
>>
>
>
> --
>
> +++++++++++++++++++++++++++++++++++
> Derek S. Sikes, Curator of Insects
> Professor of Entomology
> University of Alaska Museum
> 1962 Yukon Drive
> Fairbanks, AK 99775-6960
>
> ***@***.***
>
> phone: 907-474-6278
> FAX: 907-474-5469
>
> University of Alaska Museum - search 400,276 digitized arthropod records
> http://arctos.database.museum/uam_ento_all
> <http://www.uaf.edu/museum/collections/ento/>
> +++++++++++++++++++++++++++++++++++
>
> Interested in Alaskan Entomology? Join the Alaska Entomological
> Society and / or sign up for the email listserv "Alaska Entomological
> Network" at
> http://www.akentsoc.org/contact_us <http://www.akentsoc.org/contact.php>
>
--
+++++++++++++++++++++++++++++++++++
Derek S. Sikes, Curator of Insects
Professor of Entomology
University of Alaska Museum
1962 Yukon Drive
Fairbanks, AK 99775-6960
***@***.***
phone: 907-474-6278
FAX: 907-474-5469
University of Alaska Museum - search 400,276 digitized arthropod records
http://arctos.database.museum/uam_ento_all
<http://www.uaf.edu/museum/collections/ento/>
+++++++++++++++++++++++++++++++++++
Interested in Alaskan Entomology? Join the Alaska Entomological
Society and / or sign up for the email listserv "Alaska Entomological
Network" at
http://www.akentsoc.org/contact_us <http://www.akentsoc.org/contact.php>
--
+++++++++++++++++++++++++++++++++++
Derek S. Sikes, Curator of Insects
Professor of Entomology
University of Alaska Museum
1962 Yukon Drive
Fairbanks, AK 99775-6960
dssikes@alaska.edu
phone: 907-474-6278
FAX: 907-474-5469
University of Alaska Museum - search 400,276 digitized arthropod records
http://arctos.database.museum/uam_ento_all
<http://www.uaf.edu/museum/collections/ento/>
+++++++++++++++++++++++++++++++++++
Interested in Alaskan Entomology? Join the Alaska Entomological
Society and / or sign up for the email listserv "Alaska Entomological
Network" at
http://www.akentsoc.org/contact_us <http://www.akentsoc.org/contact.php>
|
|
Sorry, got sidetracked...
Not if we do a straight replacement - there's no automagic specimen-event history.
said "this specimen was {event_type} there, then." (There's some subtlety in that. "Tuning" either the "there" or the "then" makes a history of the locality/event, while fundamentally altering the nature of the event/locality should probably be accomplished by adding a stack. That mostly relies on users and documentation, not technology.) You could clone the event and add a specimen-event - the current one (which could be flipped to unaccepted) one would hold Ken's 'verbatim' data, and a new one could differ only by lacking that. #1357 would make that easy. #2041 makes it a little weird - we should somehow stop putting "from the collector" verbatim in with "from the UI/bulkloader" verbatim. Realistically I think most collections would just copy the verbatim coordinates to verbatim locality, and some would have entered them there. #2041. I'm sure I waffle around on it, but I think I like that - it puts the verbatim data in a front-and-center field designed to hold verbatim from the collector data instead of scattered around various places including stuff designed to hold input that gets transformed. I'm happy to make any of those changes for you - I assume it's not just the one specimen? |
|
Just go ahead and make this switch then. I'll find what seems to be the few
that could use some editing to preserve history and do them manually.
Thanks!
Derek
…On Wed, Apr 17, 2019 at 9:11 AM dustymc ***@***.***> wrote:
Sorry, got sidetracked...
So, if we go ahead with this switch, will it preserve the history?
Not if we do a straight replacement - there's no automagic specimen-event
history.
event determiner should be whomever...
said "this specimen was {event_type} there, then." (There's some subtlety
in that. "Tuning" either the "there" or the "then" makes a history of the
locality/event, while fundamentally altering the nature of the
event/locality should probably be accomplished by adding a stack. That
mostly relies on users and documentation, not technology.)
You could clone the event and add a specimen-event - the current one
(which could be flipped to unaccepted) one would hold Ken's 'verbatim'
data, and a new one could differ only by lacking that. #1357
<#1357> would make that easy.
#2041 <#2041> makes it a little
weird - we should somehow stop putting "from the collector" verbatim in
with "from the UI/bulkloader" verbatim.
Realistically I think most collections would just copy the verbatim
coordinates to verbatim locality, and some would have entered them there.
#2041 <#2041>. I'm sure I waffle
around on it, but I think I like that - it puts the verbatim data in a
front-and-center field designed to hold verbatim from the collector data
instead of scattered around various places including stuff designed to hold
input that gets transformed.
I'm happy to make any of those changes for you - I assume it's not just
the one specimen?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1705 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AIraM_pvVGshCr6wnV8oNJwz_bQSBfYiks5vh1WsgaJpZM4W0xJD>
.
--
+++++++++++++++++++++++++++++++++++
Derek S. Sikes, Curator of Insects
Professor of Entomology
University of Alaska Museum
1962 Yukon Drive
Fairbanks, AK 99775-6960
dssikes@alaska.edu
phone: 907-474-6278
FAX: 907-474-5469
University of Alaska Museum - search 400,276 digitized arthropod records
http://arctos.database.museum/uam_ento_all
<http://www.uaf.edu/museum/collections/ento/>
+++++++++++++++++++++++++++++++++++
Interested in Alaskan Entomology? Join the Alaska Entomological
Society and / or sign up for the email listserv "Alaska Entomological
Network" at
http://www.akentsoc.org/contact_us <http://www.akentsoc.org/contact.php>
|
done |
|
thanks!
…On Thu, Apr 18, 2019 at 6:21 AM dustymc ***@***.***> wrote:
make this switch
done
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1705 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ACFNUMYRWPCTNFQGRELNY5TPRB7WDANCNFSM4FWTCJBQ>
.
--
+++++++++++++++++++++++++++++++++++
Derek S. Sikes, Curator of Insects
Professor of Entomology
University of Alaska Museum
1962 Yukon Drive
Fairbanks, AK 99775-6960
dssikes@alaska.edu
phone: 907-474-6278
FAX: 907-474-5469
University of Alaska Museum - search 400,276 digitized arthropod records
http://arctos.database.museum/uam_ento_all
<http://www.uaf.edu/museum/collections/ento/>
+++++++++++++++++++++++++++++++++++
Interested in Alaskan Entomology? Join the Alaska Entomological
Society and / or sign up for the email listserv "Alaska Entomological
Network" at
http://www.akentsoc.org/contact_us <http://www.akentsoc.org/contact.php>
|
|
#2498 makes this irrelevant; it will be possible to normalize (eventually/hopefully even more than now), or to denormalize to about any extent. |
Issue Documentation is http://handbook.arctosdb.org/documentation/locality.html
Is your feature request related to a problem? Please describe.
We would like to track who is georeferencing localities associated with our specimens and when these localities were georeferenced. Right now the only way to do this is by using Verified By and Date Verified in Specimen Event, or by using free text in Locality Remarks.
Describe the solution you'd like
Georeferenced By and Date Georeferenced fields in the Locality table. They could be optional fields that have a "Me, Today" button (like in the Specimen Event Verification Status section) that would populate the fields with the operator's name and that day's date.
This could also help us keep tabs on whether the georeference was recorded by a collector, or was retroactively assigned as part of a curatorial georeferencing project. Might pair well with proposed verbatim coordinates fields in #1486.
Describe alternatives you've considered
At the moment, we are tracking this using Verified By and Date Verified under Specimen Event. This seems wrong given that our georeferencing process only involves interpreting legacy data on Arctos and is entirely separate from processes of verifying the validity of collecting data on a specimen by specimen basis.
For other institutions, these processes might be more interdependent. In that case, I imagine that Verified By and Georeferenced By would be the same agent. That said, it feels to me like georeferencing a specific locality is different enough from verifying an event that it deserves separate attention.
We are also trying to capture the who and when of georeferencing in the Locality Remarks field, but it would be nice to have something more controlled.
The text was updated successfully, but these errors were encountered: