...

Attendees 

• Jared Whiklo
• Jim Coble 
• Andy Wagner
• Doron Shalvi
• Yinlin Chen
• Kevin Ford
• Michael Durbin 
• Benjamin Armintor 
• Andrew Woods
• David Wilcox 
• Benjamin Armintor
• Joshua Westgard
• Nick Ruest
• Aaron Birkland
• Daniel Lamb

Agenda

1. API Specification
   1. Ideally the first public draft would be published over the next couple weeks
   2. Moving towards a shared understanding: Purpose of the API specification 
      1. Some of the disagreements about the details of the spec arise from differing opinions on the purpose of the spec itself
      2. Notes on purpose of the spec
      3. Two different perspectives:
         1. Spec defines minimal but required set of capabilities that must be implemented in order to “do Fedora”
         2. There are a range of capabilities, and you may or may not do all of them
            1. If you do any of them, here is some guidance/expectations on the behaviour
      4. Josh: what is the scope of the spec?
         1. Is the spec mainly about aligning Fedora with LDP, or should it also include things (like fixity) that are historically associated with Fedora that do not fit into an HTTP interaction model?

   3. Does Persistence Fixity belong in the specification?

      1. Josh: It's an important function of this kind of system, and the expectations about how it might be done need to be clear

      2. Danny: some discussion of back-fillability of functions
      3. Aaron: application concerns are different for RW apps than for RO apps, too
      4. Andrew: consider the notion of substitutable backends- seems like spec should be clear enough that an app should be able to be agnostic to some extent; what capabilities should be guaranteed? what are implementation dependent? is a key distinction for the API definition effort. What can we do?
      5. Aaron: unsure how much we can do with regard to, for example, the flexibility in the LDP approach of constraints documents and statement rejection (again mattering to RW and not to RO apps)
      6. Andrew: To what degree is substitutability reasonable or sensible?
      7. Nick: If we're silent on SSR, cannot promise any functional substitutability (in managing apps)
      8. Danny: the spec is really leading me to use the simplest interaction models, which might good, but may also be too simple
      9. Josh: feels strongly that it should be a refinement of LDP
      10. Kevin: If the purpose is interoperability with an eye toward swapping out back-ends then we should tighten the spec
      11. Pain point: putting RDF (e.g. an ontology) into Fedora that does not conform to Fedora’s restrictions (e.g. single subject rule) so it must be uploaded as a binary file
      12. Is the SSR a technical limitation or an important part of what Fedora is?
          
          1. Andrew: it is a philosophical limitation - Fedora is a digital object repository so RDF describes objects in Fedora rather than random subjects in the world

   4. Outstanding issues

2. Implications of blank node redesign: 

   Jira
   server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2108

   1. Warrants a 4.8.0 release?
   2. Instead of being created off to the side, these are now created as hash URIs
      
      1.  Jared: Will anyone notice this change?
      2. Andrew: existing resources will not change, but new blank nodes will be created as hash URIs
      3.  If administrators wanted to remediate this difference they would need to do this work (or a tool could be created)
   3. Nick: Do we need to release this along with a tool? What kind of release is it?
      
      1.  Andrew: It is not backwards-incompatible so it is a minor release
      2. Aaron B: Some clients may have written code that would make this backwards incompatible
      3.  Andrew: We could float this to the community to see if anyone is depending on the previous functionality
         
         1.  Basing this on mailing list feedback is not necessarily indicative of what people are doing
      4. Jared: Do we define breaking change based on the repository or potential workflows?
      5. We should produce a tool to remediate the different ways of handling blank nodes and put out a minor release: 

         Jira
         server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key FCREPO-2423

3. Suggestions from recent Fedora Leaders meetings
   1. Have an elected Fedora Committer join Fedora Leaders calls
   2. Have DuraSpace-hosted release testing infrastructure
   3. Interest in tighter alignment of effort and priorities between Islandora/Hydra/Fedora
4. Announcement: Monday - 2017-04-17 - Import - Export Planning Meeting
5. ...

6. Status of "in-flight" tickets

     Click here to expand...

...