Time/Place

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

Attendee

Agenda


  1. Feedback on /fcr:fixity  endpoint
    1. Fedora API Specification github issue
  2. Getting to 5.0 
    1. Review of work that happened this week: 
      1. External content (proxy, copy, and redirect)  - PR merged, there are a few issues relating to it that are low hanging fruit. 



    2. 5.x Documentation Effort
      1. 5.x Documentation Updates matrix
    3. Another sprint? 
      1. Timeframe/Duration/Availability
    4. Ecosystem tools dependent on the release:
      1. import export tool
      2. camel tool kit  
      3. fcrepo4-vagrant
      4. java client 
      5. api-x 
  3. : 

    1. Are we comfortable with messages emitted?

  4. Progress Report on Fcrepo-Cloud-Migrator Tool
    1. variants in .ttl between the python export and ruby-rdf

Ticket Summaries

  1. Please squash a bug!


  2. Tickets resolved this week:


  3. Tickets created this week:


Minutes

  1. fcr:fixity endpoint
    1. discussed in fcrepo leadership
    2. Andrew: fixity as a test case that highlights need for clear feedback and communication channels between community, tech, leaders, and committers
    3. tech thread and leadership thread: do we want fixity service? yes
      1. open discussions about resources needed to maintain this feature
      2. if it is important for community it should be in the spec
    4. github issue: https://github.com/fcrepo/fcrepo-specification/issues/373
      1. open question about whether there could be an additional header to RFC 3230 that returns a success/failure status
    5. deprecation status?
      1. should it be in the core? seems to be a ciritial preservation feature
      2. Peter: fine with moving this to a header if we can get a status header a la Andrew's GitHub issue
      3. Josh: agrees that this needs to be a core responsibility of Fedora
        1. external content wrinkle
        2. external content is beneficial to large content repos
        3. external content is not covered by current fixity
        4. Josh has been looking at extensions to check fixity for external content
      4. Bethany: copy and proxy will check fixity on new external content implementation; only redirect is left out
        1. could use some further testing
        2. Josh: how does it perform?
    6. Andrew: interested in the header approach
      1. Peter: can we use a link header for this?
    7. Bethany: are the spec writers talking about this?
      1. Andrew: no, this is why github issue has been added
    8. Jared: where do we store the digests? have to persist check
      1. external content is a bigger concern for performance
      2. redirect seems hard to implement
      3. Jared: need to store checksum where it is always available; similar to MIME type
      4. Peter: sounds like a server-managed triple?
        1. Bethany: store as a property on the binary itself?
        2. Jared: if server-managed triple do you return it in your graph?
        3. Andrew: these seem to be issues in general about server-managed triples
      5. Jared: the reference implementation should only implement the spec
        1. adding additional features to reference implementation means the spec is lacking
        2. Josh: API-X as an alternative to core?
        3. Jared: should also be discussion around the github issue
        4. if it is a vital part of Fedora then it should be in the spec; discuss how (MUST/MAY/SHOULD?)
        5. Andrew: agrees essential features should be in spec
      6. fixity service only answers the question of "is this resource what you think it is?"
        1. "self-healing repo" feature is out of scope; current/future fixity service does not address the question of "what next?"
        2. Jared: interested parties should speak up in comments on the github issue
        3. Bethany: we should send a follow-up email on the original thread(s) that highlights the github issue
      7. Doran: seems to be two issues: a) should we have the service? b) how should it be implemented?
  2. getting to 5.0
    1. PR for external content went in this week
      1. handful of issues to check
      2. any other 5.0 developments last week? no
    2. documentation updates
      1. ongoing effort
      2. Andrew: note the red X's indicating pages that need work; reviewer should add notes about what kind of changes are suggested
      3. Josh: can contribute to documentation effort
        1. are there instructions about what should be done for updates? procedure?
        2. Bethany: just go in and edit the 5.x versions of pages
        3. if you work on a page work on the whole page, or note where you stop
      4. Kevin: reviewer status?
        1. Peter: use the star
        2. Bethany: do we need to track who reviewed?
        3. Kevin: add reviewer name in the "Who?" column
    3. another sprint
      1. timeframe: July? maybe 2 sprints
      2. Andrew: did a Doodle go out
        1. no one seems to have seen a Doodle
        2. action: send out a Doodle to get a timeframe (Andrew)
      3. Andrew: 2 sprints sound good
        1. earliest/latest dates? July-October
  3. messages emitted
    1. what do we need to do to move FCREPO-2604 along?
    2. Andrew: Kevin's point: does a change to a inbound reference warrant a message?
      1. if yes, close ticket as complete
      2. if no, need more work
    3. Josh: inbound reference shouldn't change the state of the target resource
      1. Bethany: agrees
    4. Kevin: implication is just for resources that need to know that inbound references changed
    5. Bethany: can we distinguish between different kinds of changes
      1. Andrew: we don't track individual properties, so might be weird if we track this but not individual properties
    6. Josh: could this be useful for indexing
      1. Peter: does this have enough information to be useful for indexing
    7. Bethany: puts the work on the client?
    8. Jared: can we use different ActivityStream type for these type of change messages?
      1. there are object/link type relationships
      2. makes for easier filtering
      3. Bethany, Peter: agree
      4. Andrew: requires Fedora to know that a change is due to an inbound reference
      5. action: new JIRA ticket to explore nature of changes before messages are emitted (Jared)
  4. fcrepo cloud migrator tool
    1. Carrick: can do an overview next week
    2. has anyone tried ingesting edited Turtle? not yet
    3. Peter: looks like RDF 1.0 to 1.1 conversion issue (explicit to implicit string type)

Actions