Versions Compared

Old Version 2

changes.mady.by.user Brian Lowe

Saved on

compared with

New Version 3

changes.mady.by.user Brian Lowe

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: rearrange things mangled in copy/paste

...

  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
      .
    1. Already reviewed/merged on main branch and sprint branch
    2. CRIS call for submissions extended to March 13th
      1. .
    3. One new pull request for resolving independent Vitro deployment issue
    2. Second pull request for (re)supporting multiple listeners.
      1. Already reviewed/merged on main branch and sprint branch
  4. 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.
      1. N3 template processing
      2. Logging of steps / error detection and recovery
    1. User interface
    2. Validation of custom actions
    5. API class needs to be added to the ontology
    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

...