...

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 Andreas Czerniak
9. William Welling 

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
   3. VIVO conference - probably online in October or November
   4. Open repositories conference
      1. DSpace+VIVO integration
   5. Roadmap for 2022-2023
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
         1. https://webprotege.stanford.edu/#projects/b7ebb822-2a8d-4fd3-ba36-5b9e8bd3f400/edit/Classes
         2. https://drive.google.com/file/d/1Wou_KWJfAm9cwRVALoV5QvDiRD3mnYQW/view?usp=sharing
      2. The use case examples
         1. https://app.diagrams.net/#G176In5cQ-tWecx0aP0ILBTODuCoiYk-0o
            1. https://drive.google.com/file/d/14oVxX2xVMdvMAc0lTc7hUJYnKJUPXUTY/view?usp=sharing
         2. https://github.com/matthiasluehr/vivo-custom-forms/tree/master/mentoring
   5. Implementation of proof-of-concepts
      1. https://github.com/litvinovg/Vitro/tree/dynapi

Notes

1. Questions/Issues/Pull requests/Announcements (Dragan):
   1. William: has implementation plan / design been developed for this?
   1. Dragan:  Will be discussed with applicants when project starts in late February.  Will be a loosely-coupled integration using REST API (VIVO calling DSpace API).
   2. William: may be opportunity to align with other DSpace community initiatives, e.g. LDN and CoreNotify.  VIVO could produce LDN message for notifying DSpace.  Would be more progressive in terms of where DSpace and other repositories are going.
1. Integration of DSpace and VIVO: reviews are scheduled; should be completed next week, and hopefully the project will start soon.
2. CRIS conference with VIVO track:  still planned as an on-site conference in Dubrovnik.  CERIF to VIVO mapping will be submitted; other VIVO-related topics welcome.
3. VIVO conference will be an online event, probably in October or November.  May be a smaller event, e.g. workshop or webinar rather than a full conference.
4. Open Repositories will be onsite-only conference in Denver in June.  DSpace-VIVO integration will be submitted.
5. VIVO versus Vitro distinction brought up with Leadership Group.  Many Leadership members not aware of distinction.  TIB has a current application of pure Vitro.
2. The preparation for the February sprint (Dynamic API)
   1. Created a couple of classes, shared on Github.
   2. Action pool is instantiated with the servlet context. Creates actions from the triple store with the configuration loader.
   3. For now, the concept itself is working.
   4. Binds RDF classes to Java methods
   5. Starting point will be extended to have working examples.
   6. For now, just uses standard RDF model, but at some point should be moved to its own model.
   7. Please look at branch; feedback welcome. https://github.com/litvinovg/Vitro/tree/dynapi
   8. Modified ontology a bit and added ExecutionStep with Step as a superclass.  Conditional is also a subclass of Step.
   1. Georgy: Yes, follows properties to instantiate complete tree.
   1. Georgy: Yes.
   1. Restful API is main goal, but hard to work on REST API until other fundamental pieces are in place. 
   2. William: could be two parallel tracks, one focusing on REST API and other on consuming it from Freemarker.
   1. In Agile terms, we’re dealing with a spike:  investigate implementation and document its feasibility.  Seems like Georgy has already done a lot of that, so leaning toward delivering a feature.
   2. Georgy:  We will see.  There are lots of tasks ahead.  Need to figure out how to create a good solution for testing, etc.
   3. Dragan:  At the end of the sprint, we should at least have a proof of concept.  Seems like we’re already close to that.
   4. Georgy: For replacing Freemarker, should we create a RESTful function that taps into existing logic, or replace logic with dynamic API implementation?
   1. Dragan: Second.  Pick existing function but implement it with dynamic API and invoke/display using Freemarker.
   1. William:  Seems complicated to assume that new types of actions can be added.  Thought it was a finite set.
   2. Georgy:  I think there could be an unlimited number of actions.  Action is a function that can be executed against the triple store (create, fetch something).  Some things could also be done against Solr index for performance.  Actions and steps will be expressed in RDF.  Templates for N3 generation would be text literals as now; same with SPARQL queries.
   3. William: makes sense now that they would not be finite.
   4. Dragan:  Some new actions could be created by combining existing steps.
   5. William:  Will it be dangerous to run these actions?  People could destroy their databases if they create these actions without knowing what they’re doing.
   1. Georgy:  Agree; need some validation.  Initially, the standard actions should be delivered in a non-editable graph.
   2. William: may need shape validation (e.g. SHACL) on result of the action, which could get complicated.
   3. Dragan:  For now, could validate the input and whether it is consistent with the ontology, but validating the result could be difficult.
   6. William: How will it handle concurrent requests? Will there be transactions?
   1. Georgy: Hard to say at this point, but hope that it will be able to execute in parallel.
   2. Brian: Transactions not currrently part of RDFService interface; would be supported by TDB/SDB but not by arbitrary SPARQL endpoint implementations.  Depends on how much we want to tie ourselves to triple stores that support transactions.
   3. William: Seems like we should have a safe mode somehow to be able to perform a complete action and then validate its results.
   7. William: Need to have a good backlog of tasks defined so that people on the sprint are not left wondering what to do.
   8. Dragan: Believe there will be 10 or more tasks defined before the sprint.  Task for the next few weeks is to define those issues and organize them on the project board.
1. Eight (8) people have registered for the sprint. 
2. Georgy:
3. William: To make this easier for all of the developers to get on board with, can we make a sprint branch with a PR for the starting point?  We could then review that PR, merge it, and then branch for each feature.
4. Dragan:  Is it possible to use the RDF property annotation to instantiate related objects?
5. William: Would it be possible to develop the basis of a testing strategy before the sprint starts?  We should stipulate that all code come with test coverage during this sprint.
6. William: Will there be a trivial example of a controller endpoint? That could be the basis for integration testing.
7. Dragan:  Would be nice to be able to demonstrate that some Freemarker template is now getting its data from dynamic API.  Not sure how realistic it is to work on both.
8. William:  What is goal of sprint?  Primarily documentation, or implementation of a sprint?
9. Georgy:  May be tasks for ontology group to define additional actions.

Draft notes on Google Drive

...