Closed Jegelewicz closed 6 years ago
This comes up every now and then, usually when someone from the NPS is in a collection failing to find "their" stuff.
NPS assigns (at least) two identifiers; we should be explicit about which one an OtherID refers to.
There is one similar existing term: LVNP: Lassen Volcanic National Park. The data are inconsistent - some are "0-100" others "LVNP 02-1" - and there's no indication if this is a catalog number, accession number, or something else.
There are a ton of recoverable data in "U. S. National Park Service accession" (YUCH-61), some that might be recoverable but would take some work (YUCH184, YUCh-00228), and some that probably aren't recoverable (0-108) and as such might be better in "original identifier" or something.
"U. S. National Park Service catalog" is similar.
I have no idea how much of the data in those things is what it claims to be.
We can enforce format for specific identifiers, if the data support that. If a unit can DO SOMETHING with their numbers we can just link them (by adding a base_URL) and check the links. (Those aren't mutually-exclusive things; we should strive to do both with all otherIDs.)
I don't really see any reason to preemptively create these identifiers; that table is already enough of a mess without introducing 417 (or 834) new identifiers, most of which will never be used.
I hear you on all that, but we aren't asking for a bunch of identifiers, just one with a controlled vocabulary for the value (the list of park names) so that we don't get inconsistent spelling of parks, etc.
Because the Park Service doesn't consistently supply identifiers, this would be a way for us to manage somewhat unmanageable information. We can use accession number for newer stuff, but a lot of the legacy stuff either has no NPS accession or the formats are all over the place. Just to be able to say which park would be a help to us even if it doesn't help NPS...
Oh - I'm obviously confused. If you mean control OtherID values that's somewhere between a complete rebuild and magic.
What is it that you're trying to do??
https://arctos.database.museum/info/ctDocumentation.cfm?table=CTFEATURE exists and contains similar data, but probably isn't what you want.
http://handbook.arctosdb.org/how_to/National-Park-Specimens.html
I think projects is probably the best place to track who owns NPS specimens - I think @amgunderson has something but I can't find it in the documentation.
Oh - I'm obviously confused. If you mean control OtherID values that's somewhere between a complete rebuild and magic.
What is it that you're trying to do??
Yeah :-( that's what I was trying to do..
We resorted to the U. S. National Park Service accession and UMNH is going to try to be careful to at least be consistent with the "numbers" they use there so that they can search by park as well as by all.
I think projects is probably the best place to track who owns NPS specimens - I think @amgunderson has something but I can't find it in the documentation.
Yes, but you still have to know which specimens they are and add them to a loan when they don't all happen to make up a single accession. A project will still be used for these, but we were trying to find an easy way to get them all in a search to create the data loan to add to the project(s).....
Do we have national parks as higher geography?
On Thu, Oct 18, 2018, 7:34 PM Teresa Mayfield-Meyer < notifications@github.com> wrote:
Closed #1753 https://github.com/ArctosDB/arctos/issues/1753.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/1753#event-1913709228, or mute the thread https://github.com/notifications/unsubscribe-auth/AOH0hJOS-DiS1x9PzsY4sacuT1koL1sEks5umSwIgaJpZM4Xu_gP .
That doesn't work very well as they often overlap counties and sometimes even states....
Parks are Features, but as @Jegelewicz said that's not usually all we enter. That's just a problem (if it's a problem) of how the data are entered, not the model - nothing is stopping us from having "North America, United States, Yellowstone National Park" or "North America, Klondike Gold Rush National Historical Park."
We were going to set those up as WKT polygons, correct? We have the same problem with wolf recovery areas that cross state lines. Can we create searchable WKT polygons at the higher geography level?
On Thu, Oct 18, 2018 at 8:52 PM dustymc notifications@github.com wrote:
Parks are Features, but as @Jegelewicz https://github.com/Jegelewicz said that's not usually all we enter. That's just a problem (if it's a problem) of how the data are entered, not the model - nothing is stopping us from having "North America, United States, Yellowstone National Park" or "North America, Klondike Gold Rush National Historical Park."
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/1753#issuecomment-431228508, or mute the thread https://github.com/notifications/unsubscribe-auth/AOH0hPQdjjd8TUQ8aZePCgrzGF2EA3V_ks5umT5dgaJpZM4Xu_gP .
I'm not sure what's going on with that, but we certainly have a place for WKT.
wolf recovery areas
https://github.com/ArctosDB/arctos/issues/1366
IDK if those should be geography or not - go for it, probably...
searchable
Sorta. I can do a bit with various JS platforms, but if we're going to go very far with spatial data we really need spatial tools.
another thing to add to the collaborative grant with TACC?
On Thu, Oct 18, 2018 at 9:24 PM dustymc notifications@github.com wrote:
I'm not sure what's going on with that, but we certainly have a place for WKT.
wolf recovery areas
1366 https://github.com/ArctosDB/arctos/issues/1366
IDK if those should be geography or not - go for it, probably...
searchable
Sorta. I can do a bit with various JS platforms, but if we're going to go very far with spatial data we really need spatial tools.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/1753#issuecomment-431233076, or mute the thread https://github.com/notifications/unsubscribe-auth/AOH0hKu3dppPBMgYRtKZwg_hdon7M9Asks5umUXIgaJpZM4Xu_gP .
Issue Documentation is http://handbook.arctosdb.org/how_to/How-to-Use-Issues-in-Arctos.html
Table COLL_OTHER_ID_TYPE
Value NPS Unit
Definition A unit of the National Park Service
Collection type All Collection types
Attribute data type controlled vocabulary
Attribute value list of all National Parks
Attribute units N/A
Part tissue flag N/A
Other ID BaseURL N/A
Context Providing a method across Arctos to aggregate specimens from any given NPS Park
Priority I would like to have this resolved by date: 2018-10-30
Might also be a good method for Forest Service Units and State Park Units.