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
- https://vivo-project.slack.com
- Self-register at: http://bit.ly/vivo-slack
Attendees
- Dragan Ivanovic
- Georgy Litvinov
- Benjamin Kampe
- Mark Vanin
- Veljko Maksimovic
- Rolf
- Michel Héon
- Anna GuillaumetWilliam Welling
Resources
Agenda
Goals:
- Surface any fundamental issues
Sprint logistics / scheduling
- Daily stand-up report in Slack - #dynamic#i18n-apisep-sprint-may-2022 channel
- A bi-daily meeting (Monday, Wednesday, Friday) at 10am Eastern Time (4pm CEST)
- Tools and resources
- Branches
- Test datasets
- Integration tests
- Development processes
- Dev environment... please take as first task to establish this
Tickets - https://github.com/orgs/vivo-project/projects/24/views/1Documentation - VIVO Dynamic API
- Tracks
- Ontology
- RDF representation of dynamic actions and resourceAPIs
- Binding
- Binding to Java objects representation
ExecutionExecution of a dynamic action - RCP Endpoint
- REST Endpoint
- Security
- Definition of dynamic action roles
- Authentication (endpoint and UI)
- Authorization
- JWT
- Do we need OAuth2 or OpenID Connect ???
- Validation
- syntax,
- over the ontology,
- generic SHACL rules for all dynamic actions
- custom SHACL rules for specific dynamic actions ???
- UI for running a dynamic action
- Angular & Angular Material
Some notes regarding angular from William Welling .
- I would recommend against using a openapi specification generator
- it likely does not take into consideration angular universal for SEO, central state management, or i18n
- it is not likely to be a long lived dependency, popular, or actually work well with the dynamism of custom actions
- choose between the server side module (both express and angular universal)
- consider a central state management up front
- choose i18n library (important to know whether we want runtime or build time i18n)
- adopt a style guide and have it enforced using linting
- have github action check code styles
- protect main branch against style guide violations
- incorporate best practices and have test coverage in initial commit
- have github action that performs code coverage
- protect main branch for code coverage decrease
- I would recommend against using a openapi specification generator
- CRUD operations for custom actions
- UI for management of custom actions
- Exploitation
Slack stand-up template
Panel |
---|
[VIVO Dynamic API Standup] |
Notes
...
Dragan created project board https://github.com/orgs/vivo-project/projects/4
The most simple for language speakers is the last group of tasks (Label keys translations)
There are already a couple of tasks for German, French and Spain speakers
Correction can be done in text editor, or by using Online translation editor.
Georgy: For people without technical skills we could modify vivo113rc instance (add more languages) and turn on translation interface
Group of tasks: Converter from properties to n3 data.
the other group of tasks: Improvements of UI. There are some problems with hardcoded texts. Create generic freemarker templates without language specificics.
Michel proposed to redefine the keys for translations.
Michel: I think we should first convert translations to ontology, then redefine properties and work with ftl files.
Michel: we should have information about freemarker templates in translations
Dragan: They shouldn't be coupled with freemarker templates and work on fixing templates won't create conflicts with new translation data retrieving mechanisms, but most likely we won't have enough resources to do tasks in parallel.
Michel is working on a new ontology proposal for translations. It is in the wiki https://wiki.lyrasis.org/pages/viewpage.action?pageId=257720346
Michel: My suggestion is to discuss an ontology proposal in an ontology group. It should be discussed as soon as possible. It is a blocker for majority of tasks defined for this sprint.
Michel has a shell script to convert property files to n3 files.
Georgy: there are users who would need to migrate from old translation architecture.
Michel: We can use automatic translators, like deepl to have new translations.
Michel: in example there is url for now if you want to add ftl files and translation files in produced n3
It is done to simplify the translation process, especially with TopBraid composer eclipse.
Michel: We have in this ontology many facilities: where is the ftl file and where is the property
Dragan: Some data properties (with range and domain) are not defined.
Michel: it is an rdf file, you can define that as an rdf property.
Michel insists on encoding theme name and application in the uri. It is much easier to work with translations in VIVO Studio in that case, as then you can jump to the freemarker file from n3.
Georgy: I disagree, we should stick to what Brian suggested: uris should be unique and contexts should be stored as properties, that would be more flexible and won't create uri conflicts.
Dragan: We should continue discussion with the ontology group.
Michel: it is not a blocker, if we select another approach we can change that. It is easy to change.
The next meeting will be on Monday if there is no ontology meeting. If there is a meeting we will join them
We will continue discussion on the other issues. Could you take a look at the project board?
Dragan: Decision regarding ontology is a crucial point for us, we should definitely consult with an ontology group.
Dragan: I will try to create branches for the sprint, something like i18n-redesign.
In the wiki page Michel will prepare questions for the ontology group. If you have other questions don't hesitate to put questions there.
Dragan: It was a nice discussion, we are not on the same page yet, but it is always good to have discussions on crucial points. Let's continue on Monday.
Dragan: If there is an ontology group meeting on Monday please join all of you
Discussion about approach for implementation of authorization. Conclusion was that we should create a separate ontology for Vitro AuthZ solution. One, or two person should work on designing it before we implement that into Dynamic API. Georgy 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.
Angular and Angular Material will be used for development of UI. William thinks generators are not solution for our case, it should be dynamic UI capable to adopt on any change in a dynamic action on the fly. Angular Universal will be used for implementation of Server Side Rendering for the improvement of Performance and Search Engine Optimization. NGRX will be used as a central state management. A runtime i18n is needed.