Date

Call-in Information

Time: 11:00 am, Eastern Time (New York, GMT-04:00)

To join the online meeting:

Slack

Attendees

(star)  Indicating note-taker

  1. Brian Lowe
  2. Georgy Litvinov
  3. William Welling (star)
  4. Huda Khan
  5. Alexander (Sacha) Jerabek 
  6. Dragan Ivanovic 
  7. Sandra Mierz 

Agenda

  1. Further investigation of the mailing list issue
    1. schema.org missing authors? https://groups.google.com/g/vivo-tech/c/MAoUdgZYOwo/m/uPswpzD_AgAJ?utm_medium=email&utm_source=footer
  2. 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."
  3. Small(er) development items for 1.13 (https://docs.google.com/spreadsheets/d/103P9P4v6yUBSb5BnVaK40NoGx1fIYyL8uaHKUubZWbE/edit?usp=sharing) vs decoupling UI (frontend) from backend 
  4. JIRA vs GitHub issues
    1. "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
  5. Merging developers and committers calls? 
  6. Defining shapes or subgraphs for use in APIs, edit forms, indexes etc.
    1. Diagrams:
      1. existing architecture: https://docs.google.com/presentation/d/1raO98mklGUQgAc6wMMbgDEsHVk1zoCA3bq4Fyy21GjI/edit?usp=sharing 
      2. Georgy: existing versus proposed
    2. JSON entities in/out
      1. Apache Marmotta LDPath syntax https://marmotta.apache.org/ldpath/language.html
      2. JSON-LD framing: https://www.w3.org/TR/json-ld11-framing/
        1. Is round-tripping a potential benefit?
      3. Defining exercises for evaluation
    3. Ontology model for defining form behavior
  7. Moving Scholars closer to the core
    1. Build messaging system first? versus
    2. Original option of typing into existing document modifiers:
      1. "win/win" opportunity: Scholars and VIVO both eliminate some complexity
      2. converting Scholars SPARQL queries to VIVO DocumentModifiers
      3. replacing URIFinders with fast, reliable Solr lookups 

Needing reviews

    1. Unable to locate Jira server for this macro. It may be due to Application Link configuration.
    2. https://github.com/vivo-project/Vitro/pull/242
    3. Unable to locate Jira server for this macro. It may be due to Application Link configuration.
    4. Unable to locate Jira server for this macro. It may be due to Application Link configuration.
    5. Unable to locate Jira server for this macro. It may be due to Application Link configuration.

References

  1. 2019-01 Architectural Fly-in Summary#201901ArchitecturalFlyinSummary-Ingest
  2. VIVO in a Box current document for feedback:

Future topics

  1. Prioritizing and planning post-1.12 development
  2. Forward-looking topics:
    1. frameworks: Spring / Spring Boot / alternatives
    2. Horizontal scalability
    3. Deployment
    4. Configuration : files / environment variables / GUI settings
    5. Editing / form handling
    6. Adding custom theming without customizing build
  3. Post-release priorities
    1. Ingest / Kafka
    2. Advanced Role Management
    3. Moving Scholars closer to core - next steps
  4. Vitro JMS messaging approaches - redux
    1. Which architectural pattern should we take?
    2. What should the body of the messages be
  5. Incremental development initiatives
    1. Unable to locate Jira server for this macro. It may be due to Application Link configuration.
    2. Unable to locate Jira server for this macro. It may be due to Application Link configuration.
    3. Integration test opportunities with the switch to TDB - requires startup/shutdown of external Solr ..via Maven

Tickets

  1. Status of In-Review tickets

    type key summary assignee reporter priority status resolution created updated due

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Notes

Dragan introducing himself as new tech lead!

  1. Further investigation of the mailing list issue
    1. schema.org missing authors? https://groups.google.com/g/vivo-tech/c/MAoUdgZYOwo/m/uPswpzD_AgAJ?utm_medium=email&utm_source=footer
  1. Still needs to be responded to.
  2. 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.
  1. 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."
    1. 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.
  2. Small(er) development items for 1.13 (https://docs.google.com/spreadsheets/d/103P9P4v6yUBSb5BnVaK40NoGx1fIYyL8uaHKUubZWbE/edit?usp=sharing) vs decoupling UI (frontend) from backend 
    1. 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.
      1. Decoupling is related to VIVO in a Box
      2. Also related to integrating Scholars Discovery into the core
      3. Request from Laurie Arp (LYRASIS) is to estimate the developer hours necessary.  Could investigate additional budget for hiring developers.
        1. 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.
        2. Scholars Discovery took six months with two developers, but is read-only so less complex than a full VIVO.
        3. Should try to make an estimate that is no more than 50% off.  Will not be an easy task.
      4. William: hard to make an estimate without a scope of the decoupling.
        1. Dragan: REST API, Spring, Spring Boot.  Should try to implement React or something like that; no longer based on Freemarker.
          1. A lot of effort has been invested in the existing Freemarker UI, so could be tricky.
          2. Current university students are learning React and Angular, not things like Freemarker.
      5. Ralph: What about not using a framework?  Companies sometimes get tied into frameworks they don’t control when all they really needed was Javascript.
        1. 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.
        2. 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.
          1. Ralph: server-side rendering is the way to go.
          2. William: Angular, React and Ember all provide for server-side rendering with Javascript is disabled.
      6. 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.
        1. William agrees.
      7. 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.
        1. Important topic for coming weeks.  Will start Google doc to summarize.
        2. Two options for proceeding: start new project and start replicating functionality, or fork existing code and modify it.
        3. Should also look at old, unused things that could possibly be removed.
        4. William:  are the reasoner, indexing, etc. still going to be part of the same application, or split into separate applications?
          1. Could simplify pulling out legacy/dead code or features that are no longer used.
          2. Dragan: I like idea of decomposing.  But could introduce performance challenges.  Should become more clear in the coming weeks.
        5. What will happen in the meantime?
          1. 1.13 (and maybe 1.14) should be released (with bug fixes / other improvements for the customer) while 2.0 is being developed.
          2. 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.
          3. Dragan: If we outsource development, first phase might be just to rewrite existing application in new architecture.
          4. 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.
          5. Dragan will be looking for input from the developer group in shaping the Google doc / estimates.
          6. Benjamin: momentum is there for major changes.  Not sure if we’ve seen commitment to time/money from the institutions involved in leadership.
          7. 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. 
            1. Benjamin:  has been conflict/disconnect between this stated goal and the technologies that have been identified.
          8. Dragan: Maybe can meet main goal of VIVO in a Box by decoupling in main VIVO.
          9. A&M will be contributing more to VIVO development once they are past their Folio implementation.
    2. What do we do for 1.13?
      1. Should we define what to release next while waiting for leadership decisions.
      2. 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.
  3. JIRA vs GitHub issues
    1. "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
  4. Merging developers and committers calls? 
    1. Dragan: would be good to have just one regular meeting per week.
    2. Ralph and Benjamin still see a use for a separate committers’ call, but maybe not as frequently.
      1. Ralph: this question might actually be better suited to a committers’ call.
      2. Benjamin: can also assess where 1.12.1 is on a call this week.
    3. Will have a Thursday committers’ call this week, and then assess from there whether the schedule should be reduced.

Draft notes on Google Drive


Task List



  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.