...

1. Status of In-Review tickets

   Expand
   Jira server DuraSpace JIRA jqlQuery filter=14416 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5

   
   

Notes

1. Dependencies between unit tests
   
   
1. VIVO-2003 - Vitro unit tests fail if not run in a certain order OPEN  
1. https://vivo-project.slack.com/archives/C8RL9L98A/p1626082946083900
2. https://vivo-project.slack.com/archives/C8RL9L98A/p162608352608510
2. Look into Spring Frameworks to help with the order of tests
3. Look at dependency injection
4. Maybe a static order for .1 then resolve for real in .2
2. VIVO-PROXY
1. Starting a collaboration with the University of Lausanne for the development of VIVO-PROXY
2. Forking VIVO-PROXY Repo from UQAM to https://github.com/vivo-community/VIVO-PROXY
3. Defining shapes or subgraphs for use in APIs, edit forms, indexes etc.
1. Diagrams:
1. existing architecture: https://docs.google.com/presentation/d/1raO98mklGUQgAc6wMMbgDEsHVk1zoCA3bq4Fyy21GjI/edit?usp=sharing 
2. Results of initial experiments with SHACL
3. Defining more transparent N3-based templates?
4. Mapping to simplified JSON objects for data ingest
1. Inspiration? William Welling: Apache Marmotta LDPath syntax https://marmotta.apache.org/ldpath/language.html
5. SPARQL for list views/ indexing / URI finding
4. Moving Scholars closer to the core
1. Build messaging system first? versus
2. Original option of typing into existing document modifiers:
1. "win/win" opportunity: Scholars and VIVO both eliminate some complexity
2. converting Scholars SPARQL queries to VIVO DocumentModifiers
3. replacing URIFinders with fast, reliable Solr lookups 
5. Prioritizing future development items:
1. quick wins / items for a more rapid release
2. collaborative items for future sprints
3. (Add/edit at will) spreadsheet: https://docs.google.com/spreadsheets/d/103P9P4v6yUBSb5BnVaK40NoGx1fIYyL8uaHKUubZWbE/edit?usp=sharing

• Can we get a second slide with everything Brian said?
• (I suppose we could make the slide : ) )
• Right now, the N3 patterns are defined in the JAVA generator classes, which are then processed in separate classes that do a lot of parsing of the submitted values, entering into the variables, and then assessing which N3 required strings are present, etc.
• A few years ago, we worked on a custom json simplification of this process
• It still used the processing pipelines underneath
• Is it also possible to include the Capability-map structure in the diagram?
• Don - I would also like to see this existing diagram built out a little bit more. Perhaps include some documentation on what we like or don't like for each component

Draft notes on Google Drive

...