Date
Call-in Information
Time: 11:00 am, Eastern Time (New York, GMT-04:00)
To join the online meeting:
- Go to: https://lyrasis.zoom.us/my/vivo1?pwd=a2Q3RUVKVkN2dkNHV3FUaFRtLzhGdz09
- Passcode: 351860
One tap mobile:
US: +16699006833,,9358074182# or +19292056099,,9358074182#
Or Telephone:
US: +1 669 900 6833 or +1 929 205 6099 or 877 853 5257
Meeting ID: 935 807 4182
International numbers available: https://zoom.us/u/aeANHanzED
Slack
- https://vivo-project.slack.com
- Self-register at: http://bit.ly/vivo-slack
- Self-register at: http://bit.ly/vivo-slack
Attendees
Indicating note-taker
- Brian Lowe
- Benjamin Kampe
- Georgy Litvinov
- Michel Héon
- William Welling
- Benjamin Gross
- Ralph O'Flinn
- Don Elsborg
- Huda Khan
- Dang Vu Nguyen Hai
- Christoph Gopfert
Agenda
- List of desired development items:
- quick wins / items for a more rapid release
- collaborative items for future sprints
- (Add/edit at will) spreadsheet: https://docs.google.com/spreadsheets/d/103P9P4v6yUBSb5BnVaK40NoGx1fIYyL8uaHKUubZWbE/edit?usp=sharing
- Defining shapes or subgraphs for use in APIs, edit forms, indexes etc.
- Diagrams:
- existing architecture: https://docs.google.com/presentation/d/1raO98mklGUQgAc6wMMbgDEsHVk1zoCA3bq4Fyy21GjI/edit?usp=sharing
- Georgy: existing versus proposed
- Results of initial experiments with SHACL
- Defining concrete next steps
- Ontology model for defining form behavior?
- N3-based templates?
- Deriving indexing / display queries?
- Mapping to simplified JSON objects for data ingest
- Inspiration? William Welling: Apache Marmotta LDPath syntax https://marmotta.apache.org/ldpath/language.html
- Diagrams:
- Moving Scholars closer to the core
References
- 2019-01 Architectural Fly-in Summary#201901ArchitecturalFlyinSummary-Ingest
- VIVO in a Box current document for feedback:
Future topics
- Prioritizing and planning post-1.12 development
- Forward-looking topics:
- frameworks: Spring / Spring Boot / alternatives
- Horizontal scalability
- Deployment
- Configuration : files / environment variables / GUI settings
- Editing / form handling
- Adding custom theming without customizing build
- Post-release priorities
- Ingest / Kafka
- Advanced Role Management
- Moving Scholars closer to core - next steps
- Vitro JMS messaging approaches - redux
- Which architectural pattern should we take?
- What should the body of the messages be
- Incremental development initiatives
- Integration test opportunities with the switch to TDB - requires startup/shutdown of external Solr ..via Maven
Tickets
Status of In-Review tickets
Notes
- Dependencies between unit tests
- VIVO-2003 - Vitro unit tests fail if not run in a certain order OPEN
- Look into Spring Frameworks to help with the order of tests
- Look at dependency injection
- Maybe a static order for .1 then resolve for real in .2
- VIVO-PROXY
- Starting a collaboration with the University of Lausanne for the development of VIVO-PROXY
- Forking VIVO-PROXY Repo from UQAM to https://github.com/vivo-community/VIVO-PROXY
- Defining shapes or subgraphs for use in APIs, edit forms, indexes etc.
- existing architecture: https://docs.google.com/presentation/d/1raO98mklGUQgAc6wMMbgDEsHVk1zoCA3bq4Fyy21GjI/edit?usp=sharing
- Inspiration? William Welling: Apache Marmotta LDPath syntax https://marmotta.apache.org/ldpath/language.html
- Diagrams:
- Results of initial experiments with SHACL
- Defining more transparent N3-based templates?
- Mapping to simplified JSON objects for data ingest
- SPARQL for list views/ indexing / URI finding
- Moving Scholars closer to the core
- Build messaging system first? versus
- Original option of typing into existing document modifiers:
- Prioritizing future development items:
- quick wins / items for a more rapid release
- collaborative items for future sprints
- (Add/edit at will) spreadsheet: https://docs.google.com/spreadsheets/d/103P9P4v6yUBSb5BnVaK40NoGx1fIYyL8uaHKUubZWbE/edit?usp=sharing
- Can we get a second slide with everything Brian said?
- (I suppose we could make the slide : ) )
- Right now, the N3 patterns are defined in the JAVA generator classes, which are then processed in separate classes that do a lot of parsing of the submitted values, entering into the variables, and then assessing which N3 required strings are present, etc.
- A few years ago, we worked on a custom json simplification of this process
- It still used the processing pipelines underneath
- Is it also possible to include the Capability-map structure in the diagram?
- Don - I would also like to see this existing diagram built out a little bit more. Perhaps include some documentation on what we like or don't like for each component