...
- 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)
- GraphQL would be doing that in one request i.e. getting as much info as much as possible
- 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)
- 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
- Ralph (deserves all the cake!!)
- 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
...