This wiki space is archived.

The active wiki for the Samvera Community can be found here:

Child pages
  • Samvera Tech Call 2017-08-23

This wiki space is archived. The active wiki for the Samvera Community can be found here:

Skip to end of metadata
Go to start of metadata

Time: 9:00am PDT / Noon EDT

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

Moderator: steve van tuyl

Notetaker: Carolyn Cole



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

    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

    7. Welcome all newcomers!
  2. Agenda (moderator)
    1. Delete 1.0.0 tag from hyrax? (Anna)
      1. causes confusion when looking at a commit to see whether it's been released
        1. github shows that code has been released when it has not been.  This causes confusion for people looking into github
      2. requires coordinated effort to not add the tag back in during future releases.
        1. Unless everyone deletes their local tags in their repos, it could get pushed back up again
        2. Add a note to the release process to either delete the local tag first or delete the remote tag again after?
      3. Here's the command to use: 
        git tag -d TagName && git push origin :refs/tags/TagName
      4. The group voted to go forward with removing the tag
    2. Change PCDM relationship on Collections (move from Collection hasMember Collections to Collection memberOf Collections) (Jeremy F)
      1. Rationale - performance issues along with the following:
        1. There appears to be a logical disconnect between the PCDM implementation of Collections and the validation of nesting collections:

          1. For PCDM the "parent has_member child" relationship is defined, and managed on the parent.

          2. For the Nesting collections, we require that:
            * The child is EDIT-able by the user
            * The parent is READ-able by the user
            The Nesting collections requirement implies that the PCDM relationship is pointing in the wrong direction. And Jeremy may have misread the spec, but is still concerned about the direction of the relationship.

        2. Collection or a Collectible A collection hasMember Collectible only for collections.  For works the membership was reversed for performance reasons.

        3. Currently to add something to a collection I must have edit permissions on both the collection and the work

          1. Is it ok to collect something that I do not have edit rights for it?

            1. User collection of things I can see (view access) to track things I like

            2. I am a staff member who can create collections, but I do not have edit permissions to the collection

            3. Currently the UI does not allow users with view access to add items to a collection.

          2. Ordering would be the only technical reason to not change the reverse, but it would be really weird to have ordered collections with unordered works

          3. Create a collection membership entity that would handle the order conceptually

            1. would allow you not to have edit access in the work you are collecting

            2. would need to be in fedora

            3. could persist the ids only but that has linked data implications

            4. Flip the relation to get the performance and add an order table in the database

          4. Edit permission to the predicate, but not permissions to the entire work.

            1. Thinking about property permissions

          5. If I can collection something I can change that one and only property

        4. Put up a PR with the rationale and let the community review the PR for this

    3. Admin Set Relationship Predicate (Tom)
      1. Objects in Hyrax are currently related to Admin Sets with dcterms:isPartOf; this makes it challenging to use this generic partitive relation for other cases
        1. There is an issue discussing this at
          1. AdminSet relations show up in the other relations that are defined as isPartOf
          2. The property seems to general for admin set
        2. DCE would like to make the admin set relationship configurable in 2.0, advise new installers to use something other than isPartOf (what?), and change the default in 3.0.
          1. Comment here:
          2. Include migration tools to change the predicate that is more narrowly scoped
          3. Lower barrier is to make the admin set predicate configurable, and just deprecate the current predicate
        3. DCE will put in a PR for this
    4. Reminder to review Permission Group change proposal/notes from 2017-8-16 Samvera Tech Call
      1. Jeremy will provide some examples to add more information to the proposal
      2. This will be discussed again in two weeks
      3. Comments are enabled on the google doc, please add some if you need clarifications
  3. Moderator/notetaker for next time (moderator)
    1. Moderator: Anna Headley
    2. Notetaker: Michael J. Giarlo
  4. After call, this week's notetaker should create the agenda for the next call.


  • No labels