Time/Place

This meeting is a hybrid teleconference and slack chat. Anyone is welcome to join...here's the info:

Attendees

Agenda

  1. Sign up for the upcoming Alignment Sprint
  2. Review Ben Pennell's exposition of options for implementing mementos of binaries and their descriptions
  3. Documentation mini sprint
    1. Who is interested? 
    2. Timeframe
    3. Objective
    4. Next steps
  4. "Pre-sprint" work that can be done
    1. Reading work? 
    2. Low-hanging JIRA tickets:
      1. ?
  5. Shall we consider using Duraspace checkstyle rules?
    1. Checkstyle Analysis
    2. Repo
    3. There are three rules in the fedora checkstyle rules that are not in the Duraspace checkstyle rules: 
      1. requiring @author in javadoc
      2. "final" required for parameter variables
      3. "final" required for local variables

Sprint tickets 

type key summary assignee reporter priority status resolution created updated due

Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Ticket Summaries

  1. Please squash a bug!

    key summary type created updated due assignee reporter priority status resolution

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

  2. Tickets resolved this week:

    key summary type created updated due assignee reporter priority status resolution

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

  3. Tickets created this week:

    key summary type created updated due assignee reporter priority status resolution

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Minutes

  1. Sign up for the upcoming Alignment Sprint
  2. Review Ben Pennell's exposition of options for implementing mementos of binaries and their descriptions
    1. Document has been shared on chat and listserv.  Includes ideas from Esme and Ben.  There have been many suggestions on different ways to create and retrieve binary mementos.
    2. What kind of link headers should be provided by Fedora?  Should Fedora determine if a binary and description memento are related?
    3. Three possible implementations noted:
      1. Create mementos one by one.  Two requests would be needed.
      2. Similar to 1. above, except on retrieval Fedora would provide a "described by" link to the original resource instead of attempting negotiation.
      3. A single request would create both a binary and description memento, when importing a historical memento.  The description memento would then effectively be a newly created node.
    4. Historical mementos are primarily for importing from another Fedora, but could also be used to create additional versions from scratch.
    5. Bethany prefers an approach where a single post creates both.  Jared prefers the second approach because it alleviates the server from having to handle negotiation.
    6. The group has previously agreed to replace references between resources with literals.  Should we handle headers the same way?
    7. Possibly, we are stretching the Memento spec.  When requesting a Memento object, how sould we respond in order to still be compliant with LDP?
    8. Deletions
      1. If the canonical object is deleted, the versions are also deleted.  Perhaps split binaries and descriptions into seaprate objects?  Seems not worthwhile.
      2. Should Fedora keep versions of items that have been deleted, so that these could be restored?  Memento is capable of doing so if we desire.  Makes sense in a Disaster Recovery scenario.  To do so, we'd have to move the timemaps out into a separate location in the repo.
      3. Conceptually, is versioning for items only currently in the repo, or all items that have ever been in repo?
    9. Outstanding questions:
      1. Should we have LDP responses for mementos?Does a memento object act as a full LDP object, particularly with respect to headers?
      2. Are the edge things (such as headers) important for our users' workflows?  Should we handle these?
      3. Is versioning for items only currently in the repo, or all items that have ever been in repo?
      4. Should Fedora keep versions of items that have been deleted?
  3. Documentation mini sprint
    1. Issues with documentation on the wiki were noted.  Is the documentation correct and sufficient?
    2. To be discussed in the tech call next week.
  4. "Pre-sprint" work that can be done
    1. It would be helpful to finish work from the last sprint - creating mementos of resources - before the next sprint begins, to avoid questions and merge conflicts in next sprint.  This work is defined in an existing ticket describing the creation of binary mementos.  To aid this process, it would be helpful to make decisions on binary mementos now.
    2. The next sprint will focus on mementos and ACLs.

    3. Peter promised an investigation into moving WebAC from ModeShape to the web layer.

    4. The WebAC tickets fall into a few categories: 
      1. Fixing headers, aligning with WebAC spec.
      2. Dealing with ACL append mode. Tricky / impossible to do at Modeshape layer.
      3. Implementing support for default ACLs. Separate from ACL append issues?
    5. Regarding binary versions, we could use input from the community and Fedora leaders before the next Sprint.  Jared will send an email to Fedora leaders to get input.  David recommends presenting a summary in the email including use cases and benefits, with technical details attached.  Fedora leaders will include input from the Islandora and Samvera communities.
    6. Also worthwhile to obtain feedback from Fedora leaders on the deletion issue (true deletes or keep a copy to be restored), since this is a broad issue regarding expectations of a repository.
    7. All of the above should be discussed at the next sprint planning meeting.
  5. Duraspace checkstyle rules - Danny to bring up next week.
  6. Actions
  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.