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
Output: person could have many positions that show up as “relationships”
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
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.
Andy: keep discussion going - interested in maintaining relationship with VIVO community
VIVO dev/committers: continue discussion around technical details before making final decision
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.
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
Don: speaking with Harry from Duke regarding Docker. Grabbed fork of repo and set up on Colorado server. Want to move forward with multiple options for Docker implementations -e.g. One Docker compose that does SDB, one that does TDB. Would be nice to have Docker implementations that only spin up Solr container and the VIVO container and doesn’t do build inside Docker image (right now downloads all the things and deploys). Worthwhile to build VIVO image in another container and then push image to running Tomcat container -something more production ready than initial use case of Docker which is more about how to get system set up fast. (Possible future agenda item for review with Andrew - possibly set up an issue in GitHub for vivo community)
Oracle announced more knowledge graph support, Huda slacked a message about it, Don stayed up all night as a result. Don is going to look at it some more
Indicating note-taker