Fedora Strategic Planning Sub Committee Meeting
Date: June 2, 2022
Attendees:
- Arran Griffith
- Laurie Arp
- Tim Shearer (Steering Chair)
- Jennifer Gilbert (Chair-Elect)
- Robin Ruggaber
- Scott Prater
- Thomas Bernhart
- Heather Greer-Klein
- Jared Whiklo
- Kate Dohe
- Rosalyn Metz
- Jon Dunn
ITAV Facet: Technology
ITAV Activity: https://wiki.lyrasis.org/display/ITAV/ITAViP+Toolkit%3A+Technology?preview=/225150170/225150507/ITAViP_Tech_P3_ListOfDreams.docx
Idea | Vote |
Fedora embraces ethical source principles | |
pre-built expression for indexing/harvesting (e.g. google) | |
Fedora standards implementation remains flexible to local implementations - can opt in to LDP, or out, for example | |
Integration with long term preservation technologies/services | |
Easily integrate with ILS, ArchivesSpace, etc. | |
Fedora supports multitenant implementations | |
Fedora could scale horizontally (sharded repositories, managed by a load -balancing, parallel processing capable main repo) | |
Supported Fedora - Archivematica integration | |
Move to PREMIS 3 ontology | |
Keep fedora current in terms of technology (I'm happy with the current feature set of Fedora) | |
Replace the WebAC access control (partial) specification with something...better | |
default behaviors/configurations that are easy to understand and adopt (while keeping the ability to configure pretty robustly for those who can dig in). Maybe a "performant" setting, a "preservation" setting, etc. | |
Fedora would be tested/certified with a variety of cloud and on-premise underlying storage systems | |
Apache mod_fedora plugin to integrate Apache seamlessly with Fedora | |
Relevant installation information gathering to meet privacy requirements globally | |
Fedora could replace DSpace as a self-submit institutional repository system | |
Multi-lingual support | |
Fedora would be written to support/facilitate international adoption | |
Make a Fedora admin UI | |
Fedora's admin UI meets WCAG standards | |
Fedora would support "side-loading" ingest mechanism for content moved directly into underlying storage (maybe someone will tell me this is already possible!) | |
Fedora would have a robust one-click install front end UI | |
"lite" interface that is separate from the core, but built by fedora for those who don't use or can't afford samvera, islandora, or a "fat client" local development effort | |
redefine Fedora away from a piece of software, middleware | |
Fedora deployment and maintenance is possible without heavy developer expertise | |
"push button" upgrade | |
Fedora would provide easy access to usage and storage analytics/metrics via a dashboard and API | |
Fedora would not be bound to the LDP (Linked Data Platform) specification | |
focus on being even more of a black box (plug and play in any repo system) that just works. double down on api and specs | |
Fedora would include standard deployment models for common environments, e.g. AWS, Kubernetes, etc. (maybe this is already true??) | |
Ability to (within the spirit of privacy, not just the law) centralize data that informs decision making (size, version, etc) | |
Fedora would support high-latency (i.e. tape) storage, possibly through an S3 gateway, to enable large digital preservation use cases | |
Move away from java (not necc a change to the behavior, just about recruitment of skilled labor) | |
fedora would become a specification like IIIF that works with many technologies are either side talking Fedora | |
The fedora application would go away entirely and we would rely on the standards it is built on and ocfl-java | |
The fedora application would be in a programming language that is more accessible to the library community. | |
The fedora API would become a widely adopted API and standard. It would not be tied specifically to Fedora but instead be spun off as its own specification. |
Notes:
- Voting not included here, as there are duplicate "ideas"
- Will allow participants time to provide feedback on how to combine the ideas and will redistribute the votes accordinly