...

1. Please squash a bug!

   Expand
   Jira server DuraSpace JIRA jqlQuery filter=13122 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

2. Tickets resolved this week:

   Expand
   Jira server DuraSpace JIRA jqlQuery filter=13111 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

3. Tickets created this week:

   Expand
   Jira server DuraSpace JIRA jqlQuery filter=13029 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

Minutes

1. Updates and Announcements
   1. Fedora 4.6.0 has been released!
      1. Last release that will be dependent on ModeShape 4.  Master branch is now dependent on ModeShape 5 and is expected to be the basis for release 4.7.
      2. Release Notes will be updated to call out changes that necessitated a new major release (i.e., 4.6 instead of 4.5.2).
      3. There is now a mandatory database config item.  4.6.0 no longer defaults to LevelDB.
   2. Registration is open for Fedora Camp NYC November 28-30
   3. Archivematica Camp - updates? outcomes?
      
      1. Not much outcome in terms of Fedora - Archivematica hacking
   4. Import/Export sprint update
      1. Sprint began on Monday.  Goal is to complete Phase 1 priorities.
      2. So far, sprint is basically through Phase 1 a, b, and c sub-priorities
2. Linked Data Notifications - roll into Fedora as an fcrepo-exts project? Unknown User (acoburn)
   1. Web resources can be linked to an inbox.  Clients can then create events on that inbox.
   2. Some minor contradictions between Fedora and the Linked Data Notifications spec – e.g., in the absence of an Accept header, Fedora will return Turtle and Linked Data Notifications spec calls for JSON-LD in that case.
   3. Is this worth including as an fcrepo-exts project?
      1. Examples of what it would be used for?  Dropping in notices about resource changes and specific out-of-band events associated with a resource; e.g., photo of college president gets used in a publication.
      2. Would existing audit functionality allow handling these kinds of events?  Currently, no clear way to get from a resource to the audit events associated with that resource (though there is to go from the audit event to the resource).
      3. Linked Data Notifications has the advantage of having a spec behind it.  We would not be making up our own thing.
      4. Adding this to fcrepo-exts seems to pose no conflict with the intent of fcrepo-exts (a place for interesting functionality related to Fedora that isn't core).
   4. Unknown User (acoburn) will work on this, though it may be a while before he gets to it.
3. GraphQL - roll into Fedora as an fcrepo-exts project? Unknown User (acoburn)
   1. Most of Fedora deals with a resource as a whole.
   2. GraphQL is a draft spec for querying REST endpoints and returning only requested data.
   3. Unknown User (acoburn) will likely experiment with it locally at Amherst and later move it to a fcrepo namespace if it looks like it may be of wider use.
4. Process for deprecating fcrepo-transform Andrew Woods
   1. 4.6.0 still has fcrepo-transform as part of webapp-plus.  Work has been done to pull the functionality into a Camel component.
   2. 4.6.0 returns a deprecation warning header.  The plan is to remove it from 4.7 and provide documentation on how to use the new Camel component functionality as a replacement.
   3. Anything else we should do to inform the community about this particular deprecation (or deprecations in general)?  No additional suggestions.
5. concurrency
   1. Closely spaced PUT's to the same named resource can result in resources with same name, except for array type suffix.
   2. Michael Durbin is working on PR that involves locking.
   3. How aggressively do we want to lock or do we want to lock at all?
   4. Opinions
      1. What Michael Durbin is doing seems to address the issue.
      2. Any counter-arguments? A. Soroka (not on call) may have some?
      3. Short-comings of current solution
         1. Pairtree nodes need to be locked.  Michael Durbin will incorporate this.
         2. Doesn't work with transactions.  Note this for now and decide later whether to address.
      4. Would proposed approach potentially result in long-blocked requests if putting to same part of pairtree as a large binary PUT?  Michael Durbin will see how hard it would be to address this concern.
   5. Consensus is to move forward with proposed approach.
   6. Longshou Situ is also working on this at the ModeShape level: https://issues.jboss.org/browse/MODE-2624.
6. Revisit default behavior on PUT requests containing RDF bodies: 

   Jira
   server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-1928

   1. Change default behavior of PUT request.  Postpone to next call.
   2. To consider in the meantime:
      1. How does proposed change align with LDP specs?
      2. Is the proposed change the desired behavior?
      3. How does the http requirement for idempotency factor in?
7. Fedora 4.7.0 planning – Postponed to next call.