Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Current »

\uD83D\uDDD3 Date

12:00 PM EDT

\uD83D\uDC65 Participants

Regrets

\uD83E\uDD45 Goals

\uD83D\uDDE3 Discussion topics

Time

Item

Facilitator

10 minutes

Introductions

All

25 minutes

Review the Goals of the Charter:

  • Identify and complete any pre-work to determine the scope of development.

  • Determine what infrastructure is needed to engage in the scoped development.

  • Determine the scope of development.

  • Create a high-level outline for the development work.


25 minutes

Review the Deliverables of the Charter:

  • Pre-work outcomes document.

  • An infrastructure proposal.

  • A scoping document.

  • An outline of the development effort.

Notes

  • Hyrax 5.0 is being worked on, it should be good enough to stand up a new clean application. There hasn’t been any work yet for migration work. The plan is to release this by Samvera Connect.

  • Valkyrie PostGRES Metadata adapter and then it's a matter of setting whatever backend you want.

  • Question: What paradigm is being used for metadata preservation? Not clear right now but perhaps that is a question and a discussion for this group.

  • Emory has been doing some work with ActiveFedora to connect Hyrax and Fedora 6.

  • Hyrax 5 will have both Valkyrie and ActiveFedora

    • There is some work for shared testing infrastructure between ActiveFedora and Fedora 6 so that we can do some comparison testing between ActiveFedora and Valkyrie.

  • Identify and complete any pre-work to determine the scope of development.

    • There is probably some discussions around metadata and object models and what we want to persist in Fedora.

    • What are the actual use cases for Fedora 6 with Hyrax that we want to address?

    • We also need to think through greenfield v. migration.

    • Is it worthwhile to come up with our use cases for Fedora 6 and compare them? Perhaps we can come up with a sensible default way of doing implementing Hyrax and Fedora 6 and also communicate what these sensible defaults do for performance.

      • We should also run our use cases past the community that isn’t present.

      • We can then give them a proposal and ask them to react to it.

    • Test use cases and objects might help us with creating that infrastructure needed to engage in development.

    • One goal might be to not have such a fragile relationship with solr and activefedora (i.e., let’s not make the mistakes of the past). Objects should be independent once persisted in Fedora.

  • Convening the group:

    • Arran can handle the scheduling and creating agendas for the group

  • Use cases next step

    • Find common use cases within the group and then share those with the broader community.

    • Questions that we might want to answer

      • What are you trying to persist in Fedora?

      • How do we want Hyrax to be interacting with Fedora? Is Fedora 6 the only place you’re storing things?

      • What is the size of the architecture that you’re hosting Hyrax in?

      • Are you going to be running your fedora component alone or with another component (i.e. solr for indexing)?

✅ Action items

  • Emory, IU, UNC, Bodleian: Gather use cases for the institutions in the room for Fedora and Hyrax.
  • Arran Griffith to share the use cases with the institutions not here that would be impacted.
  • Heather Greer Klein to let the group know if there will be time for working group meetings at Samvera Connect
  • Arran Griffith to schedule a meeting for two weeks from now (the week of October 9th)

⤴ Decisions

  • No labels