Hydra Tech Call 2015-12-02

Owned by Bill Branan
Jun 16, 2017
3 min read

Time: 9:00am PDT / Noon EDT

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

Moderator: Steven Ng

Notetaker: Anna Headley

Attendees:

  • Steven Ng, Temple
  • Colin Brittle, Va. Tech
  • Adam Wead, Penn State
  • Julie Hardesty, Indiana U
  • Carolyn Cole, Penn state
  • Lynette Rayle, Cornell
  • Anna Headley, CHF
  • Justin Coyne, DCE
  • Ryan Wick, Oregon State


Agenda:

  1. Call for additional agenda items
    1. Merging sufia-core into sufia
  2. Next call
    1. Date: December 9, 2015
    2. Moderator:  Justin Coyne
    3. Notetaker:

  3. Collection Permissions (References: Collection Permissions, User Collections, Admin Sets, Display Sets)
  4. ORE Aggregations (References: email PCDM: members, ordered_members, and ORE, gist: ordered_members vs. members and their interactions)


Minutes:

  1. Call for additional agenda items
    1. Merging sufia-core into sufia
  2. Next call
    1. Date: December 9, 2015
    2. Moderator:  Justin Coyne
    3. Notetaker: 

  3. Collection Permissions (References:  Collection Permissions,  User Collections, Admin Sets, Display Sets)
    1. Cornell has a use case wherien some collections are private, being used as part of mediated workflow process. Used to do batch processing while metadata is being added and want to make sure they don't show up anywhere. Also have public collections that public should be able to see, facet on. Proposes addition of collection permissions that mimic file permissions (visibility, sharing) to fill this use case.
      1. Concern: difficult to facet by collections if some are private and some are public
        1. But files facet fine.
        2. Even if you filter you are introducing things into facet set that are not useful to the user.

      2. Additional concern: user can create collections, which may be confusing if collections created by user 1 show up in search results for user 2

    2. Implement Admin Sets?
      1. Benefit is that a file can only belong to one admin set, so permissions inheritance is simplified.
      2. Can admin sets be either private or public?
        1. Intended to be behind the scenes, related to policy
    3. Concern about overloading collections, which were created for users.
    4. How would Admin Set and Display Set be implemented? Would this be part of hydra-collections or something else?
      1. It would be separate, because hydra-collections is only user collections (see also: 

        https://github.com/projecthydra-labs/hydra-admin-collections)

    5. Is this a use case for other people: having private collections and public collections (regardless of what they are called)?

      1. Penn State has had users request permissions, but usually around wanting to share edit ability.

      2. We think maybe Cincinnati has implemented some of this.

      3. Temple has public and private collections in prev. version of hydra. They do facet these.
      4. Avalon has collection-level permissions. (roles are: anyone, logged-in, collection staff only – for both files and collections)

    6. Concern that the name of a collection could cause offense when seen in a facet

      1. Currently are in sufia – they all show up in search results (not in facets)

      2. Moderating user creations is maybe its own question

    7. Facet implemented by Lynette could be extended to allow 2 facets: 1 for public and 1 for private.
    8. Desire to not facet on collections that were created by another user.
      1. However, faceting on display set or admin set would be fine.
      2. Could this be something we let users control on an individual / preference-setting basis?
    9. Separating out display sets and admin sets would help keep us from overloading collections even if permissions are added to collections.
    10. Permissions?
      1. Some support for these
  4. ORE Aggregations (References: email PCDM: members, ordered_members, and ORE, gist: ordered_members vs. members and their interactions)
    1. See also email thread
    2. Lynette wants to interact with a single 'members' object via the API.
      1. Concerns about that approach
    3. Impacts dive into hydra - philosophical approaches
    4. We agree to let this conversation continue on hydra-tech for now.
  5. Merging sufia-core into sufia
    1. This will happen on Friday, master will essentially become sufia 7.
    2. PRs submitted against master should be evaluated for backporting to 6.x stable branch
    3. There may also be PRs that are only relevant to 6.x
    4. Will there be an RC on Friday? Don't know yet.
    5. Upgrade path? Not yet determined.