...
- Further investigation of the mailing list issue
- schema.org missing authors? https://groups.google.com/g/vivo-tech/c/MAoUdgZYOwo/m/uPswpzD_AgAJ?utm_medium=email&utm_source=footer
- The issue reported via Slack by Naveen Sadhu: "Hello..We use pypubmed harvester process to retrieve additional information for publications like subject areas, keywords. Recently we had issues : duplicate subject areas in our VIVO application. We are using pypubmed python script to check vivo(our app) data against pubmed central repository and add subjectareas if not available. I did check python script that we are using and no issues there. Anyone faced similar issues before? Any help would be greatly appreciated."
- Small(er) development items for 1.13 (https://docs.google.com/spreadsheets/d/103P9P4v6yUBSb5BnVaK40NoGx1fIYyL8uaHKUubZWbE/edit?usp=sharing) vs decoupling UI (frontend) from backend
- JIRA vs GitHub issues
- "Andrew: have meeting with Tim Donahue of DSpace project. DSpace has already done a similar transition. Will ask for feedback/advice." 2020-12-08 - VIVO Development IG
- Merging developers and committers calls?
- Defining shapes or subgraphs for use in APIs, edit forms, indexes etc.
- Diagrams:
- existing architecture: https://docs.google.com/presentation/d/1raO98mklGUQgAc6wMMbgDEsHVk1zoCA3bq4Fyy21GjI/edit?usp=sharing
- Georgy: existing versus proposed
View file name Architecture cur and new.pdf height 150
- JSON entities in/out
- Apache Marmotta LDPath syntax https://marmotta.apache.org/ldpath/language.html
- JSON-LD framing: https://www.w3.org/TR/json-ld11-framing/
- Is round-tripping a potential benefit?
- Defining exercises for evaluation
- Ontology model for defining form behavior
- Diagrams:
- Moving Scholars closer to the core
...
Status of In-Review tickets
Expand Jira server DuraSpace JIRA jqlQuery filter=14416 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5
Notes
Dragan introducing himself as new tech lead!
- Further investigation of the mailing list issue
- Still needs to be responded to.
- No new updates this week.
- We should try to make time to investigate further.
- Action item: Benjamin Gross will respond to the email to solicit more details. Doesn’t have an answer yet.
- The issue reported via Slack by Naveen Sadhu: "Hello..We use pypubmed harvester process to retrieve additional information for publications like subject areas, keywords. Recently we had issues : duplicate subject areas in our VIVO application. We are using pypubmed python script to check vivo(our app) data against pubmed central repository and add subjectareas if not available. I did check python script that we are using and no issues there. Anyone faced similar issues before? Any help would be greatly appreciated."
- Team isn’t familiar with this particular tool. Hard for us to respond to. Benjamin has asked about which particular tool is being referred to in Slack.
- Small(er) development items for 1.13 (https://docs.google.com/spreadsheets/d/103P9P4v6yUBSb5BnVaK40NoGx1fIYyL8uaHKUubZWbE/edit?usp=sharing) vs decoupling UI (frontend) from backend
- Dragan: Decoupling frontend from backend is important but risky and error-prone, especially because test coverage is lacking. Moving to a new architecture will take time, and capacity is an issue.
- Decoupling is related to VIVO in a Box
- Also related to integrating Scholars Discovery into the core
- Request from Laurie Arp (LYRASIS) is to estimate the developer hours necessary. Could investigate additional budget for hiring developers.
- DSpace has implemented front end in Angular, but took five years from original idea to production release. Needed to hire some full-time developers to complete the project.
- Scholars Discovery took six months with two developers, but is read-only so less complex than a full VIVO.
- Should try to make an estimate that is no more than 50% off. Will not be an easy task.
- William: hard to make an estimate without a scope of the decoupling.
- Dragan: REST API, Spring, Spring Boot. Should try to implement React or something like that; no longer based on Freemarker.
- A lot of effort has been invested in the existing Freemarker UI, so could be tricky.
- Current university students are learning React and Angular, not things like Freemarker.
- Ralph: What about not using a framework? Companies sometimes get tied into frameworks they don’t control when all they really needed was Javascript.
- William: this is part of the appeal of React, since it’s a library and not a framework. But you still need to pick a templating engine.
- William: Angular rewrite forced everyone to rewrite their UIs; want to avoid something like that. But also need to consider SEO. With frameworks you can get server-side rendering out of the box.
- Ralph: server-side rendering is the way to go.
- William: Angular, React and Ember all provide for server-side rendering with Javascript is disabled.
- Huda: Would be good to split the problem into two pieces. Define a solid API for getting data out of the system. Then decide front-end implementation.
- William agrees.
- Dragan: Should look at the most stable solutions on the market and what libraries/frameworks other projects are using. But we’ll need to accept that we won’t necessarily be able to make a perfect decision.
- Important topic for coming weeks. Will start Google doc to summarize.
- Two options for proceeding: start new project and start replicating functionality, or fork existing code and modify it.
- Should also look at old, unused things that could possibly be removed.
- William: are the reasoner, indexing, etc. still going to be part of the same application, or split into separate applications?
- Could simplify pulling out legacy/dead code or features that are no longer used.
- Dragan: I like idea of decomposing. But could introduce performance challenges. Should become more clear in the coming weeks.
- What will happen in the meantime?
- 1.13 (and maybe 1.14) should be released (with bug fixes / other improvements for the customer) while 2.0 is being developed.
- William: exposing a REST endpoint immediately gives benefits to the end user. There’s more to sell in 2.0 than just better architecture / better maintainability.
- Dragan: If we outsource development, first phase might be just to rewrite existing application in new architecture.
- William: hard to think about trying to upgrade Vitro and VIVO to a modern architecture. Rewrite would take less time than iterative upgrading. But iterative upgrading might give you more intermediate releases with new functionality.
- Dragan will be looking for input from the developer group in shaping the Google doc / estimates.
- Benjamin: momentum is there for major changes. Not sure if we’ve seen commitment to time/money from the institutions involved in leadership.
- William: VIVO in a Box has no interest in the long-term redesign. It wants a fast path to a simple, turnkey VIVO with harvesting.
- Benjamin: has been conflict/disconnect between this stated goal and the technologies that have been identified.
- Dragan: Maybe can meet main goal of VIVO in a Box by decoupling in main VIVO.
- A&M will be contributing more to VIVO development once they are past their Folio implementation.
- What do we do for 1.13?
- Should we define what to release next while waiting for leadership decisions.
- Need to add additional columns to feature spreadsheet to assess whether feature impedes decoupling and whether it introduces or perpetuates technical debt that harms maintainability.
- JIRA vs GitHub issues
- "Andrew: have meeting with Tim Donahue of DSpace project. DSpace has already done a similar transition. Will ask for feedback/advice."2020-12-08 - VIVO Development IG
- Merging developers and committers calls?
- Dragan: would be good to have just one regular meeting per week.
- Ralph and Benjamin still see a use for a separate committers’ call, but maybe not as frequently.
- Ralph: this question might actually be better suited to a committers’ call.
- Benjamin: can also assess where 1.12.1 is on a call this week.
- Will have a Thursday committers’ call this week, and then assess from there whether the schedule should be reduced.
Task List
- Benjamin Gross to respond to schema.org issue email on listserv