...

 Indicating note-taker

1. Andrew Woods
2. Brian Lowe 
3. Ralph O'Flinn 
4. Benjamin Gross
5. Don Elsborg
6. Pierre Roberge
7. Alexander (Sacha) Jerabek
8. Steven McCauley
9. Maxime Bélanger
10. Amin Keshavarz
11. Rachid Belkouch
12. Nicolas Dickner
13. Mike Conlon
14. Brock Balducci
15. Hector Correa
16. María Amalia Flórez Huertas
17. Huda Khan Michel Héon

Agenda

1. Community updates
   1. VIVO Scholars
2. Brown demo - read/write UI on VIVO
3. Special topics for future dev calls
   1. 2019-12-06 - Special Topic - TDB vs SDB
4.  In-review tickets 

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

       - need 1 more reviewer

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

       - need 1 more reviewer

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

       - need 1 more reviewer

   4. 
      

      Expand
      Jira server DuraSpace JIRA jqlQuery filter=14416 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

      
      

5. Short-term development activity
   1. Extract ontology from core codebase
   2. Extract languages from core codebase
   3. Move from 'develop' to 'master' branch
6. Review of vivo-project repos for appropriateness of being supported by Committers

...

1. Slides: https://figshare.com/articles/A_new_editing_frontend_for_VIVO/9792176/1
2. Brown began with a separate front-end (based on Rails) that speaks to the Solr index generated based on the VIVO Solr index.  They also created an editing front-end (since the original VIVO editing front-end was considered too cumbersome) which relies on a Django/flask application that communicates directly with the VIVO triple store.  
3. The current motivation is to combine the display and editing front-ends into a single interface, where display and editing would still be funneled through different application areas but the end-user would not know the difference.
High level API for graph data generation would be desirable.  
4. Challenges and opportunities
5. Multiple points of interaction with the triplestore with multiple systems adding RDF where the RDF content is inconsistent with respect to shapes/content.  Aiming for all RDF production and ingest to be brought together at a single point using the Flask app. 
6. 1. ORM (Object Relational Mapper): Mapping graph structure to object/dictionary/hashmap (based on your particular programming flavor) appears to be straightforward (although weed-level may be complicated)
   2. Stateless state of graphs eliminates some of the complexities with other ORM work (don’t need to consider integrity checks/form key validation as deletes in a graph are pretty straightforward) 
   3. Documentation based on Flask SQLAlchemy
   4. Using Describe query to get all RDF with the app that sits on top of it filtering the appropriate information 
   5. Steve says the end is in sight.  Who wants to get Steve and Hector doughnuts when the end is in fact here? (Not THE end, but the end of this work)
1. Multiple points of interaction with the triplestore with multiple systems adding RDF where the RDF content is inconsistent with respect to shapes/content.  Aiming for all RDF production and ingest to be brought together at a single point using the Flask app. 
2. High level API for graph data generation would be desirable.  
7. Andrew: Given the probable reliance on well-defined JSON shapes/expectations, would be good to compare this work with the VIVO Scholars work

...