- 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.type key summary assignee reporter priority status resolution created updated due Unable to locate Jira server for this macro. It may be due to Application Link configuration.
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
type key summary assignee reporter priority status resolution created updated due Unable to locate Jira server for this macro. It may be due to Application Link configuration.
- Versioning
- Standard (partial, only retrieval): Memento
type key summary assignee reporter priority status resolution created updated due Unable to locate Jira server for this macro. It may be due to Application Link configuration.
- Atomic Batch Operations
- Standard: TBD
key summary type created updated due assignee reporter priority status resolution Unable to locate Jira server for this macro. It may be due to Application Link configuration.
- Fixity
- Standard (partial, on ingest): http://tools.ietf.org/html/rfc3230#section-4.3.2
key summary type created updated due assignee reporter priority status resolution Unable to locate Jira server for this macro. It may be due to Application Link configuration.
- Authorization
- Standard: WebAC
type key summary assignee reporter priority status resolution created updated due Unable to locate Jira server for this macro. It may be due to Application Link configuration.
- 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
type key summary assignee reporter priority status resolution created updated due Unable to locate Jira server for this macro. It may be due to Application Link configuration.
- 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.type key summary assignee reporter priority status resolution created updated due Unable to locate Jira server for this macro. It may be due to Application Link configuration.
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
type key summary assignee reporter priority status resolution created updated due Unable to locate Jira server for this macro. It may be due to Application Link configuration.
- Versioning
- Standard (partial, only retrieval): Memento
type key summary assignee reporter priority status resolution created updated due Unable to locate Jira server for this macro. It may be due to Application Link configuration.
- Transactions
- Standard: TBD
- Fixity
- Standard (partial, on ingest): http://tools.ietf.org/html/rfc3230#section-4.3.2
- Authorization
- Standard: WebAC
type key summary assignee reporter priority status resolution created updated due Unable to locate Jira server for this macro. It may be due to Application Link configuration.
- 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
type key summary assignee reporter priority status resolution created updated due Unable to locate Jira server for this macro. It may be due to Application Link configuration.
- 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 | |||
Backup | design | x | |||
Clustering | x |
| |||
Content Modeling - Structural | x |
Content by label
There is no content with the specified labels | |||
Managed External Datastreams | x | ||||
Store/Deliver Large Files | design | x | |||
design | x | ||||
Transactions | x | ||||
Triplestore | design | x | |||
Versioning | x | ||||
Non-Functional: Easy Deployment | |||||
Non-Functional: Performance - Single-node | |||||
Post-4.0 Priority 1 Features | Design | Core | Non-core | 4.0 | Use Cases |
3 to 4 Upgrade | design | x |
Content by label
There is no content with the specified labels | ||
Audit Service | design | x | |||
Managed External Datastreams - Indexing | x | ||||
Asynchronous storage API | design | x | |||
Asynchronous storage Implementation | x | ||||
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 | ||||
CMIS | x | ||||
Content Modeling - Services and Validation | |||||
Disseminator-like Functionality | x | ||||
Human-readable Filesystem Storage | x | ||||
Metrics | x | ||||
Multi-tenancy | x | ||||
OAI-PMH | design | x | |||
ORCID Support | x | ||||
Policy-driven Storage | design | x |
| ||
Relationships API | x | ||||
Self-healing Storage | x | ||||
WebDAV | x | ||||
Non-Functional: Performance - Clustered | |||||
Previously Un-prioritized Features | Design | Core | Non-core | 4.0 | Use Cases |
Admin UI | x | ||||
Content API | x | ||||
Identifiers | x | ||||
Large-Scale Content | x |
- 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.