Committers Call 2014-07-28

Owned by Bill Branan
Jun 16, 2017
3 min read

Moderator: Rick Johnson (ND)

Notetaker:  Thomas Scherz (UC)

Attendees: 

Michael Klein (Northwestern)

Linda Newman (UC)

James Van Mil (UC)

Glen Horton (UC)

Esme Coles (SDSU)

Sue Richeson (UVA)

Rick Johnson (ND)

Adam Wead (PSU)

David Chandek-Stark (Duke)

Jim Coble (Duke)

Lakeshia Robinson (Yale)

Chris Colvard (Indiana)

Justin Coyne (DCE)

Jeremy Friesen (ND)

Dan Brubaker-Horst (ND)

Mike Giarlo (PSU)

Agenda: 

Hydramata::Works (http://ndlib.github.io/hydramata-works/)

  1. Design and Development Goals - http://ndlib.github.io/hydramata-works/demos/design-and-development-goals/

  2. Work Type and Predicate Definition - http://ndlib.github.io/hydramata-works/demos/work-type-and-predicate-definition/

  3. View Lookup for Work Type, Predicate Set, and Predicate - http://ndlib.github.io/hydramata-works/demos/view-lookup-for-work-type-predicate-set-and-predicate/
  4. Translation Services for All the Things - http://ndlib.github.io/hydramata-works/demos/translation-services-for-all-the-things/
  5. Interacting with Fedora - http://ndlib.github.io/hydramata-works/demos/interacting-with-fedora/
  6. Explaining the Suggested Structure http://ndlib.github.io/hydramata-works/demos/explaining-the-suggested-structure/

Dan:  Why are we working on Hydramata?  What are the goals?

Notre Dame has encountered problems/challenges over the course of the year:

    1. Our applications are normally in production for 3 to 10 years.  Maintenance is difficult with bleeding edge changes in Hydra components and rails components.
    2. Separating the data and presentation concerns in our applications. Let Fedora describe how the objects actually are and then let hydra present.  
    3. ActiveFedora Problems:  ActiveFedora Models are too tight.  Making the upgrade process challenging.
    4. Improving sharing across upper level features and functionality.  Hard to use external services.

Justin:  CModels:  Multiple inheritance or single table inheritance in Rails.  Good and Bad.  

      1. Justin:  Every library is a special snowflake.  Every work is a special snowflake.  There is no canonical definition for these things.  The decision makers don't have a common understanding.
      2. Jeremy: Code that we are using is the canonical representation of the data, but actually it is persisted in Fedora.

Jeremy:  What do we do about the inter-relational nature of the gems?  Pain-points and challenges.

      1. Justin:  Dependency Management is a common problem in CS.  
      2. Jeremy:  Design and Development Goals - http://ndlib.github.io/hydramata-works/demos/design-and-development-goals/
      3. Adam:  Are the issues related to ActiveFedora or Fedora?  Jeremy:  ActiveFedora

Dan:  The problem space we are working in and the design proposals for dealing with said problems is important.

Dan:  There needs to be a common awareness among developers in the hydra community.

    1. David:  Useful to share?  Sharing works best for specific functions.  Generalizing gems requires time.
    2. Jeremy:  If we are going to try sharing, configuration is a mandatory thing.

Justin:  Metadata templates;  How does this get changed?  
  1. Composition of works happens at the database. You define a work type,  you define a predicate and the parsers necessary. Translation layer is then in play.
  2. Jeremy:  Review the spec/features directory to have an understanding or the lib/hydramata/works/linters
  3. David:  How to move away from custom class coding and moving towards a databased backed means of declaring structure as a core ideal.  
  4. Jeremy:  Predicate lifting will still be required.
  5. Esme:  Basic contracts that can be fetched gives you the ability to deal with literals or any kind of object.  
  6. Also, a type system that can give you a list of available behaviors to be used.

Rick:  It was important to communicate to the committers about these pain points and solutions being developed to deal with these pain points  Ideally we want to have something more concrete to work with at HydraConnect.

Justin:  Another pain point is determining when to call from index or when to call from repository?

Esme:  More explicit.  

David:  Duplication going on.

Jeremy:  Is SOLR only our searching index or is there more information in there?

Adam:  Spotlight uses SOLR persisted in SOLR but not in Fedora.

Jeremy:  Provide a service that will check the index, the class, and then finally the database.

Justin:  Breaking down into components makes for a complex class tree.  

Jeremy:  ActiveFedora cleaves very close to ActiveRecord.  Perhaps there is another way to expose useful pieces and here is how you would re-use it as a plain old ruby object.

Justin:  Simple inheritance has worked well and questions whether a new approach will work better.

Adam:  Is there a concrete implementation of what we are trying to achieve?

Jeremy:  Rack Middleware.  Is a good example of modeling request / response cycle.  Plug-in architecture.  I.E.  NAUGHT gem.  Lotus/Model:  Repository patterns.

 

Next Call:

  1. 2014-08-04
  2. Moderator:   Adam Wead (PSU)
  3. Notetaker:   Jeremy Friesen (ND)