...
- Brian Lowe
- Ralph O'Flinn
- Huda Khan
- Maria Florez
- RafaMike Conlon
- 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 Solr
- 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
- TAMU use case driving person/documents solr core distinction
- 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 https://wiki.duraspace
- . org/display/VIVO/VIVO+Scholar+Task+Force
- 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
...