Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Package(d) ADO download #460

Open
DiegoPino opened this issue Aug 16, 2024 · 2 comments
Open

Package(d) ADO download #460

DiegoPino opened this issue Aug 16, 2024 · 2 comments
Assignees
Labels
enhancement New feature or request future roadmap Things we would love to have but are no priority for version 1.0 help wanted Extra attention is needed IR Institutional repositories, what every scholar loves and fears metadata Meta(l) data UX Like UI but with an X
Milestone

Comments

@DiegoPino
Copy link
Member

DiegoPino commented Aug 16, 2024

What?

This has been in the roadmap as an idea for a while and woke up thanks to @alliomeria today. We have already Frictionless package processing but no formatter for their content yet. But also people have asked/commented in the wild it could be nice to have a way to download a whole Object (ADO) with files, etc.

If we extend the idea, and think about a roundtrip, this concept of allowing a whole ADO to be downloaded as a ZIP file with a manifest, individual streams, etc (a Frictionless data package) could also allow seamless moving of ADOs as a whole (and ingest-able via AMI and/or JSON API) between systems.

This would also (if thought properly) allow users to have different modes (one for admins with the whole knit and caboodle 🧶 ) and one defined at a finer level for end users to download, maybe using a selective ap:tasks key, partial/admin defined subsets? Or maybe driven also by a template? or a global configuration? Or all of them? This might even allow us to package "multiple revisions" and re ingest, if someone wants to keep the whole history of changes, a thing Drupal also by default does not allow via the JSON-API or REST.

I personally like the idea of this being a data package. Very re-usable, consistent even between other platforms and reuses tooling we have.
(e.g we have a post processor that can list/read contents of such already).

The implementation could start with an on-the-fly 🪰 zipper 🤐 of attached files and JSON content protected via permissions/controller) for certain roles. And then extend to configuration and rountrip/re-ingest?

@alliomeria please feel free to comment/add/remove (or use say no/"níl" 🇮🇪 if this makes or not sense) and thanks for bringing back this idea through your pro interaction with our partners.

@DiegoPino DiegoPino added this to the 1.5.0 milestone Aug 16, 2024
@DiegoPino DiegoPino self-assigned this Aug 16, 2024
@DiegoPino DiegoPino added enhancement New feature or request help wanted Extra attention is needed future roadmap Things we would love to have but are no priority for version 1.0 metadata Meta(l) data IR Institutional repositories, what every scholar loves and fears UX Like UI but with an X labels Aug 16, 2024
@DiegoPino
Copy link
Member Author

Connects with
#441

@DiegoPino
Copy link
Member Author

and with esmero/strawberry_runners#39

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request future roadmap Things we would love to have but are no priority for version 1.0 help wanted Extra attention is needed IR Institutional repositories, what every scholar loves and fears metadata Meta(l) data UX Like UI but with an X
Projects
None yet
Development

No branches or pull requests

1 participant