Page History

...

Day 2

Summary and Outcomes

• Use usage of Fedora by UMD, NLM, and JHU were significantly different from one another
  • NLM:  Fedora feeds mostly static content to Solr via transformation (gsearch).  Solr powers user-facing Blacklight
  • UMD:  Repository-centric architecture relying heavily on async messaging.  UIs provided by HippoCMS, and potentially a Samvera head to suit different use cases.
  • JHU: Single-page app in browser makes request directly to Fedora (protected by Shibboleth, ACLs), and elasticsearch.  Fedora supports interactive workflows and async services, is not used as a preservation repository
• While use cases were diverse, users group members are interested in tackling infrastructure challenges together; recognized the community of practice around Fedora as valuable.
• There was disagreement about the utility of LDP.  Perspectives ranged from "essential to the way the application works" to "we have not moved to Fedora 4 in part due to LDP-centricity"
  • See also Stanford evaluation of Fedora, which cites the LDP API as a reason to discount Fedora as an option for their repository.
• The prospect of an OCFL-based Fedora was compelling to all attendees, but for different reasons
  • Use cases around using OCFL to organize content on disk via a separate process, have Fedora able to expose it in a way suitable for SOLR indexing
  • Attracted to transparency of filesystem content
  • See an advantage of OCFL as far as a plausible path to migration, where migration tools produce content in OCFL that Fedora can then index and serve
    • Compelling Fedora 3 → Fedora OCFL migration path
    • Migration has been a kind of second-class citizen in fedora 3→4, 4→5 OCFL offers more/simpler(?) potential migration paths, which lends credibility to the notion of a successful migration 
• Hackathon activities focused around taking objects modeled in each institution's repository, and attempting to model in OCFL.
  • Two areas of mapping Fedora resources to OCFL were explored
    • 1:1 mapping, where each Fedora resource corresponds to an OCFL object
      • Worked for JHU, UMD cases.  Probably not acceptable for NLM
      • Most difficult to navigate just by looking at objects in OCFL.  Physical model is flat, software would need to build a logical model based on contents of the OCFL objects
        • Fedora could store the RDF it needs to maintain an ldp hierarchy in a special area of the OCFL objects, maybe a .fcrepo directory, or something like it
        • In the case of UMD, they do not use containment to build a logical model, but instead use PCDM.  The notion of segregating Fedora's server-managed triples from user-managed triples as separate files in OCFL was seen as a good approach
    • "tree" mapping", where multiple Fedora resources are encapsulated in an OCFL object
      • 1:1 mapping, which worked in JHU and UMD use cases,  is a special case of this,
      • Tree mapping most strongly aligns with NLM, and probably many Fedora 3 users
      • Would want Fedora to "by default" provide a basic mapping of files and directories in an OCFL object to resources exposed by the API.  i.e. absent any fedora-specific metadata or triples, the object can still be exposed in a useful way by Fedora API
        • This would work well for NLM's use case of populating an OCFL directory as a method of ingest, or as the result of a content migration
      • Mapping of an OCFL object to an LDP container, where LDP children are artifacts in an OCFL object seems doable, but API might need amending.  e.g. add an "OCFL object" interaction model to a container
      • Problem for Fedora's API comes in managing a sequence of updates to such an object.  Almost need transactions to encapsulate a series of changes as a single version
      • Since ocfl objects are whole-object versioned, mementos for individual resources would be straightforward, all resources in a version would be in lock-step with one another