Date

22 Feb 2022

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

• https://vivo-project.slack.com
  • Self-register at: http://bit.ly/vivo-slack
    

Attendees

 Indicating note-taker

1. Dragan Ivanovic 
2. Brian Lowe  
3. Georgy Litvinov 
4. Michel Héon
5. Benjamin Gross 
6. Benjamin Kampe
7. Veljko Maksimovic
8. William Welling 
9. Kevin Day 
10. Matthias Lühr
11. Ralph O'Flinn 
12. Florian Kotschka

Agenda

1. Questions/Issues/Pull requests/Announcements
   1. Call for Interest: Integrating DSpace with VIVO
      1. The team selected, announcement published
      2. planning of the Kick-off meeting
      3. planning to present at the Open Repositories 2022 conference
   2. CRIS conference with VIVO track
      1. call for proposals closed
2. The February sprint
   1. Project board - https://github.com/orgs/vivo-project/projects/2/views/1
   2. Branches - https://github.com/vivo-project/Vitro/tree/sprint-dynapi-2022-feb-staging
   3. PRs - https://github.com/vivo-project/Vitro/pull/260, https://github.com/vivo-project/Vitro/pull/259, https://github.com/vivo-project/Vitro/pull/258
   4. LoopStep
   5. Request Body structure
   6. Response structure

Notes

Members for  DSpace-VIVO integration have been selected and announced. CRIS proposals are closed, but since there don't seem to be a lot of papers submitted for VIVO track, people can probably still submit something if they have.

Sprint started yesterday. Dragan went over the Github sprint Board, explaining his logic behind the grouping of the tasks within tracks. Each track has an overarching ‘Task container/’Epic’ which should be auto-completed once all the tasks in that track are finished.

There is currently a problem with self-assigning of tasks. Some Developers can't assign themselves to the tasks they are doing.

Definition of the OperationData and OperationResults still needs to be done and clarified. William suggests a flat JSON structure, or to use XPATH to define which part of a JSON should be mapped to a parameter of a particular step. Georgy suggests flat structures, just name and value pairs, where names of the JSON fields should correspond to existing parameter names. After that, ParameterType and Validetors linked to the parameter will be applied to check the value passed within JSON.

Parameter names don't have to be unique, but their URI has to be. If we want to generate URI from the parameter name automatically, inside the code, we need to take this into account.

William and Georgy discussed whether JSON structure should be as simple as it can, just the names of input parameters and their values, or should the JSON structure reflect the structure of the action and steps within it. One of the arguments for detailed structure is that it would be easier to generate front end forms with front end validations if the json contains more information.

Dragan asked if we can provide a REST endpoint that would, for a given action, return the json of its internal structure.

How do parameters produced by steps/operations map to fields/properties of the OperationResult object. It is important for calculating the input needed for the action. On the same topic, should we compute those needed input parameters each time someone wants to invoke the action, or should they be stored within RDF. The computing of the variables is necessary for generating OpenAPI spec, so it should be marked as a blocker task.

If we want to support loops, we need to change ConfigurationBeanLoader. William suggested also to change the algorithm that goes through all the possible permutations of ‘#’ within URI, and checks whether such a Resource exists inside the triple store.

Draft notes on Google Drive

Task List