Date
Call-in Information
Time: 11:00 am, Eastern Daylight Time (New York, GMT-04:00)
To join the online meeting:
- Go to: https://duraspace.zoom.us/j/823948749
- Or iPhone one-tap :
- US: +14086380968,,823948749# or +16468769923,,823948749#
- Or Telephone:
- Dial(for higher quality, dial a number based on your current location):
- US: +1 408 638 0968 or +1 646 876 9923 or +1 669 900 6833
- Meeting ID: 823 948 749
- International numbers available: https://duraspace.zoom.us/zoomconference?m=Qy8de-kt6W4fMMDQCAV_3qfH1W-lxAo5
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
- Don Elsborg
- Huda Khan
- Brian Lowe
- William Welling
- Benjamin Gross
- Mike Conlon
- Quinn Hart
- Andrew Woods
- Steven McCauley
- Ralph O'Flinn
Agenda
- Adding CheckStyle to the VIVO/Vitro codebase
- Discussion:
- Landing Design - External Search
- New feature: Messaging
- Based on the IndexingChangeListener pattern
- Potentially with RDF-Patch bodies
- vivo-docker2: pull request: Added initial VIVO configuration
- VIVO Scholars Task Force sprint update
- TAMU Scholars / VIVO Scholars Entities
- Next week: Cineca demonstration of facet search and other UI updates
Other topics
Tickets
Status of In-Review tickets
Received
Bugs (1.11)
Notes
- Redhat is the steward of oppenjdk 8 and 11
- 1. Andrew: CheckStyle: attempt at normalizing the codebase with a documented and enforced CheckStyle.
- Include DuraSpace checkstyle (https://github.com/duraspace/codestyle/blob/master/README.md#code-style-guide)
- Suppress all the rules.
- Incrementally enable (unsuppress) rules that we agree to.
- Proposed approach:
- CheckStyle for VSCode: https://github.com/jdneo/vscode-checkstyle
- Ralph has clairvoyantly already downloaded this 🔮✨
- General agreement that we should do this.
- 2. Suggestion: Separate vivo ontology into its own Git repository (vivo.owl file and possibly others), and pull into VIVO as a dependency. Make changes to OWL file and version it separately.
- For now, it is a single file.
- Mike: This would be a repo in the VIVO project. When people ask about the ontology, just send them to the ontology repo. Ontology group is moving forward with large-scale effort to re-model the ontology (significant changes). Will involved multiple dependent ontologies, references to existing ontology, and tooling. Not an incremental change. This work may not be done in the same repository.
- Andrew: What relationship do we anticipate between the current ontology used in the codebase and this rewrite?
- Mike: The current VIVO ontology (vivo.owl) is relatively frozen; requests for improvements have been back-burnered. We will continue to make this ontology available for people who want it. In order to truly develop the ontology, however, we need a new ontology that is 100% decoupled. Then there will be a project that can do ontology work and produce ontology releases. This will be the ontology that is actively maintained.
- Don: VIVO is a “model-driven” project. How does this new ontology work enable VIVO to continue to be a model-driven software project, and what role will developers play? Sounds like the ontologists are cutting us loose.
- Mike: Ontology does not need to be readable by a developer. Just need to be able to map to the things a developer needs to do their job.
- Ralph: JSON representation first step in that direction.
- Mike: Ontology can/should/will be mapped. Should be an ontology for scholarship; there should also be a data model. They are two different things. The correct ontology may not be easy to use in a performant application; that’s a software engineering problem. Don’t attempt to fix by changing the ontology. A triple store, however, will always be a good place to ask questions that haven’t been asked yet.
- It seems like BFO and context node abstractions introduced a lot of overhead and made the ontology less readable.
- Mike: Another giant group of use-cases, thoughts. “Connect. Share. Discover.” Share means use a common vocabulary/representation. When I look at what’s happening in research data sharing, it’s moving toward RDF because everyone can understand it. There are ontologies underneath and everyone can understand what it means. Ontology and triples are how sharing gets done. Meanwhile, we need a performant application and this will probably require a document database like ElasticSearch.
- Andrew: Ideally, VIVO application plays a role in facilitating the sharing, so it needs to adopt the new VIVO ontology at some point.
- Mike: Right. That’s why there are three phases. Second is tools and training. Multi-year, large-scale effort.
- Don: What I’m concerned with is how to represent things that are complex in a way that are readable. Simple predicates, e.g. “X taught Y”. Is there a way to use SWRL or similar rules to generate shortcut properties?
- Mike: Yes, there is a lot of opportunity here.
- Benjamin: I don’t think it’s unreasonable to expect that VIVO developers will react to ontology changes. Scary to hear about a new ontology. Would warn against completely decoupling and not informing developers.
- Mike: The decoupling is purely technical, not a way for the community to work.
- Mike: Read and comment on the one-pager.
- One pager http://bit.ly/2GYZ3n9
- White paper http://bit.ly/2R8gYuI
- Andrew: Proposal:
- 1. Pull vivo.owl into its own Git repository.
- Don: I would like to think this through because we use a three-tier build process. If we override something in vivo.owl, how will that be managed? Could be a good opportunity to add documentation about how to modify vivo.owl locally.
- Andrew: analyzing how to make updates will be a part of this effort.
- Does it make sense?
- How (if at all) do we want to include the other ontology efforts in this? Or do we keep it completely separate?
- Mike: VIVO Ontology is a product that is separable from the VIVO software. Other people use it; need to be able to find it. Software can use the particular version it wants.
- Andrew: Separate it out and make it clear which version of the ontology a software release is using. Is there the potential for confusion about which VIVO ontology-related repository people care about?
- 3. Effort to externalize the Solr index as well as to use ElasticSearch instead of Solr.
- Andrew: blocker for a number of things. VIVO kind of works with externalized Solr but needs to be completed and in the code base before 1.11 can go out.
- Ralph: This is my life for the next two days: will dive down into this. I’ve tested all of these pieces separately at different points in time. (Ralph is applying the rules of a monastic life to do this work but will be available to the developers on slack if need be.) (May the force be with you Ralph)
- Don: Is it as simple as spinning up the Docker branch with a pointer to the branch that Ralph is working on?
- Andrew: Most of the work is already in that branch, but there are three open tickets for code that needs to go into that branch. (1612, possibly two others)
- Ralph and Don will work on this; will circle back next week.
- Andrew: Would like to see Quinn’s pull request integrated so VIVO can also be spun up in addition to the other components.
- 5. VIVO Docker 2: Quinn has Dockerized the VIVO part as well.
- Quinn: Docker file includes the whole Maven build process. The Docker compose will sometimes fail in the first initialization when Solr takes longer to start than VIVO: something we’ll have to look at. We’re going to do a second image that’s pulled from the Github repo so we can pick different branches/commits in development. Becomes a bit complicated to share an image in a way that people know what they’re getting, but we’ll definitely have a Docker file to make it possible.
- Don: each institution makes its own war file that can just be dropped in
- Andrew: Would be nice to just have a war and not have to actually build the software.
- Quinn: Docker file could include a war file but you could override it with your own.
- Don agrees.
- Don: Does this include the Maven build or does it assume a VIVO war file?
- Andrew: Would ask Don and others to spin up Quinn’s pull request. I will also do it, but need two reviewers.
- 8. Andrew: Spoke with CINECA; have put some significant work into adding some features to VIVO, specifically the user interface. Faceted search and other elements; interested in getting merged into core VIVO. Want community agreement and buy-in, so will be joining call next week to do demonstration. This is moving the current product forward while also looking at the next-generation interface.
- Mike: CINECA came out of high-performance support group for Italian universities. Currently doing two VIVOs; have a CRIS product used at about 60-something Italian universities.
Actions
- - Mike Conlon, can you give this one a review?
Previous Actions
