Arctos DB
Replies: 19 comments 3 replies
-
|
Why not just change the headers in the loaders to "DWC Triplet"? It would
be very awkward and difficult to proofread and catch errors in a loader
file that uses the url instead of the triplet.
…On Thu, Dec 16, 2021 at 10:02 AM dustymc ***@***.***> wrote:
* [EXTERNAL]*
*Is your feature request related to a problem? Please describe.*
Arctos provides every record a GUID (
https://arctos.database.museum/guid/ASNHC:Mamm:20579), but we also use
the "DWC Triplet" (ASNHC:Mamm:20579) internally (where it is unique) and
call it a GUID. These things get used mostly-interchangeably, and should
not be.
*Describe what you're trying to accomplish*
1. Identifiers should be easy to copy/paste/find/identify (see eg #4199
<#4199>). URLs are, other
stuff isn't.
2. I don't think the scope of where various identifiers are useful is
fully understood; our intended-internal usage "leaks" to external, where
the identifiers cannot do what I suspect users hope they'll do.
*Describe the solution you'd like*
Phase out all 'DWC Triplet' usage; stop contributing to the problem.
*Describe alternatives you've considered*
Change internal terminology.
*Additional context*
"ASNHC:Mamm:20579" is a contribution to
https://en.wikipedia.org/wiki/Replication_crisis;
https://arctos.database.museum/guid/ASNHC:Mamm:20579 is a solution.
*Priority*
Critical big-picture, but could be phased in as forms are rebuilt in
Arctos.
—
Reply to this email directly, view it on GitHub
<#4200>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADQ7JBGD76IIHG6UXNVNTC3URILSFANCNFSM5KG2EJDQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
From the point of view of a manager trying to handle the data in these
files, requiring the use of the url is an unwanted complication. If I had
to edit the file, I would probably end up deleting the https prefix just to
be able to work with the data, and then have to add it back in before load.
The biggest problem in Arctos tools is that the various tools are
inconsistent in whether the full triplet is required or whether the triplet
is split into different columns.
On Thu, Dec 16, 2021 at 10:09 AM Mariel Campbell ***@***.***>
wrote:
… Why not just change the headers in the loaders to "DWC Triplet"? It would
be very awkward and difficult to proofread and catch errors in a loader
file that uses the url instead of the triplet.
On Thu, Dec 16, 2021 at 10:02 AM dustymc ***@***.***> wrote:
> * [EXTERNAL]*
>
> *Is your feature request related to a problem? Please describe.*
>
> Arctos provides every record a GUID (
> https://arctos.database.museum/guid/ASNHC:Mamm:20579), but we also use
> the "DWC Triplet" (ASNHC:Mamm:20579) internally (where it is unique) and
> call it a GUID. These things get used mostly-interchangeably, and should
> not be.
>
> *Describe what you're trying to accomplish*
>
> 1. Identifiers should be easy to copy/paste/find/identify (see eg
> #4199 <#4199>). URLs are,
> other stuff isn't.
> 2. I don't think the scope of where various identifiers are useful is
> fully understood; our intended-internal usage "leaks" to external, where
> the identifiers cannot do what I suspect users hope they'll do.
>
> *Describe the solution you'd like*
>
> Phase out all 'DWC Triplet' usage; stop contributing to the problem.
>
> *Describe alternatives you've considered*
>
> Change internal terminology.
>
> *Additional context*
>
> "ASNHC:Mamm:20579" is a contribution to
> https://en.wikipedia.org/wiki/Replication_crisis;
> https://arctos.database.museum/guid/ASNHC:Mamm:20579 is a solution.
>
> *Priority*
>
> Critical big-picture, but could be phased in as forms are rebuilt in
> Arctos.
>
> —
> Reply to this email directly, view it on GitHub
> <#4200>, or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ADQ7JBGD76IIHG6UXNVNTC3URILSFANCNFSM5KG2EJDQ>
> .
> Triage notifications on the go with GitHub Mobile for iOS
> <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
> or Android
> <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
>
> You are receiving this because you are subscribed to this thread.Message
> ID: ***@***.***>
>
|
Beta Was this translation helpful? Give feedback.
-
|
Briefly discussed with @campmlc @Jegelewicz in office hours.
The more I learn the more important this seems, but it's more verbose, different (which seems to always be scary), and I can't go it alone so I'm moving to discussions. |
Beta Was this translation helpful? Give feedback.
-
|
This should be expanded to "stop using partial identifiers." Our habits affecta things like API users; I've had to explain to USWFS why the thing we call a GUID is not in fact a a GUID, and how that means they can't test links by just asking the API for the identifier but rather have to unassemble and reassemble (introduce a bunch of places to make mistakes). Our approach to Other IDs is also ensuring that they cannot retrieve relationships or act on other should-be-actionable identifiers. See also #5639: this also affects expectations. |
Beta Was this translation helpful? Give feedback.
-
|
So what does this look like from a user's perspective? Asking people to type in full urls without error is assuming more than is possible in human capacity. What does your proposal look like, exactly? |
Beta Was this translation helpful? Give feedback.
-
|
My proposal is simply to avoid things that only work in very limited scopes. If some part of it advances beyond that, it will be moved out of discussions. I try not to type critical things (partially because I understand the limitations of that input device, but mostly just because it's about always easier to copy/paste), and assume everyone else does too. From a user's perspective in very general terms, this should mean grabbing everything that's in the URL bar or clicking the 'copy' button instead of needing to know the origins of the components so they can chop those accessible things up into limited-scope identifiers. |
Beta Was this translation helpful? Give feedback.
-
|
So can we use the dwc triplet internally and the full url externally? What environments would require the use of the full url? |
Beta Was this translation helpful? Give feedback.
-
Scroll up about two comments, there is no such boundary. (Or perhaps its just very porous - our API easily crosses it, if it exists.) #6064 seems to me compelling evidence that dealing with any partial identifiers (and arbitrary pigeonholes) is more difficult than it needs to be. #6248 and #6162 are two very recent issues that just couldn't exist if we used actual identifiers. |
Beta Was this translation helpful? Give feedback.
-
|
I think that the community needs to know what "use actual identifiers" means in terms of changes to workflows, interfaces, tools, loan agreements, citations, publications, identifier views and downloads etc etc before any discussion can happen. |
Beta Was this translation helpful? Give feedback.
-
|
I support calling the Arctos GUID the full URL. This is also what we are defining the GUID as in the Arctos paper per the AWG discussion 5-24-2024, as the url created based on the Arctos "record identifier". @ccicero Revised wording: "Each cataloged record has an Arctos Globally Unique Identifier (GUID) that is constructed from the record identifier (e.g., https://arctos.database.museum/guid/APSU:Fish:1079)." |
Beta Was this translation helpful? Give feedback.
-
|
As @acdoll mentioned, all references to GUID in column headers for bulkload tools should be changed to "record identifier" if we do this. |
Beta Was this translation helpful? Give feedback.
-
|
Meet in Happy Hour? |
Beta Was this translation helpful? Give feedback.
-
|
I'm there now - too busy and lost track of time! |
Beta Was this translation helpful? Give feedback.
-
|
Be right there |
Beta Was this translation helpful? Give feedback.
-
|
Thanks @Jegelewicz. Talk lunchtime tomorrow. |
Beta Was this translation helpful? Give feedback.
-
I think that's backwards, but I'm probably just being pedantic. The 'base' record URL is also a record GUID.
I believe #7808 implicitly involves calling "the GUID" "Arctos record identifier" (which is a good change, Arctos makes lots of GUIDs - and can carry non-GUID identifiers, which is making me question the proposed name... - for lots of things, and a record can have lots of GUIDs in addition to the native one). Are you suggesting we keep using the "triplet" for internal use? I think that's probably just a way to confuse ourselves (and anyone who might want to use our API), but it may be necessary, and if we do renaming it to something does seem like a small step in the right direction - unless that name is the name I thought we'd agree to use for the GUID.... |
Beta Was this translation helpful? Give feedback.
-
|
We are including in the published paper that the GUID is the URL that includes the record identifier. Right now my understanding of the Arctos GUID is based on what we as users and operators see in everything we do through the interface available to us - which is either the "DWC-Triplet" (which is clearly wrong for non-DWC collections, and so should be renamed as the Arctos record identifier), or the catalog record URL, which includes the record identifier. For the purposes of this discussion, we should clarify that we are referring to sorting these two out, and not referring to any other non-catalog record guids in use by Arctos. |
Beta Was this translation helpful? Give feedback.
-
The URL is a GUID, yes.
The URL which is also a GUID is also the record identifier; it includes it in the sense that it is it.
That's why I opened this issue, why I'd really like to just rip the band-aid off and stop pretending like we work in isolation and confusing/torturing ourselves by using cruddy identifiers. There's one useful identifier generated for every record, this does not have to be complicated or confusing.
GUIDs are GUIDs and not-GUIDs are not GUIDs, wherever they're found.
If you mean the GUID, sure. If you don't (and I think you don't) then this Issue is not being sufficiently prioritized.
We could just not use the one that clearly confuses everyone and can't DO STUFF outside of a very small (and very leaky) environment. |
Beta Was this translation helpful? Give feedback.
-
|
GUID - https://arctos.database.museum/guid/UTEP:Herb:68833 What else do we need to define? |
Beta Was this translation helpful? Give feedback.
-
#7808 maybe?! - that's proposed "Arctos record identifier" for Here's a better dictionary:
|
Beta Was this translation helpful? Give feedback.
-
|
I support @Jegelewicz proposal. It addressed the social, temporal, and user interface issues which weigh heavily here. |
Beta Was this translation helpful? Give feedback.
-
|
In light of the discussion,
let's call the "ABC:XYZ:123" thing "triplet" |
Beta Was this translation helpful? Give feedback.
-
Is your feature request related to a problem? Please describe.
Arctos provides every record a GUID (https://arctos.database.museum/guid/ASNHC:Mamm:20579), but we also use the "DWC Triplet" (ASNHC:Mamm:20579) internally (where it is unique) and call it a GUID. These things get used mostly-interchangeably, and should not be.
Describe what you're trying to accomplish
Describe the solution you'd like
Phase out all 'DWC Triplet' usage; stop contributing to the problem.
Describe alternatives you've considered
Change internal terminology.
Additional context
"ASNHC:Mamm:20579" is a contribution to https://en.wikipedia.org/wiki/Replication_crisis; https://arctos.database.museum/guid/ASNHC:Mamm:20579 is a solution.
Priority
Critical big-picture, but could be phased in as forms are rebuilt in Arctos.
Beta Was this translation helpful? Give feedback.
All reactions