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
1.11 Release!! Freshly minted
Ralph:
In Oracle, had JRE vs JDK (the way the folder structure laid out). Plugin worked based on where the JRE/JDK was located.
Andrew: ran into this. Had to install one of those (JDK or JRE) and then it worked.
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
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
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.
Andrew: Normal build?
Ralph: No, but need to review this.
Checkstyle added complexity to process.
POM file originally didn’t have reference back to Vitro as parent (had to fix POM and changes committed and part of release).
JAVA doc plugin does not play well with OpenJDK but fine for modern version of Oracle.
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.
Ralph: Some weirdness with tests - if coming from Windows vs Linux.
Ralph: best way to build it out still Linux + Oracle
Mike: Potential issue - VIVO TPF Core responds with already having done * query to get all the triples in triple store.
Ralph: ORCID, themes
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.
Mike: could set up JENA TDB and use this TPF to hit local TDB
Andrew: Pulling out the TPF code
Andrew: ORCID work.
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.
Andrew: Sustainability of project depends on working not just during sprint but after so that’s fine.
Andrew: Don, interest in pulling in VIVO Scholars/related work? Bullet 2 under tickets.
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
Having a generalized dataset that could be used to start/test
Mike: UF data is in there but has production issues (valid, but dirty data).
Don: Pitch with LASP: LOD connection with metadata catalog and central VIVO data. Hope to get more resources for VIVO work.
New tickets
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
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.
VIVO-1726 - Co-author visualization: Change cursor type when hovering over link In Review
Benjamin: Currently, visualizations are hard-coded using D3
Amalia: To change it, will need to go through code? Benjamin: yes.
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
Huda: Special topic?
Andrew: Could do something like that and then follow on with hackathon etc.