Date
Call-in Information
Time: 11:00 am, Eastern Time (New York, GMT-05: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
- Self-register at: https://goo.gl/forms/JxQFkut4TYj4Ehww1
Attendees
Indicating note-taker
Agenda
Holiday reflections? Wikidata reflections?
Design / Contribution process for larger features, examples:
- Leading up to the architectural fly-in, thoughts on refactoring / decoupling
- Resolved
Received
- - Pending response from
- Sub-question: Don Elsborgsuggesting simplification of firsttime, everytime, filegraph
- Where does this stand? What is needed to add more person identifiers to VIVO?
Benjamin Gross : Does Stefan Wolff 's recommendation resolve the issue?
-
- - Pending response from
Status of In-Review tickets
- low-hanging
- - An important step for i18n... resolves many other open issues
- - low-hanging, documentation
- - relatively straight-forward bug fix
- Kitio Fofack to review? -
- - low-hanging
Bugs (1.11)
Notes
Thoughts over the holidays
- Mike Conlon investigated wikidata un countries
- Less countries then he thinks it should have - 162
- This was entities instance of country – so that’s odd
- Eg Albania wasn’t on the list, sounds inconsistent for country definition
- So how do we work with Wikidata to determine why the list is so short and how is it maintained
- Main question – how do we follow up
- Don +1
- Mikes goal is not to update wikidata data
- Andrew noted that in Sem w3 list a wikidata question was monitored and answered by wikidata folks
- Mike C. — scholia seems very biased, very focused, working on large scale dumps. So if you want all papers from university of x, you might get nowhere
- Don – wikidata should be augmentation - non-authoritative.
- Ralph - wikidata should augment - also to deal with lag
- Don – wants to use wikidata concepts and use VIVO to map concepts between VIVO and wikidata - perhaps use openvivo for this. So try to store sameAs relationships between VIVO and wikidata. # Use the VIVO triple store and VIVO editorial interface to maintain these relationships
- Mike - UFL has the same need - Research Intelligence
Contribution process
- Andrew - Handling managing large contributions that “come over the wall”. How can the team engage in this such that we’re not faced with the problem of having a large changeset that has minimal context but to bearing on the overall VIVO design goals.
- So – how to get process engaged initially in the design phase.
- ……… crickets
- Jim – taking the procedure of creating issues then pull requests - so creation of jira issue is pro-forma. As opposed to starting with the Jira issue then we can discuss.
- Mike - not uncommon to develop first then think second.
- Don - needs to work for employing institution, then moves towards a VIVO ticket after the fact.
- Mike - is there a way to sum up tickets for the type and scale of work? So there are 3 examples of fantastic work. So these ideas are thought about for a few year.
- VIVO-1415 - Add publication claiming from PubMed and CrossRef IN REVIEW
- VIVO-1436 - Advanced role management IN REVIEW
- VIVO-1545 - Track user changes made to the content store IN REVIEW
- So these tickets above benefitted from a lot of community design work.
- Andrew - in open source world, we benefit from a planned design.
- Question is how to retroactively apply code to a design such that we can discuss. So the advanced role mgmt system was kind of like this. Where Graham presented the ACL’s to the dev group.
- So how to include great work such that there are updates that we want. How do create a process that promotes engagement and buy in as opposed to things being “thrown over the wall”. This should help bring the team together.
- Mike - 2 more examples
- The data distribution api - this was submitted, but put off. It did eventually get resolved. There wasn’t an open design process, it was submitted as a complete work.
- Jim – objection - it’s not included with the code
- Ralph - slated for 1.11
- Mike - documented in 10.0
- Ralph - so doc was added to show people HOW to add it to 1.10
- The data distribution api - this was submitted, but put off. It did eventually get resolved. There wasn’t an open design process, it was submitted as a complete work.
- For architectural flyin – will discuss what is a component what is configurable
- Jim – besides Data dist api - also provenance to capture logging of changes. So this can be implemented as a configurable add-on. Should we just strive for this model.
- Andrew - so if a work is a module, or optional – is having the team involved in design might not be paramount?
- Jim - exactly - so even if core committers are that involved - the add on can still be available and workable.
- Andrew - if we get configurable modules then the core team might not have this much engagement.
- Andrew - fundamentally this boils down to communication. So without that much process put in at this point, to move forward with communication, as opposed to people developing a large sum of code, throwing it over the wall, then ducking.
- Mike - need to identify the things that should require discussion or at least benefit from this.
- Don - so how to identify when to surface issues with VIVO
- Mike - create a ticket and use this as an entry point for design discussion. Try to have the tickets be technical and not vague.
- Andrew - summing up -
- we want transparency as to what the issues are as soon as possible.
- Use the Jira process to help identify and characterize issues, particularly from received to open.
Ticket gardening
- 1619 - jira is resolved. Code is merged - also for 1.9 branch
- Andrew - we should eventually talk about maint releases. So we might want to think about putting out a 1.9.4
- Received tickets - 1666. –
- Don - want more discussion with firsttime/everytime –
- Brian commented on the ticket explaining the way things work now.
- Mike - want to identify other institutions that run into this problem. UFL has this issue. ** Anything that is in Firsttime – this creates a big problem.
- Andrew - more big wins - Ben is good to go with 1671
- Wants people to look at in-review tickets
- VIVO-1667 - Language Filtering does not filter model on all construct queries IN REVIEW - low-hanging.
- This is a one liner
- VIVO-1661 - Merging VIVO-DE community translations into code base IN REVIEW - An important step for i18n... resolves many other open issues
- VIVO-1659 - Improve documentation on how to add new language support to VIVO IN REVIEW - low-hanging, documentation
- We can close this if we agree with documentation
- VIVO-1641 - Replace afn:localname / afn:namespace with cross-platform equivalent IN REVIEW - relatively straight-forward bug fix
This touches a few things but it’s the *** same fix applied broadly - VIVO-1630 - Start Year field keeps the same label even when language is changed IN REVIEW - Kitio Fofack to review?
- VIVO-1525 - SPARQL query page freezes IN REVIEW - low-hanging
- VIVO-1667 - Language Filtering does not filter model on all construct queries IN REVIEW - low-hanging.
- Get a review on this is helpful
Architectural flyin
- How to address workflows that bring things in from multiple data stores and store in VIVO
- On the flip side, have exports from VIVO or a canonical data store that pushes data to VIVO.
- Different VIVO front ends - so a read only view
Edit - can edit be separated from the standard view - Complexity added with seperate VIVO and Vitro. # What are the pros/cons of collapsing the two. So who cares about Vitro that doesn’t care about VIVO.
- Steve McCauley - more interested in Vitro than VIVO. He works more with Vitro.
- Mike - Metabolomics (sp?) project also using Vitro with some VIVO ontology
- Steve - will use some Vivo ontology but not all since they departed from the VIVO display.
- Andrew - Steve - are there natural architectural patterns that you would have like?
- Steve - separating the display layer from the rest of the system. Arch is fine since they don’t use it for display. Entirely as a backend.Some things could be changed. Things like externalizing search which would make things more modular. Or database not being tied to SDB/TDB so have a different triple store. Would like ability to swap things in and out. We replicate the VIVO SOLR for back end purposes.
- Mike - a deployment pattern could be that there is no front end. So could have a non vivo front end like Brown. So facts on demand and you put them where you want them. Not all sites want a front end. Just facts.
- Andrew/Mike - research intelligence system
- Don - are we discussing graph, LOD, and semantics
- Mike - semantics allow swapping out entities
Actions
Previous Actions
- Brian Lowe confirm LDF server issue with TDB content stores
- Don Elsborg to update vagrant for 1.10
- Don Elsborg - add jira tickets for abox/tbox use cases - one ticket for each use case
- Brian Lowe - check with ontology group on handles
- Alex Viggio will bring news of Elasticsearch instead of Solr up with Product Evolution.