Time/Place
This meeting is a hybrid teleconference and slack chat. Anyone is welcome to join...here's the info:
- Time: 11:00am Eastern Daylight Time US (UTC-4)
- Audio/Video Conference Link: https://duraspace.zoom.us/my/fedora
Dial-in:
+1 408 638 0968
+1 646 876 9923
+1 669 900 6833
Meeting ID:
812 835 3771
Join fedora-project.slack.com on the "tech" channel
Attendee
- Jared Whiklo
- Bethany Seeger
- Peter Eichman
- Carrick Rogers
- Kevin Ford
- Michael Durbin
- David Wilcox
- Joshua Westgard
- Doron Shalvi
- Aaron Birkland
- Andrew Woods
- Ben Pennell
Agenda
- Feedback on /fcr:fixity endpoint
- Fedora API Specification github issue
- Getting to 5.0
- Review of work that happened this week:
- External content (proxy, copy, and redirect) - PR merged, there are a few issues relating to it that are low hanging fruit.
- External content (proxy, copy, and redirect) - PR merged, there are a few issues relating to it that are low hanging fruit.
- 5.x Documentation Effort
- 5.x Documentation Updates matrix
- Another sprint?
- Timeframe/Duration/Availability
- Ecosystem tools dependent on the release:
- import export tool
- camel tool kit
- fcrepo4-vagrant
- java client
- api-x
- Review of work that happened this week:
Are we comfortable with messages emitted?
: - Progress Report on Fcrepo-Cloud-Migrator Tool
- variants in .ttl between the python export and ruby-rdf
Ticket Summaries
Please squash a bug!
Tickets resolved this week:
Tickets created this week:
Minutes
- fcr:fixity endpoint
- discussed in fcrepo leadership
- Andrew: fixity as a test case that highlights need for clear feedback and communication channels between community, tech, leaders, and committers
- tech thread and leadership thread: do we want fixity service? yes
- open discussions about resources needed to maintain this feature
- if it is important for community it should be in the spec
- github issue: https://github.com/fcrepo/fcrepo-specification/issues/373
- open question about whether there could be an additional header to RFC 3230 that returns a success/failure status
- deprecation status?
- should it be in the core? seems to be a ciritial preservation feature
- Peter: fine with moving this to a header if we can get a status header a la Andrew's GitHub issue
- Josh: agrees that this needs to be a core responsibility of Fedora
- external content wrinkle
- external content is beneficial to large content repos
- external content is not covered by current fixity
- Josh has been looking at extensions to check fixity for external content
- Bethany: copy and proxy will check fixity on new external content implementation; only redirect is left out
- could use some further testing
- Josh: how does it perform?
- Andrew: interested in the header approach
- Peter: can we use a link header for this?
- Bethany: are the spec writers talking about this?
- Andrew: no, this is why github issue has been added
- Jared: where do we store the digests? have to persist check
- external content is a bigger concern for performance
- redirect seems hard to implement
- Jared: need to store checksum where it is always available; similar to MIME type
- Peter: sounds like a server-managed triple?
- Bethany: store as a property on the binary itself?
- Jared: if server-managed triple do you return it in your graph?
- Andrew: these seem to be issues in general about server-managed triples
- Jared: the reference implementation should only implement the spec
- adding additional features to reference implementation means the spec is lacking
- Josh: API-X as an alternative to core?
- Jared: should also be discussion around the github issue
- if it is a vital part of Fedora then it should be in the spec; discuss how (MUST/MAY/SHOULD?)
- Andrew: agrees essential features should be in spec
- fixity service only answers the question of "is this resource what you think it is?"
- "self-healing repo" feature is out of scope; current/future fixity service does not address the question of "what next?"
- Jared: interested parties should speak up in comments on the github issue
- Bethany: we should send a follow-up email on the original thread(s) that highlights the github issue
- Doran: seems to be two issues: a) should we have the service? b) how should it be implemented?
- getting to 5.0
- PR for external content went in this week
- handful of issues to check
- any other 5.0 developments last week? no
- documentation updates
- ongoing effort
- Andrew: note the red X's indicating pages that need work; reviewer should add notes about what kind of changes are suggested
- Josh: can contribute to documentation effort
- are there instructions about what should be done for updates? procedure?
- Bethany: just go in and edit the 5.x versions of pages
- if you work on a page work on the whole page, or note where you stop
- Kevin: reviewer status?
- Peter: use the star
- Bethany: do we need to track who reviewed?
- Kevin: add reviewer name in the "Who?" column
- another sprint
- timeframe: July? maybe 2 sprints
- Andrew: did a Doodle go out
- no one seems to have seen a Doodle
- action: send out a Doodle to get a timeframe (Andrew)
- Andrew: 2 sprints sound good
- earliest/latest dates? July-October
- PR for external content went in this week
- messages emitted
- what do we need to do to move FCREPO-2604 along?
- Andrew: Kevin's point: does a change to a inbound reference warrant a message?
- if yes, close ticket as complete
- if no, need more work
- Josh: inbound reference shouldn't change the state of the target resource
- Bethany: agrees
- Kevin: implication is just for resources that need to know that inbound references changed
- Bethany: can we distinguish between different kinds of changes
- Andrew: we don't track individual properties, so might be weird if we track this but not individual properties
- Josh: could this be useful for indexing
- Peter: does this have enough information to be useful for indexing
- Bethany: puts the work on the client?
- Jared: can we use different ActivityStream type for these type of change messages?
- there are object/link type relationships
- makes for easier filtering
- Bethany, Peter: agree
- Andrew: requires Fedora to know that a change is due to an inbound reference
- action: new JIRA ticket to explore nature of changes before messages are emitted (Jared)
- fcrepo cloud migrator tool
- Carrick: can do an overview next week
- has anyone tried ingesting edited Turtle? not yet
- Peter: looks like RDF 1.0 to 1.1 conversion issue (explicit to implicit string type)
Actions
- Look at fcr:fixity in JIRA - creating a ticket and look at options
- See if possible option for fixity checking could be an API-X service
- Talk to API Spec group about returning fixity check result as an additional header, returned on 'want-digest'.
- Peter Eichman - See how tightly bound our current implementation is to modeshape, in regards to the fixity endpoint. Can look at at the end of next week.
- Message to list-serve to see who might be using fcrepo-java-client outside of fcrepo-camel
- Jared Whiklo - New JIRA ticket to explore nature of changes before messages are emitted
- Andrew Woods - Send out a Doodle poll to get a timeframe for next 5.0 sprints (July-October dates)