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?pwd=a2Q3RUVKVkN2dkNHV3FUaFRtLzhGdz09
- Passcode: 351860
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
- Brian Lowe
- Benjamin Kampe
- Georgy Litvinov
- Michel Héon
- William Welling
- Benjamin Gross
- Ralph O'Flinn
- Don Elsborg
- Huda Khan
- Dang Vu Nguyen Hai
- Christoph Gopfert
Agenda
- Announcements
- via David Wilcox: VIVO in a Box town hall
This is just a reminder that the VIVO in a Box town hall meeting will take place on Monday, July 26, at 11am EDT / 5pm CEST. Please use this link to register for the meeting and generate a calendar invite in your timezone: https://lyrasis.zoom.us/meeting/register/tJwqceGvrzwpHdc1g3NSgvHOhRlLF3mCjY_r.
You can read and comment on the proposal here: https://docs.google.com/document/d/1JOO2mUlGcc1eAXJG5k-7r86FyE2JKjKOqjFZ5vVp_zI.
- via David Wilcox: VIVO in a Box town hall
- Unit tests
- runOrder fix ready for 1.12.1 – just needs branch to merge into
- List of desired development items:
- quick wins / items for a more rapid release
- collaborative items for future sprints
- (Add/edit at will) spreadsheet: https://docs.google.com/spreadsheets/d/103P9P4v6yUBSb5BnVaK40NoGx1fIYyL8uaHKUubZWbE/edit?usp=sharing
- Defining shapes or subgraphs for use in APIs, edit forms, indexes etc.
- Diagrams:
- existing architecture: https://docs.google.com/presentation/d/1raO98mklGUQgAc6wMMbgDEsHVk1zoCA3bq4Fyy21GjI/edit?usp=sharing
- Georgy: existing versus proposed
- Results of initial experiments with SHACL
- Defining concrete next steps
- Ontology model for defining form behavior?
- N3-based templates?
- Deriving indexing / display queries?
- Mapping to simplified JSON objects for data ingest
- Inspiration? William Welling: Apache Marmotta LDPath syntax https://marmotta.apache.org/ldpath/language.html
- Diagrams:
- Moving Scholars closer to the core
References
- 2019-01 Architectural Fly-in Summary#201901ArchitecturalFlyinSummary-Ingest
- VIVO in a Box current document for feedback:
Future topics
- Prioritizing and planning post-1.12 development
- Forward-looking topics:
- frameworks: Spring / Spring Boot / alternatives
- Horizontal scalability
- Deployment
- Configuration : files / environment variables / GUI settings
- Editing / form handling
- Adding custom theming without customizing build
- Post-release priorities
- Ingest / Kafka
- Advanced Role Management
- Moving Scholars closer to core - next steps
- Vitro JMS messaging approaches - redux
- Which architectural pattern should we take?
- What should the body of the messages be
- 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
- VIVO in a box town hall
- One of the main principles of VIVO in a box is that it should handle everything from an upstream system. Could this be a quick solution for folks prior to doing data ingest?
- Don - might pull in more data then just comes from Elements. For example Unpaywall, Altmetric. This data would have to be mashed up, ideally in VIVO.
- Brian - so we still might have to address data ingest issues
- Don - Would like VIVO in a box to have LOD
- Brian - would be good if VIVO wasn’t just a silo but can also dynamically link out to data that’s managed elsewhere. Not sure how wide spread this is.
Agenda 3b - google do wish list spreadsheet
People are starting to mark things up
Row 49 in sem web features. Would be good to be able to look up remote entities like ROR, OpenAire, Wikidata, etc
Reconcilling inventory of our entities in relation to remote entities.
If this is important to build in,, then think more clearly about this now.
Michel - good be large or small - should start with Federated Search - hence need common Ontology . Eg wikidata has it’s own ontology. So perhaps start with federated search within VIVO communities.
So can start with searches for specific competencies. Then display this within the capability map. Opinion is that wikidata search might be more complicated.
Each server has a SPARQL query server attached to the federated query service.
Benjamin - there were efforts with search previously. Also coordinated with TPF endpoints.
Brian - could also link external resources in the ontology and then query those resources when needed. Could we pull that data into the capability map.
Michel - if we want a good capmap, we need a good ontology for concepts.
Don - used wikidata for concept tree lookups and mashed this up against CU data.
Michel - when instructors add their own freetext keywords it can get very difficult. UQAM compiles these keywords and curates them.
Don - can we have a concept/keyword (federated) service. Perhaps where we can leverage the work of all of the VIVO institutions as a whole.
Brian - we should also focus some of the semantic efforts into this domain.
Michel - link - https://www.statcan.gc.ca/eng/subjects/standard/crdc/2020v1/introduction
Classification used by all researchers if they want to make a grant or a finding for research. They have to use the classifications in the scheme.
It’s also bi-lingual ( French and English ).
Can put this in Github.
Don - does VIVO do transitive queries for SKOs
Brian - We don’t do things with the structure of SKO’s for broader/narrower. There is more we can do at the VIVO level if we have good data that capture things. Problem is that experts tend to declare their expertise in extreme detail. Aggregate and weight things based on where they appear if we do a SKO’s transitive inference. We need more relevant search results.
Michel - is it possible to make inference engine on SKOs?
Brian - SKO’s is RDFS, so we need a reasoner that can run over RDFS.
Michel - SKO’s language is more flex, OWL is more formal.
Don - wikidata concepts are in the ontology
Michel - but it’s not formal. Doesn’t believe wikidata has the owl restrictions. So not enough formal to do strict reasoning on it.
Benjamin - It would be nice if VIVO could be more clever with named graphs in general
Brian - can take a SKO”s vocab and make them OWL, but this gives you the same thing in another formallism but not really an ontology. To give it the restrictions we need a fair amount of work.
To use the broader and narrowers as they are might make things easier.
Michel - if we want a formal reasoner, we will have to move things to OWL.
Another point in the excel sheet is to make a formal reasoner. Its a powerful feature of AI is to do semantic reasoning.
Brain - perhaps a quick win is to do a set of sparql queries to “reason” over skos and place it in a separate named “inference” graph. Make this a simple module. Do this quick and have it for the next version of VIVO.
Michel - can then make SPARQL queries on explicit and/or inferred data.
Brian - pair this with an indexer ( module ) that can rank/weight this to take advantage of the new inferred data and surface individuals who “truly” match the desired search.
Michel - to do this with SKO’s, - 2 way - transpose the SKO’s data to OWL and use reasoning OR make a SKO’s inference. Could use SameAs to make a SKO’s class same as OWL class.
Brian - could do an Adhoc thing to make the SKO’s reasoner. Can have reasoner plugins in VIVO right now.
Michel - skos inference - https://github.com/NatLibFi/Skosify/wiki/SKOS-Inference
Brian - this could be a quick win.
Next meeting - August 3rd