Date
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
- Self-register at: http://bit.ly/vivo-slack
Attendees
Indicating note-taker
Agenda
- Landing Design - External Search
- New feature: Messaging
- Based on the IndexingChangeListener pattern
- Potentially with RDF-Patch bodies
- VIVO Scholars Task Force sprint update
- TAMU Scholars / VIVO Scholars Entities
Tickets
- Needing additional review
Tickets
Status of In-Review tickets
Received
Bugs (1.11)
Notes
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
- - Mike Conlon, can you give this one a review?
Previous Actions
