Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Draft notes in Google-Doc  

  • 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.
  • 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

Actions

  •   

Previous Actions

...