campmlc
commented
2 years ago Who would use this, and how? Could it be useful for ALMNH in the short term, as proof of concept?
On Thu, Feb 17, 2022 at 12:10 PM dustymc @.***> wrote:
- [EXTERNAL]*
Is your feature request related to a problem? Please describe.
The current API is (mostly, probably) capable of building a replica of the catalog record detail page by specifying appropriate "columns." That of course relies on the user having some idea of what we consider to be "catalog record details."
Good:
- There's one 'catalog record stuff' API call, no way to get lost
- Our idea of what constitutes a catalog record is not the only valid viewpoint, the current approach allows/encourages users to build what they want how they want.
- The current approach only uses the resources that are requested; it's generally cheaper than the alternative.
Not-so-good:
- Users have to sort through the documentation (which is available in the API) to figure out what they want
- We have no way of suggesting what they use or how those things interact with each other.
Describe what you're trying to accomplish
Should we offer a compiled "catalog record stuff" API call? That would provide a very easy way to get everything on the catalog record detail page, and would provide us an opportunity to organize things - eg #2450 https://github.com/ArctosDB/arctos/issues/2450 could be delivered as one unavoidable object...
rights { license: whatever, copyright_holder: agent-object, whatever: morestuff }
rather than scattering those kinds of data across multiple "columns." This would probably add some expense to most API calls, but would also allow us to predict what's going to be requested and build a cache.
Describe the solution you'd like
First, discussion - is this useful?
Describe alternatives you've considered
Don't.
Additional context
ArctosDB/internal#51 https://github.com/ArctosDB/internal/issues/51 is very related - it's difficult to build tools without knowing what sort of usage we want to allow.
If we move forward with this, the /guid/ pages in Arctos should be rebuilt to use it. This would also address the "mostly, probably" above - we don't use the current API to build those pages, so I don't know if it's actually fully capable or not.
Priority
??
— Reply to this email directly, view it on GitHub https://github.com/ArctosDB/arctos/issues/4337, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADQ7JBE4VYD2KNG3AYKC67DU3VB2ZANCNFSM5OVTAFAA . 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: @.***>
dustymc
Jegelewicz
jcabbott72
acdoll
mkoo
Is your feature request related to a problem? Please describe.
The current API is (mostly, probably) capable of building a replica of the catalog record detail page by specifying appropriate "columns." That of course relies on the user having some idea of what we consider to be "catalog record details."
Good:
Not-so-good:
Describe what you're trying to accomplish
Should we offer a compiled "catalog record stuff" API call? That would provide a very easy way to get everything on the catalog record detail page, and would provide us an opportunity to organize things - eg https://github.com/ArctosDB/arctos/issues/2450 could be delivered as one unavoidable object...
rather than scattering those kinds of data across multiple "columns." This would probably add some expense to most API calls, but would also allow us to predict what's going to be requested and build a cache.
Describe the solution you'd like
First, discussion - is this useful?
Describe alternatives you've considered
Don't.
Additional context
https://github.com/ArctosDB/internal/issues/51 is very related - it's difficult to build tools without knowing what sort of usage we want to allow.
If we move forward with this, the
/guid/pages in Arctos should be rebuilt to use it. This would also address the "mostly, probably" above - we don't use the current API to build those pages, so I don't know if it's actually fully capable or not.Priority
??