Page History

...

1. Sprint updates - i18n
   1. Discuss potential methods for external consumers like VIVO Scholars to query/harvest data from an i18n VIVO
   2. Sprint details
      1. Test plan 
      2. New GitHub repo for regression/Selenium tests?
      3. 2020-04 - Sprint Stand-up Reports
2. vivo-tech emails
   1. Missing N3-PP writer and RiotException - 

      Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1761

   2. How to remove people from Vivo - two solutions are being suggested... could someone create JIRA tickets?
      1. > 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 
      2. > 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
3. Vitro JMS messaging approaches
4. Moving tickets forward

   1. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1658

       - back on your plate, Mike Conlon

   2. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1761

       - need 2 reviewers
5. Who is working on what? - Are there active tickets in-progress?

   1. 
      

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

      
      

6. Incremental development initiatives

   1. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1688

   2. Jira
      server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1751

   3. Integration test opportunities with the switch to TDB - requires startup/shutdown of external Solr ..via Maven

      1. Jira
         server DuraSpace JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-1752

...

Address sparql queries for each language. THis 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.

...

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 langueage context language context from the search. 

Michel - the germans Germans did the language choice functionality. 

Andrew - brians Brians explanation of language search results being context aware seems like the right answer. So quasi results but not architected for language awareness.

...

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 linquistic contextlinguistic 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.

...

So search ALLTEXT issues need to be identified and a pattern developed to accomdate lang 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,

1. Ui UI - when lang is picket picked - all tags get changed
2. API - does that respect the lang header/tags
3. If there’s a lang header, does the triple store respect this and when/how should SOLR

...

Michel - the mechanism on how to find the linguistic context isn’t importatimportant, if we send a sparql request we need to know which language we’re in.

Brian - general princile for principle for end user, we can’t get rid of the language drop down and cant can't count on users changing headers. 

Michel - if researcher is editiing VIVOediting 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 want’s to 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 indvidualson 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 

...

Huda - The n3 for search indexer and config, and theres the there's the code for the search indexer

...

William - difficult to find the things that pinpoint what has changed. A design needs to happen with the pinchpoint on pinch point on when a triple is changed, that needs to be identified.

...

Brian - current listening is only at the triple levelevel. Are we happy with this only happening in the triple level or should we sythethis a synthesize a document change and send those messages to 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” point” should be above the actual data source.

...

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.

...