Versions Compared

Old Version 5

changes.mady.by.user Brian Lowe

Saved on

compared with

New Version Current

changes.mady.by.user Andrew Woods

Saved on

Key

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

...

  1. Ralph O'Flinn 
  2. Steven McCauley 
  3. Andrew Woods
  4. Brian Lowe (star)
  5. Don Elsborg
  6. Maria Amalia Florez
  7. Rafael Mancera
  8. Jose Mongui
  9. Huda Khan
  10. Jim Wood
  11. Benjamin Gross

Agenda

  1. VIVO 1.11.0 release... 

    1. External Search

      1. Merge 'sprint-search' (vivo, vitro) into 'develop'?
      2. Related branches
        1. https://github.com/vivo-project/VIVO/tree/sprint-search
        2. https://github.com/vivo-project/VIVO/tree/dev-search
        3. https://github.com/vivo-project/Vitro/tree/sprint-search
        4. https://github.com/vivo-project/Vitro/tree/dev-search
      3. Related tickets
        1. Jira
          serverDuraSpace JIRA
          serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
          keyVIVO-1589
        2. Jira
          serverDuraSpace JIRA
          serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
          keyVIVO-1592
        3. Jira
          serverDuraSpace JIRA
          serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
          keyVIVO-1596
        4. Jira
          serverDuraSpace JIRA
          serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
          keyVIVO-1600
        5. Jira
          serverDuraSpace JIRA
          serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
          keyVIVO-1612
        6. Jira
          serverDuraSpace JIRA
          serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
          keyVIVO-1611
  2. Integrating content and navigating between VIVO installations
  3. VIVO Scholars Task Force updates
  4. Tickets in-review
    1. Needing one more review - any volunteers? 
      1. Jira
        serverDuraSpace JIRA
        columnskey,summary,type,created,updated,due,assignee,reporter,priority,status,resolution
        serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
        keyVIVO-1692
      2. Jira
        serverDuraSpace JIRA
        serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5
        keyVIVO-1670


    2. Expand

      Jira
      serverDuraSpace JIRA
      jqlQueryfilter=14416
      serverIdc815ca92-fd23-34c2-8fe3-956808caf8c5


...

      1. Ralph:  Think we’re done.  Plan is to finish up merging and get it all cleaned up.  Was a good experience.
      2. Don: tested two things; one was external search.  No issue there. Also tested the smoke test; behaved well.  Was pretty straightforward.
    1. Blazegraph integration
      1. Andrew:  documentation related to 1.11 would mention Blazegraph but with caveats that it is not ready for production.
    2. Other “pet” tickets for release?
      3. Brian: Triple Pattern Fragment server not respecting visibility settings
    3. ?
      1. Switch to disable TPF server seems like the way to go, at least for now (https://jira.duraspace.org/browse/VIVO-1640)
        1. Andrew:  would also be good to refactor all the TPF code not directly related to VIVO out of the main codebase: seems to be a lot of source code copied and pasted from another project.
      1. Brian: Triple Pattern Fragment server not respecting visibility settings?
  1. Adagio use case
    2. Linking across VIVOs? 
    1. Maria: (call her Amalia): received information from Huda via Slack. Would like to have what Huda did with the Connect project: pretty much what they’re looking for
    3. .We provide services for universities in Latin America.  Provide instance that each university can see their researchers.  Project is to connect those people within the same research ecosystemSearch across multiple VIVOs from one single VIVO website.
    1. .
      1. Example:  Researcher from University A connected to University B because they have products in common.  But current use case is how to connect people who don’t already have products in common.
      2. Want to be able to search and find everyone who is connected in the same ecosystem, and add them to a capability map (even if they have no works in common).
      3. Want to connect their ecosystem to other VIVOs abroad.
      1. We provide services for universities in Latin America.  Provide instance that each university can see their researchers.  Project is to connect those people within the same research ecosystem.
    2. Huda: Feature requirements?
      1. If searching for “Biology” from VIVO A, the results of people and research are not just from Institution A but also from other universities
    5. ?Capability Map:  also bring back data from multiple VIVO instances
      1. ?
      1. Amalia:  Want access to index from another VIVO.  Don’t want to duplicate content but harvest [discover?] content in other VIVOs?
        1. Don’t want everything duplicated.  Just pull content in order to expand the capability map.
      2. Huda: 
        1. Use sameAs relationship from UNAVCO to Cornell, traverse sameAs dynamically in the interface to render content from Cornell VIVO.
        1.  For UNAVCO/Cornell Connect example, there are pieces of code that were added to each VIVO instance in order to bridge across different profiles for the same person
    6. .Use sameAs relationship from UNAVCO to Cornell, traverse sameAs dynamically in the interface to render content from Cornell VIVO
        1. .
        2. For search index, we set up whitelists to allow e.g. UNAVCO to search Cornell’s SOLR:
        3. Miles Worthington’s VIVO Searchlight might also be relevant (https://github.com/milesw/searchlight) 
      1. Rafael:
        1. Do the VIVO instances communicate directly with one another to read one another’s SOLR index or is there some intermediating layer?
        2. Huda:  Yes. In UNAVCO/Cornell example, each had two SOLR URLs configured (local and remote);  could search both directly, because each server had access to the other’s SOLR.
        3. Code still exists but Cornell’s instance does not, so this setup is no longer running live.
      2. Huda: 
        1. Also a component of reading profile JSON from another VIVO.
      3. Amalia:
        1. Interested also in a JSON approach as we are integrating non-VIVO sites using JSON.
      4. Huda:
        1. VIVO community also working now on GraphQL and other new developments that might also address this use case.
      5. Amalina:  Open to collaborating/collecting with others working in this space.
      6. Andrew:  Was there discussing of including the UNAVCO/Cornell work in a release of VIVO
        1. Huda:  JSON part was shot down because it was a direct translation of Java objects and not the kind of JSON people were expecting to see.  Can’t remember if we discussed the search part.
        2. Benjamin says there was a pull request at some point, but wasn’t acted on.
        3. Huda:  Can possibly do a code walkthrough on a future call.
      1. Search across multiple VIVOs from one single VIVO website.
      2. Capability Map:  also bring back data from multiple VIVO instances?
    • Linking across VIVOs? 
  7. VIVO Scholars Task Force update
    1. Jim Wood: In this sprint, filling out the base of the GraphQL endpoint.  Planning to auto-generate much of the GraphQL endpoint. Will be producing two front-end examples in Go and Javascript.
      1. One GraphQL query mapping to a template
      2. Should be easier to maintain with standard web development skills
      3. Use data from any source and query it in a unified fashion
      3. Huda: GraphQL would allow you to conduct searches as well.  Is it possible to extend that across multiple search indices?  
      1. Jim:  In theory it is possible; don’t know at this time how much work would be involved.
      4. Andrew:  Is the current approach in the VSTF to have a GraphQL endpoint over the Solr index, or is it backed by ElasticSearch?
      1. Jim:  Underlying architecture now is Solr.  With Spring data abstraction layer, possibility to use ElasticSearch.  Can be done at the lower level of code so as not to impact the GraphQL endpoint.  Not something to launch with.
      2. Andrew:  Solr is a different Solr from the main VIVO Solr?
        1. Jim: Yes.
      • Jim Wood: In this sprint, filling out the base of the GraphQL endpoint.  Planning to auto-generate much of the GraphQL endpoint. Will be producing two front-end examples in Go and Javascript.
      • Huda: GraphQL would allow you to conduct searches as well.  Is it possible to extend that across multiple search indices?  
      • Andrew:  Is the current approach in the VSTF to have a GraphQL endpoint over the Solr index, or is it backed by ElasticSearch?
    5. Don:  Amalia, do you use the editing interface of VIVO?
      1. Plan to develop a workflow where the researcher can request that the university upload something to the platform.
      • Amalia:  no plans to let researchers edit information.  Universities in Colombia follow a protocol where someone (not the researcher) is designated to edit that content.
        • Plan to develop a workflow where the researcher can request that the university upload something to the platform
      • .


    Actions

    •   

    Previous Actions

    ...