Fedora Repository
Space shortcuts
Page tree
Skip to end of metadata
Go to start of metadata

2019 Technical Roadmap

Fedora 6.0.0

The next major version of Fedora will focus on the following requirements:

  1. Replace the ModeShape persistence layer with a different technology that implements the Oxford Common File Layout
  2. Add a synchronous query service
  3. Improve the fixity service
  4. Address known performance and scale issues
  5. Support migrations from earlier versions of Fedora (3.x, 4.x, and 5.x)

Further details can be found on the design page. 

Fedora 6 development is expected to take place over the course of four code sprints between Fall 2019 and Summer 2020. 

Why the Oxford Common File Layout?

The OCFL provides the following benefits:

  1. Parsability, both by humans and machines, to ensure content can be understood in the absence of original software
  2. Robustness against errors, corruption, and migration between storage technologies
  3. Versioning, so repositories can make changes to objects allowing its history to persist
  4. Storage diversity, to ensure content can be stored on diverse storage infrastructures including cloud object stores
  5. Completeness, so that a repository can be rebuilt from the files it stores

These benefits supplement the digital preservation features already provided by Fedora, including:

  1. Fixity: Checksums can be calculated, stored and compared on demand
  2. Versioning: Objects and files can be versioned and restored on demand
  3. Import/Export: Objects and files can be exported on demand to facilitate their use in other elements of a digital preservation workflow
  4. Audit: Preservation metadata can be generated by repository events and indexed in a triplestore for querying

The combined functionality of Fedora with OCFL persistence will better support an overall digital preservation strategy.

2017-2018 Technical Roadmap

 Click here to expand...

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

 Click here to expand...

  1. 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...

    T Key Summary Assignee Reporter P Status Resolution Created Updated Due
    Refresh


    The Fedora services are:

    1. Create/Read/Update/Delete on repository resources
      1. Standard: Linked Data Platform
      2. Include Import and Export of RDF, and option for RDF serialization to disk
      3.  tickets...

        T Key Summary Assignee Reporter P Status Resolution Created Updated Due
        Refresh

    2. Versioning
      1. Standard (partial, only retrieval): Memento
      2.  tickets...

        T Key Summary Assignee Reporter P Status Resolution Created Updated Due
        Refresh

    3. Atomic Batch Operations
      1. Standard: TBD
      2.  Click here to expand...

        Key Summary T Created Updated Due Assignee Reporter P Status Resolution
        Refresh

    4. Fixity
      1. Standard (partial, on ingest): http://tools.ietf.org/html/rfc3230#section-4.3.2
      2.  Click here to expand...

        Key Summary T Created Updated Due Assignee Reporter P Status Resolution
        Refresh

    5. Authorization
      1. Standard: WebAC
      2.  tickets...

        T Key Summary Assignee Reporter P Status Resolution Created Updated Due
        Refresh

  2. Formalize the core Fedora Service Provider Interfaces (SPIs)
    1. Messaging SPI
      1. Defining the interface that a Fedora repository implementation should implement to publish repository events
  3. Runtime configurability
    1. Enable the update of configuration settings at runtime, e.g. changing hostname published in repository events
    2. Enable pluggability of extension modules, e.g. adding an OAI-PMH module at runtime
  4. Performance and Scale
    1. Establish metrics for repository limits, including:
      1. number of resources
      2. number of bytes
      3. See: Performance and Scalability Test Plans
      4.  tickets...

        T Key Summary Assignee Reporter P Status Resolution Created Updated Due
        Refresh

    2. Establish guidelines for storage options based on usage patterns

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

 Click here to expand...

  1. 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...

    T Key Summary Assignee Reporter P Status Resolution Created Updated Due
    Refresh


    The Fedora services are:

    1. Create/Read/Update/Delete on repository resources
      1. Standard: Linked Data Platform
      2. Include Import and Export of RDF, and option for RDF serialization to disk
      3.  tickets...

        T Key Summary Assignee Reporter P Status Resolution Created Updated Due
        Refresh

    2. Versioning
      1. Standard (partial, only retrieval): Memento
      2.  tickets...

        T Key Summary Assignee Reporter P Status Resolution Created Updated Due
        Refresh

    3. Transactions
      1. Standard: TBD
    4. Fixity
      1. Standard (partial, on ingest): http://tools.ietf.org/html/rfc3230#section-4.3.2
    5. Authorization
      1. Standard: WebAC
      2.  tickets...

        T Key Summary Assignee Reporter P Status Resolution Created Updated Due
        Refresh

  2. Formalize the core Fedora Service Provider Interfaces (SPIs)
    1. Eventing SPI
      1. Defining the interface that a Fedora repository implementation should implement to publish repository events
  3. Runtime configurability
    1. Enable the update of configuration settings at runtime, e.g. changing hostname published in repository events
    2. Enable pluggability of extension modules, e.g. adding an OAI-PMH module at runtime
  4. Performance and Scale
    1. Establish metrics for repository limits, including:
      1. number of resources
      2. number of bytes
      3. See: Performance and Scalability Test Plans
      4.  tickets...

        T Key Summary Assignee Reporter P Status Resolution Created Updated Due
        Refresh

    2. Establish guidelines for storage options based on usage patterns

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

 Click here to expand...
Currently Supported FeaturesDesignCoreNon-core4.0Use Cases
AuthN/Zdesign
x(tick)
Backupdesignx
(tick)
 Backup Use Cases

Clustering
x
(warning)
  • Consistent deployment
  • REST-API support against master node
Content Modeling - Structural
x
(warning)
 Content Modeling Use Cases

Content by label

There is no content with the specified labels

Managed External Datastreams

x(tick)
 External Storage Use Cases

Store/Deliver Large Filesdesignx
(tick)
 Large Files Use Cases

Search

design
x(tick)
Transactions
x
(tick)
Triplestoredesign
x(tick)
Versioning
x
(tick)
Non-Functional: Easy Deployment


(tick)
Non-Functional: Performance -
Single-node 


(warning)






Post-4.0 Priority 1 FeaturesDesignCoreNon-core4.0Use Cases
3 to 4 Upgradedesign
x
 F3 to F4 Upgrade Use Cases

Content by label

There is no content with the specified labels

Audit Servicedesignx

Managed External Datastreams - Indexing

x

Asynchronous storage APIdesignx

Asynchronous storage Implementation
x

LDP-Paging
x


Web Access Control

x

API Partitioning
x








Post-4.0 Priority 2 FeaturesDesignCoreNon-core4.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

 Multi-tenancy Use Cases

OAI-PMHdesign
x

ORCID Support

x

Policy-driven Storagedesignx

 Policy-Driven Storage Use Cases

Relationships API
x


Self-healing Storage

x

WebDAV

x

Non-Functional: Performance - Clustered









Previously Un-prioritized FeaturesDesignCoreNon-core4.0Use Cases

Admin UI



x(tick)
Content API
x
(tick)
Identifiers
x
(tick)
Large-Scale Content
x
(warning)
 Large-Scale Content Use Cases
  • No labels

3 Comments

  1. Tom Cramer

    Questions:

    1. which set of these requirements / functions fulfill Fedora's traditional emphasis on digital preservation? We need a cohesive set of functions bundled together to tell this story to the library community in particular. 
    2. it seems to me that an admin UI is an important tool (non-core, important for Beta users), and not listed. 
    3. do we know what/where/how migration assistance tools should factor in to this list, if at all?
    4. where are non-functional requirements; ease of deployment, performance, scalability, test coverage, docs?

     

     

  2. Tom Cramer

    for Beta P1 vs P2, do the items in P1 directly support early adopters?

    1. 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.

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.