March 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 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

• Danny Lamb
• Melissa Anez 🌟
• Martin Dow
• Nat Kanthan
• Marcus Barnes
• Jon Green
• Jennifer Eustis
• Kim Pham
• John Yobb
• Mark Baggett
• Amanda Lehmen
• Ed Fugikawa
• Aaron Coburn
• Jared Whiklo

Agenda

1. Fedora API spec continued
2. "Externally Referenced Content" in CLAW/Fedora 4 - Issue #564
3. ... (feel free to add agenda items)

Minutes

Fedora API Spec:

Danny: Update: At the Fedora Tech call after our call last week, they discussed batch/atomic operation and decided to move it into a spec on its own, if there are no objections from the community. It will be its own, optional, specification. Doing this to give it the time that it needs to be done properly. Does this hurt anyone's plans, in this group?

No one raises a virtual hand.

Danny: This covers most of what we were talking about in the spec last week. What's left is the externally referenced content piece, which was discussed on this issue. So far one solid use case, From Brad Spry. This seems likely to be a common use case.

Do we need the Fedora community to handle this, or should we attack it ourselves? Danny may have a plan but would like to hear others.

Jared: University of Manitoba has a desire for external datastreams. May not care how we do it. It seems like doing it at the Fedora level might benefit, because Ben Armintor has indicated they may need the same. If we push the use cases together, we could get larger team to work on it.

**Aaron: **There's this discussion about redirect vs proxy. Ben's case with a proxy seems more useful. Amherst doesn't need the redirect.

Danny: It seems like we don't have anyone clamouring for this to happen in Drupal. Looking for any objections?

No one raises a virtual hand.

Danny: If we do ask this of Fedora, we should contribute to make it happen.

Jared: Regardless of whether there's a change in Fedora to add externally referenced content, it still seem like we're going to have to proxy at the Drupal level because of the lack of granularity at the Web AC permissions level. Fedora will handle making sure you have access ot the object, but well probably still want to proxy it at the Drupal level? Because of the way our objects are not going to be broken down, you'd have to have access to that non-rdf source object.

Danny: if push comes to shove, if our API allows us to isolate the content of the files and we return the binary as a download, we could just use that URI that comes from our own API and pass that around, which forces it through Drupal and that authorization. Either way, the discussion seems to have died down, so maybe we are done with this issue?

Jared: The question for Fedora is: What is Islandora's stance? Do we need it or not?

Melissa: We could bump that issue on the list and twitter again. With a little "speak now or hold your peace" emphasis

Danny: We need to get the stakeholders to hold their stakes.

Jon: It's difficult to say this early. Agrees that the redirect doesn't make sense and there's utility in proxying things through Fedora. But LYRASIS won't have a solid use case until they start deploying. Feels like proxying through Fedora would be a good thing.

Jared: If we want it at the Fedora level, we need to make a case for it in the spec. The strongest case is from those using this type of set up in Fedora 3, who want to do the same in Fedora 4.

Jon: Can say for sure that they want to be able to store data outside of Fedora. If Fedora is holding preservation masters, doesn't want those to live as a Fedora 3 managed datastream. But still not familiar enough with Fedora 4 to know if that's doable. Ideally, for cost reasons, being able to store the preservation master elsewhere would be good.

Jared: Not sure anyone needs to redirect datastream, because you can do that with an rdf property.

Danny: if we says that files are going to live in whatever storage Drupal uses and we just give it this external body uri that points back to Drupal, then we can have the metadata live in Fedora and have it point back to the thing in Drupal, handling the access that way. There's a good chance that will do what you want, but as always with Drupal, there's a chance it won't fit all use cases.

Natkeeran: Need flexibility to map files to multiple external storage systems. Would be good if user does not have to migrate as storage needs increase.

Melissa will shake the cage on Twitter for more comments and then Danny will try to synthesize what we've discussed and take it to Andrew Woods for Fedora.

Jon: Let's be realistic about there being modifications to the API sec in the future, too. This isn't the end of the discussion.

Aaron: That is totally right. If version 1.0 is successful and there are additional needs, there will be a 1.1. But the big caveat: Don't expect it to happen very quickly. Look for a timeline measured in years, because it probably won't happen until we understand the failings of 1.0, which requires a lot of implementations - and right now we have no implementations of the spec.

Danny: That's the end of the agenda. Any other topics?

Aaron: Just for information, he is working on an alternate implementation of the Fedora spec. One interesting this that he has stumbled on is the notion of 'delete'. The spec doesn't actually define the behavior of delete. Not tombstones- recursive delete. If you have foo/bar and you delete foo what happens to bar? three possibilities:

1. foo and bar are deleted
2. you can't delete foo because it isn't empty
3. you delete foo, but bar stays as an orphan.

All of thee are valid in the current spec and all have use cases.

Danny: it's tricky and we've been grappling with it. Not sure how to write something that would handle all three use cases.

Aaron: Bets you could craft something in current Fedora 4 where recursive delete would go wrong and the whole thing would fail.

Danny: What's the best way to handle it? Try to influence the spec, or just be aware and prepared?

Aaron: In favour of just being prepared. Make it a configuration option.

Danny: We may have to pick a way and go with it, changing down the road if we find a need. But then if people have implementation, we'd trigger migrations which is painful.

Jared: With this behavior you wont be able to swap from CLAW on top of the reference implementation to using Cavendish or Trellis without careful consideration. Still possible, but you'd have to really look at why you wan tot do it wand what the benefits are.

Danny: Something else to worry about.

Martin: Question for Aaron: Why is it better to fix the definition of delete as a config option rather than extending the spec explicitly to describe the variations on 'delete'?

Aaron: Personal opinion, but the main thing Fedora brings to the table is a unification of a variety specifications, all in one whole. In so far as it does that, it's great. In so far as it restricts behavior within any of those, there needs to be a high bar. For example: LDP has all kinds of delete. If Fedora only allows one, the reason needs to be very compelling. The spec needs to be balanced between defining behavior enough that you can have multiple implementations and multiple designs in one big tent, but not constrain behavior so much that it becomes too complicated for certain deployment models or removes certain use cases.