Page tree
Skip to end of metadata
Go to start of metadata

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

 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
    Loading...
    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
        Loading...
        Refresh

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

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

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

        Key Summary T Created Updated Due Assignee Reporter P Status Resolution
        Loading...
        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
        Loading...
        Refresh

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

        T Key Summary Assignee Reporter P Status Resolution Created Updated Due
        Loading...
        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
        Loading...
        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
    Loading...
    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
        Loading...
        Refresh

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

        T Key Summary Assignee Reporter P Status Resolution Created Updated Due
        Loading...
        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
        Loading...
        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
        Loading...
        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

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

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. 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. for Beta P1 vs P2, do the items in P1 directly support early adopters?

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