January 11, 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 Daylight Time US (UTC-4)
• 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

• Nick Ruest
• Danny Lamb
• Marcus Barnes
• Kim Pham
• Don Richards
• Ed Fugikawa
• Amanada Lehman
• Melissa Anez ⭐
• Adam Soroka
• John Yobb
• Bryan Brown
• Aaron Coburn
• Martin Dow
• Natkeeran Ledchumykanthan

Agenda

1. Recap of January 3 Islandora CLAW RDFUI Use Cases Meeting
2. Newbie tickets
3. Is CLAW predicated on an idea of mirroring data between Drupal and Fedora?
4. (add agenda items)...

Minutes

irclog

1. Recap of January 3 Islandora CLAW RDFUI Use Cases Meeting

   Kim: Meeting on Jan 3rd to discuss rdf ui and use cases for how it can work for Islandora. Use cases came from Amanda Lehman, Bryan Brown, and Jenn Eustis. They came up with 4 or 5 use cases that they think will be in scope for CLAW. Notes with consolidated use cases can be found here. Kim will take this and make GitHub issues for further discussion.

2. Newbie tickets

   Easy way to get involved and contribute! Support is available.

3. Is CLAW predicated on an idea of mirroring data between Drupal and Fedora?

   Adam: Asking because conversations in irc led to questions about some fundamental assumptions regarding how CLAW works. His assumption was that CLAW is predicated on an idea of mirroring data between Drupal and Fedora, i.e, what's available from Drupal is available from Fedora, and vice versa, as though the other didn't exist. To the point of each half being able to operate if the other was destroyed. Now hearing that it may just sync one way in the MVP design.

   Looking to check in on these assumptions and get some clarity.

   Danny: Mirroring was an early idea that was an ideal, but ended up dialed back of scope. What you do in Drupal gets flushed to Fedora. If you can do that, it's pretty straightforward to use some camel to send the data back the other way, dependent on how you configure your rdf mapping in Drupal.

   The real motivation for the two way sync was migration. The current migration tooling for 3 -> 4 would get you there and let you re-index back into Drupal. This is done in Salmon.Drupal-> Fedora sync is always on. Fedora -> Drupal would be on demand.

   Adam: On demand Fedora -> Drupal does meet what he considers mirroring. Another assumption: post MVP, most people will be able to move the data back and forth in as lossless a fashion as possible. Fair?

   Danny: Yes, but keeping it lossless will be on the end user. You need to set up your mapping properly.

   Adam: Concerns addressed! Some sites might decide to automate the process completely, but as long as CLAW is providing the platform to go in both directions, that satisfies the need.

   Danny: The assumption about destroying one an having the other still work is also valid. This is one of the reasons we're going async. If Fedora goes down, the site does not go down with it.

   Adam: 😌

   Nat: Would CLAW be able to be deployed without the Fedora sync?

   Danny: technically, yes. But as it in the the MVP, but you'd be doing your derivative processes based on things in Fedora, so it is still listening for Fedora events. If you wanted a deployment like that, you'd need to create a Drupal with the events that Islandora would emit through Drupal, the driver for derivative creation. The tooling is there, but it would take some work.

   Adam: Wondering what brought that question.

   Nat: From an adoption point of view. If we could decouple the dependency, it might increase adoption. Could see some uses just going with the Drupal side, in smaller institutions who don't necessarily need the preservation layers. Installing the full stack seems to be one of the main barriers for adoption.

   Adam: From the Fedora side, things are (slowly but surely) moving towards standardization that would allow for differing implementations to be much easier.

   Danny: Would not consider what we're doing in Drupal likely to become an alternate implementation.

   Nick: Drupal and Fedora is Islandora. The Islandora community has a governance structure, and our Board of Directors have confirmed that Drupal 8 and Fedora 4 is our development path. Islandora as just Drupal + Solr is not in our plans.

   Adam: Sure sure. But imagining a Fedora that is written in just PHP, we could picture and Islandora that was just Drupal.

   Nick: If there's an implementation of the Fedora specification that works better for our community, then that's where we'd go. But the assumption is that Fedora is our specification. If folks want to plug in an alternate Fedora behind CLAW and it passes the Fedora tck jck (transcription fail!), that should still work.

   Aaron: Are there changes Fedora could make right now that could better serve the Islandora community?

   Nick: Not really

   Danny: There may be issues, but they are getting addressed.

   Adam: One last question. For Nat: adoption could get a boost if Fedora wasn't in the picture because Drupal is easier and more familiar. Is that true of php, or Drupal specifically?

   Nat: There are two reasons for the question. First, Drupal is a platform that many people are comfortable with. Second, since we have this architecture where we are going to sync Fedora and Drupal, was just wondering if it's a feasible goal to have the decoupling, since it might not be a lot of extra work on top of the way we are doing sync.

   Danny: It sounds like, underlying this topic, the installation process remains a big concern. We are trying to smooth that with CLAW as well, which can help address those adoption concerns. We are very committed to smoothing the install process.

   Adam: Going back to the first topic, since there's time left on the call: The use case that is overriding for the Smithsonian is a vast group of researchers, not all doing the same things, no one metadata standard (or any way standardize). One of the things they'll be interested in is how to assemble a big box of tools and predictes and hand them to some one untrained (who will not be trained), who may be the only person who knows enough about was is being described to describe it. This is more an ideal than a use case. Is RDF ui a part of this? Can we do this without a standard, but by supporting whatever assertions they want to make about an object?

   Danny: The RDF ui is just about providing an interface for users to do their mapping. There will still be some art in terms of doing those mappings properly for RDF. We won't be saying "if you pick this ontology, that's all you get."

   Adam: Sounds like the RDF ui is not targeted at this part of work. Ok.

   Danny: Knows there are use case, but hasn't yet had the 'shape' of research data described enough to deal with it.

   Adam: Agreed. Those shapes can be incredibly varied Anything from images, to GIS, to x-ray astronomy, to genomics. That's the problem.

   Danny: that's the conundrum of islandora. We have to be able to handle anything.