Arctos DB
Replies: 23 comments 7 replies
-
|
One idea we had discussed which makes sense to me is to have a limited
number of IDs such as "catalog number" , "collector number", "preparatory
number", "other ID", and then have the issuer of the ID as a metadata
field.
So we could have:
ID type: catalog number
ID value: MSB:Mammal:12345
ID issuer: Museum of Southwestern Biology (agent name)
ID link: url etc
ID assigned by: Mariel Campbell
ID assigned date: 2023-01-01
ID remarks: I really need this field to explain any weirdness etc
Then we could use this to replace all the IDs that have issued by agents?
…On Thu, Feb 23, 2023, 1:49 PM dustymc ***@***.***> wrote:
* [EXTERNAL]*
I think most of
https://arctos.database.museum/info/ctDocumentation.cfm?table=ctcoll_other_id_type
could and should be lumped into
https://arctos.database.museum/info/ctDocumentation.cfm?table=ctcoll_other_id_type#other_identifier,
and I think that doing so would not in any way degrade the data. Other
people seem to have very different views, and this causes friction for the
code table committee.
There are functional implications to having so many identifiers, including
1. Given 600+ values, many data entry folks likely do something
arbitrary, and
2. Treating them as columns means the search results form is very
crowded.
As above I think there are arguments for having any more, but I don't
understand them.
Can we develop some sort of functional policy regarding what should, and
should not, be an identifier in Arctos?
Possibly related, we create Arctos IDs with new collections, maybe we
shouldn't - there are ~300 of them now, most probably aren't used. The
answer here should be influenced by the rest of the policy - if we go in
some direction that will results in thousands more identifiers then these
probably won't be noticeable, if we go in some direction with fewer then
reducing these when possible may have a significant impact.
—
Reply to this email directly, view it on GitHub
<#5707>, or unsubscribe
</~https://github.com/notifications/unsubscribe-auth/ADQ7JBAO657Y5SZYSBRJHLDWY7ENXANCNFSM6AAAAAAVGDPLQ4>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
@campmlc that's probably better in #4604, which is currently stuck. If we can simplify that down to a few fields (something like your list) rather than what I got stuck on that would be great; implementing that is near the top of my list, or would be if I knew how to. Not being able to fully develop a policy without metadata seems reasonable, but I don't think it's a full roadblock either. For example, the table currently contains one instance of 'Texas Department of Fish and Game' - the details can be inferred, the precision is some huge department who must issue thousands of kinds of identifiers, I just can't see a single realistic thing that "Texas Department of Fish and Game=1" can do which "other identifier=Texas Department of Fish and Game 1" can't, and there's no metadata structure which might conceivable change that. I can see no real reason to put this - at least the start of it - off. While looking for a nice example (we have lots to choose from!) I noticed that about 300 of our ~600 identifiers have been used, and about 200 of them for less than 100 records. Most of this problem doesn't seem like it's actually as complicated as we're trying to make it. I also noticed ALMNH Ethnology Collection which seems to be a nonfunctional duplicate of functional identifier ALMNH:EH, so let's add 'code table admins can't sort it out and make messes' to The List. Actually there are a bunch of duplicates and a couple projects in there! That will almost certainly be a huge pain to clean up, even if nobody protests, and that is very likely to be a lossy process - whoever knew something when they chose one of the cruddy identifiers may be long gone. |
Beta Was this translation helpful? Give feedback.
-
|
I just want to confirm that as a first pass we are focusing on reducing the size of the code table by tackling low quality identifiers without linkable urls that can easily be converted to "other identifier" ID type with "issued by" agent information. However, some of the IDs in the list are clearly institutional catalog numbers that reference a specific collection. I suggest when this is the case, we proceed as above except we assign "catalog number" as the ID type, rather than other ID. Some identifiers will need to remain in the code table as explicitly defined IDs for various reasons, primarily that they encode significant information that would be lost if they are converted to "other identifiers". Examples include collector number, preparator number, IDs significantly associated with Arctos collections (NK, AF, IF), and anything that can or will be used in Entity creation. Anything potentially in these categories will need to be flagged and evaluated. These should be tackled last. |
Beta Was this translation helpful? Give feedback.
-
That is not a consideration, at all. Some of these clearly DO STUFF, those can easily continue to DO STUFF with the "typeness" moved to Agents (a data object that can itself DO STUFF - something identifiers have never had access to before). For some select few (which I'm hoping to elucidate somewhere in this Issue) it's convenient to keep them typed because it makes it slightly easier to do things like label columns in spreadsheets, or something, I guess. I don't think there's any possible situation in which moving the 'typeness' to Agents loses functionality or implies - well, anything.
Strongly disagree for all the reasons given in the IDs thread. That descriptor means a few things (most notably what many of us call "collector number"), and there are a few more things ("accession number" most prominent among them, as least among Arctos collections) that mean what you seem to think 'catalog number' means. The unnecessary type is a point of confusion, not clarification. Clarity to a global audience should be a consideration.
... who, as an Agent, issues identifiers. Is this what's not being understood? Are some of the suggested migration paths using too coarse an Agent? (If so, please suggest something better in those threads.) (If that's not it, please help me understand what the issues are, because I am struggling with that.)
Please be explicit. I absolutely have not (and will not) propose anything that I can see as lossy, and if I'm not seeing something I need to.
Why would you think this?
I think this is probably correct, but can it be quantified? ("Locally functional" is about as close as I can get, but that's not quite right. These - and collector and preparator number, but only with the addition of an Agent - lead to paperwork, but I'm not sure that's critical. The type makes them super easy to stuff into a type-named column - "NK' - in spreadsheet-like views, but that seems like weak sauce. ??????????)
I still don't know what's going on with this, things issued by Arctos collections seems like it might be a part of the criteria (except this seems to be critical for elusive reasons?????)
Agent-links are unquestionably much better at this. |
Beta Was this translation helpful? Give feedback.
-
|
I think I'm confused about what is happening over all. I follow Github and conversations pretty closely, and take the notes at AWG, but I'm still pretty lost about what is going on with Identifiers.
I know we will have a cleaner Identifier table, but I am feeling totally at sea on what they are being turned into, and how that is going to be handled and presented. I've seen examples of what it will look like in the identifier field, but besides that how will these new things do anything? We are creating new organization agents, and they will get to create new "other identifiers". But what will that do? How is that going to be searched? And how will that present when we want that identifier to be up front and top in the object record page? I am really at sea, and not understanding, and the changes are happening really really really fast. If I don't pay attention to the issues (which are going on during spring breaks by the way, people are not paying attention right now, and I feel like I cannot take a spring break because of this) something is going to be done without my say so. I know you won't get change everything right now that way, but is this breaking stuff? Do we really need to force this change on all of the collections right now? |
Beta Was this translation helpful? Give feedback.
-
|
Everyone remain calm! Every single identifier that is being modified has an issue in GitHub and you can express your objections to them there. Dusty has @ everyone involved with every identifier, so sort issues where you are mentioned and review those. The simplest explanation of what is happening is this. And this change opens up real possibilities that we didn't have in the code table. For example We used to have UFC: University of Florida Collections but this represents three diffferent agents now Florida Museum Invertebrate Zoology Collection which includes the url http://specifyportal.flmnh.ufl.edu/iz/ which is the search engine for that collection - search the associated identifier and you have connected the Arctos record to the Florida record. So this facilitates a closer link to related data than we could with the single identifier in the code table. Check out https://arctos.database.museum/guid/ALMNH:Inv:1000 Go to the url search the identifier in the Arctos record find the related record! |
Beta Was this translation helpful? Give feedback.
-
I'm with @ewommack - I have no clue what is happening despite the explanation. All I can see is my inbox is blowing up and I'm hoping I don't lose any data... the link you give us above is what is in every single one of the 600 emails I'm apparently going to get and I still don't clearly know what you're doing. I'm going to assume (I know... my mom always said...) that what you're doing is not going to hurt the discoverability of my collector numbers or links to items in other collections at UAM that are cross-cataloged (items transferred between collections like Art and Arch) and link to those other records thru the relationships we established. It would be great if we are able to have a better process for communicating and discussing the prioritization of massive changes like this (and the verbatimizing agents change - not to beat a dead horse, but I'm going to be fixing that global change for years to come). Like, call a special meeting of the AWG to clearly explain and show examples of the advantages of the new process so we can all clearly understand the rationale - sometimes reading these github issues is like a senior seminar in cross-cultural communications! And maybe @Jegelewicz can explain how to block these 600 emails and the additional 600 replies I'm getting as each of these changes gets their own issue? Like Beth, we're on spring break and I have other priorities and I'm spending all my time muting conversations or deleting messages. |
Beta Was this translation helpful? Give feedback.
-
|
At some level all of those things stay the same, the 'typeness' just gets moved. At a more practical level, it looks to me like typing will better. It's come up quite a bit lately that identifier types seem to not be used very consistently, users don't seem to be really digging through the documentation (of 600+ identifiers, whoodathunk?....) and figuring out what they all mean, so they use what they hope it might mean. (Field number - primarily a fish-thing by definition - is probably the most obvious place to see this.) Under the new system, there will be a lot fewer, much coarser options (at least for the bulk of things). A user will have fewer choices, be more likely to choose the right thing even if literally picking random types, and - most importantly - they'll attribute the thing to you (which I think/hope is much easier to understand) and that seems much more likely to lead to data. All of that carries over to search. Some casual user is much more likely to figure out "@ewommack was involved" than they are to read our documentation and figure out that field number doesn't mean what they think it should mean, and so they're a lot more likely to successfully perform targeted searches. I don't think there are any functional connection change. Certainly going from some type that is effectively "any of the many types issued by this huge institution" to a generic type with the huge institution issuing is just a clarification. MAYBE there's some more-subtle tail on that, but I don't think I see it yet. That's much of what I'm trying to work out here; where's that line, is something missing from some UI, can procedures become deterministic, etc.? (Resolvable identifiers - things capable of actually making connections - will be another discussion; they will need discussed here for policy development, but we are not there yet.) One thing the agents DO is introduce agent-stuff; structure. "Types" aren't an isolated identifier, but involve some agent (maybe the wet collection) who has a parent (collection) who has a parent (institution). (And what @Jegelewicz said - neat!) |
Beta Was this translation helpful? Give feedback.
-
Mange your profile in GitHub - don't get every single notification - just those where you are mentioned https://handbook.arctosdb.org/how_to/How-to-Use-Github-for-Arctos.html#managing-github-notifications |
Beta Was this translation helpful? Give feedback.
-
|
The functionality that you have explained has nothing to do with how we use the UWYMV identifiers. I'm sure it will be nifty for some, but it will screw up ours. They do not link to outside sources, we do not use them that way. I really think Arctos jumped when it should have walked here. This is a big change, that is being done very fast, and you are expecting people to be able to find these notices during a major break period for most collections. I know spring break is annoying, and it is very staggered. Most schools (K-12, colleges) take it at different times. People are not there to answer your issues. I really recommend that you change the "I will plan on proceeding with this about 2023-03-27 if there are no objections." In another frustration I have asked twice now in two different GitHub conversations to please do not change the University of Wyoming identifiers. I've just heard - wait for the issue that will be posted about them. Instead of waiting on pins and needles for something to come through, I'll post the issue (#5937). I think this would have worked a lot smoother if Arctos had reached out to collections first and asked which identifiers they did not wanted changed. I know you guys are excited about this new functionality, but it went from let's clean up a code table and change a couple, to changing everything. I do not think we understand or are ready for that yet. |
Beta Was this translation helpful? Give feedback.
-
|
This has nothing to do with linking to outside sources (although it can facilitate that). This only changes one thing - the identifier type. BUT it lets you have a ton more flexibility in describing the type through the agent that issues it. You will still be able to use these identifiers the same way you always have! Perhaps I should add some for you so that you can see how it works? |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the offer of a demo, but I would really not like them changed please. |
Beta Was this translation helpful? Give feedback.
-
We are doing that right NOW - see the appropriate issues! WHO is "Arctos"? We discussed this at the AWG meeting and everyone was on board - if there was a lack of clarity, we should have said NO, then sent this back to the committee.
There is a banner and a GitHub Announcement and we are putting every single identifier change in a separate issue for discussion. What else could we have done/do? |
Beta Was this translation helpful? Give feedback.
-
|
The notes say you were proposing to change institutional identifiers. I took that to mean you were changing ones for other outside Arctos museums. Instead you're changing everything. I think you've changed the scope and goal of the issue. Is it now to eliminate Identifiers completely? I am making the point that GITHUB does not have away messages, and people are not there to be contacted in your short time span you are giving them. Instead of saying - if you do not respond by this date we're changing this, it might be better to say we would like to change this, it relates to your collection, please give us an ok before we can.. I thank you for the offer of a demo, but I really would not like them changed please. |
Beta Was this translation helpful? Give feedback.
-
|
I think if we drop the 3-23-23 automated cutoff and actually follow the
protocol as described in each issue - with sign off by two Code Table
admins required, that will give everyone a chance to evaluate how this is
working with some of the easy to change identifiers, and contemplate other
potential issues on a collection by collection basis. We have a Code Table
meeting this week - which is spring break. We should use this meeting for
everyone who can attend to put together some documentation on how these
proposed changes will work, with examples for the various scenarios.
Each identifier needs to be evaluated as to whether the issued by metadata
and "other identifier" ID type is sufficient to capture all necessary
information and make required links, or whether the ID needs to be changed
for existing records prior to the update, or whether the ID needs to remain
in the code table, and collections need to be given time to understand the
options. We have issues for this- but there are an overwhelming number of
issues being created right now, and even people paying attention are
missing them. We need to give everyone more time to asses, and resources
they need to understand what the proposed model is and does.
…On Tue, Mar 14, 2023 at 9:38 AM Teresa Mayfield-Meyer < ***@***.***> wrote:
* [EXTERNAL]*
if Arctos had reached out to collections first and asked which identifiers
they did not wanted changed.
We are doing that right NOW - see the appropriate issues!
WHO is "Arctos"? We discussed this at the AWG meeting
<https://docs.google.com/document/d/1wUmwHePioIXX9SzuAqXv848QKR-G8jjmH3Xs-opWcRA/edit#>
and everyone was on board - if there was a lack of clarity, we should have
said NO, then sent this back to the committee.
Identifiers Interest Group - #4604
<#4604 (comment)>
Trying to pair down the Identifiers list
When you are adding Another Identifier, have a Issued by this Agent and
link to the Arctos Agent page that explains info on this identifier.
Add issued by and remarks to identifiers
Convert all institutional identifiers to a generic term and add
institution as issuer ( see
https://arctos.database.museum/info/ctDocumentation.cfm?table=ctcoll_other_id_type
There is a banner and a GitHub Announcement
<#5771> and we are putting every
single identifier change in a separate issue for discussion. What else
could we have done/do?
—
Reply to this email directly, view it on GitHub
<#5707 (comment)>,
or unsubscribe
</~https://github.com/notifications/unsubscribe-auth/ADQ7JBDLIZQYIG5J3BEFOITW4CGGZANCNFSM6AAAAAAVGDPLQ4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
That is what we are doing - none of the Arctos collection identifiers will be changed. UWYMV Frozen Tissue Collection show up in the list because they do not have a base url so they don't link to anything. In the issues for those, you can just express why you would rather keep them as they are (although I would advocate for adding the issued by agents to them anyway).
It isn't a big deal and there is really no reason to panic. |
Beta Was this translation helpful? Give feedback.
-
|
But that is not how we want it to work. Please do not change it and do not create an agent for those. It is not the functionality we use it for, and we do not want it. |
Beta Was this translation helpful? Give feedback.
-
|
This was my understanding as well: "The notes say you were proposing to change institutional identifiers. I took that to mean you were changing ones for other outside Arctos museums." |
Beta Was this translation helpful? Give feedback.
-
|
I don't understand the opposition to an agent? I have already created them - and they aren't hurting anything are they? If they are, I need to understand why. |
Beta Was this translation helpful? Give feedback.
-
|
Because it is not how we use those Identifiers, and we did not agree to it. Creating agents for museums outside of Arctos is what I agreed to in the AWG meeting. Not this. Please do not do this. Please do not create those agents. |
Beta Was this translation helpful? Give feedback.
-
|
This needs to stop until people are in agreement. I didn't understand all of this until Adrienne stopped by my office and explained to me the NEON and Mexican Wolf situations at MSB where there is more than one kind of number being issued by the same entity. These problems have been parsed out to individuals directly involve and because of that, I wasn't on that thread. Why aren't we given these lists and being asked what these numbers are? 'other identifier' works if there's only an institutional catalog number, but it's usually pretty easy to get more specific than that, and most of us know our collections well enough to be able to say that all of the specimens we have with this kind of number. I would prefer that I were able to email Dusty after he sends out the list of numbers from a particular institution and tell him that these are institutional catalog numbers |
Beta Was this translation helpful? Give feedback.
-
|
A brief note about why we are doing this. The current other identifier code table includes over 540 unique values. This makes customizing search results almost impossible if they are all listed as options for columns. In addition, it makes selecting an identifier difficult during search or data entry as one may need to peruse this long list to find what one needs. As Arctos grows, the only thing that can happen is that this code table will grow as well and at some point it is going to be unmanageable with hidden duplicates everywhere. A smaller selection of generic types, accompanied by the most specific issuing agent possible will reduce growth in this code table and create richer data about the identifiers. See #5707 (comment) for an example of how this process has made the related data move one step closer to Arctos and provided a more succinct identifier rather than a generic one (a specific collection vs. an entire museum) Please remember that agents can be organizations and that is very loosely defined. Collections are organizations and may be divisions of museums, institutions or even other collections! GBIF and GRSciColl recognize collections and we should too. Creating an appropriately specific agent should not be a problem. This is a new way of thinking about identifiers. It requires documentation and use to find flaws, however, any changes made are just moving information from the identifier to the agent. A specific agent was created for each identifier being proposed for change, so for now, nothing is happening except that once an issuing agent is assigned, you have the ability to embellish that agent. Add links to websites or GRSciColl or GBIF collection or to people who work in them. Create a rich web of information about your identifiers by telling the world who created them. |
Beta Was this translation helpful? Give feedback.
-
|
Proposed identifier categories to start discussion. We have to start with some common terms here - each of these may raise different issues and require different management, instead of the blanket approach we are using now. There is some overlap - please comment. Also attaching a google doc link.
https://docs.google.com/document/d/1txiBBRNUYbeoWvCdtFtsJbjanrZD9dWcT6pB8Hk6g9U/edit?usp=sharing |
Beta Was this translation helpful? Give feedback.
-
|
@AdrienneRaniszewski @ewommack @AJLinn @campmlc @dustymc @Jegelewicz Implementation has gotten way ahead of discussion on this. The decentralization of this process into an issue for each set of numbers has made this process especially problematic because we have no idea what the bigger issues are. I only knew what's going on with MSB:Mamm because I can hear Adrienne's gasps of frustration dealing with NEON and Mexican Wolf issues. Adrienne and Mariel and I met this morning to discuss. I DO NOT approve any more changes to MSB:Birds until this issue is resolved. This is my notice. I am not going through all of the individual issues to stop each one. So far for MSB:Birds, this process is only turning institutional catalog numbers of other collections into other identifers. I'm not willing to conflate an institutional catalog number with a number a student , wildlife rehabilitator, or agency personnel assigns for their often more ephemeral use. When there are entities like USFWS and NEON that assign multiple types of numbers, the likelihood that relationships are lost or at least very difficult to reconstruct sounds very high if they are all subsumed into other identifiers. Way forward: Send us these lists of numbers by identifier type as was done in the proliferation of issues and let us go through and determine what kind of identifiers these are. Let us annotate the lists as we have done for things like attributes, parts, agents, etc. in the past. Adding some new identifier types is likely going to be part of the solution (e.g., studbook number). At that point, implementation of these changes can begin. |
Beta Was this translation helpful? Give feedback.
-
|
I trust that no data are being lost, nor any search functionality will be
lost, all these changes are just moving data from one field to another to
clean up the waste basket field we have now.
Confirmation of this would be good!
-Derek
…On Wed, Mar 15, 2023 at 9:55 AM catherpes ***@***.***> wrote:
@AdrienneRaniszewski </~https://github.com/AdrienneRaniszewski> @ewommack
</~https://github.com/ewommack> @AJLinn </~https://github.com/AJLinn> @campmlc
</~https://github.com/campmlc> @dustymc </~https://github.com/dustymc>
@Jegelewicz </~https://github.com/Jegelewicz>
Implementation has gotten way ahead of discussion on this.
When Beth and Angela and Mariel are waving their hands and yelling for
this to stop, but everything is proceeding forward over spring break with
an artificial deadline for implementation, this makes me really nervous.
The decentralization of this process into an issue for each set of numbers
has made this process especially problematic because we have no idea what
the bigger issues are. I only knew what's going on with MSB:Mamm because I
can hear Adrienne's gasps of frustration dealing with NEON and Mexican Wolf
issues.
Adrienne and Mariel and I met this morning to discuss.
*I DO NOT approve any more changes to MSB:Birds until this issue is
resolved. This is my notice. I am not going through all of the individual
issues to stop each one.*
So far for MSB:Birds, this process is only turning institutional catalog
numbers of other collections into other identifers. I'm not willing to
conflate an institutional catalog number with a number a student , wildlife
rehabilitator, or agency personnel assigns for their often more ephemeral
use.
When there are entities like USFWS and NEON that assign multiple types of
numbers, the likelihood that relationships are lost or at least very
difficult to reconstruct sounds very high if they are all subsumed into
other identifiers.
Way forward: Send us these lists of numbers by identifier type as was done
in the proliferation of issues and let us go through and determine what
kind of identifiers these are. Let us annotate the lists as we have done
for things like attributes, parts, agents, etc. in the past. Adding some
new identifier types is likely going to be part of the solution (e.g.,
studbook number). At that point, implementation of these changes can begin.
Overall, this seems like a great opportunity to clean up identifiers, but
it needs to be done in an agreeable manner.
—
Reply to this email directly, view it on GitHub
<#5707 (comment)>,
or unsubscribe
</~https://github.com/notifications/unsubscribe-auth/ACFNUM4JATPDBRF2FPUMCLDW4H7CPANCNFSM6AAAAAAVGDPLQ4>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
--
+++++++++++++++++++++++++++++++++++
*Derek S. Sikes*, Curator of Insects, Professor of Entomology
University of Alaska Museum (UAM), University of Alaska Fairbanks
1962 Yukon Drive, Fairbanks, AK 99775-6960
***@***.*** phone: 907-474-6278 he/him/his
University of Alaska Museum <https://www.uaf.edu/museum/collections/ento/>
- search 357,704 digitized arthropod records
<http://arctos.database.museum/uam_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
|
Beta Was this translation helpful? Give feedback.
-
This has been going on for well over a year. These aren't the only nor original issues, but #4101 and #4604 are the main development issues leading to the recent changes.
correct
correct (and inherently improved)
That seems like a reasonable way to view the most essential elements of this. (Beyond the basics, IssuedBy is capable of carrying much more data than a type, and so is capable of answering many more questions. As a sort of incidental the new arrangement is much nicer in tabular views. There's much more - all fleshed out in the issues - but I think that's probably what will be most noticeable to most users.) |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, I can't keep up with every issue. From this issue 5707 back to to 4101 is over three Arctos Issues per day annually including weekends and holidays. I don't know how anyone can keep up. Half of the time I don't understand the language being used in these discussions and I try to adapt to the changes and keep my head down with the understanding that what's being done is ultimately helping to better serve the data. This is a case where I began to go along, as the UAZ records indicate, but now see that this needed to be slowed down. Mariel, Angela, and Beth who are invested in this process in a way that I'm not were also not in agreement with this, and this was a good indicator that we need to wait until some things get resolved. |
Beta Was this translation helpful? Give feedback.
-
|
Adding the issued by agent name to all IDs is not controversial - this is a
much needed improvement that greatly expands functionality. However, there
needs to be discussion of how to handle the different categories of
identifiers as previously posted in this issue. We have consensus at MSB
that we do not want all identifiers in these issues to be converted to
other IDs. IDs which are known to be institutional catalog numbers of any
sort need to be recorded as catalog number or institutional catalog number.
Other numbers, eg National Park Service catalog numbers and accession
numbers, should be converted to catalog number and accession number
respectively - this should be the case anytime we have multiple
different IDs that are issued by the same agent. There are additional ID
types that also need to be maintained in the code table, and some that will
need to be added, eg studbook number, band number, etc, in order to
maintain functionality of relationships with other collections and with
external agencies and to ensure accurate entity formation. The type of
identifier subject to conversion should be opened for discussion.
On Wed, Mar 15, 2023 at 12:18 PM DerekSikes ***@***.***>
wrote:
… * [EXTERNAL]*
I trust that no data are being lost, nor any search functionality will be
lost, all these changes are just moving data from one field to another to
clean up the waste basket field we have now.
Confirmation of this would be good!
-Derek
On Wed, Mar 15, 2023 at 9:55 AM catherpes ***@***.***> wrote:
> @AdrienneRaniszewski </~https://github.com/AdrienneRaniszewski> @ewommack
> </~https://github.com/ewommack> @AJLinn </~https://github.com/AJLinn>
@campmlc
> </~https://github.com/campmlc> @dustymc </~https://github.com/dustymc>
> @Jegelewicz </~https://github.com/Jegelewicz>
>
> Implementation has gotten way ahead of discussion on this.
> When Beth and Angela and Mariel are waving their hands and yelling for
> this to stop, but everything is proceeding forward over spring break with
> an artificial deadline for implementation, this makes me really nervous.
>
> The decentralization of this process into an issue for each set of
numbers
> has made this process especially problematic because we have no idea what
> the bigger issues are. I only knew what's going on with MSB:Mamm because
I
> can hear Adrienne's gasps of frustration dealing with NEON and Mexican
Wolf
> issues.
>
> Adrienne and Mariel and I met this morning to discuss.
>
> *I DO NOT approve any more changes to MSB:Birds until this issue is
> resolved. This is my notice. I am not going through all of the individual
> issues to stop each one.*
>
> So far for MSB:Birds, this process is only turning institutional catalog
> numbers of other collections into other identifers. I'm not willing to
> conflate an institutional catalog number with a number a student ,
wildlife
> rehabilitator, or agency personnel assigns for their often more ephemeral
> use.
>
> When there are entities like USFWS and NEON that assign multiple types of
> numbers, the likelihood that relationships are lost or at least very
> difficult to reconstruct sounds very high if they are all subsumed into
> other identifiers.
>
> Way forward: Send us these lists of numbers by identifier type as was
done
> in the proliferation of issues and let us go through and determine what
> kind of identifiers these are. Let us annotate the lists as we have done
> for things like attributes, parts, agents, etc. in the past. Adding some
> new identifier types is likely going to be part of the solution (e.g.,
> studbook number). At that point, implementation of these changes can
begin.
> Overall, this seems like a great opportunity to clean up identifiers, but
> it needs to be done in an agreeable manner.
>
> —
> Reply to this email directly, view it on GitHub
> <
#5707 (comment)
>,
> or unsubscribe
> <
/~https://github.com/notifications/unsubscribe-auth/ACFNUM4JATPDBRF2FPUMCLDW4H7CPANCNFSM6AAAAAAVGDPLQ4
>
> .
> You are receiving this because you are subscribed to this thread.Message
> ID: ***@***.***>
>
--
+++++++++++++++++++++++++++++++++++
*Derek S. Sikes*, Curator of Insects, Professor of Entomology
University of Alaska Museum (UAM), University of Alaska Fairbanks
1962 Yukon Drive, Fairbanks, AK 99775-6960
***@***.*** phone: 907-474-6278 he/him/his
University of Alaska Museum <https://www.uaf.edu/museum/collections/ento/>
- search 357,704 digitized arthropod records
<http://arctos.database.museum/uam_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
—
Reply to this email directly, view it on GitHub
<#5707 (comment)>,
or unsubscribe
</~https://github.com/notifications/unsubscribe-auth/ADQ7JBE7R52N4OQWYNKUVSTW4IBXNANCNFSM6AAAAAAVGDPLQ4>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
Please add the identifier type that would be preferred over other identifier to the individual issues OR add them to the Google Sheet in the suggested other ID type column and I will transfer them. Please make use of one of the existing generic other ID types below or if something new is needed, create a code table request. Let's keep in mind that we are attempting to lower the cost of ID type by shortening the list of types in the code table. Some "generic" identifiers may still be too specific and using a more appropriate Agent source might make more sense. Post here if you have any questions! barcode [ link ] |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
I think most of https://arctos.database.museum/info/ctDocumentation.cfm?table=ctcoll_other_id_type could and should be lumped into https://arctos.database.museum/info/ctDocumentation.cfm?table=ctcoll_other_id_type#other_identifier, and I think that doing so would not in any way degrade the data. Other people seem to have very different views, and this causes friction for the code table committee.
There are functional implications to having so many identifiers, including
As above I think there are arguments for having any more, but I don't understand them.
Can we develop some sort of functional policy regarding what should, and should not, be an identifier in Arctos?
Possibly related, we create Arctos IDs with new collections, maybe we shouldn't - there are ~300 of them now, most probably aren't used. The answer here should be influenced by the rest of the policy - if we go in some direction that will results in thousands more identifiers then these probably won't be noticeable, if we go in some direction with fewer then reducing these when possible may have a significant impact.
Beta Was this translation helpful? Give feedback.
All reactions