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. Brian Lowe
  2. Benjamin Kampe 
  3. Georgy Litvinov 
  4. Michel Héon 
  5. William Welling 
  6. Benjamin Gross 
  7. Ralph O'Flinn 
  8. Don Elsborg (star)
  9. Huda Khan 
  10. Dang Vu Nguyen Hai
  11. Christoph Gopfert

Agenda

  1. Announcements
    1. via David Wilcox: VIVO in a Box town hall

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

  2. Unit tests
    1. runOrder fix ready for 1.12.1 – just needs branch to merge into Unable to locate Jira server for this macro. It may be due to Application Link configuration.
  3. List of desired development items:
    1. quick wins / items for a more rapid release
    2. collaborative items for future sprints
    3. (Add/edit at will) spreadsheet: https://docs.google.com/spreadsheets/d/103P9P4v6yUBSb5BnVaK40NoGx1fIYyL8uaHKUubZWbE/edit?usp=sharing
  4. Defining shapes or subgraphs for use in APIs, edit forms, indexes etc.
    1. Diagrams:
      1. existing architecture: https://docs.google.com/presentation/d/1raO98mklGUQgAc6wMMbgDEsHVk1zoCA3bq4Fyy21GjI/edit?usp=sharing 
      2. Georgy: existing versus proposed
    2. Results of initial experiments with SHACL
    3. Defining concrete next steps
      1. Ontology model for defining form behavior?
      2. N3-based templates?
        1. Deriving indexing / display queries?
    4. Mapping to simplified JSON objects for data ingest
      1. Inspiration? William Welling: Apache Marmotta LDPath syntax https://marmotta.apache.org/ldpath/language.html
  5. Moving Scholars closer to the core
    1. Build messaging system first? versus
    2. Original option of typing into existing document modifiers:
      1. "win/win" opportunity: Scholars and VIVO both eliminate some complexity
      2. converting Scholars SPARQL queries to VIVO DocumentModifiers
      3. replacing URIFinders with fast, reliable Solr lookups 

References

  1. 2019-01 Architectural Fly-in Summary#201901ArchitecturalFlyinSummary-Ingest
  2. VIVO in a Box current document for feedback:

Future topics

  1. Prioritizing and planning post-1.12 development
  2. Forward-looking topics:
    1. frameworks: Spring / Spring Boot / alternatives
    2. Horizontal scalability
    3. Deployment
    4. Configuration : files / environment variables / GUI settings
    5. Editing / form handling
    6. Adding custom theming without customizing build
  3. Post-release priorities
    1. Ingest / Kafka
    2. Advanced Role Management
    3. Moving Scholars closer to core - next steps
  4. Vitro JMS messaging approaches - redux
    1. Which architectural pattern should we take?
    2. What should the body of the messages be
  5. 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

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

  • 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 

Draft notes on Google Drive



  • No labels

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