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. Brian Lowe 
  2. Dragan Ivanovic  
  3. Georgy Litvinov 
  4. Benjamin Kampe  
  5. Andreas Czerniak
  6. Veljko Maksimovic (star) 
  7. Michel Héon
  8. Benjamin Gross 

Agenda

  1. Questions/Issues/Pull requests/Announcements
    1. Call for Interest: Integrating DSpace with VIVO
    2. CRIS conference with VIVO track
  2. The preparation for the February sprint
    1. Wiki page
      1. 2022 - VIVO Sprints
        1. https://forms.gle/GKBCDznBF2KtsEQR7
    2. Date for the sprint
      1. February 21st - March 11th
    3. Georgy's document - https://docs.google.com/document/d/1vtNIVEYWdBgV11N-wiPk_UNKpiFQ4sKetJ8elJ6xy2E/edit#heading=h.k389x4cotzuw
    4. Specification - https://docs.google.com/document/d/1n7gSf_cSDS5mbTI4HwVGj-2sQd5if0177Nrdtri9BtM/edit?usp=sharing

Notes

Dragan: applications for integration of VIVO and DSpace are closed. Deadline might be extended, but not likely. CRIS conference with VIVO track will be held in Dubravnik, probably live. Applications for the conference are open until Feb 15th. Everyone who wants to be a part of a sprint should fill in the google form. That way we can prepare better for the sprints. Georgy will take a lead when it comes to Dynamic API, since it is his idea.

Georgy: Explained the diagram for architecture of dynamic api. Few more things should be cleared, like in which order would the steps be executed. Will continue working on Proof of Concept for the Dynamic API.

Dragan: Are we going to have just one generic class representing actions, and many implementations for different types of actions?

Georgy: Inheritance should be used as much as possible. One abstract class can be used to represent an action, and then later many different classes implementing the base action class for different types of tasks. We should also maybe use some JS library which would give end-users an easy drag-and-drop GUI to define their own “pipelines” of action. Georgy is also working on The Action processing flow, which should be done before starting the proof of concept. “Condition” will probably be renamed to “Decision”. Some other terms would be renamed to make more sense to users who are not RDF experts.

Dragan: Discussed how we only need a vCard for external authors of papers, which are not a part of our organization/university. Those researchers/authors do not need to have a full VIVO profile. Presented a diagram for adding a co-author depending on whether he/she is from within our institution or not. This use-case can be used as a proof of concept/first function to be implemented with dynamic api.

Dragan presented ontology for Dynamic api. The ontology can be viewed with a web protege tool. WebVOWL can be used to visualize the ontology. Protege is mainly used for editing ontologies, as Michel explained. He also suggested that in the future we should maybe try to integrate VIVO with protege (as it is also an open-source tool). The tool is very popular within the semantic-web community, so time should be invested into learning the web protege. Michel also believes that adoption of VIVO could rise if it is integrated with a popular tool such as protege. Georgy agrees with this, and we could also get rid of our ontology-editing code if we decide to use protege for those tasks. Georgy said that if we go with integration, it should be loose-coupled with VIVO, probably with an API.

Conditionals within the dynamic web ontology would have two possible outputs: true and false. They should not have actions within them, they should just decide in which direction further processing will go.

Brian explained the “hasClass” property. How we define which classes need which objects to be loaded on startup of the application. Further work on the ontology is needed.

Georgy: Engine (action processor) would be the one abstract class representing the action, and “Pool of Actions”' would be all of the different implementations of the Action base class.

Draft notes on Google Drive

Task List



  • No labels