...

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

...