...

1. Brian Lowe 
2. Dragan Ivanovic  
3. Georgy Litvinov 
4. Michel Héon
5. Benjamin Gross
6. Matthias Lühr 
7. Benjamin Kampe
8. Veljko Maksimovic 
9. Andreas Czerniak

Agenda

1. Questions/Issues/Pull requests/Announcements
   1. Call for Interest: Integrating DSpace with VIVO
      1. Reviews scheduled
   2. CRIS conference with VIVO track
      1.  CERIF 2 VIVO mapping - https://docs.google.com/document/d/1qJgxuIdMBSdL6c_w7BADOPhazjE6UKl8I-EawdwRuqA/edit?usp=sharing
2. The preparation for the February sprint
   1. Registration
      1. https://forms.gle/GKBCDznBF2KtsEQR7
   2. Date for the sprint
      1. February 21st - March 11th
   3. Goal, idea and approach - 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
      1. Ontology - https://webprotege.stanford.edu/#projects/b7ebb822-2a8d-4fd3-ba36-5b9e8bd3f400/edit/Classes
      2. The use case examples
         1. https://app.diagrams.net/#G176In5cQ-tWecx0aP0ILBTODuCoiYk-0o
         2. https://github.com/matthiasluehr/vivo-custom-forms/tree/master/mentoring

...

1. Questions/Issues/Pull requests/Announcements
   1. Call for Interest: Integrating DSpace with VIVO
      1. Reviews scheduled. Selection is ongoing.
   2. CRIS conference with VIVO track
      1. CERIF
       CERIF
      1. 2 VIVO mapping - https://docs.google.com/document/d/1qJgxuIdMBSdL6c_w7BADOPhazjE6UKl8I-EawdwRuqA/edit?usp=sharing
         1. Formal description is part of abstract. Mostly modeling. 
         2. May be some technical parts 
         3. Others are invited to join, and provide comments.
      2. May still be an in-person conference but may move to virtual still
2. Call for Interest: Integrating DSpace with VIVO
CRIS conference with VIVO track
4. The preparation for the February sprint (Dynamic API)
   1. Registration
      1. https://forms.gle/GKBCDznBF2KtsEQR7 
   2. Date for the sprint
      1. February 21st - March 11th
   3. We have made some progress thanks to @Georgy
   4. Goal, idea and approach - https://docs.google.com/document/d/1vtNIVEYWdBgV11N-wiPk_UNKpiFQ4sKetJ8elJ6xy2E/edit#heading=h.k389x4cotzuw
   5. Specification - https://docs.google.com/document/d/1n7gSf_cSDS5mbTI4HwVGj-2sQd5if0177Nrdtri9BtM/edit?usp=sharing
      1. Ontology - https://webprotege.stanford.edu/#projects/b7ebb822-2a8d-4fd3-ba36-5b9e8bd3f400/edit/Classes
      2. In this spec we also have a link to the ontology app that will enable us to work on it.
      3. The use case examples
         1. https://app.diagrams.net/#G176In5cQ-tWecx0aP0ILBTODuCoiYk-0o
         2. https://github.com/matthiasluehr/vivo-custom-forms/tree/master/mentoring - thanks for sharing @Matthias` Form for thesis and advisor relationships. Georgy was able to model using his proposed process.
   6. Changes?
      1. Conditional - Dragan requests an example where it might be used. E.g. would a form be dependent on the result of the conditional check? 
         1. Should be reusable - checks for parameters, but also checks for current state of Solr etc.
         2. Dragan - will there be a specific language for the condition? Or a sub-hierarchy of conditional elements that link to a java class? 
         3. Check something with triplestore - create SPARQL
         4. Check something related to parameters - predefined checks 
         5. For first implementation, it might not include a
   conditional 
   7. 1. 1. conditional
   8. The generators for custom forms are hard to understand
   9. Walked through diagram:
      1. Get request to create person or individual via a REST request.
         1. Using name or ID or individual? 
            1. Mapping to an http verb to an action (e.g. create a person)
            2. That mapping/action will be described in RDF
         2. We will load appropriate action based on request verb (plus resource name) + mapping
         3. Then go step by step 
            1. For person example, first is set first and last name
            2. Validate. If all goes well, go to next step
            3. If end, respond with results
   10. Using name or ID or individual? 
   11. We will load appropriate action based on request verb (plus resource name) + mapping
   12. Then go step by step 
   13. 1. 1. Class for each step?
          2. Georgy - yes, class for each step, plus class for template
       2. Search index refresh is not part of this… there will still be
       listeners 
       1. listeners
   14. How about when we need to get individuals? E.g. suggestions for autocomplete
       1. This is coming out of the search index 
       2. Dynamic API will have a special function to get data the same way.
       3. Dragan - I believe there are issues with multilanguage search 
          1. Brian - fundamental issue is the search index doesn’t distinguish between languages. So you will get results in multiple languages, but you can’t get them in just one language 
       4. Georgy - could theoretically swap out Solr with SPARQL using dynamic API
   15. Any additional deficiencies with ontology at the moment? 
       1. owl:Thing > Action, Conditional, Parameter, Role, SPARQLQuery, SolrQuery, Step, Template, Validator
       2. @Georgy - nothing at the moment 
   16. WebProtege - what prefix should we use for dynamic API? 
       1. There are some old prefixes for the application but they have mannlib in the URI. We no longer have access to the mannlib web spaces, and limited participation from Cornell.
       2. Brian- perhaps http://vivoweb.org/ontology/api/ or http://vivoweb.org/ontology/dynamicapi/
       3. If we want to make it clear it’s a vitro, we could do something like https://vivoweb.org/ontology/vitro-dynamic-api/ 
       4. Michel - we should bring the suggested prefixes to the ontology group
Registration
6. Date for the sprint
7. We have made some progress thanks to @Georgy
8. Goal, idea and approach - https://docs.google.com/document/d/1vtNIVEYWdBgV11N-wiPk_UNKpiFQ4sKetJ8elJ6xy2E/edit#heading=h.k389x4cotzuw
9. Specification - https://docs.google.com/document/d/1n7gSf_cSDS5mbTI4HwVGj-2sQd5if0177Nrdtri9BtM/edit?usp=sharing
10. Changes?
11. The generators for custom forms are hard to understand
12. Walked through diagram:
13. How about when we need to get individuals? E.g. suggestions for autocomplete
14. Any additional deficiencies with ontology at the moment? 
15. WebProtege - what prefix should we use for dynamic API? 
16. 1. Dragan - The complexity is mostly in the action pool section
    2. Georgy - yes, the plans are big!
    3. Meeting again next Tuesday, same time and place

Task List

•  Dragan Ivanovic to represent example 1 in rdf in accordance with the defined ontology
•  Georgy Litvinov to continue working on the Dynamic API proof-of-concept
•  All - to review/update Sprint - Dynamic API based on an ontology wiki page
•  All - to consider to register and participate in the sprint. Registration is here: https://forms.gle/LQjiyMFd1NL3B63v5
•  All - Add comments to Georgy's document
•  All - Add comments to Specification

...