> a nice feature in the UI would be a deletion option that allows you to delete the primary object, plus whatever else is created via the UI when you create a new object. It could re-use the logic in the form controller
> Another possibility would be an automatic deletion of orphan objects: vcards without individuals, publications without authors, and for us membership without members. This could take place synchronously or asynchronously, through a script
CU Expert Finder is bringing in MeSH vocabulary including broader/narrower
Mike: Online VIVO conference June 16-18. Favoring Eastern seaboard, not sure what we’re doing with the West coast but working through that.
Technical track where technical content can be presented. All developers and everybody are invited to submit and present. “The doors will be open shortly.”
Announcements to go out: save the date and then call for proposals
Andrew: Sprint
Reviewing the plan for integration with 'master' branches
For each for the projects, there are sprint branches.
Merging pull requests into those branches.
Plan: Four massive pull requests from sprint branches into their respective master branches
Not realistic to break up effort into small pieces that would flow into master branches independently. Better to create stable functionality in the sprint branches first and then merge into master.
Is this a shared understanding?
Michel: Good strategy
Alexander (Sacha) from chat: link to zoom sprint meeting for tomorrow:
Keeping track of changes in sprint branches will help understand the subsequent massive pull request to master
Would be good to have more sprint participants involved in the review and merging process so that the team is familiar with the changes when this code goes into production
Don: Will try to participate in this context
Outstanding tasks
Lots of work on French language content
Update/Test German language files
Need more work in this context
Calls with Christian and Matthias to get their work in
Work in progress
Documentation needed for:
Using the new functionality
how to enable languages
How to add a new language
Testing update functionality
Most tickets in scrum board are result of testing
Focused on current site and current functionality
Toggling between languages and checking that different languages are displayed apparently
Additional testing to be done around editing and update
Potential architectural refactoring
Opportunity to use the same mechanics for filtering triples in the back-end to some of the front-end work occurring
Michel
Have to develop Maven file and capture behavior of page and translate to Java to make it write jobs
For each test, login and logout and clean the database
When the first (version?) is done, the rest should go faster
Andrew: Do you have Solr spinning up in the test environment?
Seeing how to test with Selenium
Andrew: Dependency of VIVO on Solr. How to spin up Solr in context of automated integration tests. Should be possible. If running VIVO locally and Solr not turned on, don’t see anything on home page
Michel: Could do a Selenium test to check the situation when Solr has not started
Andrew: Assuming there will be a Solr running for tests
Michel: test case on vintage VIVO without language context.
Andrew: Tomorrow’s meeting: how do we land current effort and how to finish all the tasks
Andrew: When adding a property to Vitro languages, not found by the code base but adding a property to VIVO languages, that property is found.
Brian: correct that adding a property to Vitro languages should show up
Sacha will help with reviewing pull requests (?I think I got this right)
(i) > a nice feature in the UI would be a deletion option that allows you to delete the primary object, plus whatever else is created via the UI when you create a new object. It could re-use the logic in the form controller
(ii)> Another possibility would be an automatic deletion of orphan objects: vcards without individuals, publications without authors, and for us membership without members. This could take place synchronously or asynchronously, through a script
Brian: Deletion of related nodes when an object is deleted: Functionality that used to exist. Remnants called “stub entities”. Had relationships like Vcard class and relationship classes in 1.6. Before that, had simple versions called context nodes. If you deleted an entity, you’d also delete the context node and possibly related entities. That general mechanism could be extended and revised to work with the current version of the ontology.
Andrew: Where on priority scale?
Brian: Low?
Andrew: Hints and artifacts that could be revived and retooled.
Brian: Depends on priority for GUI based editing in general.
Mike: University of Florida enacts a protocol similarly to (ii) above
Action: Brian will look for or draft documentation of the important features of URI finder and document builder configuration in the display model. Understanding these features is very useful for understanding the important components of VIVO’s search indexing.
Actions - how to find the pinch points and what pinch points are we listening too
Brian: Perhaps better to think at a higher level
When edit/add action happens, listeners use URI Finders which identify which URIs need to be re-indexed
Once those identified, document builders use the index builder queries to run SPARQL queries that get data to map to fields in the Solr documents/index
E.g. add year to year facet field
Result set from SPARQL query -> Fields which have that info
Messaging system: messages could look like that
Row: tuples/variable names to values
Index: field names where the info is mapped
Mike: Florida had been asking for simple triple messaging. Just send us the triples.
Don: Triple level makes sense so that code handling that can then do what it wants
Indicating note-taker