...
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 )