Date

15 Jul 2020

• Time: 10:00 am, Eastern Time (New York, GMT-04:00)
• See in your timezone

Call-in Information

To join the online meeting:

• Go to: https://lyrasis.zoom.us/my/vivo1

• 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
    

Attendees

 Indicating note-taker

1. Andrew Woods
2. Brian Lowe
3. Nicolas Dickner
4. Ralph O'Flinn
5. Douglas C. Hahn
6. Rachid Belkouch
7. Robert Nelson
8. Damaris Murry
9. William Welling
10. Michel Héon
11. Robert Cartolano
12. Jim Wood
13. Anthony Helm
14. Benjamin Gross
15. Jeremiah Mercurio
16. Stephen Paul Davis
17. Alexander (Sacha) Jerabek
18. Terrie R. Wheeler

Objective

1. Work towards community decision on how to move the VIVO Scholar initiative forward

Agenda

1. Brief introductions: What is your interest in the conversation?
2. Status of VIVO Scholar
   1. Bridge between VIVO and Scholar: https://github.com/vivo-community/scholars-discovery
   2. User interfaces on the other side of the bridge:
      1. TAMU - https://github.com/vivo-community/scholars-angular
      2. Duke - https://github.com/vivo-community/vivo-scholar-ui
3. Possible futures for the initiative
   1. Relevant VIVO priorities:
      1. Improved UI
      2. Decoupled architecture
      3. Defined entities (Ingest)
      4. Event-driven workflows
4. Follow-on actions

Notes 

Draft notes in Google-Doc

1. Awoods: general intro about the purpose of meeting, to gauge interest and reasons for following VIVO Scholar (VS) developments.
2. Dmurry: focus was on the front end, trying to match Scholars Discovery with the UI at Duke. Trying to bring in more users into VIVO community by allowing more turn key implementation, ease of use.
3. Dhahn: for TAMU we tried using the Sparql, but was not aligned with developers’ orientation, interested in having options such as VS. interested in growing the product and knowledge sharing.
4. Awoods: productive to have institutional interests overlap with VS developments direction. Looking to get a sense of where people are in terms of implementing VS.
5. Wwelling: [gives overview of of technical details]: middleware layer, runs sparql queries transforms into solr documents (flat file with compound documents); harvest process is configurable; indexing has reference limitation to solr, looking at elasticsearch; flattening aids in discoverability, facets, etc. Local developments include integration with Angular, etc.
6. Dhahn: we’ve been running it in production for a year, works flawlessly, hard part is maintaining harvest and sync, not hard but could be faster. Sync every 2 hours, put into triple store for display.
7. From Douglas Hahn to Everyone:  10:32 AM
   1. FYI, here is the API docs for the REST endpoint
   2. https://api.library.tamu.edu/scholars-discovery/api
   3. Here is our UI in production
   4. https://scholars.library.tamu.edu/vivo/
8. Bgross: concerns about maintaining a separate stack are being addressed.
9. Ahelm: delay with editing profiles and not being immediately visible in interface is one of the issues.
10. Mheon: there is nothing about semantic web technologies in graphic [https://wiki.lyrasis.org/display/VIVO/2020-07-15+-+Special+Topic+-+VIVO+Scholar+Next+Steps?preview=/187175723/187176371/VIVO%20Scholar%20Diagram.png]. Seems to be a disappointing lack. 
11. Rcartolano: what is the disadvantage?
12. Mheon: no linked data, no sparql endpoint, no management of semantic data, 
13. Rcartolano: is there a use case that would illustrate the missing functionality for the end user?
14. Mheon: when trying to federate disparate data sources this is not possible, or difficult with VS architecture.
15. Rcarlton: so crosswalk against multiple VIVOs would be possible? This is very important for us.
16. Mheon: yes.
17. Wwelling: VS is only a discovery layer, not trying to change semantic web aspects or semantic nature of VIVO. Does not preclude federated discovery of solr documents with common ontologies.
18. Awoods: is the focus here to rescope VS, or to provide a discovery layer for institutional implementations?
19. Rcartolano: we had fed searches with Z3950, primitive but functional, but slow. People want sub-second response. So performance and usability advantages to aggregate sources for search. Begins with open architecture, looking at combining best of both worlds with VIVO and other options like VS.
20. Dhahn: VIVO is different things to different people. What sells is having a front end that shows faculty profiles well displayed, satisfying demands and expectations of stakeholders.
21. Rnelson: there is a need for super simple APIs for web developers.
22. Awoods: To restate (from point 3) : Possible futures for the initiative - Relevant VIVO priorities:
    1. Improved UI
    2. Decoupled architecture
    3. Defined entities (Ingest)
23. a few priorities that overlap with VIVO priorities : community engagement, architectural advances. Hard to find balance with ‘turn key’ needs and increased complexity of core VIVO (many moving parts). Looking at integrating VS into Vcore to make it a core component.
24. Jwood: goal is broadening audience for consuming this data, many ways to express the data. The UI is just one example of displaying the data, repurposing the data is the main concern.
25. Awoods: so one way of making this more useful is addressing harvest and sync functionality
26. Jwood: yes, would like to make data flow more easily, immediately
27. Dhahn: in interests of advancing projects this has been lagging, but remains important to address in longer term. VS adds another layer of complexity, questions are raised about how to make it easier (docker? etc?)
28. Damaris: goal was to make it easier for those who already have VIVO, not to induce new adopters, that is a separate issue.
29. Awoods: given the importance of real time sync, would it make sense to refactor VIVO to populate its own solr index with solr documents that conform to VS requirements. This would eliminate need to stand up separate solr instance, it would just expand existing solr instance to accommodate other requirements. Would this be seen as a benefit to VIVO users^
30. Wwelling: could be a good intermediate solution.
31. [missed a bit about existing capability about indexes by BGross…]
32. Ahelm: looking at exploring additional functionality like what source of information is causing an update, for faculty it is unclear where the data is coming from (local edits, sources from HR etc.)
33. Awoods: seems like it would be useful to have follow up conversations to balance needs of users, developers, general roadmap for VIVO.
34. Rcartolano: would be useful to have more discussions about non-technical topics.
35. From Terrie Wheeler to Everyone:  10:59 AM
    1. Love the idea that Andrew proposes to make VIVO Scholar more closely align with the VIVO core product.  We do use the VIVO core interface, as we value the immediate updates.  Need to leave now!
36. Awoods will follow up with scheduling more calls

Actions