...
Attendees
Indicating note-taker
- Brian Lowe
- Dragan Ivanovic Georgy Litvinov
- William Welling
- Benjamin Kampe
- Matthias Lühr
- Andreas Czerniak
- Veljko Maksimovic
- Huda Khan
- Serbajit Dutta
- Florian Kotschka
- Michel Héon
Agenda
- Questions/Issues/Pull requests
- VIVO - DSpace integration project
- The preparation for the February sprint
- Wiki page
- Date for the sprint
- February 21st - March 11th
- Georgy's document - https://docs.google.com/document/d/1vtNIVEYWdBgV11N-wiPk_UNKpiFQ4sKetJ8elJ6xy2E/edit#heading=h.k389x4cotzuw
- A short vacation
- The next meeting - January 11th, 2022
Notes
First 10 minutes were dedicated to talking about migration to spring boot which was started. Also Dragan and William talked about the need to produce wars for tomcat deployment, or to maybe move to a self-executable jar containing embedded Tomcats.
Open VIVO is currently down because of the log4j security bug.
Dragan presented the project to integratie VIVO with DSpace. Applications should be sent quickly since the deadline is January 17th. One of the goals is to enlarge the VIVO community by “merging” it with a larger DSpace community. Another one is to test a paid development model for later VIVO development. Some institutions use both VIVO and DSpace, so some tasks are duplicated because people need to submit their work separately to VIVO and DSpace. This should be streamlined. The project is to be carried out in 2 phases. People who get selected for phase 1 will probably have an advantage within the phase 2 selection process. The budget for the phase 1 will be between 6000 and 10000 dollars. It would be great to have at least one vivo core developer as a part of the team, and maybe 1 or 2 developers who are not yet active vivo contributors. Phase 2 will have a bigger budget, probaby 2 times bigger.
Implementation of Phase 1 should take place between Feb 14th and May 14th. This might be subject to change since we also plan to have a sprint in February.
William thinks we should have more implementation details outlined.
Dragen: Within Phase 1 nothing should be changed within the DSpace codebase. All of the integration should be initiated and done within VIVO. DSpace has an API exposed which should be used from VIVO to load files from DSpace.
William asks if we are going to use REST contracts for communication between the two systems as opposed to message queues. He raised a few concerns about this approach and tight coupling it would create between 2 systems. He also mentions that DSpace has metadata for its schemas that could be easily mapped to the VIVO triplet model. The problem with REST api is that all of the communication will be initialized from VIVO. What happens if something changes inside the DSpace? How will VIVO sync its data if DSpace does not invoke any kind of event that VIVO will react to? Does VIVO need to scan the entire DSpace periodically to see if anything changed? That could be a problem.
Michel suggests having two separate VIVO instances, one instance just for validating data.
Some VIVO users say they need to separate user data into private and public. Only the public data would be accessible and visible from the VIVO GUI webapp. Michel suggests having two different triple stores, one for open/public data, and another one for private. Later, authorized users would be able to execute queries on both triple stores, while unauthorized users would only be able to access public triple stores.
Task List
- Dragan Ivanovic - to mitigate log4Shell vulnerability at openvivo and to start openvivo
- All - to consider participation in the DSpace-VIVO project (and to apply by sending an email to vivo@lyrasis.org).
- All - to review/update Sprint - Dynamic API based on an ontology wiki page
- All - to consider to register and participate in the sprint. Registration is here: https://forms.gle/LQjiyMFd1NL3B63v5
- All - to review Roadmap 1.x document and provide comments
- All - to review VIVO development priorities and provide comments
- All - Add comments to Georgy's document
...