...
ITAV Activity: https://wiki.lyrasis.org/display/ITAV/ITAViP+Toolkit%3A+Technology?preview=/225150170/225150507/ITAViP_Tech_P3_ListOfDreams.docx
To Do:
- Re-word, and formalize the #1 objective (10 mins)
- Take top 3 ideas and research what it skills it would actually take to accomplish it (30 mins)
- Group 1: Scott, Jon, Jennifer (List of Dreams - Group 1)
- Group 2: Jared, Thomas, Rosy (https://docs.google.com/document/d/1o6caqQm2N0EvUoTDffnSfFUshqSb4___z8nIXdSUmjg/edit?usp=sharing)
- Group 3: Kate, Tim, Robin (https://docs.google.com/document/d/1AxjcWlO3p-SJvV3W3FSqDUEK98AYioWdBZ8y6AvrKn4/edit?usp=sharing)
- Take inventory of what skills are lacking to accomplish these things (15 mins)
- How can we recruit these skills into the community?
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 | ||||
Idea | Vote | |||
| 8 | |||
| 6 | |||
| 4 | |||
Fedora could scale horizontally (sharded repositories, managed by a load -balancing, parallel processing capable main repo) | 4 | |||
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 | 4 | |||
Fedora would support high-latency (i.e. tape) storage, possibly through an S3 gateway, to enable large digital preservation use cases | 4 | |||
Fedora would be written to support/facilitate international adoption Multi-lingual support | 3 | |||
Fedora would support "side-loading" ingest mechanism for content moved directly into underlying storage (maybe someone will tell me this is already possible!) | 3 | |||
Make a Fedora admin UI; Fedora would provide easy access to usage and storage analytics/metrics via a dashboard and API | 3 | |||
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 | Fedora would include standard deployment models for common environments, e.g. AWS, Kubernetes, etc. (maybe this is already true??) | 3 | ||
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.2 | ||||
Fedora would be tested/certified with a variety of cloud and on-premise underlying storage systems | ||||
2Apache mod_fedora plugin to integrate Apache seamlessly with Fedora | ||||
Relevant installation information gathering to meet privacy requirements globally | 2 | The fedora application would be in a programming language that is more accessible to the library community. | 2Fedora standards implementation remains flexible to local implementations - can opt in to LDP, or out, for example. | |
Fedora would not be bound to the LDP (Linked Data Platform) specification | 1 | |||
Move to PREMIS 3 ontology | 1 | |||
Keep fedora current in terms of technology (I'm happy with the current feature set of Fedora) | 1 | |||
Fedora supports multitenant implementations | 0 | |||
Fedora could replace DSpace as a self-submit institutional repository system | 0 | pre-built expression for indexing/harvesting (e.g. google) | ||
Multi-lingual support | ||||
Fedora would be written to support/facilitate international adoption | ||||
Make a Fedora admin UI0 | ||||
Fedora's admin UI meets WCAG standards0 | ||||
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 | 0 | |||
Replace the WebAC access control (partial) specification with something...better | 0 | |||
Fedora embraces ethical source principles | 0 | |||
Apache mod_fedora plugin to integrate Apache seamlessly with Fedora | 0 | |||
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) | 0 |
Notes:
"Dream #1" - Overarching theme: Fedora as an API
- Idea of Fedora application “going away” - is it just that LYRASIS/Fedora program would no longer continue to exist but it would still be available within the community?
- Overhead would decrease considerably by dropping the application and devoting ourselves only to the API
- Would we just then be working ourselves out of existence
- What does Fedora offer that is compelling, that distinguishes itself from similar efforts met by other applications, standards? (OCFL, Islandora, Samvera)
- Things we need to think about - what is Fedora’s purpose or value in this new ever changing environment
- Where do we fit?
- With OCFL we know that there are institutions implementing OCFL without Fedora, so what value can Fedora offer
- Is there clear enough messaging around why you need Fedora running and what is the value of having it in the stack?
Consider Top reasons to use Fedora:
- Preservation value
- API enables you to bundle metadata and bitsreams together in to objects
- Flexibility & Data modelling
- Migration to pure OCFL seems overwhelming
- Access controls, indexing, camel toolbox and add ons that make workflow easier - may not get this from an API or persistence layer
- Managing complexity at scale
- Historical tie to the program/software - outlasted a lot of other products - “Permanence”
- If I migrate to something else, will I have to then migrate again to something new?
- Community and resources, while small, is enough to warrant staying with the program instead of trying to roll your own
- Most installations that we know of running Fedora or Fedora 3 are smaller institutions who aren't interested in API solely or don’t have the resources to run it as only as an API
- Should start considering how community can be more involved in the development cycles of partner communities like Islandora/Samvera
...
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
...
- S3 performance is below on-disc performance
- Could be related to the way files have to move in OCFL causing delays (at current state, looks like this may be the only answer)
- Need to look for someone with more experience developing with the S3 client
- Put call out to the community to try and gather user stories or user need to deal with this
- Special topic Tech Meeting
...