...

Attendees

 Indicating note-taker

1. Brian Lowe
2. Huda Khan
3. Jim Wood
4. Don Elsborg
5. Ralph O'Flinn
6. Benjamin Gross 
7. Alexander (Sacha) Jerabek 
8. Steven McCauley
9. Mike Conlon
10. Amin Kesharav
11. Huda Khan
12. Benjamin Gross

Agenda

1. Community updates (additional review?)
   
   1. VIVO Scholars
2. Special topics for future dev calls
   1. 2019-12-06 - Special Topic - TDB vs SDB
   2. Summary/report out?
3.  In-review tickets 

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

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

   3. 
      

      Expand
      Jira server DuraSpace JIRA jqlQuery filter=14416 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

      
      

4. Updates from 2019-11-27 - VIVO Committers Meeting

...

• Community updates (VIVO scholars)
• Record and share demos to show implementation plan
Duke: stock VIVO instance that will load into scholars discovery instance - that in turn loads into React to show new UIOutput: person could have many positions that show up as “relationships”
• • Working on building out the UI
  • Currently uses OpenVivo data, will be changed in coming weeks to load from our test Vivo instance as we populate more dataPublication lists and web components to show individual 
  • Trying to make sure return types make sense
  • Index from VIVO: relationships are quite broad
• • • Huda: ontology setup for “related” or base property used in many different contexts?
    • Jim: seems to be the case.  Indexing done by TAMU - using their scholars discovery
    • Anything “related by” shows up in index as relationship, but confusing on output level
    • Why would appointment to biology department have a thumbnail? (lots of different properties possible for this base relationship but not all may be relevant)
    • Huda: faux properties seemed to be a way of addressing this issue in the core/traditional VIVO app   
Demo Sites
• • Output: person could have many positions that show up as “relationships”
  • GraphQL: https://scholars-discovery-scholars.cloud.duke.edu/gui
  • UI: https://vivo-scholars-scholars.cloud.duke.edu/
  • Test VIVO: https://vstf-vivo.cloud.duke.edu/
• Record and share demos to show implementation plan
• Duke: stock VIVO instance that will load into scholars discovery instance - that in turn loads into React to show new UI
• Demo Sites
• SDB vs TDB call
  • Don: Andy talked about TDB and TDB2 and the work Graham did for SDB.  For loading and amount of triples, Andy seemed confident that TDB could scale larger than SDB.  Also looking at RDF messaging/delta patch work to look at clustering capabilities.  
  • • Re SDB: Graham is stakeholder. Submitted his performance improvement changes. In Jena 3.11.  Andy encouraged. But no discussion of changing SDB status from no longer actively supported.  
    • Colorado plans on moving forward with TDB work
    • Andy: backup nodes/quads.  Graham concerned about concurrency since TIB is highly concurrent system.  Graham trusts SDB more in this sense.
  Brian: If I recall correctly,
  • • Andy
  considers TDB more trustworthy than SDB and TDB2 since it has seen more real world use and thus there has been more opportunity for bugs to be found and fixed (b/c TDB2 is too new and SDB didn’t get as much traction)
  • Next steps? Any?
  Andy
  • • : keep discussion going - interested in maintaining relationship with VIVO community
    • VIVO dev/committers: continue discussion around technical details before making final decision
  • RDF delta patch: Don: even though William (TAMU) didn’t get it to work with SDB, Andy didn’t rule out that it could work with a few modifications.
  • • Brian: Challenge in VIVO: because an SDB Dataset can’t use a JDBC connection pool, VIVO manages the connection pool and has to associate a Dataset with each connection. No single dataset object persists in VIVO, so I suspect that when William tried to use dataset to attach delta patch, ran into trouble trying to listen to changes at the Dataset level 
    • To get it to work, change it to ignore the built in Jena implementation, and attach delta patch to RDF service and not assume there is a Jena dataset object you can use
    • Cleavage point: take Jena work but attach it to change listener in RDF service instead of at the jena dataset change listener level
  • Don: Andy talked about TDB and TDB2 and the work Graham did for SDB.  For loading and amount of triples, Andy seemed confident that TDB could scale larger than SDB.  Also looking at RDF messaging/delta patch work to look at clustering capabilities.  
  • Brian: If I recall correctly, Andy considers TDB more trustworthy than SDB and TDB2 since it has seen more real world use and thus there has been more opportunity for bugs to be found and fixed (b/c TDB2 is too new and SDB didn’t get as much traction)
  • Next steps? Any?
  • RDF delta patch: Don: even though William (TAMU) didn’t get it to work with SDB, Andy didn’t rule out that it could work with a few modifications.
  • In-review tickets
  • ORCID language strings
  • Jena 3 export of TDB databases
  • https://jira.lyrasis.org/browse/VIVO-1700 + https://jira.lyrasis.org/browse/VIVO-1699 - Created to address a specific use case and generalize it. Most in ontology group agreed it was a good idea.
  • Status of https://github.com/vivo-project/VIVO/tree/vivo-1.11.0-lib-updates and Vitro version? Ralph was looking at it, let’s discuss on the next call when Ralph is here.
  • VIVO scholars UI
  Started out as React but has moved/is moving to Web components (based on GraphQL/REST APIs)
  • • Server side: written in Go - web framework = Buffalo (like Ruby on Rails/python and django)
    • Goal: provide flexibility without having to touch Go code
    • Deployed with one file
    • Web components: accepted as a web standard.  Doesn’t really address the same React problems (not about saving client-side state)
    • Using LIT element (evolution of polymer) (library on top of raw web components) - adding helpers on top of standard web components
    • TAMU did JAVA so GraphQL or REST or both?
    • TAMU split their repo: pulled it into VIVO community so that you could add a GraphQL endpoint (data indexed in the same way and data is available through either GraphQL or their REST)
  • Started out as React but has moved/is moving to Web components (based on GraphQL/REST APIs)

  
  

  Huda wants to follow one concrete example all of the way through from the sparql triplestore->rest->graphql and onwards

  ...