...

1. Announcements
   1. From Michel: ontology version https://github.com/UQAM-SB/CCRD-CRDC/ of CRDC vocabulary.  https://www.statcan.gc.ca/eng/subjects/standard/crdc/2020v1/introduction . "Could be used as a basis for a standardized classification of expertises in VIVO." (Michel is on vacation in August but interested in comments.)
   2. VIVO-PROXY updates
   3. Via Christian, an efficient SHACL validation implementation developed at TIB: https://github.com/SDM-TIB/Trav-SHACL 
2. Unit tests
   1. Georgy has fixed the problematic unit tests in Vitro (none were was problematic in VIVO): https://github.com/vivo-project/Vitro/pull/245  
   2. runOrder fix ready for 1.12.1

      Jira
      server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-2005

3. Small(er) development items for 1.13
   
   1. Firming up requirements for SKOS reasoner / indexer feature
   2. Other candidates from 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

         1. View file
            name Architecture cur and new.pdf height 150

   2. Results of initial experiments with SHACL
   3. Mapping to simplified JSON objects for data ingest
      1. Inspiration? William Welling: Apache Marmotta LDPath syntax https://marmotta.apache.org/ldpath/language.html
   4. Defining concrete next steps
      1. Ontology model for defining form behavior?
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 

...

1. 1. Jira
      server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-2001

   2. https://github.com/vivo-project/Vitro/pull/242

   3. Jira
      server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-2002

   4. Jira
      server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-2003

   5. Jira
      server LYRASIS JIRA serverId c815ca92-fd23-34c2-8fe3-956808caf8c5 key VIVO-2004

References

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

   View file
   name VIVOInABoxIdeaProposal210526.pdf height 250

...

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

...

1. Announcements
1. From Michel: ontology versionhttps://github.com/UQAM-SB/CCRD-CRDC/ of CRDC vocabulary.  https://www.statcan.gc.ca/eng/subjects/standard/crdc/2020v1/introduction . "Could be used as a basis for a standardized classification of expertises in VIVO." (Michel is on vacation in August but interested in comments.) (Michel was here today and discussed this topic.)
1. CRDC: Canadian classification/vocabulary for research.  Standardized across Canada.  Based on international organization.  Open data made from statistics canada.  Taxonomy is in CSV file. 
2.  Michel translated it into OWL/RDFS.  After discussion with Christian, made SKOS version of ontology. Branch issue 1 on GitHub.  When back in September, Michel will investigate more about SKOS and then merge with main branch.
3. Tried with VIVO and it seemed to work well.  
4. If researchers using VIVO in Canada, could then be represented in capability map with standardized expertise.
5. Research area forms where vocabularies can be used.  Would be good to include this ontology/vocabulary as choice in form.  
6. Taxonomy in both French and English.  Three fields and four levels depth.  For each level, individual entities which can be associated with research expertise.  
7. Repository has two ontologies: CCRD-CRDC: data graph.  Another one has the semantics.  Java source is code for transforming CSV into TTL. 
8. Brian: need to use SKOS version?
1. Michel: SKOS.  
9. Michel: Three different data graphs for each taxonomy field. Not sure what the best way to represent this info might be, but good to have this discussion before including in the core.
10. Brian: how large?
1. Michel: Under 5000 triples
11. Brian: What is the semantic file?
1. Michel: Documentation under stats canada. Will see three fields and explanation of what main field is for.  Semantic ontology: properties of columns of CSV file. Rules for structuring taxonomy.  Meta-ontology. 
2. VIVO-PROXY updates
1. Github: https://github.com/vivo-community/VIVO-PROXY 
2. Michel: Cleaned code for the prototype originally presented at conference.  Created additional APIs: persons, organizations, preferred position for person in organization, research area.  Another API to create concept in VIVO.  Another to send IRI in VIVO and retrieve triples in TTL or any form. 
1. Can be compiled
2. Readme file explains proxy
3. Calling API: CURL commands with JSON data
3. If people could test it, this proxy might be a good starting point for sprint in September or October (after mid-September)
1. Sweden/Louisiana universities will be interested in this sprint
4. In the VIVO community github
5. Brian: RDF API for person: Is that doing more than the linked data response for an entity?
1. Michel: SPARQL describe request for a URI.
2. Uses Swagger
3. Port 1919: description of the API and ability to try the API
4. Need to send in validated data since no validation process within Proxy
5. William: vivo’s own responsibility to validate incoming data and not client.
6. Michel: If bad username/password: won’t see a 404 error since VIVO giving back 200.  VIVO proxy doesn’t have a way to check if user credentials resulted in error. 
1. Have pull request for VIVO to give 404 error if bad authentication. 
1. VIVO proxy: Or will need to re-manage communication with VIVO.   
7. William: Does SPARQL update return responses that show if something doesn’t work?
8. Michel: Sparql update api seems to work ok.  
1. When creating a new URI: put it in query.  Or build sparql function that can call VIVO to generate instance with particular URI
2. Management of individuals not trivial in VIVO. If used in VIVO, can’t use one generated in VIVO itself
9. William: if only properties available are first name, last name - no way to disambiguate automatically using just query.  If don’t match exactly, whole new URI. 
10. Michel: more formal way is to check if URI exists
11. Brian: could have api look for keys in ontology - compound key or ORCID that already exists in the system, so can infer that this is the same entity already in the system instead of trying to guess. 
12. Michel: Command design pattern implemented in code. VIVO proxy has own stubs with JAVA class.  Request inside VIVO receiver.
1. https://github.com/vivo-community/VIVO-PROXY/blob/main/bundles/ca.uqam.tool.vivo-proxy/src-custom/main/java/ca/uqam/tool/vivoproxy/pattern/command/receiver/VivoReceiver.java 
13. William: Do you need to change getters/setters if YAML for Swagger changes
1. Michel: no
14. William: What is test coverage?
1. Michel: Currently none.  This is a prototype.
15. Brian: Authentication message always coming back as 200 with VIVO even when login doesn’t work.
1. Proxy relying on human user behavior.  Error shows up on the page but doesn’t send an http error
1. Options: Scrape the response or build separate API that returns error code directly
3. Via Christian, an efficient SHACL validation implementation developed at TIB:https://github.com/SDM-TIB/Trav-SHACL 
2. Unit tests
1. Georgy has fixed the problematic unit tests in Vitro (none was problematic in VIVO):https://github.com/vivo-project/Vitro/pull/245  
2. runOrder fix ready for 1.12.1VIVO-2005 - Add runOrder to unit tests In Review
3. Small(er) development items for 1.13
   
1. Firming up requirements for SKOS reasoner / indexer feature

Draft notes on Google Drive