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. Georgy Litvinov 
  4. Michel Héon
  5. Benjamin Gross 
  6. Benjamin Kampe
  7. Veljko Maksimovic (star)
  8. José Ortiz
  9. Andreas Czerniak
  10. Mark Vanin 
  11. Nicolas Dickner 
  12. William Welling 
  13. Huda Khan 

Agenda

  1. Questions/Issues/Pull requests/Announcements
    1. 6. German VIVO workshop - https://events.tib.eu/vivo-workshop-2022/programm/2022-06-15/
    2. VIVO 1.13.0 release candidate - Release Testing - 1.13.0
    3. Theme settings in the localization files - https://vivo-project.slack.com/archives/C8RL9L98A/p1653394256098719
  2. The next sprint
    1. date
      1. May 30th - June 17th
    2. Registration
      1. link
      2. Six/Seven registered participants so far
    3. Infrastructure
      1. Wiki page - Sprint - Dynamic API based on an ontology 2
      2. Slack channel created
      3. Project board
        1. We will continue using this Project board - https://github.com/orgs/vivo-project/projects/2
          1. but extend it with new issues (features, bugs)
      4. Starting point
        1. backend
          1. https://github.com/vivo-project/Vitro/tree/sprint-dynapi-2022-feb-staging
            1. will be renamed to dynamic-api
          2. https://github.com/vivo-project/Vitro/tree/sprint-dynapi-2022-feb
            1. wouldn't be used
        2. frontend
          1. https://github.com/vivo-project/Vitro-angular/tree/dynapi-2022 
          2. https://github.com/vivo-project/Vitro-angular/tree/dynapi-2022-staging   
      5. Cleaning up not completed work at previous sprint
        1. https://github.com/vivo-project/Vitro/pull/285
          1. GET all and GET one - two dynamic actions or one ?
        2. https://github.com/vivo-project/Vitro/pull/286
          1. deletion and modification
        3. https://github.com/vivo-project/Vitro/pull/287
        4. Transforming xml notation of Dynamic API ontology to turtle/n3 notation
        5. Introducing new jena model for dynamic actions
        6. Cleaning up issues at  https://github.com/orgs/vivo-project/projects/2/views/1
      6. Tracks
        1. Ontology
          1. RDF representation of dynamic actions and resourceAPIs
        2. Binding
          1. Binding to Java objects representation 
        3. Execution
          1. Execution of a dynamic action
        4. RCP Endpoint
        5. REST Endpoint
        6. Security
          1. Definition of dynamic action roles
          2. Authentication (endpoint and UI)
          3. Authorization
            1. JWT
            2. Do we need OAuth2 or OpenID Connect ???
          4. The ontology - link
        7. Validation
          1. syntax,
          2. over the ontology,
          3. generic SHACL rules for all dynamic actions
          4. custom SHACL rules for specific dynamic actions ???
        8. UI for running a dynamic action
          1. Angular & Angular Material

          2. Some notes regarding angular from William Welling.

            1. I would recommend against using a openapi specification generator
              1. it likely does not take into consideration angular universal for SEO, central state management, or i18n
              2. it is not likely to be a long lived dependency, popular, or actually work well with the dynamism of custom actions
            2. choose between the server side module (both express and angular universal)
              1. https://angular.io/guide/universal
              2. https://github.com/nestjs/ng-universal
            3. consider a central state management up front
              1. https://ngrx.io/
            4. choose i18n library (important to know whether we want runtime or build time i18n)
              1. http://www.ngx-translate.com/
              2. https://ngneat.github.io/transloco/
              3. https://angular.io/guide/i18n-overview
            5. adopt a style guide and have it enforced using linting
              1. have github action check code styles
              2. protect main branch against style guide violations
            6. incorporate best practices and have test coverage in initial commit
              1. have github action that performs code coverage
              2. protect main branch for code coverage decrease
        9. CRUD operations for custom actions
        10. UI for management of custom actions
        11. Exploitation

Notes

Benjamin Kampe said the German VIVO workshop will be organized as an online event open (free) for participation, but majority of presentation might be in German. 

Dragan Ivanovic informed participants that VIVO 1.13.0 release candidate has been created, waiting confirmation from some committer that release candidate can be deployed and run for spreading the news.

Georgy Litvinov noticed a problem of duplication of some nodes in localization files and loading of those nodes. It should be fixed before VIVO 1.13.0 is published. Brian Lowe will try to create a PR which fixes this issue, Dragan Ivanovic will organize reviewing of the PR, and create a new VIVO 1.13.0 release candidate.

 Dragan Ivanovic proposed an ontology for definition of permissions (https://webprotege.stanford.edu/#projects/88e4b833-30b4-4486-8bd3-fa9dd60cf9f3/sharing) which should be in accordance with discussion at pre-sprint meeting and should address granting permissions for execution and modification of a dynamic action. Georgy Litvinov thinks this is a big issue deserving a complete sprint, and we need a quick and simple solution for forthcoming sprint. That solution might be that users with role Administrator can modify (create, update, delete) dynamic actions, while a role for execution of a dynamic action is defined by using hasRole object property in the Action class. 

William Welling explained why angular code generator is not solution for dynamic api, and why he thinks we need dynamic routing and dynamic UI capable to adopt at any change in a dynamic action, or adding a new dynamic action. This will be a challenging task which need further exploration whether and how it is possible. 

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.