Versions Compared

Old Version 9

changes.mady.by.user Andrew Woods

Saved on

compared with

New Version Current

changes.mady.by.user Andrew Woods

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Draft notes in Google-Doc

  • 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:
    • Sprint JIRA board
      • 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)
    • Meetings
  • VIVO tech emails
    • How to remove people from Vivo - two solutions are being suggested... could someone create JIRA tickets?
    • (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
  • Vitro JMS messaging approaches - redux
    • Proposal that it might be more user friendly if the message content was abstracted away from RDF to a change set that wasn’t RDF-centric
    • Revisiting action plan
    • 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
    • Andrew: Need to consider use cases
      • Solr indexing
      • Logging/Transactions
    • Andrew: slide 1 vs 2
      • Where the work happens: within VIVO or outside it

Actions

  •