Time/Place

This meeting is a hybrid teleconference and IRC chat. Anyone is welcome to join...here's the info:

Attendees 

Agenda

  1. Announcements
    1. Oxford Common Filesystem Layout meeting happened last Friday
    2. Auto-invite form for fedora-project slack now available (thanks Michael B. Klein)
  2. Needing volunteers
    1. New Fedora Clustering configuration - Carrick Rogers? 
  3. 4.7.5 release - Planning for week of January,15th 2018
    1. Release manager - Osman Din
  4. Fedora API Test Suite... needing:
    1. Try the tool against an API implementation
    2. Code reviewing the tool... lots of low-hanging fruit
  5. Simple, synchronous query in Fedora
    1. Prior art
    2. Queries to support
      1. select ?s where {?s ?p ?o}
      2. select ?s where {?s <some-pred> ?o}
      3. select ?s where {?s <some-pred> <some-object>}
  6. Tickets requiring attention
    1. - Bethany Seeger to review?
    2. - Ralf Claussnitzer to explore?
    3. - Ben Pennell to explore?
    4.  - on hold or close?
  7. 5.0.0 release
    1. API Alignment
    2. Pairtrees?
    3. - Danny Bernstein working this?
      1. Is tying Memento creation to modeshape a bad idea?
        https://github.com/whikloj/fcrepo4/blob/fcrepo-2617/fcrepo-kernel-modeshape/src/main/java/org/fcrepo/kernel/modeshape/services/VersionServiceImpl.java#L72
    4. - Daniel Lamb working this?
  8. Beyond 5.0.0 - Areas of improvement
    1. Persistence?
    2. Journaling?
    3. Simple, synchronous query?
  9. ...

  10. Tickets In-Review


Ticket Summaries

  1. Please squash a bug!


  2. Tickets resolved this week:


  3. Tickets created this week:


Minutes

Danny B will be hosting next week's call

  1. OCFL
    1. OCFL call
      1. round robin survey of digital preservation at 6 institutions
      2. application independent disk/fs layouts
      3. [Danny B] key takeaways?
        1. covered tooling/specifications for standardizing file storage layouts
        2. effort from Stanford called "Moab" to group these tools, adds process as a layer on top, does versioning
        3. looking for common elements across institutions' digital preservation file storage strategies
      4. [Bethany] more "what are we doing" conversations useful
      5. [Bethany] what about distributed setups for serving the data?
      6. assume we are writing to disk
      7. "disk" is not fully specified
      8. scale wrt lots of content but not performance issues
    2. 1.b. think about using Slack more on the technical side of Fedora?
  2. Clustering config
    1. [Carrick] it is on DevOps TODO list, should happen in the next 2 weeks (11-22 Dec)
  3. 4.7.5 release, scheduled Jan 15
    1. aim to get a RC out soon (this week or next)
    2. [Danny B] will review master on Monday for bugfixes that should be backported, cherrypick onto 4.7-maintenance
    3. do release off 4.7-maintenance branch
    4. look for unresolved bugfix tickets
    5. [Peter] can do RC testing first week of January
    6. [Carrick] can also RC testing first week of January, w/Avalon & Hyrax
    7. [Danny B] will put out RC next week
    8. [Jared] will assist
    9. will likely have to push out the Jan 15 release date
    10. review tickets for anything you want in 4.7.5 that is not yet
  4. UMD/NLM achitecture meetup
    1. [Doron] we hold DC Fedora Users Group twice a year
    2. had a smaller meeting at UMD to focus on architecture needs, upcoming needs, and a discussion of community status
    3. attendees: Doron, Esmé, Josh Westgard, Peter, Mohamed, Ben Wallberg
    4. NLM is just beginnning additional projects that require architecture buildout of enduser admin tools
      1. currently on F3, want to migrate, ran into issues before
      2. discussed Hyrax, Figgy, Valkyrie
      3. IR vs. digital repository, CMS-like feature that we don't need
      4. current model is to have large files on fs, external links in F3, would like to continue this model in F4
      5. would like F4 to support the "rebuild repo from fs" capability that OCFL promises
      6. NLM thinks F4 conceptually seems fine for modelling
      7. performance is still an issue in migration
    2. [Aaron B] F4 is more akin to a resource store rather than an object store
      1. provides primitives to model objects
      2. resources are managed and versioned individually
    3. OCFL defining object repo in the filesystem
      1. resembles the F3 object notion
    4. F4 provides tools to model objects, but not persisted and managed as a unit
    5. OCFL object members are collocated in some structure
    6. can F4 provide guidance on structuring resources in the userspace level?
    7. [Doron] looking for F4 to provide an object store
      1. want to publish RDF on the web
      2. fine with using multiple tools for object store and object publishing
    8. [Andrew] reflect on the API spec and imagine if your achitecture can use it
      1. related to the question of what services should Fedora offer
      2. not ideologically bound to the single subject restriction
    9. [Doron] where should LDP functionality live in the stack
    10. Fedora is not a triplestore, its an object store
    11. [Aaron B] "object store" is not defined anywhere
      1. F4 API describes resources, not objects
      2. objects is a high-level concept that is constructed through relationships
      3. left as an exercise for the user to define objects in terms a of linked data
    12. [Peter] F3 had built in object model
      1. need to start object model sharing and reuse discussion?
      2. [Andrew] PCDM was the first attempt at object model consensus
      3. [Aaron B] F4 not opinionated wrt object models
      4. [Andrew] mapping flexibility of resources on F4 to OCFL will be an interesting exercise
  5. encourage folks to run API test suite at various implementations
  6. desire for very simple synchronous query in F4
    1. [Jared] are we putting query into F4?
    2. [Andrew] this is just exploratory for now