Date
Call-in Information
Time: 11:00 am, Eastern Time (New York, GMT-04:00)
To join the online meeting:
- Go to: https://lyrasis.zoom.us/my/vivo1
One tap mobile:
US: +16699006833,,9358074182# or +19292056099,,9358074182#
Or Telephone:
US: +1 669 900 6833 or +1 929 205 6099 or 877 853 5257
Meeting ID: 935 807 4182
International numbers available: https://zoom.us/u/aeANHanzED
Slack
- https://vivo-project.slack.com
- Self-register at: http://bit.ly/vivo-slack
- Self-register at: http://bit.ly/vivo-slack
Attendees
Indicating note-taker
- Don Elsborg
- Andrew Woods
- Huda Khan
- Benjamin Gross
- Ralph O'Flinn
- Brian Lowe
- Michel Héon
- Alexander (Sacha) Jerabek
- William Welling
- Mike Conlon
- Steven McCauley
Agenda
- Sprint updates - i18n
- Discuss potential methods for external consumers like VIVO Scholars to query/harvest data from an i18n VIVO
- Sprint details
- Test plan
- New GitHub repo for regression/Selenium tests?
- 2020-04 - Sprint Stand-up Reports
- vivo-tech emails
- Missing N3-PP writer and RiotException -
- How to remove people from Vivo - two solutions are being suggested... could someone create JIRA tickets?
- > 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
- Vitro JMS messaging approaches
- Moving tickets forward
- - back on your plate, Mike Conlon
- - need 2 reviewers
- Who is working on what? - Are there active tickets in-progress?
- Incremental development initiatives
- Integration test opportunities with the switch to TDB - requires startup/shutdown of external Solr ..via Maven
Tickets
Status of In-Review tickets
Notes
Sprint updates - i8n
Sprint started Monday, this week and next week. Kickoff meeting happened.
Re: consuming 18n VIVO data for scholars, scholars team needed to determine how that would work with Scholars. How would tags work?
Andrew - presumably this is related to triples in triple store and how this data would be accessed?
William - could be done a few ways.
Address sparql queries for each language. This would be redundant
Another way is to have multiple harvest stages, one for each language, this would then put the output into separate solr indexes, one for each language.
Biggest concern is how to represent this in a discoverable way. In Solr and how the UI would access the language data. William doesn’t see a problem in the triple store itself.
Ralph - so how to allow a choice if there are languages. Should Scholars discover show the languages the same way as VIVO core
Andrew - so the issue might be more with Scholars displaying language data.
Michel - linguistic data needs to be put in the SPARQL query. So when the users are doing certain actions, the language context is placed in the query. Not sure how SOLR is working with this at this point? He says SOLR is working fine and it knows what the language is. Easier to talk about architecture.
Don - so if you are doing a search and you’re in the French context, does the search only return French?
Michel - not quite sure how SOLR is used in the architecture.
Brian - doesn’t believe that VIVO Solr is working with languages.
Andrew- so need to know how SOLR search is operating
Brian - all lang literals placed in ALLTEXT, so if searching esp using a language term, it does return because it’s in the index. BUT, all languages are jumbled together. The shortview will retrieve the label of the individual from the sparql query. So will get the language context from the search.
Michel - the Germans did the language choice functionality.
Andrew - Brians explanation of language search results being context aware seems like the right answer. So quasi results but not architected for language awareness.
Brian - there used to be a problem in older VIVO where things looked like it worked, but one part of the interface where there were inconsistencies because labels might not have been queried right.
Michel - each piece of text needs a linguistic label. It’s a clear request and we have the right text because the query is based on the linguistic context. For users who need multi-lang, each piece of text needs to have a linguistic tag. True for vcards and true for every other ontological data element.
Andrew - The lang tags assignments are done in the UI with this sprint
Michel - yes, each text has a tag which is added to
Lots of discussion on ALLTEXT contents vs the labels returned by search. FIll this in
So search ALLTEXT issues need to be identified and a pattern developed to accommodate lang tags in search.
William - for the case where a lang context is picked .. static text should be changed according to context. So if the dropdown lang picker is set,
- UI - when lang is picked - all tags get changed
- API - does that respect the lang header/tags
- If there’s a lang header, does the triple store respect this and when/how should SOLR
Andrew - certainly static text and also the triple store
William - if lang header is set, does VIVO only return triples for that lang tag in header.
Brian - this used to be the case, but not entirely sure anymore. Needs to be checked.
William - if dropdown is selected, for French, should only French be returned. A standard should be set and applied. If this paradigm is set in Vitro, it should also be used for Scholars. So everything is looking at the appropriate place for the lang tag - eg browser header.
Michel - the mechanism on how to find the linguistic context isn’t important, if we send a sparql request we need to know which language we’re in.
Brian - general principle for end user, we can’t get rid of the language drop down and can't count on users changing headers.
Michel - if researcher is editing VIVO, if they want to write abstract in EN, they have to select linguistic context, then go into the editor and write abstract. Then if he wants to switch to FR, they have to save, then go back and change language context for FR and go back to the abstract editor and write it in FR and save. Good argument to have a drop down language override on individuals
Action - investigate recommended patterns for SOLR to support language contexts.
Lot more questions, optimization, language context overrides, honoring headers, etc
Agenda 2a
- 1761 - look at PR please
Agenda 3 - JMS messaging, link and slide
https://docs.google.com/presentation/d/1dVRoE8xgy4Ie1-TDikM5AwjKT5BmRavhCM4Qn-Nd3HE/edit?usp=sharing
Andrew wants us to gain consensus on which messaging approach to pick.
How to capture the information for code discovery, javadocs are a natural choice, but this also requires publishing the docs. When people investigate code, is there another way to surface the discovery?
Brian - a diversion might be to document all of the methods. In the rdf display model, there’s a whole set of properties on document findings. Can create appropriate RDF entities. This is in the RDF configuration ontology. This might be more useful then docs for each method.
Mike - so who is setting and using this.
Brian - he used this to document configuration properties on what the search indexer is doing is a good place to start
Huda - The n3 for search indexer and config, and there's the code for the search indexer
Mike - found dozens of rdf configuration files. How to start this document.
Brian - start with just the search indexer. Jim started this, if you find an example in the rdf file you can grep into java to find the methods.
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.
William - difficult to find the things that pinpoint what has changed. A design needs to happen with the pinch point on when a triple is changed, that needs to be identified.
Brian - rdfserviceFactory is there and there is a single place in here where you can register a listener. This might not be hard to see where …
Queues of URI’s that have been changed, then actions happen on the queues. So whole complex cascade of what happens. So RDFService and RDFServiceFactory. There should be a place where listeners register to hear about changes.
How to register to listen , a java class that runs during startup. It would be logical to set this up in the applicationsettings.n3, this would be better then placing it in the java class.
Andrew - messaging would be registering a service for the Factory queue.
Brian - current listening is only at the triple level. Are we happy with this only happening in the triple level or should we synthesize a document change and send those messages to clients.
William has a PR to Vitro that listens to data source in TDB and it detects data source changes with rdfDelta. But if externalized triple stores are the approach, then the listener “pinch point” should be above the actual data source.
Actions - how to find the pinch points and what pinch points are we listening too.
Brian - high level goal on what we want to achieve with this. Would be nice to offer a messaging solution that allows people to not think about RDF. A standard mechanism that does the complicated things related to what changed and send a changed document out.
Don - so can we plug in Williams Tamu discovery harvester to a “pinch point” listener.
William - will need to still identify what has changed and how the shape of the changes correlate to the documents that would be created with something like the Scholars Discovery harvester.
Actions
