Date

Call-in Information

Time: 11:00 am, Eastern Time (New York, GMT-04:00)

To join the online meeting:

Slack

Attendees

(star)  Indicating note-taker

  1. Rachid Belkouch
  2. William Welling 
  3. Brian Lowe 
  4. Andrew Woods
  5. Don Elsborg (star)
  6. Alexander (Sacha) Jerabek
  7. Ralph O'Flinn
  8. Benjamin Gross
  9. Santhosh
  10. Huda Khan

Agenda

  1. Announcements
    1. Andrew Woods out next two weeks
  2.  2020-08 - i18n Editing Sprint - where i18n stands
  3. Moving Scholars closer to core - next steps
    1. SelectQueryDocumentModifier
    2. Entities: Collection, Concept, Document, Organization, Person, Process, and Relationship
    3. Configuring Solr
  4. Moving Data Ingest Task Force forward

Future topics

  1. Vitro JMS messaging approaches - redux
    1. Which architectural pattern should we take?
    2. What should the body of the messages be?
  2. Renaming of 'master' branch? (ZDNet, BBC)
    1. Guidance from GitHub 
    2. DSpace has done it
    3. Fedora has done it
    4. Samvera is doing it
  3. Incremental development initiatives
    1. Unable to locate Jira server for this macro. It may be due to Application Link configuration.
    2. Unable to locate Jira server for this macro. It may be due to Application Link configuration.
    3. Integration test opportunities with the switch to TDB - requires startup/shutdown of external Solr ..via Maven
      1. Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Tickets

  1. Status of In-Review tickets

    type key summary assignee reporter priority status resolution created updated due

    Unable to locate Jira server for this macro. It may be due to Application Link configuration.

Notes 

Draft notes in Google-Doc 

Andrew out next two weeks. How should we plan the upcoming Tuesday agendas. 

Don kicking around pointing GraphQL to the Facetview Elastic endpoint

William - sounds good but there is a lot of work involved. There’s no magical schema/response creation. Need to make the resolvers to make the requests. 

Andrew - perhaps time is best spent to integrate the VIVO indexing in the core. Not sure about widespread usage of facetview.

William - could be a good idea to be able to spin up new resolvers for GraphQL. 

Andrew - should we as a community have the ability to spin up new resolvers

William - schemas have to map what is coming out of the endpoints.  Perhaps there should be a generalization.

Don - wants to use a long lived reference spec to push and distribute the GraphQL interface

William - creating a schema from the facetview doc could be simpler then the SOLR index. Would be best to have this be part of a project. Still likes the idea of externalizing GraphQL

William - current implementation of Graphql disc uses the spring abstraction. It generates it’s schema from the model in scholars discovery. For GraphQL query might want to make multiple types of  data. Schemas are hold ups from a resolver. Can request remote schemas. Wondering what resolver to use for GraphQL.

Don - wants to use the Kotlin GraphQL lib used by Duke. Don will share links with William.

Andrew - meet in 2 weeks. 

Ralph - just pick tickets, do some work. 

Ben - Cancel since Andrew isn’t here.

Is Huda working on a presentation.

Huda - yes, co-chair LOD affinity group. They meet every 2 weeks. ? about if you have LOD how do you index this info. Created slides to show this in a high level view. Is it an entity in a SOLR doc. William sending her info so Huda understands this now. Will share slides. So if we want to do some queries, we might not always want to use SPARQL. Found  some thesis’ where people can embed full text search in SPARQL. Won’t get into the nitpicky stuff yet about nesting. Why would you want to index the graph, what kind of questions are being asked. Discovery takes some things into account like types and class groups. Takes literals and dumps them into a text field. Scratching the surface right now.
? are you highlighting the state of the art?
People on the call might be interested in if they are wanting to index their data, what would you want to capture . what kind of decision points are there to be made. Which properties to include in the index for what purpose.

Wrap for i18n sprint

Andrew - high level message is i18n work is close. Much smaller set of tickets open. Half of the tickets finished. Sept 21 is a 1 week sprint. Can hopefully finish the last of the tickets.

VIVO 1688 separate VIVO ontology. Manage Vitro annotations separately. In i18n the annotations ( tbox annotations ) are represented in each of the language files per language. VIVO annotations moving to language files. 

Ralph - ontology meeting happening Thursday. Mike will be there.

Brian - thinking more about annotations vs initial tbox. Makes sense to have 2 different annotations files. One only contains the lang things like labels, examples, a couple of different properties that are lang dependent, vs others like display rank are different. Call those things vitro annotations since they are Vitro namespace. So this would trim things down. 

Andrew - some rdf files in core, with them having excluding en-us attr. So every lang including english is in vitro languages. Working on deleting the rdf files from core and moving to vivo languages. So when starting VIVO and not using international, vivo recognizes this and defaults to en-us. 

I18n languages get loaded into content store. 

There is another ticket they want to finish which can refresh firsttime files.  If you restart VIVO with changes to firsttime file there’s investigation to see what changes are and then it applies it.
https://jira.lyrasis.org/browse/VIVO-1918


Chat note from Benjamin:

“I agree with the design pattern Brian suggested, where language-specific triples should be pulled out so translations can be easier.

But how can we document a case where a single 'object' is referenced in many different repositories, so that if somebody were to say 'dateIssued' (https://github.com/vivo-project/VIVO/blob/master/home/src/main/resources/rdf/tbox/firsttime/vitroAnnotations.n3#L6096) was the wrong triple and wanted to change it to a different one, that they know to change the URI in VIVO, Vitro, VIVO-languages, wherever the annotations exist... etc.”

Andrew - curious if Santosh is going to use i18n? 

Santosh - hasn’t thought about i18n yet. Goal is to keep system updated so they don’t fall back. Any feature that keeps customers engaged. He will add that to his list.

Sacha - will look at tickets regarding capability map. Looking at documentation. 

Brian - feels like we’re getting close to being able to merge. 

Andrew - pressing initiatives - vivo scholar and solr index; data ingest task force ( getting data into vivo and making the process clear )

Actions

  •  



  • No labels

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.