Date
Call-in Information
Time: 11:00 am, Eastern Time (New York, GMT-05: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
- Don Elsborg
- Huda Khan
- Ralph O'Flinn
- Andrew Woods
- Steven McCauley
- Harry Thakkar
- Julia Trimmer
- Richard Outten
- Jim Wood
- Alex Viggio
- Brian Lowe
- Robert Nelson
- Greg Burton
- Andrei Tutor
- Paul Albert
- James Silas Creel
- Douglas C. Hahn
- William Welling
- Benjamin Gross
Agenda
TAMU Scholars Demo
Texas A&M University will be demonstrating work that has been completed on their replacement for the VIVO user interface front end (TAMU Scholars). This replacement front end is based on Solr, Spring Data, and Angular Universal. The basic goals of this front end are:
Align the technology stack as much as possible with the existing VIVO stack to assist with ease of implementation by others if they choose especially smaller libraries.
Read only UI.NO updating back to the triple store.
100% Search Engine Optimization. IE: A person / crawler does not need JavaScript enabled for page rendering. Server side, and Client side rendering if needed.
TAMU Scholars follows much of the same ideas of the VIVO Scholars Task Force but with a slightly different technology stack. (GitHub Repo)
TAMU Scholars Link
Spring Data Solr API LinkOther topics (that can be pushed to next week)
VIVO-Docker2 pull-request and approach
Tickets
Status of In-Review tickets
Received
Bugs (1.11)
Notes
TAMU demo
Scholars UI API: demos.library.tamu.edu/scholars-ui-service/api
Spring Docs API documentation
Sample request and responses
Goes through Spring CRUD repo to Solr: filtering, pagination, etc. out of the box on top of Solr
Solr index created via harvest mechanism. Creates explicit JAVA model of all properties to be indexed and filters/facets. A SPARQL query for each of those properties/Solr fields.
Top level tabs mirror VIVO: People, Organizations, Research etc.
Paginated results with subclasses/related types in the left facet column
Turning off JavaScript will still result in the same experience which is a priority for Google Scholars crawling
Main search box provides search across all content types
Results have tabs for different types (people, publications, grants, awards, courses, concepts)
Template for person result will be different from publication etc. Different templates for type
Entity view shows information for that person, publication etc.
Tabs for info (mirroring VIVO property group tabs)
Templates still in progress but many completed. Many sections per entity
Server-side rendering is optimization as well as providing SEO. Also plays into screen readers/accessibility and ADA compliance
Alex: Motivation for Google Scholar
Most prominent example of a crawler not indexing our site because site relies on JavaScript
Real goal: any search engine out there can crawl the institution’s scholarly information and that information can be discoverable and accessible
Back to experience with DSpace and trying to get information to be indexed.
Search functionality using Solr copy fields
Copies from a source field to other fields, e.g. text field which can be used for searching for any terms in that content
Author’s name, research areas added for expression searching
Default is OR. Can also use AND
Front-end written to talk to the Scholar REST API endpoint.
Solr: nested document support not what they needed. Flattened fields into Solr
Multiple Solr collections - one per entity type
Persons
Positions : [“Associate Professor::n876…”]
:: delimiter helps encode the different components of information - converted into a nested array for the front-end
Even when searching across people, may need info from publications to be displayable
Can do lazy fetching of results as needed, e.g. publications. Fields identified as being lazily rendered - the ids are used to fetch info when display required and then those are added to the main object being used for display
YAML file configures the facets that will be shown on the search pages
Which templates, name, and the facets to be included
Different types of views: directory (e.g. main organizations tab), discovery (through main search box which shows different tabs for entity types in results)
Andrei: Angular universal just in server-side rendering?
Node server that pre-renders the page
When you refresh, it loads quickly - pre-rendered and handed off to the client
If JavaScript enabled, it “rehydrates” and takes over
Every view rendered by Angular, discovery and other templates rendered by JavaScript doT (olado.github.io/doT)
Databases. Please fill in details. Thanks. Hibernates.
Translation mechanisms for themes
Theme is also persisted in the database
Configurable: text, images, etc.
Use Bootstrap
Dynamic theming via CSS variables
Andrew: follow-on conversation about what we can learn from the different initiatives. What are collaboration points?
VIVO Scholars, VIVO Core, and TAMU Scholars
Striking similarities between overall high level architecture between VIVO Scholar/Product evolution and TAMU scholars
Swap out specific implementations/technology choices
Actions
- Mike Conlon, can you give this one a review? -
Previous Actions