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. Georgy Litvinov 
  3. Brian Lowe 
  4. Benjamin Kampe 
  5. William Welling
  6. Michel Héon 
  7. Mark Vanin (star)             

Agenda

  1. Questions/Issues/Pull requests/Announcements
    1. VIVO-docker2 
      1. https://github.com/vivo-community/vivo-docker2/issues/22
    2. i18n issue
      1. https://vivo-project.slack.com/archives/C8RL9L98A/p1663253504895989
    3. combine construct and select query, examples:
      1. https://stackoverflow.com/questions/28427219/sparql-functions-in-construct-where
      2. https://stackoverflow.com/questions/33890540/bind-in-construct-query-with-sub-select-sparql
  2. Dynamic API
    1. Need more design 
      1. not ready for further implementation for the forthcoming sprint
    2. A separated task force led by Georgy Litvinov 
      1. Dynamic API Task Force
    3. Approved 
  3. The i18n redesign sprint
    1. When?
      1. 19.09. - 07.10. 
    2. What?
      1. Wiki page
      2. GitHub project board

Notes

  1. Questions/Issues/Pull requests/Announcements
    1. VIVO-docker2 

Should not be used/not active, respond to the open issue: better use the docker image inside of VIVO. Link how to use docker in VIVO: https://github.com/vivo-project/VIVO#docker

  1. i18n issue

We should analyze the issue and check whether we should open a GitHub issue and add to the i18n redesign project board - https://github.com/orgs/vivo-project/projects/4 

  1. combine construct and select query, examples:

Having construct and select query at once might create problems with language filter, probably better to firstly create construct query/model and then select query to get right data.

  1. Dynamic API

Georgy took a week off (19.09-23.09). Dynamic API will start in approximately 3 weeks. If you have a will to participate in, contact Georgy.

  1. The i18n redesign sprint

Georgy: idea to have a file for each translation. Move VIVO/VITRO languages to VIVO and VITRO, combine projects, that we have now as separated on git.

William: There might be a problem, that the RDF-file could be too big, because of a few thousand properties. 

Georgy: online translators save translations in file and cache it, if you want to change your text, this file will be overridden. 

Michel: more earlier we have ontology, better we would have a plan to introduce translations.

William: mechanism to detect which label for desired language wasn’t translated, have or haven’t label for translation. Nice to know if the content doesn’t have a translation label.

Dragan: Especially when VIVO is growing and some data might miss the translation labels.

Georgy: labels should be backward-compatible. In a future when we get rid of property files, but people who still would have property files, wouldn’t have problems after running VIVO.

Brian: it’s quite a hard task, when a person will make second-tier, third-tier changes in property files (will make future customization of their local i18n), because of semantic mechanisms. 

Dragan: institutions/people without serious technical support might not even try to customize their VIVO (maybe, they wouldn’t face aforementioned problem).

Michel: have all translations in one place. 

Brian: even if there’s a mistake in the directory structure, it was made like this after years, so it’s not a good idea to change it completely/on a whole new design. 

William: other opinion: people might see the structure we have now and have a concern/question - “Why do we have it like that?”.

Michel: if you want to add a new language now, it’s very complicated, you need not only a person who knows this language well, but also a person from computer science field.

Dragan: from his and Veljko Maksimovic experience translating to Serbian, not all files were translated in a first cycle, which means files are hard to find right now.

Dragan: how to organize entry and property files? If we are combining them, should they both be present? From Brian’s idea: people might want to change their own local property files translations.

Georgy: for backwards compatibility it’s a nice idea, but it will, for sure, add complexity for maintaining. URIs should be unique, results should be put inside hashmaps for quickness.

Michel: part of the ontology on a line 130 <-uqam> works as a local dialect of French in Quebec, because French used in Quebec (French Canadian) is different from French used in France. Problem is French Canadian differs from the French used in Quebec and since we use the IETF standard for languages we cannot introduce a new tag, because it’s under standard. 

Georgy: you can update your local files, 3-tier in VIVO documentation, but you will have to provide your changes again, after installing a new version of VIVO. The question is going in a new area: local languages and how they should be treated.


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.