Date

02 Jul 2019

Call-in Information

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

To join the online meeting:

• Go to: https://duraspace.zoom.us/j/823948749
• Or iPhone one-tap :
  • US: +14086380968,,823948749#  or +16468769923,,823948749#
• Or Telephone:
  • Dial(for higher quality, dial a number based on your current location):
  • US: +1 408 638 0968  or +1 646 876 9923  or +1 669 900 6833
  • Meeting ID: 823 948 749
• International numbers available: https://duraspace.zoom.us/zoomconference?m=Qy8de-kt6W4fMMDQCAV_3qfH1W-lxAo5

Slack

• https://vivo-project.slack.com
  • Self-register at: http://bit.ly/vivo-slack
    

Attendees

 Indicating note-taker

1. Brian Lowe 
2. Ralph O'Flinn 
3. Huda Khan
4. Mike Conlon
5. Richard Outten
6. Benjamin Gross
7. William Welling
8. Julia Trimmer
9. Rob Nelson

Agenda

1. Sprint Goals
   

   1. External Search

      1. Merge 'sprint-search' (vivo, vitro) into 'develop'?

   2. Enable connection of decoupled, read-only "profiles" user interface to VIVO

   3. Define "shapes" of VIVO entities

   4. Dockerize appropriate components

2. VIVO Scholars Task Force sprint update/demo (Richard Outten , William Welling , +Team)
   1. OpenVIVO - openvivo sample data loaded into the VSTF application
   2. GraphQL
   3. TAMU Scholars
3. Tickets in-review
   1. Needing one more review - any volunteers? low-hanging
      1. Unable to locate Jira server for this macro. It may be due to Application Link configuration.
   2. Click here to expand...

      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.

Tickets

1. Status of In-Review tickets

   Click here to expand...

   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. Received

   Click here to expand...

   Click here to expand...

   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.

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

      1. (re-)Raises interest in reconsidering first-time, every-time, tdbconfig design

   2. Unable to locate Jira server for this macro. It may be due to Application Link configuration.
      1. Should be low-hanging

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

      1. Where does this stand? What is needed to add more person identifiers to VIVO?

   4. Unable to locate Jira server for this macro. It may be due to Application Link configuration.
      1. Mike Conlon : thoughts on where this stands?

3. Bugs (1.11)

   Click here to expand...

   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 

Draft notes in Google-Doc  

• VIVO Scholars task force update: Started with TAMU middleware layer to see if we can add GraphQL endpoint to
  • 7 Solr cores with separate set of queries possible for each core
  • Publications data in person Solr core is there for faceting and querying but does not reflect all of the data in the documents (which has all the publication info)
    • When looking at the person search results, you get publications information back when you want (e.g. user clicks on a publication or asks for publication info, request is sent to retrieve that info and render that info)
    • Ability to have server to do bundling of comprehensive object
  • If you want to power the front-end, you would want more publications data
  • Flexibility with GraphQL: can choose what you want
  • TAMU use case driving person/documents solr core distinction
  • GraphQL would be doing that in one request i.e. getting as much info as much as possible
  • Resolver to get data in shape
  • Define mappers and converters for GraphQL 
• Front-end in this case is completely run by GraphQL endpoint
• Able to reflect back on what is in the Solr index and create GraphQL resolvers
• Schema outlines structure of data
• GraphQL configuration speaks to TAMU middleware which speaks with their Solr
• Next steps: build GraphQL structure some more to get full-feature nested objects
• Front-end piece: haven’t done much with that yet but do plan on it eventually
• From Andrew’s email (copy/pasted)
  • The local VIVO installation can use TBD or SDB
  • VS (VIVO Scholar) extracts content from the VIVO triplestore via sparql-queries
  • The results of those queries go into an index (now Solr, ElasticSearch soon)
  • In any case, the VS frontend calls the REST API of the VS backend that exposes the indexed content via an API
• I have updated the deployed VSTF (VIVO Scholar Task Force)/TAMU configuration to use OpenVIVO person thumbnails and have done some "quick and dirty" styling to make the site more reminiscent of openvivo.org.
• http://54.160.51.113:4200/
• For those who have not been working on the VSTF/TAMU application, my brief summary of the architecture is:
• Updating VS configuration to support the OpenVIVO content was relatively straight-forward. It would be interesting to discuss other features that would be good to expose in VS.
• Julia sent out email to community list and posted updates on wiki/mockups.  Put some out there and collecting feedback by survey.
  • Profile page mockups, 3 different approaches
  • Also working on search page mockups and will put those out there
  • Also townhall on July 11th: open to everyone and hoping to get thoughts and questions
• Take a look and give your thoughts and take the survey
• https://wiki.duraspace.org/display/VIVO/VIVO+Scholar+Task+Force 
• Ralph (deserves all the cake!!)
  • Did that with installed version of VIVO
• Sprint search: merged into copy of develop
• Fixed all merge issues
• Tested in docker
• Latest MariaDB and latest Solr (version 8) 
• Dockerized VIVO itself with latest snapshot of development search (1.1    1)
• All works great!
• Loaded up with test data and real data - continues to work great!
• Once Don has tested it, we can call it a day!
• Enable connection of decoupled, read-only "profiles" user interface to VIVO
• Andrew’s open vivo example
• Work that the task force has done
• Shapes? Nothing finalized yet
• Tickets in review
  • Pull request: https://github.com/vivo-project/VIVO/pull/125
  • Need just one more reviewer: https://github.com/vivo-project/VIVO/pull/125
  • What style do we actually want to enforce?
  • https://github.com/vivo-project/Vitro/compare/develop...awoods:vivo-1692?expand=1#diff-d3455d71ca9aa05152222bc3d6ae20ddR19 
  • Right now it is setting up infrastructure but all checks are disabled -if suppressions are removed then we would see these style rules applied
• https://jira.duraspace.org/browse/VIVO-1687
• https://jira.duraspace.org/browse/VIVO-1692?src=confmacro

Actions

Previous Actions

• Unable to locate Jira server for this macro. It may be due to Application Link configuration.  - Mike Conlon, can you give this one a review?