Time/Place

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

• Time: 11:00am Eastern Daylight Time US (UTC-4)
• Dial-in Number: (712) 775-7035
  • Participant Code: 479307#
  • International numbers: Conference Call Information
  • Web Access: https://www.freeconferencecallhd.com/wp-content/themes/responsive/flashphone/flash-phone.php
• IRC:
  
  • Join the #fcrepo chat room via Freenode Web IRC (enter a unique nick)
  • Or point your IRC client to #fcrepo on irc.freenode.net

Attendees 

• Jared Whiklo 
• Bethany Seeger
• Longshou Situ
• Unknown User (acoburn)
• David Wilcox
• A. Soroka
• Kevin Ford (ArtIC)
• Allen Flynn
• Namita Bahulekar
• Benjamin Armintor

Agenda

1. Review Versioning Spec - meeting - recap
2. Thoughts on multi-tenancy
3. ...

4. Status of "in-flight" tickets

Ticket Summaries

1. Please squash a bug!

2. Tickets resolved this week:

3. Tickets created this week:

Minutes

1. Versioning Spec Meeting
   1. Meeting went well, input from lots of stakeholders from various communities.
   2. Big issues were how the creation of new versions would be handled. Memento to be the versioning interaction model which is good for getting versions but does not handle the issue of creation of versions.
   3. Andrew Woods has had some discussions with the Memento community and they are open to the idea of expanding the spec to handle version creation.
   4. Different proposals were put forward.
   5. Benjamin Armintor suggested we provide a way to make the interaction model discoverable and not tie down to a specific creation strategy. 
   6. Still some smaller details to work out but in a good place.
   7. Moving from the current Google Doc to using ReSpec for the writing of the actual specification.
   8. Suggested that this be placed in the general Duraspace Github account (where PCDM resides), will pursue this once Andrew Woods returns from travel.
   9. This Fedora API Spec that is the furthest along and is blazing a path for all the coming specifications.
   10. More information will be forthcoming on listservs and future tech calls.
2. Multi-tenancy
   1. It has an impact on the CRUD specification that affects the use of PUT.
   2. The question is can you use PUT to create a whole new section of the repository and what does that do for multi-tenancy.
   3. Currently the hierarchy is created for you, other options are disallow those PUTs or add the resource with connections but without containment.
   4. We have seen some scenarios around multi-tenacy, and having regions of the repo that have a disconnectivity of one kind or another (perhaps intra-repo references).
   5. We really need some more use cases to help guide the discussion around these issues. Please submit one if you have one.
      1. Multi-tenancy Single Fedora Instance
3. In-flight tickets
   1. : Spec says that the acl:agent should be a URI, but all of our use cases were using literals. The PR tries to convert the literal to a URI and leave URIs alone (we think).
   2. : Should be resolved with  which is waiting on updating the w3/ldp-test-suite to use Jena 3. A. Soroka has submitted an issue (https://github.com/w3c/ldp-testsuite/issues/229) and PR (https://github.com/w3c/ldp-testsuite/pull/228) with no response. Should we fork the test-suite to resolve this issue? Or call on tamsin johnson or Rob Sanderson to help us bring this issue to light?
   3. : Joshua Westgard is working on a Python script to complete this.
   4. : Endpoint is deprecated and can now be removed. A. Soroka will merge.
   5. Lots of e-tag issues. Unknown User (acoburn) a PR in to help resolve these (https://github.com/fcrepo4/fcrepo4/pull/1033), once this is complete then there will be a subsequent PRs to help address these issues.
   6. : Remove JCR Node from the FedoraResource. There is no longer a getNode() method. Is this a good approach? The FedoraResource has a getNode() method, but this will vary with the FedoraResourceImpl and will depend on the Modeshape implementation. Seems like this is a good step forward. (https://github.com/fcrepo4/fcrepo4/pull/1032)
   7. : ActiveMQ is the only messaging implementation that Fedora has, the Messaging Spec will allow for multiple implementations. Camel toolbox assumes we are using ActiveMQ, but with OSGi we can inject this service at runtime. This "abstraction" is an OSGi queuing abstraction. The messaging bean created could be replaced with an OSGi reference. So you could have a service that creates a service with messaging using ActiveMQ component or using RabbitMQ component or using whatever. Suggested that this change includes comprehensive documentation to assist in this type of change.