...
- Unknown User (escowles@ucsd.edu)
- Nick Ruest
- A. Soroka
- Unknown User (acoburn)
- Michael Durbin
- John Doyle
- Jared Whiklo
- Yinlin Chen
- Andrew Woods
- David Wilcox
- Osman Din
- Unknown User (daniel-dgi)
Agenda
- Current priorities
- fedora 3 to 4 migrations
- etags
- blank nodes
- fixity service redesign
- LDP: point-like objects, align with spec
- Java 8 refactor
- move towards API standards (memento? webac?)
- Open Repositories planning (committer meeting)
- Islandora / F4 migration update
- XML Forms special meeting
- migration-utils work
- auditTrail mappings – are we good to proceed?
- Blank node issue (updating existing bnodes) vs. autocreated IDs
- Next week's call
- ...
...
- Current Priorities
- There doesn't appear to be enough engagement to get to most of these priorities.
- can we narrow our focus or develop a strategy?
- Unknown User (escowles@ucsd.edu) thinks blank nodes need to be addressed soon. While users may be happy with the reversion, there real issues that prompted us to move forward before still exist.
- A. Soroka expressed that the "satisfied customers" are not satisfied with blank nodes, but with automatically generated resource IDs.
- Andrew Woods stated he though the requirement was that people be able to ingest "blank nodes" and then be able to edit them.
- A. Soroka reemphasized that he though that the current implementation is not truly a blank node as mutating these "blank nodes" made them "named resources" and resulted in a very tricky implementation.
- adding support for blank nodes that cannot be altered is relatively easy to implement and doesn't stretch the model
- immutable blank nodes would satisfy the XML-ish RDF constructs that appear to be the main/only use case.
- Unknown User (acoburn) asked whether one could remove one of several blank nodes with the same identifier (ie, "dc:creator")?
- A. Soroka indicated that it was difficult, but doable. One possibility is that when you skolemize the blank node coming in, you create a determinant hash fragment that would be recreated identically when a request to delete that blank node came in.
- There was some consensus that focusing on hash URIs would be a constructive approach.
- Andrew Woods suggested that some other items on the list (fixity redesign, etags) would bring us closer to LDP spec and that they're sort of broken now, and fixing them might be a priority.
- Unknown User (escowles@ucsd.edu) advocated for the etags, blank nodes and fixity service be considered "working", but in need of improvement and roughly the same priority.
- The migration work seems to be under control.
- Java 8 refactor is largely ready to go, but requires a pretty thorough multi-person review and testing (ie, a cursory code review would not suffice)
- we need to commit several people to this or we loose a lot of work we've already done
- we may not have critical mass to merge it in and hope things are resolved though use... but would be risky before open repositories.
- No one seemed to think there was anything missing from this list, so Andrew Woods thought he'd try to pick out a few items and rally some focused effort on them.
- Jared Whiklo suggested that since the Java8 stuff was largely done, it might be the best ROI.
- Unknown User (escowles@ucsd.edu) thinks blank nodes need to be addressed soon. While users may be happy with the reversion, there real issues that prompted us to move forward before still exist.