- Created by Chris Beer, last modified by David Wilcox on Mar 09, 2020
2019-2020 Technical Roadmap
The next major version of Fedora will focus on the following requirements: Further details can be found on the design page. Fedora 6 development is expected to take place over the course of monthly code sprints throughout 2020. The OCFL provides the following benefits: These benefits supplement the digital preservation features already provided by Fedora, including: The combined functionality of Fedora with OCFL persistence will better support an overall digital preservation strategy. Fedora 6.0.0
Why the Oxford Common File Layout?
2017-2018 Technical Roadmap
Formalize the core Fedora services Application Programming Interface (API)
This priority is to clearly define the core services that Fedora promises as a standards-based RESTful API, accompany this API with any necessary domain-specific ontologies, and provide a compatibility test suite. Outstanding issues can be found on GitHub.
Align the current Fedora implementation with the API specification
Once the API specification is complete, the current Fedora implementation will need to be updated to fully align with the specification. This work will result in a 5.x Fedora release based on our move to semantic versioning.
Support alternate Fedora implementations
One of the goals of the API specification is to allow the community to experiment with different back-end Fedora implementations to address different use cases. We will support and encourage community members as they experiment along these lines.
2016-2017 Technical Roadmap
Formalize the core Fedora services Application Programming Interface (API)
This priority is to clearly define the core services that Fedora promises as a standards-based RESTful API, accompany this API with any necessary domain-specific ontologies, and provide a Technology Compatibility Kit (TCK) for each service.tickets...
The Fedora services are:- Create/Read/Update/Delete on repository resources
- Standard: Linked Data Platform
- Include Import and Export of RDF, and option for RDF serialization to disk
- tickets...
- Versioning
- Standard (partial, only retrieval): Memento
- tickets...
- Atomic Batch Operations
- Standard: TBD
- Click here to expand...
- Fixity
- Standard (partial, on ingest): http://tools.ietf.org/html/rfc3230#section-4.3.2
- Click here to expand...
- Authorization
- Standard: WebAC
- tickets...
- Create/Read/Update/Delete on repository resources
- Formalize the core Fedora Service Provider Interfaces (SPIs)
- Messaging SPI
- Defining the interface that a Fedora repository implementation should implement to publish repository events
- Messaging SPI
- Runtime configurability
- Enable the update of configuration settings at runtime, e.g. changing hostname published in repository events
- Enable pluggability of extension modules, e.g. adding an OAI-PMH module at runtime
- Performance and Scale
- Establish metrics for repository limits, including:
- number of resources
- number of bytes
- See: Performance and Scalability Test Plans
- tickets...
- Establish guidelines for storage options based on usage patterns
- Establish metrics for repository limits, including:
Note: Items 1 and 2 define priorities related to "Fedora as a specification", whereas Items 3 and 4 relate to "Fedora as an implementation".
2015-2016 Technical Roadmap
Formalize the core Fedora services Application Programming Interface (API)
This priority is to clearly define the core services that Fedora promises as a standards-based RESTful API, accompany this API with any necessary domain-specific ontologies, and provide a Technology Compatibility Kit (TCK) for each service.tickets...
The Fedora services are:- Create/Read/Update/Delete on repository resources
- Standard: Linked Data Platform
- Include Import and Export of RDF, and option for RDF serialization to disk
- tickets...
- Versioning
- Standard (partial, only retrieval): Memento
- tickets...
- Transactions
- Standard: TBD
- Fixity
- Standard (partial, on ingest): http://tools.ietf.org/html/rfc3230#section-4.3.2
- Authorization
- Standard: WebAC
- tickets...
- Create/Read/Update/Delete on repository resources
- Formalize the core Fedora Service Provider Interfaces (SPIs)
- Eventing SPI
- Defining the interface that a Fedora repository implementation should implement to publish repository events
- Eventing SPI
- Runtime configurability
- Enable the update of configuration settings at runtime, e.g. changing hostname published in repository events
- Enable pluggability of extension modules, e.g. adding an OAI-PMH module at runtime
- Performance and Scale
- Establish metrics for repository limits, including:
- number of resources
- number of bytes
- See: Performance and Scalability Test Plans
- tickets...
- Establish guidelines for storage options based on usage patterns
- Establish metrics for repository limits, including:
Note: Items 1 and 2 define priorities related to "Fedora as a specification", whereas Items 3 and 4 relate to "Fedora as a reference implementation".
Previous Technical Roadmap Items
Currently Supported Features | Design | Core | Non-core | 4.0 | Use Cases |
---|---|---|---|---|---|
AuthN/Z | design | x | Authorization Use Cases | ||
Backup | design | x | Backup Use Cases | ||
Clustering | x |
| |||
Content Modeling - Structural | x | Content Modeling Use Cases
Content by label
There is no content with the specified labels
| |||
Managed External Datastreams | x | External Storage Use Cases | |||
Store/Deliver Large Files | design | x | Large Files Use Cases | ||
design | x | Search Use Cases | |||
Transactions | x | Transactions Use Cases | |||
Triplestore | design | x | Triplestore Use Cases | ||
Versioning | x | ||||
Non-Functional: Easy Deployment | |||||
Non-Functional: Performance - Single-node | Performance Use Cases | ||||
Post-4.0 Priority 1 Features | Design | Core | Non-core | 4.0 | Use Cases |
3 to 4 Upgrade | design | x | F3 to F4 Upgrade Use Cases
Content by label
There is no content with the specified labels
| ||
Audit Service | design | x | Audit Service Use Cases | ||
Managed External Datastreams - Indexing | x | ||||
Asynchronous storage API | design | x | Async Storage Use Cases | ||
Asynchronous storage Implementation | x | Asynchronous Storage Use Cases | |||
LDP-Paging | x | ||||
Web Access Control | x | ||||
API Partitioning | x | ||||
Post-4.0 Priority 2 Features | Design | Core | Non-core | 4.0 | |
Batch Operations | x | Batch Use Cases | |||
CMIS | x | ||||
Content Modeling - Services and Validation | Content Modeling (extended) Use Cases | ||||
Disseminator-like Functionality | x | ||||
Human-readable Filesystem Storage | x | ||||
Metrics | x | Audit Use Cases | |||
Multi-tenancy | x | Multi-tenancy Use Cases | |||
OAI-PMH | design | x | |||
ORCID Support | x | ||||
Policy-driven Storage | design | x | Policy-Driven Storage Use Cases | ||
Relationships API | x | ||||
Self-healing Storage | x | ||||
WebDAV | x | ||||
Non-Functional: Performance - Clustered | Clustering Performance Use Cases | ||||
Previously Un-prioritized Features | Design | Core | Non-core | 4.0 | Use Cases |
Admin UI | x | Admin UI Use Cases | |||
Content API | x | Content API Use Cases | |||
Identifiers | x | Identifier Use Cases | |||
Large-Scale Content | x | Large-Scale Content Use Cases |
- No labels
3 Comments
Tom Cramer
Questions:
Tom Cramer
for Beta P1 vs P2, do the items in P1 directly support early adopters?
Andrew Woods
It is a good question. I suspect there are several flavors of "early adopters" to choose from. If we want the "have a copy in Glacier" group, then that will sway the features one direction. If we want the "bare bones, existing use case" that will sway them another. etc.
Maybe we should discuss and determine the highest value target adopters for the initial feature set.