...

1. Brian Lowe 
2. Dragan Ivanovic  
3. Georgy Litvinov 
4. William Welling 
5. Veljko MaksimovicBenjamin Gross 
6. Huda Khan
7. Benjamin Gross 
8. Michel Héon 
9. Florian Kotschka
10. Benjamin Kampe 
11. Fadwa Alshawaf
12. Christian Hauschke 
13. Andreas Czerniak
14. Dominik Feldschnieders
15. Matthias Lühr 

Agenda

1. Announcements
2. Questions/Issues/Pull Requests
   1. Pablo E Diaz Ramirez issue
      
      1. https://groups.google.com/g/vivo-tech/c/ZIyA_ZTunHM
3. Reorganization of Wiki pages - https://docs.google.com/document/d/1JmdIHYcaYCDCYSQyevKjAVdgH4aZ8JXr3Ls9eIjlrS8/edit?usp=sharing
4. Continue discussing Dynamic API proposalhttps://docs.google.com/document/d/1vtNIVEYWdBgV11N-wiPk_UNKpiFQ4sKetJ8elJ6xy2E/edit?usp=sharing
5. Discussion about sprints' topics
   1. https://docs.google.com/document/d/1hJSWAa3ENoFOYyp0GyvDqBdehra3AmFBAD9X2dX3cSo/edit?usp=sharing
6. Discussion about priorities for further development of VIVO - https://docs.google.com/spreadsheets/d/103P9P4v6yUBSb5BnVaK40NoGx1fIYyL8uaHKUubZWbE/edit?usp=sharing

...

Draft notes on Google Drive

1. Announcements
1. DSpace/VIVO integration was spec’d out. 
2. Will be discussed tomorrow at leadership group.
3. Will likely be small budget
4. Hoping for 2-3 contributors, hopefully one from outside community 
2. Questions/Issues/Pull Requests
   1. https://groups.google.com/g/vivo-tech/c/ZIyA_ZTunHM
   2. Waiting on full tomcat log to investigate
1. Pablo E Diaz Ramirez issue
   
   
3. Reorganization of Wiki pages - https://docs.google.com/document/d/1JmdIHYcaYCDCYSQyevKjAVdgH4aZ8JXr3Ls9eIjlrS8/edit?usp=sharing
1. Still to do
4. Continue discussing Dynamic API proposalhttps://docs.google.com/document/d/1vtNIVEYWdBgV11N-wiPk_UNKpiFQ4sKetJ8elJ6xy2E/edit?usp=sharing
   1. Idea is to have one universal form framework 
   2. Have set of rules that we can use to create forms
   1. Store SPARQL query and results
   2. How to invalidate?
   3. Don’t want to invalidate entire cache if a small part of the db is updated
   4. Current approach: URI finders (used to reindex Solr fields)
1. Georgy has added some additional topics to proposal 
2. Dynamic forms
3. Dynamic API cache
4. Dragan: These might be two separate ideas. Perhaps caching can be part of a later effort. 
5. William: We don’t want to prematurely optimize, though we do know there will be a performance limitation 
6. Dragan: Sprint or meetings to discuss design? Perhaps 3 meetings to discuss prior to a sprint.
7. Georgy: You can also add comments to google doc
8. William: Should we have a formal specification for it prior to actually writing code? I.e. Starting with a draft proposal is important. Can break down draft writing into separate parts.
9. Michel: Also need to decide on technology to use prior to writing code
10. William: Can write spec prior to deciding on tech. 
11. Brian: How realistic is it to write the rest of the spec with the ontology spec?
12. William: They inform each other 
13. Where to develop ontology? William: Any repo should be fine. Somebody just needs to take point and create a draft spec/ontology. Dragan: Do we need to work on same doc, rather than committing to same repo? William: Could use google docs at start but it should be formalized at some point. W3 has a lot of good standards for spec formats. 
14. William: What about the processor that reads the graphs and generates the sparql queries. What about the design of that? That’s when deciding on the tech comes into play. 
15. Dragan: Current action: Add comments to Georgy’s document 
16. Suggestion: Split out caching portion of proposal so we can focus on dynamic API 
17.  
5. Discussion about sprints' topics
   1. Michel: No objections though we do have other priorities. 
   2. i18n, putting all.properties file into ontology. Not a fun project, but important. 
   1. How much interest outside the existing languages? 
   2. Properties file is a blocker to implementing at multiple orgs with same language but different vernacular. Need variants to language.
   3. Nice opportunity to add skos concepts
   3. Brian: Along those lines, somebody on Slack mentioned sorting doesn’t work right. There are small things that keep us from saying we are really ‘done’ with i18n work. Do we risk alienating community if we don’t offer something interesting to non-i18n users? 
1. https://docs.google.com/document/d/1hJSWAa3ENoFOYyp0GyvDqBdehra3AmFBAD9X2dX3cSo/edit?usp=sharing
2. Perhaps we just selected the sprint topic! Other ideas? 
3. Additional ideas can be found on sprint doc linked above
4. Idea for first sprint would be specification and not implementation, proof of concept (yet).  Proposing February 21 and first two weeks in March, OR last two weeks in January.  Dragan suggests former works better for him. 
6. Discussion about priorities for further development of VIVO - https://docs.google.com/spreadsheets/d/103P9P4v6yUBSb5BnVaK40NoGx1fIYyL8uaHKUubZWbE/edit?usp=sharing

1. i18n
1. Move i18n properties from resource bundles to ontology / (editable) RDF
2. Find solution for syntax differences between languages that does not require template customization per language 
2. Data ingest
1. Michel: Idea behind ingest is using open api and swagger technologies. If we build something for dynamic API that uses same technology, we can reuse for data ingest. We will be familiar with the technology at that point.
2. Georgy: Do we use vivo-proxy? Michel: We could, yes
3. Michel: VIVO-Proxy has two parts. First is open api, which delegates to process which translates from JSON to SPARQL. Georgy: Perhaps this is overlapping with Dynamic API proposal? 
4. Dragan: We are always thinking about deduplication as well. Is that part of this? 
5. Michel: No, this is data transformation. 
3. Issues with custom ontology in current environment: Requires a lot of custom code to successfully use custom ontology, beyond very simple things. Dynamic API would make this easier. 
4. How many sprints would implementing the Dynamic API take? 
1. Georgy: We will likely know more after we draw up the spec. But doesn’t seem like an overly complex task.
2. William: There will be complications. It’s well beyond one sprint.
3. Georgy: Depends on how many cases will be taking on (ie types of data)
4. Brian: Can we reduce scope initially to custom forms? Define in RDF instead of generator Java.
5. Dragan: Let’s continue discussion next week prior to deciding on topic of first sprint

Task List

Add comments to Georgy's document