/
Hydra Tech Call 2017-01-18

Samvera Community Wiki

Hydra Tech Call 2017-01-18

Jun 16, 2017

Time: 9:00am PDT / Noon EDT

Call-In Info: 1-641-715-3660, access code 651025

Moderator:  @Thomas Scherz

Notetaker: @James Griffin

Attendees:

  • @Glen Horton (Deactivated)

  • @Thomas Scherz

  • @Lynette Rayle (Cornell)

  • @Collin Brittle (Virginia Tech)

  • @James Griffin (Lafayette College Libraries)

  • @Andrew Myers (wgbh)

  • @Esmé Cowles (Princeton)

  • @justin (Stanford)

  • @Anna Headley (CHF)

  • @Steve Van Tuyl (Oregon State University)

  • @Steven Ng (Temple University)

  • @tamsin johnson (DCE)

  • @Former user (Deleted) (U of Alberta)

  • @Adam Wead (Penn State University)

  • @cam156 (Penn State University)

  • @Michael Joseph Giarlo (Stanford University)

  • @Trey Pendragon (Princeton University)

  • @scossu (Art Institute of Chicago)

  • @Benjamin Armintor (Columbia University)

 

Agenda

  1. Roll call by timezone per following order - ensure notetaker is present

    1. folks outside North and South America

    2. Eastern timezone

    3. Central timezone

    4. Mountain timezone

    5. Pacific timezone

    6. folks who were missed or who dialed in during roll call

  2. CanCan and curation concerns ( @Joe Atzberger)

  3.  Discuss AIC API work ( @Adam Wead, @scossu)

  4. (STANDING) Update on  Sufia/CurationConcerns Consolidation Plan ( @Michael Joseph Giarlo or  @justin)

    1. Hyrax branching and the Sufia upgrade path ( @Michael Joseph Giarlo)

  5. (STANDING) Sufia 7.3 Blockers - University of Cincinnati local sprint.   @Thomas Scherz 

  6. Question from Hydra Plugins WG ( @Andrew Myers)

    1. plugins are trying to alter flow around characterization and derivative generation

    2. is actor stack the right integration point?

    3. does sipity work flow engine come into play here?

  7. Moderator/notetaker for next time:

    1. Moderator: TBA

    2. Notetaker: TBA

 

Notes

CanCan and CurationConcerns

  • Joe Atzberger did not attend the call

 

AIC API Work

  • Wead:

    • As Cossu was not originally on the call, was uncertain as to what to state

  • Giarlo:

    • Suggested that Wead and Cossu place this on the agenda

    • AIC developed an API which plugs into the Sufia base for their repository

    • Has heard demands for HTTP API's from other members of the Project Hydra community for shared Gems

    • Invites interested community members to review and inspect this work

  • (Cossu joins the call)

  • Cossu:

    • Clarifies that there are no plans to gemify the solution developed by AIC

    • This was built around a customized system

    • The scope remains narrow due to time constraints

    • Would be eager to see a collaborative effort arise which leads to gemification

  • Wead:

    • Proposes a HAPI Gem for projecthydra-labs

    • Would this help any community members interested in a OAI-PMH harvester?

  • Binkley:

    • Currently the OAI-PMH harvester is often found within a separate app.

  • Giarlo:

    • Clarifies that CRUD operations are supported for the creation of assets and derivatives, as well as the updating of assets

    • May wouldn't be one-to-one for OAI-PMH functional requirements

  • Pendragon:

    • Enquires as to what this is used for at AIC

  • Cossu:

    • Other systems which don't depend upon Fedora 4 for storage can leverage CurationConcerns

    • Further, provides custom derivative generation (provided by users or an external system)

  • Pendragon:

    • How is this API different from transmitting HTTP requests to CurationConcerns endpoints?

  • Cossu:

    • The multiple step process of file ingestion in Sufia required such development

  • Wead:

    • Essentially this work wraps the Actor around an API call

    • A POST request with a payload of some metadata and files is received, the validity is checked, and it is passed on to the Actor

Sufia/CurationConcerns Consolidation Plan

  • Giarlo:

    • Looking to cut a release of Hyrax release soon (0.1.0)

    • This would create a new 0.1 stable branch

    • 0.1.x work would be the migration target for parties coming in from Sufia and CurationConcerns

    • As there is still more feature work in Hyrax for Hydra-in-a-Box, this approach doesn't block this from being merged to the master branch

  • Myers:

    • Any concern about trying to having a 0.x release as  migration target? Wouldn't this be subject to change?

  • Giarlo:

    • Doesn't see many changes coming to 0.1.x branch

    • It should only have fixes (no minor or major updates) 

Sufia 7.3 Blockers

Scherz:

  • Dev. environments have been established and University of Cincinnati (Scherz and Horton) are starting to grab available issues

  • They will focus on those solved by ScholarSphere first

  • Looking to identify any additional stakeholders interested in this sprint

  • They will keep the conversation going on Slack and in Pull Requests

Question from Hydra Plugins WG

Myers

Taking GeoConcerns as a first case (it is effectively a plugin)

Also, written to be the one and only plugin for a CurationConcerns App.

Discussion revolves around utilizing integration points in the Hyrax stack

Identifying why those integration points might not be sufficient

GeoConcerns deals with a special set of files

Characterization flow changes a bit depending upon the file uploaded

GeoConcerns clobbers some methods which prevent it from integrating from another plug-in

The WG found that the Actor stack seems to be the right integration point

Myers to attendees: Is this true?

Also is the workflow engine from Sipity an integration point?

Scherz

Actor stack feels like the right point

Pendragon

No great answers...Actor stack is just a list of classes run in order

List is defined on the first Actor in the stack

Big issue with derivatives...property of the FileSet determines which derivatives to generate

Myers:

Is the decision to have only one FileSet an open design question for Hyrax?

Subclassing FileSets would require quite some bit of code

This dovetails a bit with the Hydra FileSets WG

In that developers should try to emphasize the need to generate derivatives from Files rather than FileSets

Has found that Actors stack Jobs...it's somewhat hierarchical

Is there some way to flatten this?

Otherwise these are nested Jobs within Jobs

Perhaps a queue-like structure?

Pendragon:

This is a hierarchy because jobs have dependencies

Myers:

Is there a way to resolve this dependency without introducing a tree-like structure?

Hyrax developers are lovers of Modules and mixing it in

Mixing these out of order brings in problems relating to method overriding and inheritance

They may try to code a mechanism for identifying intermodular dependencies

This could also be useful to implement for Jobs or Actors

Do any attendees have any knowledge of any Gems in the backlogs which enhance interoperability?

The next meeting for the Hydra Plugins WG is on 01/31/17

Moderator/notetaker for next time

  • Moderator:  @Andrew Myers

  • Notetaker:  @Michael Joseph Giarlo