...
Status of In-Review tickets
Expand Jira server DuraSpace JIRA jqlQuery filter=14416 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5
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