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. Michel Héon 
  3. William Welling 
  4. Huda Khan (star)
  5. Bruce Herbert (first half hour)

Agenda

  1. Development issues for RC1 are cleared.  Only documentation / test procedure updates remain.  Blocker issues:
      1. 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.

  2. Documentation
    1. Simplifying first pages of documentation / "Quickstart" installation guide with Docker
    2. VIVO 1.12.x Documentation
    3. READMEs that need updating
      1. Updating set of available languages (or point people to list of directories?): https://github.com/vivo-project/Vitro-languages/tree/rel-1.12.0-alpha
        1. Should this also be copied to VIVO-languages?
      2. Updating links to current wiki documentation: https://github.com/vivo-project/VIVO/tree/rel-1.12.0-alpha
        1. Also update Docker documentation to check out parallel repositories?
  3. RC1 testing
    1. Making it easy
    2. For comparison: DSpace "testathon" page and demo server: DSpace Release 7.0 Testathon Page
    3. Submitting test results without needing wiki access:
      1. Draft Google forms courtesy William Welling: https://docs.google.com/forms/d/e/1FAIpQLSe3xKY5QbzMoZ6fzkaxZMz8_oSGtkVGSYWMNBk_hjVaUtp1Qg/viewform
  4. Any "final" initial feedback on VIVO in a Box before next Leadership meeting: https://docs.google.com/document/d/1lfTzXSXrtpRVT3CVWAj55XOou94kIg7QJ2NrHPQewUM/edit?usp=sharing
    1. Reference slides: 
  5. Other topics?

Future topics

  1. 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
  2. Post-release priorities
    1. Ingest / Kafka
    2. Advanced Role Management
    3. Moving Scholars closer to core - next steps
  3. Vitro JMS messaging approaches - redux
    1. Which architectural pattern should we take?
    2. What should the body of the messages be
  4. 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

Notes

  • Bruce: Leadership group is moving along with the VIVO in a Box project.  Hoping technical group can define what may be easy to do with respect to this idea and what may require more work. Need to see what may be possible/time requirements.
    • Need better definitions around some portions. 
    • Sense that kind of features that have been proposed to make things easier, but quite different from how VIVO currently operates.
    • Are we thinking about a new different product? Orthogonal to what current group is interested in?  
    • Doubt around VIVO project at Texas A&M would pay off, but few early wins around publications where info was being harvested and profile system that helps with promotions.  Simple profiles at first.
    • If buy-in at organization, can get more resources .
    • Potential users
      • Administrator: Button push for deploy and installation
      • Librarian:  a place to put the data but don’t want to install the machine
    • Making VIVO studio to help librarians to extract data and put that in VIVO.  Have Vivo but not easy to put data in.  Want to collaborate with non-developers.
      • In this studio, instances of VIVO, Kafka, Jena, OWL API
      • Plugin environment
      • Quite complicated but nice solution to have
    • Make the process more like DSpace where librarians can install and run it without additional tech support. 
    • Brian: Can look at discussion and thoughts regarding this here: https://docs.google.com/document/d/1lfTzXSXrtpRVT3CVWAj55XOou94kIg7QJ2NrHPQewUM/edit 
    • Bruce: In a perfect world, a product that can be expanded in the future.  Ability to customize.  
    • Michel: Questions around who VIAB (VIVO in a Box) is for? Many different possible users 
    • Bruce: William has made argument that project like this would also need working on the core VIVO.  
  • William: Piqued by VIVO Studio.
    • Capability to go inside VIVO, change ontology, inside JAVA code to change language information. 
    • Michel: Everything embedded inside environment.  Install eclipse.  
    • William: VIVO Studio packaged eclipse.  Runs VIVO on a port?
    • Michel: No.  When you open studio, have all the environment to install, start, and stop VIVO. 
  • William: could be interesting if VIVO Studio were an environment where librarians or others could experiment with customizations / ontology extensions / data loads, and when satisfied, request a merge to production VIVO.
  • With Remote Application Platform https://www.eclipse.org/rap/ could obviate need for local installation entirely
    • Michel: may be too complex to add this; too many things going on.
    • William: probably better to use RAP if built in from the ground up.
  • William: any plans for new data sources?
    • Michel:  Thinking about adding Swagger w/ REST API for admin tasks, e.g. adding users. Plus middleware that converts those requests to SPARQL UPDATEs
    • William: Studio may be more expedient solution for goals of VIVO in a Box.  Could be a good starting point.
    • William: plans for intermediate database?  Or no intermediate database?
    • William: Active Directory / LDAP consumer for Kafka stream would be the biggest bang for the buck.
  • Discussion of making source-specific graphs a standard part of VIVO pipeline. Michel and Brian both like to transform data sources to RDF as quickly as possible and then both map into the VIVO ontology using SPARQL and coalesce the different source graphs into a combined VIVO graph.  Michel likes having separate Fuseki servers hosting certain sources rather than having to combine into one store.  RDF and SPARQL are great for the low-level combining of data from different sources; their weaknesses come in supporting real-time queries and having a perfect or near-perfect coalesced RDF graph that a public VIVO typically requires in order to look good.
    • Brian: Is there a way we can avoid the need for a perfect coalesced graph and instead index directly from the source graphs and links between them while hiding problem areas where links may not exist?
    • William:  Are there going to be generalized solutions that work across institutions for the first transformation into the source graphs?

Draft notes on Google Drive



  • No labels

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