...
- Brian Lowe
- Georgy Litvinov
- Michel Héon
- William Welling
- Huda Khan
- Alexander (Sacha) Jerabek
- Dragan Ivanovic
- Sandra Mierz
Agenda
- Welcome Dragan Ivanovic as tech lead
- Mailing list issues
- schema.org missing authors? https://groups.google.com/g/vivo-tech/c/MAoUdgZYOwo/m/uPswpzD_AgAJ?utm_medium=email&utm_source=footer
- 1.12.1 status
- Small(er) development items for 1.13
- Search features related to SKOS / expertise?
- CRDC: https://github.com/UQAM-SB/CCRD-CRDC/ of CRDC vocabulary. https://www.statcan.gc.ca/eng/subjects/standard/crdc/2020v1/introduction .
- Sprint candidates? https://docs.google.com/spreadsheets/d/103P9P4v6yUBSb5BnVaK40NoGx1fIYyL8uaHKUubZWbE/edit?usp=sharing
- Search features related to SKOS / expertise?
- 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
View file name Architecture cur and new.pdf height 150
- JSON entities in/out
- Apache Marmotta LDPath syntax https://marmotta.apache.org/ldpath/language.html
- JSON-LD framing: https://www.w3.org/TR/json-ld11-framing/
- Is round-tripping a potential benefit?
- Defining exercises for evaluation
- Ontology model for defining form behavior
- Diagrams:
- Moving Scholars closer to the core
...
Status of In-Review tickets
Expand Jira server DuraSpace JIRA jqlQuery filter=14416 serverId c815ca92-fd23-34c2-8fe3-956808caf8c5
Notes
...
Welcome Dragan Ivanovic as tech lead
Dragan Ivanovic is a new tech lead. He is a full professor at the university of Novi Sad, Serbia and engineer and author of CRIS system at his university. Excited to join VIVO and collaborate in the next period. In following weeks Brian will be gradually transferring duties to Dragan in the next couple weeks.
Mailing list issues
Schema.org missing authors problem. Strange issue. It looks like schema org with type=review Maybe no authors lead to markup errors. This issue needs more investigation.
From chat:
...
vivo-project/VIVO/blob/main/webapp/src/main/webapp/templates/freemarker/lib/lib-microformats.ftl
‘<#import "lib-microformats.ftl" as mf>’ and ‘<@mf.sectionSchema individual/>’ within the latter file calls the macro code in the former file
1.12.1 status
1.12.1 release content is ready to go. We can 1.12.1 branch from main, need to confirm that from Ralph to make sure it won’t break anything. There was weird issue with 1.12 release when glitch happened and release became broken because sonatype policy doesn’t allow replacing bad artifacts. And previously some unit tests were dependant on other unit test. We fixed that by running test alphabetically and fixed underlined (removed dependencies between tests) problem. Hopefully later this week we will be able to release 1.12.1 and fully focus on 1.13.
Small(er) development items for 1.13
- 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.)
- CRDC: Canadian classification/vocabulary for research. Standardized across Canada. Based on international organization. Open data made from statistics canada. Taxonomy is in CSV file.
- 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.
- Tried with VIVO and it seemed to work well.
- If researchers using VIVO in Canada, could then be represented in capability map with standardized expertise.
- Research area forms where vocabularies can be used. Would be good to include this ontology/vocabulary as choice in form.
- Taxonomy in both French and English. Three fields and four levels depth. For each level, individual entities which can be associated with research expertise.
- Repository has two ontologies: CCRD-CRDC: data graph. Another one has the semantics. Java source is code for transforming CSV into TTL.
- Brian: need to use SKOS version?
- Michel: SKOS.
- 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.
- Brian: how large?
- Michel: Under 5000 triples
- Brian: What is the semantic file?
- 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.
- VIVO-PROXY updates Github:
- Search features related to SKOS / expertise?
- CRDC:
- Search features related to SKOS / expertise?
- vivo
- community
- VIVO-PROXY
- 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.
- Can be compiled
- Readme file explains proxy
- Calling API: CURL commands with JSON data
- If people could test it, this proxy might be a good starting point for sprint in September or October (after mid-September)
- Sweden/Louisiana universities will be interested in this sprint
- In the VIVO community github
- Brian: RDF API for person: Is that doing more than the linked data response for an entity?
- Michel: SPARQL describe request for a URI.
- Uses Swagger
- Port 1919: description of the API and ability to try the API
- Need to send in validated data since no validation process within Proxy
- William: vivo’s own responsibility to validate incoming data and not client.
- 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.
- Have pull request for VIVO to give 404 error if bad authentication.
- VIVO proxy: Or will need to re-manage communication with VIVO.
- William: Does SPARQL update return responses that show if something doesn’t work?
- Michel: Sparql update api seems to work ok.
- When creating a new URI: put it in query. Or build sparql function that can call VIVO to generate instance with particular URI
- Management of individuals not trivial in VIVO. If used in VIVO, can’t use one generated in VIVO itself
- 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.
- Michel: more formal way is to check if URI exists
- 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.
- Michel: Command design pattern implemented in code. VIVO proxy has own stubs with JAVA class. Request inside VIVO receiver.
- William: Do you need to change getters/setters if YAML for Swagger changes
- Michel: no
- William: What is test coverage?
- Michel: Currently none. This is a prototype.
- Brian: Authentication message always coming back as 200 with VIVO even when login doesn’t work.
- Proxy relying on human user behavior. Error shows up on the page but doesn’t send an http error
- Options: Scrape the response or build separate API that returns error code directly
- Unit tests Georgy has fixed the problematic unit tests in Vitro (none was problematic in VIVO):https://github.com/vivo-project/Vitro/pull/245 runOrder fix ready for 1.12.1VIVO-2005 - Add runOrder to unit tests In Review
- Small(er) development items for 1.13
- CCRD-CRDC/ of CRDC vocabulary. https://www.statcan.gc.ca/eng/subjects/standard/crdc/2020v1/introduction
This small feature that could be added to 1.13 could add better support for reasoning in relationships with SKOS vocabulary. We can use SKOS rather it is done the way it is now. That kind of a feature could be good for everybody. We talked about reasoner plugin. Seems like an attractive thing to work on. At the same time will there be companion features that could make VIVO even more useful.
Can we formulate that kind of feature to better rank people? Does it seem interesting and relevant? It could be more future looking thing.
Benjamin raised a problem of boosting, because boosting was removed from Solr. We can plan that for 1.14.
- Sprint candidates? https://docs.google.com/spreadsheets/d/103P9P4v6yUBSb5BnVaK40NoGx1fIYyL8uaHKUubZWbE/edit?usp=sharing
Things that we find useful for our institutions.
There was an attempt to create war file with VIVO before last release, but that wasn’t practical for that time. Changing that behaviour at that point broke behaviour. General installation approach is the same but for the next release we could do something to move towards that direction. That is one that is on the list, but this is something we need to work with.
Making VIVO extendable online without need for editing files could be very useful.
Adding some additional stylesheets should be simple without rebuilding the whole system.
We should also think about how to make interface development easier for custom implementations. One option is to use the third tier. Or is it could be reasonable to use default build with own overwritten files out of that installation.
On one hand we want to be standard and on other hand we want to improve user experiences. Is there a general idea of a feature to create customization that could be used on other installations?
Decoupling frontend and backend is one of important goals for now.
Priorities should be ranked and resolved by ranks (take into consideration best practices). We could add columns to the spreadsheet and rank issues and features.
JIRA is going to be migrated to free JIRA could. Whether or not we want to save them or use them will be discussed at the Lyrasis meeting tomorrow.
Most of us prefer Github to JIRA. Where features will be touching VIVO and Vitro should go?
...