Date

Call-in Information

Time: 10:00 am, Eastern Time (New York), 4pm Central European Summer Time

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. Miloš Popović 
  3. Georgy Litvinov  
  4. Doug Chestnut
  5. Kshitij Sinha
  6. Yuji Shinozaki
  7. Ivan Mrsulja (star)
  8. Michel Héon 
  9. Brian Lowe 
  10. Mark Vanin 
  11. Benjamin Kampe 
  12. B Henderson

Agenda

Notes

  • 2023 LD4 Conference on Linked Data

DRAGAN: A community member is one of the co-chairs. Event is in person and the topic is relevant for the VIVO community. Link is provided in the SLACK channel if someone wants to participate.

  • VIVO REST API

DRAGAN: I have specified an API for core entities, DynAPI engine is ready to support it. It is not so easy to cover everything but initial version is here. It will be the standard API for VIVO in the future. If someone customizes the faux properties for VIVO, some endpoint customizations will be needed as well. Detailed description is provided in corresponding links in agenda.

Question: should pids be hardcoded or be left in the array form as is suggested now? Any feedback on the specification is helpful, what is missing or what needs improvement.

MICHEL: In vivo data is built as a graph, and when you represent resource via form, you will miss info if you try to make a form of every possible person definition. It should be in RDF format. We should make a generic converter from RDF to JSON and then visualize it, its less complicated than estimating how a form should look.

DRAGAN: In REST it is possible to offer resource in different formats, we might offer that as well, but the question is usability of those different representations in other systems because most developers are not familiar with RDF triplet format.

MICHEL: I think it is better to have triple to JSON converter and return only in RDF format.

DRAGAN: In DynAPI all endpoints are customizable, people can specify a response content-type.

GEORGY: We could have parallel APIs if someone needs them, we can inform people how to add them.

  • UF performance issue with login

DRAGAN: Florida UNI login error, Georgy mentioned that maybe logging took some time because of huge model, and it may be that in 1.13 there are some bugs that cause login issues but they will be fixed in 1.14. I have checked catalina.log, everything seems fine but I need to check vivo.log file.

  • VIVO 1.14.0 RC 3

DRAGAN: We will wait a little before publishing a new RC. You will be provided with testing instructions. Any feedback will be helpful.

  • VIVO REST API
  • Versioning

DRAGAN: We will have different API versions, what about documentation for those versions? One idea might be to try to add different paths for documentation in WIKI space. We could also use GitHub projects, use MD as a language to write docs.

  • Fetching data

DRAGAN: Fetching should have some standard features (pagination, localisation, sorting…). How we should implement it in the DynAPI will be discussed in the next meeting. 

GEORGY: Localisation should work from a language filter that is already implemented.

DRAGAN: Great, also I had some problems while designing pagination and sorting. There is a lot of complexity when checking the limit, need to find a simpler way.

BRIAN: When writing to an API, people should be able to provide fields in different languages?

DRAGAN: we should check how we can support multilingual content in JSON.

BRIAN: Maybe do a convention when we have field_language field names in JSON.

  • Continues work with Project boards vs Sprints

DRAGAN: I will be available to answer to any request or answer questions. Inform me when you would be able to contribute. There will maybe be an official sprint in June, REST API based. Everyone is encouraged to join. This sprint is maybe better to be organised as project board so issues are available for anyone to take them. Do we need 4 sprints per year or are the project boards better, give me some feedback?

Draft notes in Google Docs

Task List

Previous Tasks 

  • Dragan Ivanovic to add columns in the project board for Priority and Difficulty.
  • Sprint participants to read description of issues and think about their preferences. 
  • No labels

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