Hydra Tech Call 2015-10-14

Time: 9:00am PDT / Noon EDT

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

Moderator: Adam Wead (Penn State)

Notetaker: Andrew Myers (WGBH)

Attendees:

  1. Adam Wead (Penn State)
  2. Mike Giarlo (Stanford)
  3. Justin Coyne (Data Curation Experts)
  4. Trey Terrel (Princeton)
  5. Ryan Wick (Oregon St)
  6. James Griffin (Lafayette College)
  7. Steven Ng (Temple)
  8. Corey Harper (NYU)
  9. Andrew Myers (WGBH)
  10. Esme Cowles (Princeton)
  11. Jon Stroop (Princeton)
  12. Glen Horton (U of Cincinnati)

Agenda:

  1. Call for agenda items
    1. Mike Giarlo - discuss next release of Sufia (see end of agenda)
  2. Can we cut a new release of the PCDM stack? (Justin)
    1. activefedora-aggregation, hydra-pcdm, hydra-works, curation_concerns
    2. Justin: Currently developing with master branches of all of these; a release would help with stability.
    3. Trey: Plan on introducing some breaking changes in coming weeks.
    4. Conclusion: 
      1. Action Item: yes, we can go ahead and cut one, but expect changes within the coming weeks that would require cutting a new one.
      2. all gems still in 0.x.x – so we under no SemVer obligations to maintain backward compatibility between minor releases
  3. Features we've implemented in goldenseal that could move to curation_concerns if they are wanted: (Justin)
    1. Administrative Sets (not using contains)?
      1. PCDM AdministrativeSet type is not being asserted, because there are still questions about it's implementation.
      2. Desired features of admin sets in curation_concerns include:
        1. can turn them on and off
        2. uses PCDM
        3. can move between admin sets without altering URI
      3. Currently (2) and (3) conflict, as spelled out issue #36 here: https://github.com/duraspace/pcdm/issues/36
      4.  Hesitation to bring this into curation_concerns until issue #36 is resolved
      5. Esme:
        1. may be able to solve this by adding a predicate that doesn't use ldp:contains
        2. we need to just agree on what the predicate should be
        3. resolution can happen within context of issue #36 – no need for extra meeting
      6. Conclusion: look at bringing this feature in, pending issue #36.
    2. IIIF support (using RIIIF)?
      1. Justin: Opinions due to IIF implementation probably do not belong in curation_concerns
      2. Jon: Agree.
      3. On a side note... a Rack-based IIIF endpoint with intention of being highly configurable, possibly for use with Hydra-in-a-Box, has been started by Tom Johnson (DPLA) and Jon Stroop (<= I think is who mentioned that).
      4. Conclusion: do not move to curation_concerns at this time because use cases too varied; carries too many opinions
    3. IP based restriction (on campus access)
      1. Princeton definitely needs it, and another +1 (maybe from Mike G?).
      2. hydra-role-management may be an appropriate home for such logic
      3. Conclusion: yes - let's bring this in.
  4. Fcrepo 4.4.0 released
    1. https://github.com/fcrepo4/fcrepo4/releases/tag/fcrepo-4.4.0
      1. Justin:
        1. 4.3 didn't contain any bug fixes; this one apparently does.
        2. for instance, you couldn't upload OGG files in 4.3
      2. Unknown: Does this include updating metadata of files?
        1. Esme: yes
        2. (Notetaker: I don't know what this means. Anyone who knows, please clarify).
    2. we should upgrade hydra-jetty
      1. Action Item: Adam is all over this like rock on roll
  5. Register opaquenamespace predicate for representative
    1. https://github.com/projecthydra-labs/curation_concerns/blob/master/curation_concerns-models/app/models/concerns/curation_concerns/has_representative.rb#L6
      1. The above is used for declaring one file as the "representative" file for a given Work that has multiple files.
      2. Justin: there was no such predicate so we made one up.
      3. Esme: FRBR has something similar, but FRBR semantics may not be what we are looking for.
    2. Is there an established process for adding vocabularies and terms to opaquenamespace.org?
      1. No, not yet.
    3. Is opaquenamespace a good option for other RDF vocabs, e.g.: https://github.com/projecthydra/sufia/issues/1327 ?
      1. ^ here are more predicates in need of a public home
      1. Could these go under the "hydra" namespace at opaquenamspaces.org?
        1. Giarlo: sure!
    4. Conclusion:
      1. Come up with an established way of adding vocabularies and terms to opaquenamespace.org
        1. Action Item: cross-post with Hydra Metadata Interest Group
      2. In the meantime, use outstanding tickets for discussion and follow-through (see requirements below):
        1. https://github.com/projecthydra-labs/curation_concerns/issues/398
        2. https://github.com/projecthydra/sufia/issues/1327
      3. Any new proposed term requires the following:
        1. URL
        2. Label
        3. Description
        4. Domain and Range are welcome, but not necessary at this time.
  6. Sufia release
    1. Ran out of time, but anyone who want's to discuss, get a hold of Mike (mjgiarlo on IRC, #projecthydra on freenode)
    2. likely going to be 6.4. Lot's of changes since 6.3
  7. Next call
    1. Date: October 21, 2015
    2. Moderator: Steven Ng
    3. Notetaker: Mike Giarlo