...
- Brian Lowe
- Ralph O'Flinn
- Huda Khan
- Maria Florez
- Rafa
- Mike Conlon
- Richard Outten Alex Viggio
- Benjamin Gross
- William Welling
- Julia Trimmer
- Rob NelsonDon Elsborg
Agenda
- Sprint Goals
- VIVO Scholars Task Force sprint update/demo (Richard Outten , William Welling , +Team)
- OpenVIVO - openvivo sample data loaded into the VSTF application
- GraphQL
- TAMU Scholars
- Tickets in-review
- Needing one more review - any volunteers? low-hanging
Jira server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1687
Expand Jira server DuraSpace JIRA jqlQuery filter=14416 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5
- Needing one more review - any volunteers? low-hanging
...
- VIVO Scholars task force update: Started with TAMU middleware layer to see if we can add GraphQL endpoint to Front-end in this case is completely run by
- GraphQL endpoint Able
- to reflect back on what is in the Solr index and create GraphQL resolvers
- Schema outlines structure of data GraphQL configuration speaks to TAMU middleware which speaks with their SolrTAMU use case driving person/documents solr core distinction
- 7 Solr cores with separate set of queries possible for each core
- Publications data in person Solr core is there for faceting and querying but does not reflect all of the data in the documents (which has all the publication info)
- If you want to power the front-end, you would want more publications data
- Flexibility with GraphQL: can choose what you want
- When looking at the person search results, you get publications information back when you want (e.g. user clicks on a publication or asks for publication info, request is sent to retrieve that info and render that info)
- Ability to have server to do bundling of comprehensive object
- If you want to power the front-end, you would want more publications data
- Flexibility with GraphQL: can choose what you want
- TAMU use case driving person/documents solr core distinction
- GraphQL would be doing that in one request i.e. getting as much info as much as possible
- Resolver to get data in shape
- Define mappers and converters for GraphQL
- Front-end in this case is completely run by GraphQL endpoint
- Able to reflect back on what is in the Solr index and create GraphQL resolvers
- Schema outlines structure of data
- GraphQL configuration speaks to TAMU middleware which speaks with their Solr Ability to have server to do bundling of comprehensive object
- Next steps: build GraphQL structure some more to get full-feature nested objects
- Resolver to get data in shape Define mappers and converters for GraphQL
- Front-end piece: haven’t done much with that yet but do plan on it eventually
- From Andrew’s email (copy/pasted)
- The local VIVO installation can use TBD or SDB
- VS (VIVO Scholar) extracts content from the VIVO triplestore via sparql-queries
- The results of those queries go into an index (now Solr, ElasticSearch soon)
- In any case, the VS frontend calls the REST API of the VS backend that exposes the indexed content via an API
- I have updated the deployed VSTF (VIVO Scholar Task Force)/TAMU configuration to use OpenVIVO person thumbnails and have done some "quick and dirty" styling to make the site more reminiscent of openvivo.org.
- http://54.160.51.113:4200/
- For those who have not been working on the VSTF/TAMU application, my brief summary of the architecture is:
- The local VIVO installation can use TBD or SDB
- VS (VIVO Scholar) extracts content from the VIVO triplestore via sparql-queries
- The results of those queries go into an index (now Solr, ElasticSearch soon) In any case, the VS frontend calls the REST API of the VS backend that exposes the indexed content via an API
- Updating VS configuration to support the OpenVIVO content was relatively straight-forward. It would be interesting to discuss other features that would be good to expose in VS.
- Julia sent out email to community list and posted updates on wiki/mockups. Put some out there and collecting feedback by survey.
- Take a look and give your thoughts and take the survey
- Profile page mockups, 3 different approaches
- Also working on search page mockups and will put those out there
- Also townhall on July 11th: open to everyone and hoping to get thoughts and questions
- Take a look and give your thoughts and take the survey
- https://wiki.duraspace.org/display/VIVO/VIVO+Scholar+Task+Force
- Ralph (deserves all the cake!!)
- Did that with installed version of VIVO
- Sprint search: merged into copy of develop
- Fixed all merge issues
- Tested in docker
- Latest MariaDB and latest Solr (version 8) Did that with installed version of VIVO
- Dockerized VIVO itself with latest snapshot of development search (1.1 1)
- All works great!
- Loaded up with test data and real data - continues to work great!
- Once Don has tested it, we can call it a day!
- Enable connection of decoupled, read-only "profiles" user interface to VIVO
- Andrew’s open vivo example
- Work that the task force has done
- Shapes? Nothing finalized yet
- Tickets in review https://jira.duraspace.org/browse/VIVO-1687
- Pull request: https://github.com/vivo-project/VIVO/pull/125
- Need just one more reviewer: https://github.com/vivo-project/VIVO/pull/125
- https://jira.duraspace.org/browse/VIVO-1692?src=confmacro
- What style do we actually want to enforce?
- https://github.com/vivo-project/Vitro/compare/develop...awoods:vivo-1692?expand=1#diff-d3455d71ca9aa05152222bc3d6ae20ddR19
- Right now it is setting up infrastructure but all checks are disabled -if suppressions are removed then we would see these style rules applied
Actions
Previous Actions
...