...

 Indicating note-taker

1. Andrew Woods
2. Ralph O'Flinn 
3. Benjamin Gross 
4. Alexander (Sacha) Jerabek
5. Steven McCauley
6. Mike Conlon
7. Brock Balducci
8. Hector Correa
9. María Amalia Flórez Huertas
10. Amin Kesharav
11. Huda Khan

Agenda

1. Community updates
   1. VIVO Scholars
2. Special topics for future dev calls
   1. 2019-12-06 - Special Topic - TDB vs SDB
3. Potentially changing time of this call... 10am ET (as opposed to the current 11am ET)?
4. VIVO edit UI's and integrations... what is the ideal "VIVO API"
5.  In-review tickets 

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

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

   3. 
      

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

      
      

6. Short-term development activity
   1. Extract ontology from core codebase
   2. Extract languages from core codebase
   3. Move from 'develop' to 'master' branch
7. Review of vivo-project repos for appropriateness of being supported by Committers

...

Draft notes in Google-Doc

• Mike suggests looking at https://vue.tufts.edu/ .  Can this be containerized?
• Amin intro: New to VIVO and listening in to better understand VIVO. 
• Internationalization challenges: How to display text right to left? E.g. in Persian. 
• Mike: There is an HTML tag for doing that, but no example with VIVO currently. (DIR=RTL to make all the text go right to left).  (HTML tag reference https://www.w3schools.com/tags/att_global_dir.asp )
• Can that tag be added automatically when the language is changed? 
• Sacha: Would be good to include in the internationalization task force to address languages that go right to left (e.g. Persian, Hebrew, Arabic) since we have not addressed this use case yet

See i18n page: https://wiki.lyrasis.org/display/VIVO/Internationalization+Task+Force

Also a Slack channel : https://vivo-project.slack.com/archives/CAVDCPXBM

1. Community updates
   1.  VIVO Scholars- call yesterday agreed they would nominate somebody to attend the Tuesday dev call to provide an update. Nobody today! 
2. Special topics for future dev calls
   1. 2019-12-06 - Special Topic - TDB vs SDB
      1. Special topic call coming up on December 6 on TDB vs SDB. Call for agenda items. Wiki page for call: https://wiki.lyrasis.org/display/VIVO/2019-12-06+-+Special+Topic+-+TDB+vs+SDB
      2. Mike: Created a table with common assumptions made about TDB and SDB for discussion, we seek confirmation on the hearsay. 
      3. Andrew: Ideally, a recommendation would come out of the meeting, or a VIVO project position on TDB vs SDB.
      4. Mike: We may need a followup meeting after we surface the facts in this first call. We need information! E.g. there is an assumption that TDB is fast to read and slow to write, but what does this mean? At how many triples does this become meaningful? There are different scenarios when it comes to how VIVO is updated, for example many small transactional edits vs huge bulk reloads.
      5. Critical issues should be defined. E.g. sustainability 
      6. Andy Seaborn, lead of Apache project will be on the call. He will be looking for facts on how VIVO uses SDB and TDB. Scales and issues. Andrew suspects that Andy will not have an opinion on sustainability of TDB vs SDB because it really seems VIVO is the only community using SDB so it’s more or less up to us. 
      7. Mike: How memory-bound is TDB? TDB is a file based system. Graham’s concern: No concurrent JVM access. 
      8. Andy’s suggestion: Wrap the triplestore with Fuseki to allow multi access 
      9. Mike: Seems to be a need for a lightweight abstraction layer in between VIVO and TDB.
      10. Andrew: How about corruption? SDB seems to be more resilient. TDB, seems to be a risk of corruption if a single bit is flipped
3. Potentially changing time of this call... 10am ET (as opposed to the current 11am ET)
   1. Potential for a governance call occurring at the same time as this call.
   2. No proposal for moving at this point… but stay tuned
4. VIVO edit UI's and integrations... what is the ideal "VIVO API"
   1. Coming out of Brown’s presentation last week on their editing interface.
   2. Is SPARQL the correct abstraction? Or should there be a mechanism where updates can occur without SPARQL (ie knowledge of the data model).
   3. Steve: An update API that does not use SPARQL suggests everyone needs to align their data models
   4. Benjamin: Any level of editing abstraction requires SPARQL to sit in the back anyway, so the model should still be customizable. 
   5. Mike: Hector was asking for a way to interact with VIVO data via JSON rather than RDF.  Isn’t the Scholars project working on this? Andrew: No agreement on technology within the Scholars effort, e.g. GraphQL vs not.
   6. Mike: If you’re using an Elasticsearch or Solr layer to support a UI doesn’t that require the creation of these documents? Not so worried about details if documents align to the entities we use in the VIVO universe (such as pubs and orgs). 
   7. Huda: What are the specific use cases? Observation: two ways to edit data, 1. Go straight to triple (SPARQL update), direct pipeline to backend 2. Use JSON and don’t worry about the ontology.
      1. VIVO editing interface kind of does this, it creates an abstraction to update that creates the necessary RDF 
      2. If we create an API with this abstraction we would likely want to redo the VIVO editing interface to use it.
   8. Mike: We don’t understand the nuance of the original VIVO editing interface and its use cases.
   9. Andrew: Primary use case for edit API is focused on having a separate user interface where faculty can edit profiles (separate from VIVO). Perhaps a lightweight, separate interface for end users (faculty) vs the VIVO editing interface that allows you to edit everything.
   10. Mike: How about access control? How about bulk editing? E.g. upload a bibtex or EndNote file. But most complaints seems to be about self edit (faculty editing their own) and the VIVO interface not doing it well. In OpenVIVO we locked down most editing capability and got a good reaction. We stopped them from going into areas where they can hurt themselves. Maybe VIVO should have different default editing settings.
   11. Andrew: Is the advanced role management required for this? Mike: No. All configuration for OpenVIVO was done using standard mechanisms.
   12. Mike: Technique suggestion for soliciting feedback from community. Surveys don’t work because it’s the same people every time. What about the sites we never hear from? It would be difficult… but we could set up a one hour structured interview https://en.wikipedia.org/wiki/Structured_interview with every site.  Plan out very well the questions we ask, policy, pain points, current and future use, technology, community.
5. In-review tickets
   1. VIVO-1732 - jena3tools does not work with TDB databases IN REVIEW
   2. Benjamin reports that the fix was a simple check to see if the database is TDB or SDB. Looking for a pair of reviews.

Actions

•  Organize a session on Brown's work on editing

...