Dates
Sept 17-28, 2018
Participants
- Graham Triggs
- Andrew Woods
- Mike Conlon (Second week: September 24-28, documentation, testing)
- Qazi Asim Ijaz Ahmad (Not sure about the dates yet. Would like to work on Elastic Search with Don)
- Kitio Fofack mainly on i18n (available for the sprint)
- Christian Hauschke (2nd week, i18n)
- Ralph O'Flinn
- Brian Lowe
- Don Elsborg
- Steven McCauley
- Manuel Schwarz
Meetings
2018-09-17 Sprint - Kickoff Meeting
Tickets
Scrum Board
Elasticsearch / Solr Upgrade
Team
- Don Elsborg (CU Boulder)
- Qazi Asim Ijaz Ahmad
- Steven McCauley
- Ralph O'Flinn
Purpose/Rationale
Security concerns with Solr dependencies
Integrated elastic index in VIVO to support facetview UI used by Unavco, CU Boulder, DCO
Brings index work from Product Evolution group closer to the VIVO core
Deliver more structured and rich json and eventually json-ld documents from VIVO's indexes for web consumers
Deliverables
Discuss/Analyze/Document the ElasticSearch work done by individual sites.
Which sites?
- Create a design for externalized search
- Support ElasticSearch (v6.4.0)
- Support Solr (7.4.0 & 4.10?)
- Implement externalized search
- Initial Solr work from Huda (Ralph O'Flinn, Steven McCauley )
- Initial ElasticSearch work from Jim ( Don Elsborg)
- merge pull requests from items a and b above into a new combined sprint branch
- verify the search engine abstraction layer such that VIVO can work with both ES and SOLR based on above 2 items
Create instructions on how to make YOUR VIVO installation work with ES or SOLR (on the assumption that Solr will still be the default).
Second priority deliverables
Analyze how to build a nested json-doc that represents an object ( person, publication, grant, etc ) in the index ( both SOLR or Elastic )
Lay groundwork for analysis of incorporating semantics ( json-ld, other ) in the indexed document. Mapping the objects from VIVO-ISF to an indexed semantic document would need to involve the ontology group
- Request: keeping the delivered Elasticsearch integration backwards compatible with VIVO 1.9.3 and 1.8.x – could be valuable
Relevant docs
- https://www.searchtechnologies.com/blog/solr-vs-elasticsearch-top-open-source-search
- https://sematext.com/blog/solr-vs-elasticsearch-differences/
- https://db-engines.com/en/ranking/search+engine
Multi-Language Support
Team
- Christian Hauschke
- Kitio Fofack
- Ralph O'Flinn
- Manuel Schwarz
Purpose
Implement interface i18n on home page, the capability Map and the profile header form.
The interface should be able to completely switch to the selected language.
Deliverables
Identify all places in code/freemarker/jsp that need extraction and create related JIRA Tickets
Split codebase across different people (per package?)ACTION: Kitio to divide codebase
- Initialize language artifacts necessary to be complete for interface i18n
- Create the translations (English, German, French)
- Improve toggling mechanism (do not use flags)
- Improve technical documentation for adding new languages
- Pulling in Maven artifacts
Future deliverables
- Rectifying differences in grammar
- Pluralization - need appropriate infrastructure
- i18n support for multi-language content
ABox / TBox RDF Loading
Team
- Don Elsborg
- Brian Lowe
- Mike Conlon
Purpose
- Identify and understand current documentation
- Accessing VIVO Data Models#InitializingtheModels
- Directories and Files
- Graph Reference
- Ontology Reference
- Understand and Document recommendations for updating and overriding `firsttime` and `everytime` RDF files
- Understand and Document how this RDF data is organized in the content and configuration triple stores
Deliverables
- Documentation of Content, Structure, Purpose, etc of 'firstime' / 'everytime' / 'filegraph' abox,tbox RDF files and each of the directories that they're located in. See item 1.b 'Directories and Files' above
- Documentation of where 'firsttime' / 'everytime' / 'filegraph' abox/tbox RDF is loaded (which triplestores-config vs content stores), and why
- Verify the documentation of the relationships with vdata/rdf and the actual graphs – changes in the GUI don't get reflected in $vitro-home/rdf
- Documentation of pitfalls – things not to delete. (ClassGroups? And other things that are loaded by firsttime and are difficult to reset to their initial state without clearing the triple store)
- Documentation of use cases for updating 'firsttime' / 'everytime' RDF files
- Documentation of recommendations for above use cases
Future deliverables
- Resetting 'firsttime' - Brian Lowe to elaborate
- Persisting updates from the GUI (ClassGroup / PropertyGroup / etc) - Don Elsborgto elaborate