Skip to end of metadata
Go to start of metadata


Call-in Information

Time: 11:00 am, Eastern Time (New York, GMT-05:00)

To join the online meeting:



(star)  Indicating note-taker

  1.  Don Elsborg
  2. Ralph O'Flinn
  3. Andrew Woods  
  4. Mike Conlon
  5. Huda Khan
  6. Steven McCauley
  7. Jim Blake
  8. Brian Lowe


  1. Holiday reflections? Wikidata reflections?

  2. Design / Contribution process for larger features, examples:

    1. VIVO-1415 - Getting issue details... STATUS
    2. VIVO-1436 - Getting issue details... STATUS
    3. VIVO-1545 - Getting issue details... STATUS
  3. Leading up to the architectural fly-in, thoughts on refactoring / decoupling
  4. Resolved
    1. VIVO-1619 - Getting issue details... STATUS
  5. Received

     Click here to expand...

    T Key Summary Assignee Reporter P Status Resolution Created Updated Due

    1. VIVO-1666 - Getting issue details... STATUS  - Pending response from Brian Lowe

      1. Sub-question: Don Elsborgsuggesting simplification of firsttime, everytime, filegraph
    2. VIVO-1663 - Getting issue details... STATUS  - Where does this stand? What is needed to add more person identifiers to VIVO?

    3. VIVO-1671 - Getting issue details... STATUS  - Benjamin Gross : Does Stefan Wolff 's recommendation resolve the issue?

  6. Status of In-Review tickets

     Click here to expand...

    T Key Summary Assignee Reporter P Status Resolution Created Updated Due

    1. VIVO-1667 - Getting issue details... STATUS  - low-hanging

    2. VIVO-1661 - Getting issue details... STATUS  - An important step for i18n... resolves many other open issues
    3. VIVO-1659 - Getting issue details... STATUS  - low-hanging, documentation
    4. VIVO-1641 - Getting issue details... STATUS  - relatively straight-forward bug fix
    5. VIVO-1630 - Getting issue details... STATUS  - Kitio Fofack to review?
    6. VIVO-1525 - Getting issue details... STATUS  - low-hanging
  7. Bugs (1.11)

     Click here to expand...

    T Key Summary Assignee Reporter P Status Resolution Created Updated Due


Draft notes in Google-Doc

Thoughts over the holidays

  1. Mike Conlon investigated wikidata un countries
  2. Less countries then he thinks it should have - 162
  3. This was entities instance of country – so that’s odd
    • Eg Albania wasn’t on the list, sounds inconsistent for country definition
  4. So how do we work with Wikidata to determine why the list is so short and how is it maintained
  5. Main question – how do we follow up
    • Don +1
  6. Mikes goal is not to update wikidata data
  7. Andrew noted that in Sem w3 list a wikidata question was monitored and answered by wikidata folks
  8. 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
  9. Don – wikidata should be augmentation - non-authoritative.
  10. Ralph - wikidata should augment - also to deal with lag
  11. 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. 
  12. Use the VIVO triple store and VIVO editorial interface to maintain these relationships
  13. Mike - UFL has the same need - Research Intelligence

Contribution process

  1. 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.
  2. So – how to get process engaged initially in the design phase.
    • ……… crickets
  3. 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.
  4. Mike - not uncommon to develop first then think second.
  5. Don - needs to work for employing institution, then moves towards a VIVO ticket after the fact.
  6. 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
  7. So these tickets above benefitted from a lot of community design work.
  8. Andrew - in open source world, we benefit from a planned design.
  9. 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.
  10. 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.
  11. 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
  12. For architectural flyin – will discuss what is a component what is configurable
  13. 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.
  14. Andrew - so if a work is a module, or optional – is having the team involved in design might not be paramount?
  15. Jim - exactly - so even if core committers are that involved - the add on can still be available and workable.
  16. Andrew - if we get configurable modules then the core team might not have this much engagement.
  17. 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.
  18. Mike - need to identify the things that should require discussion or at least benefit from this.
  19. Don - so how to identify when to surface issues with VIVO
  20. Mike - create a ticket and use this as an entry point for design discussion. Try to have the tickets be technical and not vague.
  21. 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

  1. 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
  2. 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.
  3. Andrew - more big wins - Ben is good to go with 1671
  4. 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
  5. Get a review on this is helpful

Architectural flyin

  1. How to address workflows that bring things in from multiple data stores and store in VIVO
  2. On the flip side, have exports from VIVO or a canonical data store that pushes data to VIVO.
  3. Different VIVO front ends - so a read only view
    Edit - can edit be separated from the standard view
  4. 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.
  5. Steve McCauley - more interested in Vitro than VIVO. He works more with Vitro.
  6. Mike - Metabolomics (sp?) project also using Vitro with some VIVO ontology
  7. Steve - will use some Vivo ontology but not all since they departed from the VIVO display.
  8. Andrew - Steve - are there natural architectural patterns that you would have like?
  9. 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.
  10. 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.
  11. Andrew/Mike - research intelligence system
  12. Don - are we discussing graph, LOD, and semantics
  13. Mike - semantics allow swapping out entities


  • Mike Conlon to find contacts at wikidata to answer technical questions. We need to know how to interact with the wikidata community when it comes to understanding and validating, or eventually updating their data.
  • Don Elsborg to move forward with a firsttime/everytime config model discussion

Previous Actions

  • No labels