Date

Call-in Information

Time: 10:00 am, Eastern Time (New York, GMT-04:00)

To join the online meeting:

  • https://lyrasis.zoom.us/j/84378615572?pwd=bGUxSjlyRTdjOGl5U1B6L0Yva3RQdz09

    Meeting ID: 843 7861 5572
    Passcode: 556561
    One tap mobile
    +16699006833,,84378615572#,,,,*556561# US (San Jose)
    +19292056099,,84378615572#,,,,*556561# US (New York)

    Dial by your location
            +1 669 900 6833 US (San Jose)
            +1 929 205 6099 US (New York)
            +1 253 215 8782 US (Tacoma)
            +1 301 715 8592 US (Washington DC)
            +1 312 626 6799 US (Chicago)
            +1 346 248 7799 US (Houston)
            877 853 5257 US Toll-free
            888 475 4499 US Toll-free
    Meeting ID: 843 7861 5572
    Passcode: 556561
    Find your local number: https://lyrasis.zoom.us/u/kerqtGDrJ4

Slack

Attendees

(star)  Indicating note-taker

  1. Dragan Ivanovic 
  2. Brian Lowe    
  3. Michel Héon 
  4. William Welling 
  5. Mark Vanin 
  6. Benjamin Kampe 
  7. Georgy Litvinov (star) 

Agenda

Questions/Issues/Pull requests/Announcements

    • When
      • 20.02.23 - 10.03.2023
    • The topic
      • Jena upgrade
        • clean up or get rid of SDB code
        • fix live backup of TDB
      • External triple store performance improvement
      • integration of vivo-solr into main codebase
        • is that vitro-solr or vivo-solr?
      • VIVO-Installer review depending on the target user: developer, infra architect, corporate/institutionnal evaluator, etc.
      • Implement a new owl-reasoner (maybe https://github.com/stardog-union/pellet)
      • Reformat codeSource replace tabs by spaces.

Notes

  1. Dragan: Issue with calendars is not resolved yet. We don’t know who is responsible for the account.
  2. Dragan: Support link is working again. It is better that we have it than to not have it. After this meeting I am going to sent message to VIVO website contact form.
  3. Dragan: On VIVO LG started discussions how to make progress with limited resources. One idea was to find some grant to speed up VIVO development. It was also discussion about communication improvements between VIVO community, LG group and technical group.
  4. We should organize some event to promote release and will see how it goes.
    If we are going to organize monthly meeting I am not sure how the response is going to be.
  5. Dragan: In annual report list of VIVO instances was updated, it looks like there are ~70 VIVO instances in the world. 
  6. Dragan: regrading PRs
    Dragan: William reviewed PR 3805 and result is in the PR comments.
    Some comments are minor, related to sample data and shouldn’t be treated as a blockers for merging into main.
    William: It would be good to standardize sample data and get good datasets. Sample data repository is on VIVO project. OpenVIVO provided continuous deployment for samples. With automated deployment we would be able to quickly have instance to test.
    William: about testing I am going to redeploy testing with zip file
  7. Dragan: Michel sent us demo site and in the previous release Georgy did the same. We are going to use it to test upcoming release.
    • I have one question: we have github actions, if we have the script you are developing at the moment would we be able to test VIVO with selenium tests?
    • William: yes, but we may need another framework to run the container.
    • Dragan: It is important it would give us more options to test.
      William: we would be able to test the bug before and after the fix. It reduces amount of efforts required by person. It is a part of CI/CD notion.
      Inside each folder of sample data we have folders with zipped content. There are openvivo and uf sample datasets.
      Dragan: We need to restructure the repository?
      William: potentially, yes.
    • Dragan: uqam is not a good sample data as it also have customization for labels. I am not sure if this is a sample data at all.
      What is the next step for this?
      William: I would make it an item to discuss and think how to deploy.
      Dragan: Let’s discuss that next time.
      Let’s go over William comments and decide what we should resolve before release publishing.
      William is going to try that again and give us final report and we will see what issues we would resolve.
  1. Dragan: I have prepared some release notes page. One thing is missing there. There is a page for Faux properties, but for object properties only. I am going to take a second look and extend documentation.
    I created links to google forms created from 3805 PR instructions.

  2. Regarding next sprint we might be able to start on 20 of February. It would be nice to have i18n-redesign branch merged into main branch.
    I tried to organize tasks in tracks. If topics are too different, then question if they should be on the same branch. Tasks in the sprint shouldn’t be diverse.
    Let’s see where we will be in the next couple of weeks.
    The question if we should have separate VIVO Solr and Vitro Solr. If we decide to move it somewhere then it should be moved into Vitro.
    We started discussion about different installers for different users.
    It would be nice to have flexibility in installation.
    I would like to have some improvements, but it doesn’t look trivial.
    Michel, could you tell more about the new reasoner implementation.
    Michel: Actual reasoner is not a full owl reasoner.
    If we make sparql query with infer triples and at the moments it is not possible. I think Brian can say something about reasoner.
    Brian: Now we have a minimal reasoner VIVO needs to support basic features. We used to use a reasoner for TBox reasoning, because it is much smaller than other data we have in VIVO. In large ontologies it could be very expensive operation.
    Abox is different because it is supported only by simple reasoner: type hierarchy (for performance reasons). It is something that becomes tricky when we have huge base.
    We don’t use pellet on TBox as it had license changed. Your license obligations as far as it is embedded with internal reasoners is going to change.
    In general it wouldn’t be trivial to have complete reasoning on TBox.
    By materializing inferences process is getting complicated. If you do that for the whole abox, then there is a lot of stuff to update in the graph.
    If you don’t try to materialize you still have the problem that you should wait a lot of time for queries. So it is not easy to support full owl reasoning in abox.
    We can’t do it partially as it would be complicated to track what supports full reasoning and what not.
    I don’t know how much is freely available… but there are a lot of practical problems to support full reasoning in the application.
    Dragan: we need to define scenarios for reasoning.

Draft notes in Google Docs

Task List

Previous Tasks 

  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.