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. Georgy Litvinov 
  3. Brian Lowe 
  4. Benjamin Kampe 
  5. William Welling
  6. Michel Héon 
  7. Huda Khan (star)             
  8. Jose Salm
  9. Veljko Maksimovic 

Agenda

  1. Questions/Issues/Pull requests/Announcements
    1. VIVO 1.13.0 has been released
      1. VIVO 1.13.0 Release Announcement
      2. https://github.com/chenejac/VIVO-release-publisher
  2. Dynamic API
    1. Need more design 
      1. not ready for further implementation for the forthcoming sprint
    2. A separated task force led by Georgy Litvinov 
      1. Dynamic API Task Force
  3. VIVO development fund - https://docs.google.com/document/d/1k_fzP8O59Um1FnePje7JKGlKzfqv4dzxgYN4oqPCpu8/edit?usp=sharing
  4. DSpace-VIVO integration further steps
    1. Assets storage component - https://docs.google.com/document/d/1bYRH4fl4ubOoq6KmxCxGSofHRd9iF7m7gV2tDZDUJYs/edit?usp=sharing
  5. The next sprint
    1. When?
      1. 19.09. - 07.10. 
    2. What?
      1. 2022/2023 VIVO Releases Planning
        1. I18n
          • Language-aware autocompletion
            • done
          • Internationalized browse sorting
            • done
          • Moving properties labels to rdfs
            • generator
          • Adopting of online label editor to work with rdf files
          • Find solution for syntax differences between languages that does not require template customization per language
            • find problematic labels
            • decouple to parts in free marker templates
            • translate
          • Reviewing translations for French, Germany, Spanish, etc.
    3. Who?
      1. https://forms.gle/qLi1PhRrrpvUrrYRA
    4. Infrastructure
      1. Wiki page
      2. GitHub project board
      3. slack private channel

Notes

  1. Questions/Issues/Pull requests/Announcements

    1. VIVO 1.13.0 has been released
      1. VIVO 1.13.0 Release Announcement
      2. https://github.com/chenejac/VIVO-release-publisher 
        1. Dragan made this in his account but maybe we can move it later to VIVO community or create GitHub actions in VIVO project
        2. Three scripts
          • + one configuration file (Version, release candidate number, etc.)
          • Using these parameters, first script will create release candidate
            • A wiki page for release testing + google forms should be created
              • Testing
              • If there is some issue, opening GitHub issue, resolving, pull request, reviewing, merging, running the first script again for release candidate 2
          • The second script should publish GitHub release, and sonatype release
            • A wiki page for release announcement 
            • Sonatype needs manual check and click on publish release
              • might be removed in the future (can be configured in pom files)
          • The third script for cleaning up tags/branches and merging to main branch (new snapshot version number in pom files)
      3. Dragan: William’s suggestion for first script as GitHub action, Second as Docker.  
        1. William: Great start for now
      4. Dragan: Will work on script. Then come back to review scripts, and perhaps set up to try for next release. 
  2. Dynamic API
    1. Need more design for UI
    2. A separated task force led by Georgy Litvinov 
      1. Dynamic API Task Force
        1. Task force creation
      2. Given need for more design work in UI, dynamic API not ready for further implementation for the forthcoming sprint
      3. Needs more work and need to slow down implementation on the API while we work on the UI portion
        1. William: Suggest a spike (agile methodology term about team working on documentation and proof of concept around functionality, with deliverable of work being the documentation/proof of concept itself)
      4. Georgy: Separate meeting to work on dynamic API.  Components, work needed.  Need to have time for planning, which is something we don’t always have during regular sprint cycles. 
        1. Takes time to review existing architecture and understand how to implement new architecture.  Sprint has time constraints.  Developer meeting can’t focus only on dynamic API.  A separate task force/dedicated meeting would be helpful.
  3. DSpace-VIVO integration further steps
    1. Assets storage component - https://docs.google.com/document/d/1bYRH4fl4ubOoq6KmxCxGSofHRd9iF7m7gV2tDZDUJYs/edit?usp=sharing
    2. Dragan: In this context, need to have VIVO be able to ask to store a file/resource in DSpace. But it would need some specific code.
    3. Williman: DSpace upload may be involved.  May need item submission workflow which requires an existing item for a resource to be uploaded.  Datasets often don’t go into DSpace storage and would be elsewhere.  Also, supplemental data may be very large, and often go into another repository (e.g. DataVerse etc.).  Requires planning on what type of integration.  If we just want a link between VIVO author and links within DSpace - not sure about uploading a file through VIVO to DSpace.
    4. Dragan: If you’re a researcher, if you login, seems like a complicated workflow to first have to upload your publication in DSpace and then come back to VIVO and enter a link to DSpace item. 
    5. William: Often, DSpace will have a curator/repository admin who controls what can be saved within DSpace. 
    6. Dragan: Considering asset management component in VIVO which enables a common interface which could be implemented for multiple linked storage solutions (e.g. DSpace, Fedora, etc.)  There may be a workflow around what can be submitted etc. 
  4. The next sprint

    1. When?
      1. 19.09. - 07.10. 
    2. What?
      1. 2022/2023 VIVO Releases Planning
        1. I18n
          • Language-aware autocompletion
            • done
          • Internationalized browse sorting
            • done
          • Moving properties labels to rdfs
            • generator
          • Adopting of online label editor to work with rdf files
          • Find solution for syntax differences between languages that does not require template customization per language
            • find problematic labels
            • decouple to parts in free marker templates
            • translate
          • Reviewing translations for French, Germany, Spanish, etc.
    3. Who?
      1. https://forms.gle/qLi1PhRrrpvUrrYRA
    4. Infrastructure
      1. Wiki page
      2. GitHub project board
      3. slack private channel
    5. Notes
      1. Originally, in January, we wanted to have two sprints in the year
      2. Dragan: Since Dynamic API may need extra work (design spikes etc.), suggesting we work on a different topic for this sprint, such as internationalization.  Perhaps we do Dynamic API work in the December sprint, or we use the task force approach to focus on the Dynamic API work. 
      3. Internationalization
        1. Michel: Interested in this
          • In French context, would be useful to add French abstract text with option to add English text
            • Dragan: French would be default in French context.  This would provide option to also add abstract in English using language options.  
        2. Benjamin K: Also interest in Germany to work on i18n work
        3. Dragan: Michel and Benjamin, would you be interested in participating this sprint as well
          • Michel and Benjamin: yes
      4. William: Multiple repositories for i18n work seems to complicate process.  Any thoughts on bringing together language work into a single repository?
        1. Michel: Agree but problem is language specific properties file in directories.  If we merge all properties into ontology file, then could solve this issue.  Second issue is Freemarker files that are language specific.   
      5. Dragan: For moving from properties file to RDFS, would there be changes in how we read etc. the info?
        1. Brian: The templates themselves should not be affected. More a matter of reading info out from RDFS
      6. Dragan: Do we already have an ontology defining how we would store labels for properties, etc.?
        1. Michel: No but it should be straightforward
        2. Brian: Would be useful to do that in the week prior to the sprint so that the sprint time would be more productive
        3. Michel: “I volunteer as tribute!" (Paraphrased of course. He said he’d work on this)
        4. Dragan: Will create project board, wiki, etc. to define goals, etc. and announce to community
      7. Dragan: Considering the dates.  Two weeks? 
        1. Michel: Seems short.  Will review calendar. 
      8. Dragan: For next Tuesday, Michel will have thought about the ontology work and we can then decide when to start the sprint. 

Draft notes in Google Docs

Task List

  • Dragan Ivanovic will bring up with leadership group that we would like to set up task force for dynamic API
  • Dragan Ivanovic will create infrastructure for the next sprint (slack channel, GitHub project board, wiki page, GitHub branch, GitHub issues, etc.)
  • Michel Héon to work on the ontology for UI labels (in multiple languages)
  • All to think about dates for the next sprint

Previous Tasks 

  • No labels

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