Date

Call-in Information

Time: 10:00 am, Eastern Time (New York, GMT-04:00)

To join the online meeting:

  • https://lyrasis.zoom.us/j/84378615572?pwd=bGUxSjlyRTdjOGl5U1B6L0Yva3RQdz09

    Meeting ID: 843 7861 5572
    Passcode: 556561
    One tap mobile
    +16699006833,,84378615572#,,,,*556561# US (San Jose)
    +19292056099,,84378615572#,,,,*556561# US (New York)

    Dial by your location
            +1 669 900 6833 US (San Jose)
            +1 929 205 6099 US (New York)
            +1 253 215 8782 US (Tacoma)
            +1 301 715 8592 US (Washington DC)
            +1 312 626 6799 US (Chicago)
            +1 346 248 7799 US (Houston)
            877 853 5257 US Toll-free
            888 475 4499 US Toll-free
    Meeting ID: 843 7861 5572
    Passcode: 556561
    Find your local number: https://lyrasis.zoom.us/u/kerqtGDrJ4

Slack

Attendees

(star)  Indicating note-taker

  1. Dragan Ivanovic  
  2. William Welling  
  3. Benjamin Kampe 
  4. Andreas Czerniak
  5. Veljko Maksimovic (star)
  6. Huda Khan 
  7. Michel Héon 

Agenda

  1. Questions/Issues/Pull requests
    1. Log4j  severe vulnerability 
      1. How to mitigate the Log4Shell (CVE-2021-44228, CVSSv3 10.0) vulnerability
      2. https://github.com/vivo-project/vivo-solr/pull/5
  2. VIVO - DSpace integration project
    1.  Call for Interest: Integrating DSpace with VIVO
    2. https://docs.google.com/presentation/d/173s_8rOJEmZwi60POuLxaFjtpQo-88UTFxwIVrP9KDA/edit?usp=sharing
  3. The preparation for the February sprint
    1. Wiki page
      1. 2022 - VIVO Sprints
        1. https://forms.gle/GKBCDznBF2KtsEQR7
    2. Date for the sprint
      1. February 21st - March 11th
    3. Georgy's document - https://docs.google.com/document/d/1vtNIVEYWdBgV11N-wiPk_UNKpiFQ4sKetJ8elJ6xy2E/edit#heading=h.k389x4cotzuw
  4. A short vacation 
    1. 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.

Draft notes on Google Drive

Task List



  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.