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)
• U.S.A/Canada toll free: 866-740-1260, participant code: 2257295
• International toll free:  http://www.readytalk.com/intl 
  
  • Use the above link and input 2257295 and the country you are calling from to get your country's toll-free dial-in number
  • Once on the call, enter participant code 2257295
• IRC:
  
  • Join the #duraspace-ff chat room via Freenode Web IRC (enter a unique nick)
  • Or point your IRC client to #duraspace-ff on irc.freenode.net

Attendees 

• Unknown User (escowles@ucsd.edu)
• Nick Ruest 
• A. Soroka 
• Unknown User (acoburn)
• Michael Durbin
• Jared Whiklo
• Yinlin Chen
• Andrew Woods
• David Wilcox
• Osman Din
• Unknown User (daniel-dgi)
• Stefano Cossu

Agenda

1. Brief updated from NE-FUG/Training in New Haven this week
2. High-priority bugs? efforts?
   1. Merge it? 
   2. Blank node issue?  
   3. Hash fragments, thoughts?

3. migration-util issues: 

4. Java8 branch testing commitments: https://github.com/fcrepo4/fcrepo4/tree/Java8
5. 4.2.0 release?
   1. Audit Service
   2. Java8 compiler/artifacts
6. 3.8.1 release?
7. Islandora / F4 migration update
   1. Lot's of work on Services, and tight Drupal integration
   2. ontology
8. ...

Minutes

1. 
   
   • The "unconference" style worked well for the group.
   • The afternoon break out session to have participants describe an item in PCDM worked well to get people thinking and talking about their uses.
   • The vagrant VM has served the standard training install use-case well.
   • Unknown User (acoburn) : Has been attending North-East Fedora Users Group for years and found this was a more useful meeting. The combination of informal programming plus more structured training/presentation. Previously it seemed to be a more superficial discussion, this was more technically involved.
     
     
2. 
   
   • What are high-priority bugs/issues that may have fallen through the cracks.
   • Make sure that JIRA tickets contain a Fedora 4 Affects Version and/or Fixed In Version or they don't show up on Andrew Woods's listing.
   • Possibly performance problem (a set in jcr.utils, getting larger and larger).
   • Was planning that new blank node implementation would fix this, with blank node rollback we should review this issue and look at new fix.
   • A. Soroka & Unknown User (acoburn) : Rather than having that map in jcr.rdf.tools, push it up a layer to a particular document it would get picked up by garbage collection. (ie. Scope it to the request.)
   • Create a new ticket for the above issue.
   • Hash URI fragments - Andrew Woods remembers that support was introduced in support of real world RDF, which have hash URIs. Now we are in a state of incomplete support and possibly have some undiscovered bugs we should revisit. From a standards perspective, what is a hash uri? Possibly pick one interpretation go forward using disseminators (maybe?)
   • Options are 1) remove support for URI hash fragments, 2) keep URI hash fragments and complete the implementation (ie. fix any surrounding bugs).
   • Unknown User (escowles@ucsd.edu) feels that URI hash fragments work well.
   • A. Soroka agrees with the basic thrust, but we should explain that these are not blank nodes. To ensure both people happy with automatic generation of resources and those who might have been surprised by this action are aware of how it will work now.
   • Stefano Cossu expected that a hash URI fragment would be a part of the larger object/data, this could eventually be implemented with a disseminator.
   • Currently hash URI fragments are a child resource and have no other formal relationship.
   • Stefano Cossu: these could work like the current transform fragment (fcr:transform). Should always be contained with the scope of the larger "object".
   • A. Soroka & Stefano Cossu : hash URI fragments must be contained in lifecycle of the encompassing "object".
   • Andrew Woods felt that the notion of hash fragments is a bit up in the air, there are possible bugs around how they are returned. We could fix those bugs and leave the implementation alone. Concern around existing semantics being different from how Fedora 4 implements hash URI fragments could cause people to get unexpected results.
   • These differences are not well documented, have not heard from many in the community about the way hash URI fragments currently work or any issues surrounding the current implementation.
   • Unknown User (escowles@ucsd.edu): This was added (most probably) because it was going to be used by someone, so probably best to keep it and fix any surrounding bugs. Look at it as a possible replacement for the broken blank nodes implementation. Possibly mangle RDF on ingest to generate hash nodes instead of blank nodes. Seems that most use cases for blank nodes actually need a node who's lifecycle is contained in the lifecycle of a persistent resource, either that or they got blank nodes and don't actually need them.
   • Consensus around keep hash URI fragments and fix any bugs and issues surrounding it's implementation. If others could help create a model for changing RDF with blank nodes into RDF with hash URI fragments.
   • Unknown User (escowles@ucsd.edu): Does anyone have feelings around using ebucore vs premis as ontology for some user-modifiable properties. Hydra metadata WG recommending ebucore over premis, currently only mime-type and filename are in question right now. They would be user-modifiable but would be system populated on generation.
   • A. Soroka: Ebucore for user-modifiable and premis for server-managed properties.
     
     
3. 
   
   • Michael Durbin: Still working on edge cases and bugs fixing at this stage. Working with known test migrations which are getting more bugs found. Last things needed are property mapping by default. Perhaps create some tickets around what are not being caught or is lost in migration.
   • Andrew Woods to work at making migration-utils more usable.
   • Nick Ruest to pull together the mappings in islandora-labs and some on migration-utils wiki page and put them in migration-utils GitHub README.md.
   • Unknown User (daniel-dgi): tackling hierarchy stuff soon, PCDM has hasMember for downward traversal but does not have a way to traverse up the hierarchy.
   • Nick Ruest: No feedback on audit trail mappings. Assuming they are fine and will create a ticket to add them.
     
     
4. 
   
   • Needs testing before committing to master. No new functionality, just shifting to use java 8.
   • Need people to test it and ensure no existing functionality is affected.
   • Needs a rebase, but then bug fixes should be converted to make use of java 8.
   • A. Soroka : Some changes could be modified as this was performed initially as a quick and dirty translation, there are probably lots of places to optimize for Java 8.
   • A. Soroka to work on the rebase next week (May 17).
     
     
5. 
   
   • New release time (4.2.0), to include audit service and (possibly) a bump in the compiler version in main pom.xml to require Java 8.
   • Consensus around bumping the compiler version to java 8.
     
     
6. 
   
   • Fedora 3.8.1 release is upcoming, any issues to discuss before this 3.8.1 release.
   • No issues raised.
     
     
7. 
   
   • Tight Drupal integration.
   • Link in agenda to the proposed Islandora ontology. Being brought to the Islandora community and see how we proceed. This would be for both Fedora 3 and Fedora 4.
   • Mapping Drupal fields to RDF which allows us to export RDF/A from the objects.
   • Trying to line up Drupal UUID to Fedora UUID. Calls for new Drupal UUID are trapped sent to Fedora and the new uuid is generated by Fedora and sent back to use in the Drupal environment.
   • Used to be able to search by UUID, quick test seems it was removed. If the UUID can be searched that would be useful from an Islandora perspective.
   • Discussion to be on going around whether UUID search exists and whether it should be exposed more or buried.