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
One new pull request for resolving independent Vitro deployment issue
Needs to be reviewed by two reviewers.
William: was part of a merge commit to fix the VIVO release. Will this fix Vitro but break VIVO release again?
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.
Second pull request for (re)supporting multiple listeners.
Already reviewed/merged on main branch and sprint branch
February Sprint / Dynamic API
API class needs to be added to the ontology
Dragan: Needs object property links to RPC / REST resources?
Georgy: No. Can get directly from the model.
Dragan: Binding to Java beans?
William: Use same ConfigurationBeanLoader.
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.
William: Need a REST description for each version/resource combination. Could generate one large one or multiple interlinked descriptions
Georgy: We had discussed moving configuration to the triple store to avoid needs for restarts.
Dragan: We discussed introducing new model for dynamic API actions.
Georgy: Should be accessible. Makes sense to leave them in one model.
(discussion of generating YAML specification from RDF annotations such as rdfs:label)
Michel: Original intent was to write YAML first and then generate interfaces automatically.
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.
(discussion of Swagger HTML and desirability of being able to navigate hierarchically instead of scrolling through one giant page)
Dragan: Conclusion: need to investigate what is needed for YAML file and make necessary ontology additions to support multiple versions.
William: no longer using partOf to indicate what resources are part of an API?
Georgy: Only really need data property for latest version on each resource; figure out from this which version each belongs in.
Dragan: Close to having meaningful ontology for the API actions.
Dragan: (Overview of bean loader.) Ongoing activity; some issues are closed and others are in process.
Dragan: Execution of steps – needs more development
N3 template processing
Logging of steps / error detection and recovery
Low-priority issues (unlikely to be implemented during this sprint)