Page History

...

1. https://docs.google.com/spreadsheets/d/103P9P4v6yUBSb5BnVaK40NoGx1fIYyL8uaHKUubZWbE/edit?usp=sharing
   1. Scoring columns have been filled out on the spreadsheet.
   2. If we don’t agree with the scoring, we should add comments to the spreadsheet.
   3. Publishing from VIVO Studio to staging or production servers
      1. Dragan had problems installing VIVO Studio on Windows/Mac; may still be some hard-coded paths that either need to be made configurable or created and made writable before installation.
      2. Michel: VIVO Studio is an Eclipse-based application with lots of plugins for working with TopBraid Composer (ontology engineering tool).
         1. First use case is editing ontologies.
         2. Also simplifies developing new code for VIVO.
         3. At UQAM librarians, ontologists and developers are using VIVO Studio: tool for multidisciplinary development with VIVO.
         4. TopBraid Composer is the only commercial component.  There is a free edition; needs to be downloaded separately.
         5. VIVO Studio can be used without TopBraid Composer.
         6. Currently not designed for use with production phase; publishing to production would require development of new plugins.
         7. Can edit any part of VIVO and compile and run.  Everything needed to run VIVO is inside.
         8. Accelerates development/debugging cycle.
      3. William: only potential downside of steering new implementers to VIVO Studio is pushing people into an Eclipse environment when there are other popular alternatives.  May be difficult to get non-Eclipse developers to adopt Eclipse.  Effort required to maintain may not be justified.  The clear benefit is that having a ready starting place to start working that doesn’t require setup.
      4. Michel:  upcoming sprint for VIVO Studio.  At end can collect comments and evaluate whether it’s ready to be used by the community.  Use it for one or two weeks and see if it’s good enough.
      5. Dragan: I’ve been using IntelliJ for years now but am interested in using VIVO Studio.
      6. Michel:  Using a Linux VM may be the easiest way to evaluate VIVO Studio’s capabilities.  Hard to maintain Eclipse plugins on Macs; different from the other OSes.
      7. Push to production: develop before or after re-architecting?
         1. Michel: can already push to GitHub.
         2. William: makes more sense after re-architecture.  Decoupling might result in multiple modules that need to be deployed; would break publishing.
      8. Michel will check with UQAM whether code can be moved to vivo-community.
Editing forms
2. Editing forms
   1. Tatiana: Need to adapt a lot of editing forms according to the wishes of collaborating partners.  Making this easier could be of great value to the wider community.  Are various components in the current structure that are in different places, and to adapt or build a custom entry form you need to go to various different directories and understand how they interact.
   2. Michel: VIVO Proxy has overlap with this area of interest.  Once things are exposed as API you can make your own form interface.
   3. Georgy:  have talked about creating an ontology for editing behavior so that we can specify abstract form behavior and then expose that configuration via an API.  Let users describe what data should be edited and how it should be validated without touching Java generator classes.
   4. Tatiana: Could be something more like page management or like Georgy’s translation tool in the developer panel.
   5. Georgy: use declarative declaration of form behavior.  UI generation would be a separate task; could be created in Javascript or continue in Freemarker.
   6. William: makes sense as a first step to decoupling.  How is form submission translated into actual triple store updates?
   7. Georgy:  forms specify named functions for processing the updates, with associated access control and validation options.
   8. Michel: Before doing GUI form builder we need to have a JSON API.  Need SPARQL/RDF-less manipulation of data with JSON.  After we have that we can add things like GUI or Kafka messaging.  This is the goal of the VIVO-Proxy project.  Proxy talks to VIVO either via SPARQL Update or by emulating form submission. Tested last week by uploaded 1500 persons and 200-500 articles per person.  Takes around 5-6 hours to populate VIVO.
      1. Georgy: Are there tests of populating via the form submissions so that we know when we break this behavior during decoupling?
      2. William: When we decouple the front end there’s no way that the existing form behavior will continue to work.  Having Proxy dependent on this will require a lot of maintenance.
      3. Ralph: need to have a possible path forward with decoupling before we can commit to something stable that the Proxy can tap into.  Don’t have enough info yet.
      4. Michel sees the Proxy as something that can help us develop the decoupling.
3. Scoring columns have been filled out on the spreadsheet.
4. If we don’t agree with the scoring, we should add comments to the spreadsheet.
5. Publishing from VIVO Studio to staging or production servers?
7. 1.12.1 artifact IDs are being used but those artifacts are not available.

...