...

• stateless Fedora instance(s) will scale horizontally
• database can be clustered and/or moved to cloud  database service(RDS, Aurora, etc)
• start with file system, scale out to  cloud object store (s3)

Bulk ingest

To flavors of pointing a Fedora instance at an OCFL backend.

1. via OCFL
2. via Fedora OCFL 
   1. ie "content/.fcrepo" aware

...

1. Faster ingest rates can be achieved by users writing OCFL-compliant content directly to disk
   1. Would require Fedora to (re)scan OCFL storage hierarchy
2. Optionally, user could write into OCFL-compliant storage in a way that includes Fedora optimizations (e.g. ".fcrepo/" directory)

Performance

1. Many members: performance should improve significantly since list of members will be supplied by a database index (which should support a degree of in-memory caching).  No loading of modeshape nodes required.

...

1. Same code logic used for creation of OCFL versions / Mementos in both on-demand and on-change models

Import / Export   (Migration)

• https://docs.google.com/document/d/1nvUDar1DbexdU3oTRGxzcZGG3qxsD2HWQbGyyRJIgDE/edit#

...

Migration from lower versions of Fedora to higher

1. Design
   1. Release import/export tool for each version of Fedora (4, 5, 6)
      1. Import/Export tool for a given release is able to round-trip content for that release
   2. If necessary, transform exported serialization produced from one Fedora version to the a serialization that is expected for the import Fedora version

      1. May be able to transform F3? 4, 5 directly to F6-OCFL on-disk serialization

2. Fedora resource URLs must remain unchanged during migrations
3. Persistence model of Fedora 6 should be stable enough to eliminate the need for a content migration to Fedora 7

Fixity service

1. Requirements:
   1. Check fixity of binary resource(s) by comparing computed value with stored value
   2. Check fixity of binary resource(s) given a specific set of Fedora object rdf:types
   3. Persist results of fixity check
      1. In log file?
      2. In database?
      3. In Fedora?
2. Scheduled fixity service:
   1. Probably not part of the core

...

1. 2. Run as a separate service

...

1. 1. (see: Riprap)
   2. Schedule based on circular queue of Fedora resources, ordered by "last fixity check" date property on Fedora resource
2. Retain "fedora:hasFixityService" triple or header
3. At the OCFL-level, interest in providing fixity over an OCFL storage hierarchy

Query service

1. Proposal: Query service /

Query endpoint

...

1. endpoint should support the following

...

1. queries:
   1. List all resources
   2. List resources by mimetype
   3. List resources by parent
   4. List resources by mimetype, parent, and modified date (<>=)
   5. List resources where modified  <> x date

...

2. Open questions around scope of resources to be searchable
   1. Fedora resources?
   2. Resources defined in RDF documents within the repository?
   3. Hash URIs?
3. Open questions around properties to support
   1. Server-managed triples?
   2. All properties?
4. Triplestore not necessarily required

Implementation notes

1. Index of all Fedora resources would be needed to support the query service
2. Messaging model (synchronous or asynchronous) would likely be used to populate the index
3. Full-text search would be a bonus

Transaction service

• No definitive decisions made.
• Proposal: no change to the Fedora API spec in 6.  We will either:
  • align code with the (as-yet-to-be-ratified) side-car specification
  • leave HTTP API unchanged while introducing the possibility of auto-versioning on transaction completion.

Raw notes

1. General VA Beach Meeting notes
2. Migration notes
3. Object modeling notes
4. Versioning notes
5. Fixity notes
6. Bulk ingest notes
7. Query service notes