...

Attendees

 Indicating note-taker

1. Brian Lowe 
2.  Benjamin Gross 
3. Andrew Woods
4. Brian Lowe 
5. Ralph O'Flinn 
6. Alexander (Sacha) Jerabek
7. Pierre Roberge
8. Michel Héon
10. Don Elsborg
11. Mike Conlon
12. Huda Khan
13. Steven McCauley Don Elsborg

Agenda

1. Announcements
   1. Review of auto-closed pull-requests that have come back to life!
      1. VIVO re-opened PRs
      2. Vitro re-opened PRs
      3. ...or not back to life? VIVO-Harvester PRs
   2. VIVO Triple Store Roadmap Proposal
      1. VIVO-1741 - Change default content triplestore to TDB RECEIVED
2. 2020 Sprint Planning- VIVO Sprints
3. Symplectic's Harvester... now open source, what next?
4. Pruning legacy Vitro/VIVO GitHub branches
5. From last week, what is the resolution for: 

   Jira
   server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1738

6. Vitro pull-requests
   1. authorization update for self editors - no JIRA
   2. RDF Delta patch messaging - 

      Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1718

   3. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1658

       - looks good

...

1. Triple Store Roadmap Proposal
   1. Limited feedback received so far.
   2. Related question of how much of what VIVO does requires a triple or graph store, and to what extent the triple store represents latent potential.
   3. 1. Mike: Some in the VIVO community define the problem very narrowly: store lists of publications and put them on the screen quickly.  In this case, there is no need for a triple store. The triple store becomes an appropriate solution when you consider scholarship more broadly.
      2. Don:  Got interested in VIVO because of the ability to record data about spacecraft and maintain relationships between equipment, data sets, people, etc.  The beauty and promise of VIVO (especially Vitro) is the ability to leverage all of these relationships.  
      3. Mike:  Upper level ontology work is critical for being able to share data across domains.
2. Sprint planning
Communitizing VIVO Scholar and language-aware editing
1. Limited feedback received so far.
2. Related question of how much of what VIVO does requires a triple or graph store, and to what extent the triple store represents latent potential.
3. Sprint planning
   1. Close to reaching critical mass
   2. Don may be able to recruit a volunteer to work on ETL for VIVO Scholar via a Python-based pipeline (NetworkX to RDF). Tease apart pieces of the current process and make it easier for people to debug and modify when not tied to a complex Java stack.
   1. Andrew: would be good to gauge interest on Monday.  There is also value in coalescing around a shared solution.
   3. Don: is there still the possibility to leverage VIVO’s current listeners that trigger index modification to also modify a Solr that can be used by Scholar?  What might be the barriers? Would be good to have a discussion.
      1. Mike: Access control is a critical part of Vitro, so messages plus access control is value not provided by a standard triple store.
   1. Should it be a core part of Vitro to translate between RDF changes and changes to document structures that are then sent to other applications/indexes?  Or is it better to reduce Vitro’s role and rely on RDF Delta Patch where raw RDF messages are sent to other applications?
Mike: Access control is a critical part of Vitro, so messages plus access control is value not provided by a standard triple store.
1. Communitizing VIVO Scholar and language-aware editing
1. Divide and conquer to prune legacy branches.
2. VIVO-1738 needs a comment from Don about possible resolution.

...