March 16, 2016

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

• Jared Whiklo ⭐
• Melissa Anez
• Chuck Shoppen (sp?)
• Ed Fugikawa
• Diego Pino Navarro
• Mark Cooper

Agenda

1. https://jira.duraspace.org/browse/FCREPO-1945
2. LDCX

• WebAC (list(s) threads)
• PCDM interoperability
  • Paged content (Book, newspaper, etc.) model

3. Sprint planning

• Sign-up

4. Drupal Module Naming

• Do we continue with islandora_blah or are we going to conflict with 7.x-1.x?

5. Containerizing Drupal
6. ... (feel free to add agenda items)

Minutes

1. We are not using the JMS properties currently in the sync machinery, so this does not affect us.

2. LDCX

3. WebAC

   Nick is the only Islandora person we are aware of attending LDCX, so he will be attending a meeting with some Hydra users where they want to discuss how to resolve differences between Hydra WebAC and Fedora WebAC.

   Perhaps we should store our WebAC Authorizations in a root level "Authorization" container, so it is easier to find them, if we want to reuse them?

   Do we want to log back into Drupal (using Sync) with the same user that started the update or can we use a "Fedora" user to make sync updates. Using a single user could make multiple updates easier.

   Perhaps an entity on the Drupal to store the user that ingested the content, for example via a direct batch ingest to the microservices versus starting out in Drupal.

4. PCDM Interoperability

   There was a discussion between Diego, Nick, Jared & Andrew Woods about a PCDM Interoperability group that would work to document how objects would look in PCDM.

   The hope was to keep this group relatively small and to get documented examples of various objects in PCDM.

   Diego is modelling a book object for the CLAW lessons, so we will contribute that as our example and then we can look at how it does or does not work with Hydra.

   Hopefully we can add some requirements to the PCDM ontology to ensure compatibility between PCDM implementers.

5. Sprint #5.

   The sprint will start next week. Continue working towards solving tickets and getting the Collection service running from Drupal to Fedora and back.

6. Islandora CLAW module naming.

   Is there a use case where people will want to have both 1.x and 2.x modules running in a single Drupal instance?

   Diego thinks that it could be nice to have the islandora_claw_ prefix to keep the projects separate.

   There could be someone with an old Fedora 3 and a new Fedora 4 repo running together or there could be a migration utility written in Drupal (something using the old Islandora Sync)

   Ensure we package modules using their names to avoid the issues that exist currently around having directories named different than the actual modules (ie. islandora_solution_pack_image versus islandora_image.module)

7. "Containerizing" Drupal nodes

   This comes from Diego's concerns around how we are creating drupal content and how it maps to Fedora as well as how Fedora creates versions.

   If we continue to create one object in Drupal that contains/corresponds to a large number of Fedora versions, this could create problems when we get to permissions on objects and how Fedora does versioning.

   (ie. a single Drupal node could contain a Tiff, a JP2, a full size JPG, a thumbnail JPG, metadata corresponding to the image). But we could lose some metadata about how each of these correspond to each other.

   Instead of defining a big content model that defines all the parts in one Drupal node, we build individual resources in Drupal and link them together via a "view" or similar tool (node links). Using this notion we can allow versioning of individual parts separately, manage permissions on each piece individually, and share resources so you can build a Drupal "node" using a bunch of new and existing resources.

   Right now we are using content type directly, which is a table definition to Drupal. Then you build a bundle and say that "this" content-type will also use this bundle of fields.

   Instead of extending node type, we create Binary and RdfSource types.

   Then we build the bunch of individual entities to store all the metadata.

   Then the actual content-model is an extension of the above types (Binary or RdfSource) with a bundle of required/optional entities included.

   Then the object appears in Drupal as an aggregation of multiple Drupal nodes each corresponding to a binary or Rdf node in Fedora.

   So we can mimic LDP on the Drupal side in much the same fashion we have it in the Fedora.

   Could this help in managing/syncing between Drupal and Fedora? This means a more 1-to-1 (Drupal-to-Fedora) link versus a 1-to-many (Drupal-to-Fedora) link.

8. Last Questions/statements

   Ed signed up for the sprint. Way to go, Ed!