...

Draft notes in Google-Doc

1. Community updates
1. From agenda: Scholars at TAMU released
1. Modern interface - Responsive, mobile friendly!
2. Enhanced search features -  Customized faceted searches
3. Easier access to the back end data -  ability to export data on the fly, and embed data widgets in other sites
4. Robust features for data re-use by others - Via the Discovery Service fully documented API, and direct access to the data in JSON format
2. TAMU announcement: Scholars site - based on work in VIVO Scholars task force.  Angular front-end. JAVA middleware extracts data from a VIVO instance and then populates front-end based on that data
2. 1.11 Release!! Freshly minted
1. Release process lessons learned
1. Ralph: 
1. Checkstyle added complexity to process.
2.  POM file originally didn’t have reference back to Vitro as parent (had to fix POM and changes committed and part of release). 
3. JAVA doc plugin does not play well with OpenJDK but fine for modern version of Oracle. 
1. In Oracle, had JRE vs JDK (the way the folder structure laid out).  Plugin worked based on where the JRE/JDK was located. 
1. Andrew: ran into this. Had to install one of those (JDK or JRE) and then it worked.
2. Ralph: Can fix paths/alternates but expectation is that if you install JDK that that JDK is picked up and not wrongly identified as a JRE
4. Installer: In a regular Maven(?) process, automatically flips submodules to correct versions but because VIVO’s setup includes installer within the folder, does not do so.  Instead of one line prepare, need multiple lines to do local check-ins and then have a manual release properties file (the file is now in there). Have to have these additional pieces to tell it where to pull from SCM.  If installer is removed from equation then it will work just as a regular one-line prepare process.  
1. Ralph: What is the real benefit of installer? Could it be somewhere else? Or does POM need to be reimplemented? Possible topics for an upcoming sprint
2. Andrew: Good to discuss.  Value of having custom installers and how could have a standard VIVO installation vs Maven-based while still allowing for custom builds/custom war files. 
5. Ralph: Some weirdness with tests - if coming from Windows vs Linux. 
1. Andrew: Normal build?
2. Ralph: No, but need to review this. 
6. Ralph: best way to build it out still Linux + Oracle
2. Andrew: One way to investigate these issues is to have a point release - perhaps some configuration updates might warrant a point release.  
1. Ralph: Next snapshot is 1.11.1
3. Mike: draft release announcement is here https://wiki.duraspace.org/display/VIVO/VIVO+1.11.0+Release+Announcement 
4. Andrew: Documentation around externalized Solr. 
1. Setup documentation
2. "custom field" documentation
5. Mike: Docker worked great! Publication claiming in Docker also worked well! Worked fabulously!
1. Windows may still have issues with Docker
2. Mike: Docker process seems really useful for evaluation purposes
3. Andrew: Architecturally - forces separation of components
3. For 1.11.1, configuration changes
1. Ralph: ORCID, themes
2. Externalized TPF server: VIVO-1723 - Externalize TPF Server Andrew added a SQL interface to the TPF project server.  The TPF Server can now use a SQL interface to any triple store -- Blazegraph, Stardog, JENA TDB, etc.  
3. Sprint currently underway: Sprint updates (Oct 14-25)
4. Tickets show what is currently being worked on
5. TPF: Did not have SPARQL endpoint so submitted pull request back to TPF which has been committed . See https://github.com/LinkedDataFragments/Server.Java/issues/57 
1. https://jira.duraspace.org/browse/VIVO-1707 and https://wiki.duraspace.org/display/VIVODOC18x/Using+a+different+data+store for documentation of setting up external triple store
6. Mike: could set up JENA TDB and use this TPF to hit local TDB
7. Andrew: Pulling out the TPF code 
1. Ralph: In line with modularization approach
2. Mike: Potential issue - VIVO TPF Core responds with already having done * query to get all the triples in triple store.  
4. Andrew: ORCID work.  
1. Kristina: Had some technical issues last week that have worked through.  External Solr was acting weird on Windows but figured it out. Hoping to spend rest of time this week on VIVO work.  Should be able to work on it during and after sprint. 
2. Andrew: Sustainability of project depends on working not just during sprint but after so that’s fine.
5. Andrew: Don, interest in pulling in VIVO Scholars/related work?  Bullet 2 under tickets. 
1. Useful to see if the work being done in this area is generalizable and pulling in information from different institutions is one way of testing/reviewing this
2. Having a generalized dataset that could be used to start/test
3. Mike: UF data is in there but has production issues (valid, but dirty data).
4. Don: Pitch with LASP: LOD connection with metadata catalog and central VIVO data. Hope to get more resources for VIVO work.  
6. New tickets
1. VIVO-1726 - Co-author visualization: Change cursor type when hovering over link In Review
1. Right now, the cursor stays as the default pointer and this change will convert it to a hand cursor when you hover some of the links
2. Andrew: Put in comment in ticket. Is there a sample dataset? Mike: Yes, the sample data N3 file in the VIVO sample data repo has data for coauthors.
2. Pull request: https://github.com/vivo-project/VIVO/pull/138 and https://jira.duraspace.org/browse/VIVO-1704 . If people were associated with research area, SPARQL query was returning hundreds of thousands of triples instead of the ones desired.  Slowed down the research concept pages by an order of magnitude.
3. VIVO-1727 - Improve German translation of some terms in VIVO-DE In Review
7. Amalia: Can we include additional libraries/visualizations into the code?
1. Benjamin: Currently, visualizations are hard-coded using D3
2. Amalia: To change it, will need to go through code? Benjamin: yes.
1. Data behind the visualization is generalizable/could be easily used
2. Amalia: Want to have different graphs.  
1. See https://www.d3-graph-gallery.com .
3. Mike: Different institutions had added custom visualizations (Weill Cornell, Cornell’s previously alive but not not anymore Scholars view, etc.).  Would be useful to identify what it would take to integrate visualizations. Hackathon? Potentially bring this up during a steering group meeting
4. Huda: Special topic?
5. Andrew: Could do something like that and then follow on with hackathon etc.
8. Andrew: Regular special topics calls
1. Special topics for future dev calls
1. TDB vs SDB Doodle
1. Understanding pros/cons of TDB vs SDB implementations and potentially recommendations based on this discussion
2. Eventually, we’d like to decouple the triple store so at that point, one could use whatever

Actions

•   Organize a TDB/SDB special topics conversation
•  Organize a session on Brown's work on editing

...