Date
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
- Dragan Ivanovic
- Benjamin Kampe
- Matthias Lühr
- Veljko Maksimovic
- Georgy Litvinov
- Brian Lowe
- William Welling
- Kevin Day
- Benjamin Gross
Resources
Agenda
- Organization proposals
- Split issues into smaller pieces → make smaller PRs ( maybe without creation of new github issue for each PR ) - less conflicts, faster reviews, better commit history
- Two meetings a day (standups with discussions for peope in different 3pm EST and 10pm EST) ?
- Simplier PR template for small sprint PRs ? link to issue, description of improvement
- All issues and PRs are with regular VIVO PRs and Issues. Any way to improve it in future?
- Tickets - https://github.com/orgs/vivo-project/projects/2/views/1
- Ontology
- changes
- restAPI
- REST endpoint
- version
- HEAD or part of url
- minVersion
- restAPI pool (and change in the ontology)
- version
- SolrQuery or SeachEngineQuery
- N3Template
- should that be parameterProvider or not???
- Testing strategy
- Ontology
- Blockers
- PRs - https://github.com/vivo-project/Vitro/pulls
- Documentation - VIVO Dynamic API
Slack stand-up template
[VIVO Dynamic API Standup]
Finished yesterday:
{ticket titles and associated GitHub links}
{AND please include brief textual description}
Working on today:
{ticket titles and associated GitHub links}
{AND please include brief textual description}
Blockers:
{brief textual description}
Notes
- Organization proposals
- Split issues into smaller pieces → make smaller PRs ( maybe without creation of new github issue for each PR ) - less conflicts, faster reviews, better commit history
- Two meetings a day (standups with discussions for peope in different 3pm EST and 10pm EST) ?
- Simplier PR template for small sprint PRs ? link to issue, description of improvement
GL: Briefly described his idea to try to be more effective in adoption of contribution
WW: Priority to Vitro core contribution for reviewing, because it might impact on-going tasks
GL: daily meetings for discussion about critical decisions. WW: Suggested Monday, Wednesday and Friday meeting at 10am Eastern Time. Others accepted this suggestion.
WW: We can relax PR review process, because we are using staging branch
WW: Test coverage should be improved
DI: Small PRs please, description of PRs might be simplified, please post the message in the slack when some PR is ready to be reviewed. Anyone participating in the sprint can be a reviewer, but only VIVO committers can merge PRs.
We merged three PRs during the call, and analyzed two more. SolrOperation and ResourcePool PRs are not yet ready to be closed. SolrOperation likely works for both Solr and ElasticSearch, but we decided to keep the name SolrOperation, because testing of this component for ElasticSearch is not covered yet, and majority of VIVO instances are using Solr engine. ResourcePool should be improved to support minRESTAPIversion, at the moment minRESTAPIVersion is part of the key, but it is not checking range, just the exact api version.
- Tickets - https://github.com/orgs/vivo-project/projects/2/views/1
- changes
- restAPI
- Ontology
Not necessary to add restAPI class in the ontology, we discussed how to resolve issues without this extension. Basically, we will try to modify the ontology as little as possible, because it might impact a lot of ongoing tasks' implementations.
- REST endpoint
- HEAD or part of url
- version
Probably part of url, but William suggested to read the short document at https://www.xmatters.com/blog/blog-four-rest-api-versioning-strategies/ provided by Matthias.
- minVersion
We discussed the implementation of resourcePool to support min and maxRESTAPIVersion, the idea and benefit clear, the implementation a little bit complex, but probably feasible, if not we can simplify that for this sprint by adopting minRESTAPIVersion as an exact version.
- restAPI pool (and change in the ontology)
resourcePool will be adjusted, we are not going to introduce restAPIPool.
- SolrOperation or SeachEngineOperation
SolrOperation for now, we can think about testing and supporting ElasticSearch later. GL: how is a query specified? VM: JSON format. GL: Is that complicated and error-prone for creation?
- N3Template
- should that be parameterProvider or not???
N3Template will be just parameterReceiver, if uri of newly created individual is needed for follow-up steps, firstly SPARQL Operation, a parameter provider, will create an empty individual with uri, and N3Template just fill it in with data.
- Testing strategy
We need improvement of testing strategy for VIVO, this might be good moment to start working on that. DI will create an issue in RCP endpoint track for defining testing strategy (and also testing endpoint). KD will work on that. The goal is to have real integration tests, which are not present at the moment in VIVO/Vitro.
- Blockers
OperationData is a high priority issue. WW: How resource_id from the path should be mapped to Operation data? Which structure should be used? GL: A map or something similar. DI: We should try to define the design of OperationData at the Monday meeting.
