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: https://goo.gl/forms/JxQFkut4TYj4Ehww1
Attendees
Indicating note-taker
- Andrew Woods
- Jim Blake
- Tim Worrall
- Mike Conlon
- Huda Khan
- Christian Hauschke
- Muhammad Javed
- Ralph O'Flinn
- Marijane White
- Don Elsborg
- Steven McCauley
- Benjamin Gross
- Kitio Fofack
Discussion items
- Custom form configuration
- Development processes (on vivo-tech)
- Community development priorities
- 1.10 Release
- Ontology discussions?
- Alignment with other interest groups?
- Integration testing
- Other community work to bring to next week's meeting?
Notes
Development Process
Andrew - Few people who work deeply in VIVO code like Jim, Graham...It is no obvious who have good understanding of code base.
Benjamin - This is correct
Andrew - There is interest to move forward. How we do it. We may want to start fresh.
Don - See discussion in #vivo-conf slack channel re: development workshop prior to VIVO2018
Andrew - Who are interested in creating a JIRA issue, fork, create a branch, apply a change and submit a pull request. There are all kinds of experts. All are not java developers. So others can also get benefit from it.
Don: regarding fork/branch/pull process -- how can we handle patches to a specific version? Not every installation is on the latest version.
Benjamin - If we could get some participation from community that would be great. Ralph - Agrees.
Jim: Test Procedure can also be useful instead of unit tests. Coded unit tests are not always best way to go.
Andrew - Common understanding what kind of common understanding we have. How do we ensure that changes going in do not break anything.
Andrew - Can we develop integration tests over period of time. Automated tests.
Don - In addition to above question - on what versions ?
Andrew - Integration testing is for DEV instance. Are you (Don) suggesting to target old versions too?
Don - Correct. We are still on older version.
Andrew - It’s an ambitious ask.
Mike - There is discussion about “concept of supported versions”. We never committed to it and we have it as an open question. We don’t support ver 1.1 and we don’t answer questions related to ver 1.1 and that leads to leaving it as an open question.
- Add PR-template
- Andrew - Adding a pull request template in github.
- Enable build
- Andrew - “Maven Clean Install” - Clone and Build should work.
- Update README with build instructions
- Andrew - Minor update is required to README
- Add javadocs
- Andrew - Some simple javadocs needs to add
- Add integration testing framework
- Enable checkstyle plugin
- Andrew - Enable plugin for coding styles fit.
- Set up Travis (with README badge)
- Andrew - runs every command that is required.
Andrew - Can someone go through small steps.
Ralph: Hands up. I can do it.
Kitio: Yes, I will do it too.
Benjamin: I would like to contribute where I can. Maybe Pull Request template? Does anybody have an example I can work from?
Agenda Item #1.
Huda: Powerpoint made for Linked Data for Libraries. One issue came up for we need to create several customizations. Using different ontology. Needed to make customizations.
Currently, need to config a number of classes. RDF - Fields on the Form to see and how they are linked to the Fields to be displayed. How to do more configurable way. So we don’t have to write java code. Don’t want to remove customs form completely replaced. But make it easier. In new proposal, JSON/JSON-LD contains all info for customization.
Too many details slides are available on https://docs.google.com/presentation/d/1bAKy865nAVqBcq82tRF2OVGvgz1DtTdrCVk-_YVFbzo/edit#slide=id.p3
If larger community is interested, how can we bring it in core codebase.
Andrew - Is it additive ?
Huda - Yes it is. It should not break what exist in current code. It is a different and an additional way in. The code is in Vitro layer.
Andrew - Code is available to pull and test?
Huda - Will discuss with Jim Blake and discuss further.
Jim - Yes. We did a little earlier. Possibility is that it will work with current dev branch. But can be tested.
Agenda Item 3b
Mike: Ontology Improvement Task Force tried to make a single vivo.owl ontology file (https://github.com/vivo-ontology-lab). There were 43 files in the filegraph, now there are 4 (https://github.com/vivo-ontology-lab/VIVO/tree/develop/home/src/main/resources/rdf/tbox). Goal was to load ontology easily and start to work on the ontology. The ontology should be available at a single web address – the same file should be served from the web address http://vivoweb.org/ontology/core that is the released version in the most current software. Toward the goal, application configuration assertions were removed, that didn’t belong there etc. Everything is just reorganization of the status quo, nothing is new. We discovered annotations that didn’t belong in the VIVO ontology, now there is a new VIVO Application Ontology (which may belong in the Vitro Ontology), maybe it belongs to the VIVO application. All Vitro assertions about classes and properties are in a new file vitroAnnotations.n3.
Don: Does it change the way to edit labels?
Mike: Doesn’t change anything, it’s fundamental work to allow future changes.
Don: Building an OWL file to combine with other ontology resources
Mike: this is a longterm goal
Andrew: Is it clear to folks how to test this?
Mike: The Lab is stand-alone. You can clone it and test it.
Benjamin: We should be able to take the owl files and drop them into a VIVO test installation.
Mike: Yes
Andrew: Any issues with Freemarker templates
Mike: It’s gonna break, we need to hunt down where it breaks.
Jim: Agree. The assertions control access to items on the screen. Broken SPARQL will result in granting access to things intended to be restricted.
Mike: Will start looking for the places where these assertions are used.
Action items
- ...
Recent JIRA Tickets
Tickets created in the last 30 days:
Tickets resolved in the last 30 days: