...

 Indicating note-taker

1. Don Elsborg
2. Brian Lowe 
3. William Welling 
4. Benjamin Gross
5. Huda KhanMike Conlon 
6. Ralph O'Flinn
7. Alex Viggio
8. Julia Trimmer
9. Federico Ferrario
10. Paolo Bonora
11. Hans Harlacher
12. Damaris Murry
13. Richard Outten

Agenda

1. Landing Design - External Search
2. New feature: Messaging
   1. Based on the IndexingChangeListener pattern
   2. Potentially with RDF-Patch bodies
3. VIVO Scholars Task Force sprint update
4. TAMU Scholars / VIVO Scholars Entities

5. Tickets

   1. Needing additional review

      1. Jira
         server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1692

      2. Jira
         server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1687

      3. Jira
         server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1675

          - Benjamin Gross?

   2. 
      

      
      

      Expand
      title Received Tickets...
      Jira server DuraSpace JIRA jqlQuery filter = 14802 ORDER BY created DESC serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

      
      

...

Draft notes in Google-Doc

Don has broken trees.  Don saved the peach tree through proactive action.

Ralph reminisced about snow storms.  Is there a conspiracy between milk and bread companies and meteorologists?  

(It’s that kind of meeting)

Search externalization:

Ralph: ElasticSearch configuration for roles, etc. coming out of the box.  Wanted to try this out.

Ralph: Messaging feature: Has anyone looked at this yet?

Two parts: indexing listener and RDF patch

Based on TAMU discussions around RDF?

Don: Anyone looked at the branch from Cineca that creates document modifiers based on json configuration

https://github.com/vivo-project/Vitro/pull/123

Are these two things related? They would play together in that the indexing listener would wait for events which would then trigger indexing, and once that is triggered, document modifiers are used to populate the index

Scholars task force update:

Ralph: Don, what do YOU think?

Don: Starting to converge

TAMU’s demo included reference to GraphQL.  Looking at technology stacks, perhaps we can begin to agree.  For example, TAMU is ok with JAVA, so perhaps we can continue with JAVA.  

Ralph: Front-end, do we go with Angular or React?  

Don: Ambivalent.  If move out from data interface layer, wondering if we could use the same set of JavaScript libraries that consume services and integrate those with both Angular or React. Would be good to have client-side code for consuming GraphQL data is the same regardless of implementation.

Ralph: Once GraphQL piece setup, front-end could be anything anyone wanted.  

Don: Agree generally but not everyone can build their own front-end.  As long as service consumer is common set of libraries and it is easy to style so people can go in and implement their own branding.  Haven’t discussed that yet. William has github page with data models for their first level objects. Perhaps can pair with Ralph to reconcile that with the Product Evolution json.  Questions to ask: do we have all the fields we want? Comprehensive? What is the final structure of the json payload? (Nest organization under affiliation, etc.) Also what will be the index structure.

Ralph: Pick up issues to review and then notify people on develop channel.

Moving from SDB to TDB. VIVO-1521

Don: Experiments done with different databases (MariaDB etc.)

Something about emojis

SDB code, looked at flush command, etc.  Found getLoaderNodes that constructs insert statements for SQL.  Uses library stringbuilder which uses string.length which returns 2 for 4 bytes and 1 for everything else.  That needs to be overridden or find a different library.

Why not transition from SDB to perhaps BlazeGraph?

Ralph: invested in SDB/TDB/Jena.  Good to switch to TDB and then also enable BlazeGraph.  Could go with Wikimedia version of BlazeGraph since that is a supported version.  

Don: Andrew said we could put triplestore into its own container.  VIVO to fuseki endpoint to whatever

Ralph: could sort this out in breaking out the pieces

Don: Prospect of integrating graph.  

Ralph: As part of sprint, got blazegraph running with sprint search branch

Don: If VIVO runs against blazegraph, how would inferencing work against an external triplestore?

Brian: Could work same way if external triplestore has inferencing turned on, or turn off VIVO inferencing and use the external triplestore.  Could go either way. Challenges if you wanted VIVO to take advantage of reasoning inside the triplestore especially on display with filtering out redundant inferences.

Actions

•  

  Jira
  server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1659

   - Mike Conlon, can you give this one a review?

...