...
- Benjamin Gross
- Brian Lowe
- Alexander (Sacha) Jerabek
- Ralph O'Flinn
- Andrew Woods
- Nicolas Dickner
- Jeff Tyzzer
- Michel Héon
- Huda Khan
- Don Elsborg
Agenda
- Next week VIVO Conference and Sprint - postpone sprint by a week?
- VIVO Scholars... next steps
- Selenium testing
Jira server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1885
- Bugs/Issues
- Mailing list (vivo-tech)
- Solr configuration needs updates:
Jira server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1866 - Potentially related:
Jira server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1671
- Potentially related:
Jira server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1883
- Will potentially simplify i18n '.ftl' filesJira server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1842
- Tickets to be reviewed
- one more reviewer neededJira server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1839
- low-hanging and urgent... or else we will fall out of date againJira server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1887 Jira server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1873 Expand Jira server DuraSpace JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution maximumIssues 20 jqlQuery filter=14416 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5
- Who is working on what? - Are there active tickets in-progress?
Expand Jira server DuraSpace JIRA jqlQuery filter=15500 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5
...
Status of In-Review tickets
Expand Jira server DuraSpace JIRA jqlQuery filter=14416 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5
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.
...