November 29, 2017

Time/Place

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

• Time: 1:00PM Eastern Standard Time US (UTC-5)
• Dial-in Number: (641) 715-3570
  • Participant Code: 304589#
  • International numbers: Conference Call Information
  • Web Access: https://www.freeconferencecallhd.com/wp-content/themes/responsive/flashphone/flash-phone.php
• IRC:
  • Join the #islandora chat room via Freenode Web IRC (enter a unique nick)
  • Or point your IRC client to #islandora on irc.freenode.net

Attendees

1. Melissa Anez
2. Jared Whiklo
3. Nat Kanthan
4. Seth Shaw
5. Marcus Barnes
6. Jonathan Green
7. Yamil Suarez
8. Rosie Le Faive

Agenda

1. Sandbox
   1. https://github.com/Islandora-Devops/claw-playbook/pull/40
2. Context Explorations
   1. https://github.com/Islandora-CLAW/islandora/compare/8.x-1.x...dannylamb:context-preconfigured
3. Derivative workflow
4. ... (feel free to add agenda items)

Minutes

1. • Danny is playing with the sandbox. http://future.islandora.ca. So beware if anyone is using it, it may be changing under our feet.
   • Danny added a PR for documentation for deploying outside of vagrant.
   • Nat had questions about how to deploy with passwords.
   • Jared: Maybe we can postfix each variable for passwords with _password.
   • Jonathan will make some notes about his thoughts on PR.
   • Maybe we could make a passwords.yml file.
2. • Danny has been working with the context module.
   • Has initial branch (prototype) here: https://github.com/Islandora-CLAW/islandora/compare/8.x-1.x...dannylamb:context-preconfigured
   • Context
     • Can do more then rules can out of the box, plus everything that rules can do.
     • Context lets you execute pre-made actions, which could provide us some powerful tools.
     • Seems pretty awesome so far, and seems to solve several of the problems we had with rules.
   • Danny going to continue working on prototype and make report for everyone.
   • Main motivation is to get to derivative generation.
3. • Nat is wondering what the workflow for derivative generation would be.
   • The way Danny sees it working is that:
     • Each solution pack would have its own context.
     • Then we would build actions based on the context, using preconfigured actions we could configure what happens in a particular context. The context would be attached to a node.
     • The preconfigured action would add messages to queues, then that queues would pass the messages the micro services which would trigger derivative generation.
     • Preservation master needs to live in Fedora, since the derivative services all are based on API-X.
     • So we would need to know when a preservation master is stored in Fedora.
     • If we didn't like that, we could pass a header that points to Drupal. The disadvantage there is that we couldn't use API-X so we can't use its service configuration.
   • Nat wants to know how it would work when items are in Fedora. We need feedback loop to come back to Drupal to notify that items have been ingested, or indexed.
   • Danny that absolutely is a gap, and we've all talked about it a bit.
   • Danny if we are doing it the Drupaly way maybe to push watchdog logs into Drupal using the REST interface.
   • Or we could store them somehow and use a view to display them on the screen.
   • API-X service discovery can give us flexibility if we are adding and removing services dynamically based on load etc. Allows us to discover new services.
   • Using API-X helps to give Fedora meaning in the stack, but also ties derivative generation to Fedora.

Additional discussion:

• Rosie: Does Fedora give us versions?
  • Danny points to a ticket https://github.com/Islandora-CLAW/CLAW/issues/740.
  • Perhaps all the versions will be done from Drupal. Or we could use both and make is configuration.
  • Perhaps could flush to fedora when you slice a new version.
  • Rosie: “versions of inline entities” —> for metadata or for derivative binaries?
  • Danny and Jared: Both they are tied together
  • Perhaps we could toggle when versions are flushed to Fedora. Have 'temporary' changes saved in Drupal.
  • Question becomes when we flush things to Fedora, is there an additional button for that. Maybe trigger on cron or something.
  • Rosie: Can a RDF source be versioned?
  • Danny: They can, but this gets very tricky quickly.
  • Since there are pointers in the RDF we only version one thing, but the pointers could change under your feet and we can't do too much about that. Just depending. If you want to version the full graph, you have to actually copy the full graph each time. Often we don't have control over the external URIs that are referenced.
  • If things work with momento then its possible to point to particular versions.
• Rosie: If I have a book and the book has an author, and I've represented the author locally. When I add a death date to the author what gets updated.
  • Danny: Only the author gets updated.
  • Jared: Momento gives an easy way to get older versions of things, based on headers. Things have time maps, and then you can request things on that time map. So if things support momento, then we could possibly load things based on versions, so that we load older versions of resources referenced by RDF.
  • Jared: In this example, if you look at a book you would get the latest author because we are dereferencing an URI.
• Rosie: People are very concerned about the metadata record and when that changes. Since things are not a flat document anymore, we have to consider that people will be concerned when the metadata record changes, which encompasses all of the URIs that are references in a RDF graph.
  • Versions of books for example won't contain an audit trail of history because the URIs that it reference could be updated and the book wouldn't know about the changes when looking at history.