Integration test opportunities with the switch to TDB - requires startup/shutdown of external Solr ..via Maven
Tickets
Status of In-Review tickets
Notes
Attendees
Nicolas Dickner
Andrew Woods
Jeff Tyzzer
Brian Lowe
Michel Héon
Huda Khan
Benjamin Gross
Don Elsborg
Ralph O’Flinn
Notes
VIVO Conference and Sprint
Due to a conflict with the VIVO conference, the June sprint will not be occurring the week of the 15th. A possible rescheduling/combination with the July sprint will be discussed offline, and proposed dates posted to the list.
VIVO Scholar
Andrew (supplying background): current default harvest mechanism is to slurp directly from copied TDB files.
Andrew: There is interest in moving Scholar initiative into the core VIVO project Github organization.
Michel: UQAM and its network of universities will be taking a serious look at VIVO Scholar. Desire for simpler installation and interface generation, but requirement to keep semantic web technologies. GraphQL API is not currently of interest; SPARQL is more important. French version of Scholar would be a must, and language must be selectable by the user rather than relying on the browser-supplied headers.
Nicolas: VIVO Scholar could be a nice way to implement a multi-institutional VIVO: feed multiple VIVOs into a single Solr index that drives the interface.
Benjamin: very interested in it, but internationalization and editing are must-haves. Both Scholar and VIVO do different things well; neither currently does everything well.
Andrew: Current thinking is that Scholar would be the public front end while current VIVO would be the editing backend. Texas A&M, however, is very interested in editing and having a Scholar-like editing capability.
Brian: Interested in the idea of what Scholar is doing, but don’t yet know enough about the implementation details to know whether to embrace it. Not had much success yet in getting it up and running.
Don: Complicated stack compared to, for example, what we’re doing with Facetview. Don’t see an easy path to incorporating the Scholar stack into our architecture.
Ralph: Not fully baked yet and suffers from some challenging technology stacking, but once set up it becomes easy for a web developer developing against GraphQL. Little harder for the server administrator; simplifying that may be the next goal.
Don and Ralph: Scholar needs to be able to harvest from an arbitrary SPARQL endpoint, not depend on SDB/TDB native connections.
Don: there is a lot of potential here, because you can’t do everything with SPARQL and mere mortals don’t want to think about the ontology.
Huda: Simple auto-configuration if pointed to an existing VIVO would be ideal. Is Java still the most appropriate technology once you have everything driven from an index? There are other lighter-weight technologies for rapidly spinning up front ends. Front-end development is always moving on to something new, and focusing on giving developers access to JSON and APIs and letting them choose the latest technology might be a good idea.
Ralph and Don: Not just Java; also Go component for GraphQL, which consumes the REST API exposed using Java / Spring Boot.
Ralph: Mike’s approach of using Triple Pattern Fragments may also be a good way to go; highlighted the complexity of Scholars Discovery.
Don: GraphQL stack is a nice, non-ontological way of getting access to rich data. Very interested in this for web developers; most important thing to keep.
Ralph: GraphQL should be expanded to cover the whole ontology. Middleware piece is more important than the UI.
Sections 4/5 from agenda: Brief highlighting of global transaction ID issue and other open issues, also potential importance of addressing the missing solr config in the new stand-alone installation.
Indicating note-taker