Date

Call-in Information

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

To join the online meeting:

Slack

Attendees

(star)  Indicating note-taker

  1. Dragan Ivanovic 
  2. Brian Lowe  (star)
  3. Georgy Litvinov 
  4. Michel Héon
  5. Benjamin Gross 
  6. Benjamin Kampe
  7. Veljko Maksimovic 
  8. William Welling 
  9. Kevin Day 
  10. Huda Khan 
  11. Fadwa Alshawaf

Agenda

  1. Questions/Issues/Pull requests/Announcements
    1. CRIS conference with VIVO track
      1. call for proposals extended - March 13th, 2022
    2. PR for resolving Vitro deployment issue - https://github.com/vivo-project/Vitro/pull/269 
    3. PR for supporting 2+ listeners - https://github.com/vivo-project/Vitro/pull/275
  2. DSpace-VIVO integration
    1. The project has been started
  3. 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

Notes

  1. Questions / announcements
    1. One new pull request for resolving independent Vitro deployment issue
      1. Needs to be reviewed by two reviewers.
      2. William: was part of a merge commit to fix the VIVO release.  Will this fix Vitro but break VIVO release again?
      3. Georgy: VIVO had the war option already, but in the Vitro installer it was changed from war to pom, causing the Vitro installer to break.  Ralph wasn’t sure whether that commit was related to fixing the VIVO release process.  New PR has been discussed with Ralph on committers call; he will review.
    2. Second pull request for (re)supporting multiple listeners.
      1. Already reviewed/merged on main branch and sprint branch
  2. February Sprint / Dynamic API
    1. API class needs to be added to the ontology 
      1. Dragan: Needs object property links to RPC / REST resources?
      2. Georgy: No.  Can get directly from the model.
      3. Dragan: Binding to Java beans?
      4. William: Use same ConfigurationBeanLoader.
      5. Dragan: In one VIVO instance there may be more than one API version, so there would be more than one instance of the API ontology class.
      6. William: Need a REST description for each version/resource combination. Could generate one large one or multiple interlinked descriptions
      7. Georgy: We had discussed moving configuration to the triple store to avoid needs for restarts.
      8. Dragan: We discussed introducing new model for dynamic API actions.
      9. Georgy: Should be accessible.  Makes sense to leave them in one model.
      10. (discussion of generating YAML specification from RDF annotations such as rdfs:label)
      11. Michel: Original intent was to write YAML first and then generate interfaces automatically.
      12. William:  Here we just want it to describe the API already built in RDF.  We still get value from the YAML here in auto-generating clients.
      13. (discussion of Swagger HTML and desirability of being able to navigate hierarchically instead of scrolling through one giant page)
      14. Dragan: Conclusion:  need to investigate what is needed for YAML file and make necessary ontology additions to support multiple versions.
        1. William: no longer using partOf to indicate what resources are part of an API?
        2. Georgy:  Only really need data property for latest version on each resource; figure out from this which version each belongs in.
    2. Dragan: Close to having meaningful ontology for the API actions.
    3. Dragan: (Overview of bean loader.)  Ongoing activity; some issues are closed and others are in process.
    4. Dragan: Execution of steps – needs more development
      1. N3 template processing
      2. Logging of steps / error detection and recovery
    5. Low-priority issues (unlikely to be implemented during this sprint)
      1. User interface
      2. Validation of custom actions

Draft notes on Google Drive

Task List