Date
Call-in Information
Time: 11:00 am, Eastern Time (New York, GMT-04:00)
To join the online meeting:
- Go to: https://lyrasis.zoom.us/my/vivo1
One tap mobile:
US: +16699006833,,9358074182# or +19292056099,,9358074182#
Or Telephone:
US: +1 669 900 6833 or +1 929 205 6099 or 877 853 5257
Meeting ID: 935 807 4182
International numbers available: https://zoom.us/u/aeANHanzED
Slack
- https://vivo-project.slack.com
- Self-register at: http://bit.ly/vivo-slack
- Self-register at: http://bit.ly/vivo-slack
Attendees
Indicating note-taker
- William Welling
- Andrew Woods
- Bruce Herbert
- Ralph O'Flinn
- Brian Lowe
- Michel Héon
- Don Elsborg
- Huda Khan
- Benjamin Gross
Agenda
- Community questions
- Update from VIVO Leaders meeting
- Don Elsborg : Explore using the i18n files to store local institutional RDF label and description changes.
- Current community sprint updates?
- ORCID
- Kafka
- Messaging
- 1.11.2 patch release
- Working towards 1.12
- To be reviewed
- Documentation needed
- 1.12 release planning
- Code freeze once i18n tickets are merged into the sprint-i18n branch (Jan 20th)
- Sprint to test merge of sprint-18n into master: week of Jan 25th
- 1.12 release candidate #1: Feb 1st
- Two week RC-1 testing period
- For each subsequent RC-2 (if required), adding another two weeks to the schedule
- Do we want the `war` install in 1.12? -
- To be reviewed
- Tickets that should be close to merge
- Post-i18n priorities
- VIVO-in-a-box
- Messaging
- Moving Scholars closer to core - next steps
Future topics
- Vitro JMS messaging approaches - redux
- Which architectural pattern should we take?
- What should the body of the messages be?
- Renaming of 'master' branch? (ZDNet, BBC)
- Guidance from GitHub
- DSpace has done it
- Fedora has done it
- Samvera is doing it
- Incremental development initiatives
- Integration test opportunities with the switch to TDB - requires startup/shutdown of external Solr ..via Maven
Tickets
Status of In-Review tickets
Notes
Community questions
- Error when trying to link a person with a grant
- Juan has provided some information. VIVO is swapping some variables in his instance. The error has not been reproduced by developers. It is a URI variable. Brian: maybe he has a invalid URI that is being used later. The value is not substitutable.
- Is there a SPARQL query that Juan could run? Brian suggested a query.
- ASK { <http://purl.obolibrary.org/obo/RO_0000053> owl:inverseOf <http://purl.obolibrary.org/obo/RO_0000052> }
Leadership Group approved next release schedule
The schedule:
- Final review and merge of the i18n into the core codebase - One week-long sprint during the week of Jan 25th
- Publication and community testing of a release-candidate (RC-1) - Two week-long period of community testing from Feb 1st through Feb 12th
- Iteration based on community testing (RC-2, RC-3, etc) - Each iteration will be another two weeks. We should expect at least an RC-2, maybe more.
- Final release of VIVO 1.12 - Optimistically, early March
Leadership Group applauded the strong UQAM and TIB contribution.
Michel, Brian, Benjamin, and William all can contribute to the sprint.
Don Elsborg : Explore using the i18n files to store local institutional RDF label and description changes.
Discussion: can i18N be used to create local labels aligned with institutional context. Don talked about need at UC Boulder. Michel thought this was not good practice. Brian had an idea that would take more development effort. Short term solution is update to VIVO file and then make changes there. At TAMU, we use the UI to customize the ontology.
- E.g. labels from this file I think: https://github.com/vivo-project/VIVO/blob/master/home/src/main/resources/rdf/display/firsttime/PropertyConfig.n3
- New labels with @en-US tags: https://github.com/vivo-project/VIVO-languages/blob/sprint-i18n/en_US/home/src/main/resources/rdf/i18n/en_US/display/firsttime/PropertyConfig_en_US.nt
Don: asked that when an upgrade to newer version of VIVO, are local changes preserved? Brian explained that it depends. Andrew suggested that the release notes contain instructions to address this potential issue. Benjamin: The current 3rd tier process would still work, but there are some new files that will need to be overlaid (see difference between two propertyconfig files above)
Brian suggested a potential solution.
- Have a separate directory (following on the first time change detection work ongoing) that will detect triples we want to overlay.
- Changes are made and then the software lays over the graph.
- Benjamin: This would be nice since we would only need to track our specific changes, rather than having to totally overlay the file that contains the one or two changes we want to make.
Current community sprint updates
- ORCID
- Kafka
- Messaging
Actions