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. Benjamin Kampe 
  3. Georgy Litvinov 
  4. Michel Héon 
  5. William Welling 
  6. Benjamin Gross 
  7. Ralph O'Flinn (star)
  8. Don Elsborg 
  9. Huda Khan 
  10. Dang Vu Nguyen Hai
  11. Christoph Gopfert

Agenda

  1. New feature contributions (Georgy):
    1. VIVO-2001 PR: adding SMTP authentication: https://github.com/vivo-project/Vitro/pull/240
    2. VIVO-2002 PR: adding online translation https://github.com/vivo-project/Vitro/pull/241 Example https://vivotest.iphras.ru/vivo-translate/
  2. VIVO-PROXY demo (Michel) / discussion
    1. https://www.researchgate.net/publication/352817276_VIVO-PROXY_PROOF-OF-CONCEPT_A_SwaggerOpenAPI_tool_for_VIVO_Data-Ingestion_process?channel=doi&linkId=60dafc8c458515d6fbe7f367&showFulltext=true
    2. Defining entity-based APIs
    3. Extensibility
  3. 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 
  4. Prioritizing future development items:
    1. quick wins / items for a more rapid release
    2. collaborative items for future sprints
    3. (Add/edit at will) spreadsheet: https://docs.google.com/spreadsheets/d/103P9P4v6yUBSb5BnVaK40NoGx1fIYyL8uaHKUubZWbE/edit?usp=sharing

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

  1. New feature contributions (Georgy):
    1. VIVO-2001 PR: adding SMTP authentication: https://github.com/vivo-project/Vitro/pull/240
    2. VIVO-2002 PR: adding online translation https://github.com/vivo-project/Vitro/pull/241 Example https://vivotest.iphras.ru/vivo-translate/
      1. Creates map with user translations in browser.  Substitutes translations from VIVO with translations made by the user and stored in browser cache.  When translations have been collected, they can be exported.  Or update VIVO/Vitro properties with the values that were added. 
  2. VIVO-PROXY demo (Michel) / discussion
    1. https://www.researchgate.net/publication/352817276_VIVO-PROXY_PROOF-OF-CONCEPT_A_SwaggerOpenAPI_tool_for_VIVO_Data-Ingestion_process?channel=doi&linkId=60dafc8c458515d6fbe7f367&showFulltext=true

Brian: Interesting to see API implementation. Big question: What kind of dependencies on editing forms are in? How hard will decoupling be?

Michel: Brief overview of the Proxy. It is classical VIVO in pull mode ingestion with some harvester. Idea is to push data to Proxy to send it to  VIVO server.

Without doing modification to VIVO we manage data to VIVO. You can have separate development from VIVO itself to decouple development of VIVO and Proxy. Technology Michel using for that is Swagger. Swegger is based on OpenAPI technology. So you have an editor where you code the interface itself in yaml or json and on the right side you will see the html page produced. You can POST GET and when you finish API design you can generate the code to manipulate the API. For VIVO Ajax or REST API, you can use Spring if you want it.  You will have 2 servers: VIVO itself and API of VIVO. VIVO is running inside Tomcat and Proxy is running in Jetty. You have server side code ang generate client side code, which is calling the API. This is really interesting, especially for data scientists and librarians. It could create APIs to put data inside of VIVO. It is really simple for people with computer science expertise. So this is interesting solution to put data without using SPARQL Query for that. Michel is develop it inside VIVO Studio as it has more facilities to manipulate VIVO. 

In the editor you can edit API for person, organization, etc. When swagger environment var defined many tools available. If you call maven call to generate source then all the client and server code will be generated to manipulate API. You can customize this generated code to put the data inside of VIVO. The way Michel doing this he use design pattern Command. The way he put data inside VIVO user interface is used. This is a graph to add a person. A lot of individuals and properties to create. If you want to add a person you have to create SPARQL query to create it.

As VIVO knows how to create a user Proxy can use the same interface, user used to do that. This is an API for VIVO. In FF development tool, network panel and adding a new user is just a request to VIVO.

Inside Postman Michel can use GET Request params from Firefox. Inside Postman Michel can generate Java code for this request. For each VIVO screen in that way Michel can get requests to generate data in that way. In that way bash client command generated by Swagger Michel can directly create a person.

In the return you can get JSON, RDF or any other semantic format.

The Java Request is coded inside of class VIVO Receiver. This is HTTP client code extracted from Postman.  

In that way VIVO Caller could be easily adapted and changed. 

Authorization could be configured right from API. In secure context you can use this API as a Firewall for VIVO implementation. It is compatible with all levels of auth mechanisms. It is very flexible.

Georgy: If we change something it freemarker templates and generators proxy could break?

Michel: it only uses html and requests.

Georgy: If we change n3 editing generators it could fail? So should we freeze generators then?

Michel: not really as we don’t need forms for Proxy.

Brian: If we decide that middle name is required then your request might fail. So in that case you are relying on forms.

Michel: The motivation for that in UQUAM we want to stay align with evolution of VIVO. Some librarians are trying to add data to VIVO with SPARQL. So this solution simplifies work with VIVO for not experienced users. UQUAM wants to implement Data Connect so with VIVO Proxy we can use VIVO to push data to VIVO and extract data from it. 

William The sooner we get away from freemarker forms the better.  Working with data is very important for VIVO. It would be better to have some configuration so we can use it with Open API, put it json schemas and use it. With ability to consume we need also disambiguation.

Michel: disambiguation is the work of librarians mostly. The librarian will create a robot that would pull the data, disambiguate it and send it to the proxy. 

William: This work should be automated if it could be automated.

In old VIVO and Vitro it was a CMS kind of system and all editing forms were generic. Then all these pieces were done in multiple ways.

Brian: We first need to get sense what parts could be modified in current VIVO. Now we have dependencies on editing forms. It would be nice to scrape off ui level away.

-- 

Michel: You can consider a graph as a 3 dimention system, and when we extract data from JSON we put data from 2 dimension data to 3 dimension. And graph is multiplication of all the windows and volume, but when API is being made we need more representation.

Brian: There are a lot of simple and complex things VIVO do with data. If we can get people in a mode of a graph it would make Vitro and VIVO compelling application.

William: We should leave it always configurable and flexible.

--

Draft notes on Google Drive



  • No labels

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