...
Thoughts over the holidays
- Mike Conlon investigated wikidata un countries
- Less countries then he thinks it should have - 162
- This was entities instance of country – so that’s odd
- Eg Albania wasn’t on the list, sounds inconsistent for country definition
- So how do we work with Wikidata to determine why the list is so short and how is it maintained
- Main question – how do we follow up
- Don +1
- Mikes goal is not to update wikidata data
- Andrew noted that in Sem w3 list a wikidata question was monitored and answered by wikidata folks
- Mike C. — scholia seems very biased, very focused, working on large scale dumps. So if you want all papers from university of x, you might get nowhere
- Don – wikidata should be augmentation - non-authoritative.
- Ralph - wikidata should augment - also to deal with lag
- Don – wants to use wikidata concepts and use VIVO to map concepts between VIVO and wikidata - perhaps use openvivo for this. So try to store sameAs relationships between VIVO and wikidata. # Use the VIVO triple store and VIVO editorial interface to maintain these relationships
- Mike - UFL has the same need - Research Intelligence
Contribution process
- Andrew - Handling managing large contributions that “come over the wall”. How can the team engage in this such that we’re not faced with the problem of having a large changeset that has minimal context but to bearing on the overall VIVO design goals.
- So – how to get process engaged initially in the design phase.
- ……… crickets
- Jim – taking the procedure of creating issues then pull requests - so creation of jira issue is pro-forma. As opposed to starting with the Jira issue then we can discuss.
- Mike - not uncommon to develop first then think second.
- Don - needs to work for employing institution, then moves towards a VIVO ticket after the fact.
- Mike - is there a way to sum up tickets for the type and scale of work? So there are 3 examples of fantastic work. So these ideas are thought about for a few year.
- VIVO-1415 - Add publication claiming from PubMed and CrossRef IN REVIEW
- VIVO-1436 - Advanced role management IN REVIEW
- VIVO-1545 - Track user changes made to the content store IN REVIEW
- So these tickets above benefitted from a lot of community design work.
- Andrew - in open source world, we benefit from a planned design.
- Question is how to retroactively apply code to a design such that we can discuss. So the advanced role mgmt system was kind of like this. Where Graham presented the ACL’s to the dev group.
- So how to include great work such that there are updates that we want. How do create a process that promotes engagement and buy in as opposed to things being “thrown over the wall”. This should help bring the team together.
- Mike - 2 more examples
- The data distribution api - this was submitted, but put off. It did eventually get resolved. There wasn’t an open design process, it was submitted as a complete work.
- Jim – objection - it’s not included with the code
- Ralph - slated for 1.11
- Mike - documented in 10.0
- Ralph - so doc was added to show people HOW to add it to 1.10
- The data distribution api - this was submitted, but put off. It did eventually get resolved. There wasn’t an open design process, it was submitted as a complete work.
- For architectural flyin – will discuss what is a component what is configurable
- Jim – besides Data dist api - also provenance to capture logging of changes. So this can be implemented as a configurable add-on. Should we just strive for this model.
- Andrew - so if a work is a module, or optional – is having the team involved in design might not be paramount?
- Jim - exactly - so even if core committers are that involved - the add on can still be available and workable.
- Andrew - if we get configurable modules then the core team might not have this much engagement.
- Andrew - fundamentally this boils down to communication. So without that much process put in at this point, to move forward with communication, as opposed to people developing a large sum of code, throwing it over the wall, then ducking.
- Mike - need to identify the things that should require discussion or at least benefit from this.
- Don - so how to identify when to surface issues with VIVO
- Mike - create a ticket and use this as an entry point for design discussion. Try to have the tickets be technical and not vague.
- Andrew - summing up -
- we want transparency as to what the issues are as soon as possible.
- Use the Jira process to help identify and characterize issues, particularly from received to open.
Ticket gardening
- 1619 - jira is resolved. Code is merged - also for 1.9 branch
- Andrew - we should eventually talk about maint releases. So we might want to think about putting out a 1.9.4
- Received tickets - 1666. –
- Don - want more discussion with firsttime/everytime –
- Brian commented on the ticket explaining the way things work now.
- Mike - want to identify other institutions that run into this problem. UFL has this issue. ** Anything that is in Firsttime – this creates a big problem.
- Andrew - more big wins - Ben is good to go with 1671
- Wants people to look at in-review tickets
- VIVO-1667 - Language Filtering does not filter model on all construct queries IN REVIEW - low-hanging.
- This is a one liner
- VIVO-1661 - Merging VIVO-DE community translations into code base IN REVIEW - An important step for i18n... resolves many other open issues
- VIVO-1659 - Improve documentation on how to add new language support to VIVO IN REVIEW - low-hanging, documentation
- We can close this if we agree with documentation
- VIVO-1641 - Replace afn:localname / afn:namespace with cross-platform equivalent IN REVIEW - relatively straight-forward bug fix
This touches a few things but it’s the *** same fix applied broadly - VIVO-1630 - Start Year field keeps the same label even when language is changed IN REVIEW - Kitio Fofack to review?
- VIVO-1525 - SPARQL query page freezes IN REVIEW - low-hanging
- VIVO-1667 - Language Filtering does not filter model on all construct queries IN REVIEW - low-hanging.
- Get a review on this is helpful
Architectural flyin
- How to address workflows that bring things in from multiple data stores and store in VIVO
- On the flip side, have exports from VIVO or a canonical data store that pushes data to VIVO.
- Different VIVO front ends - so a read only view
Edit - can edit be separated from the standard view - Complexity added with seperate VIVO and Vitro. # What are the pros/cons of collapsing the two. So who cares about Vitro that doesn’t care about VIVO.
- Steve McCauley - more interested in Vitro than VIVO. He works more with Vitro.
- Mike - Metabolomics (sp?) project also using Vitro with some VIVO ontology
- Steve - will use some Vivo ontology but not all since they departed from the VIVO display.
- Andrew - Steve - are there natural architectural patterns that you would have like?
- Steve - separating the display layer from the rest of the system. Arch is fine since they don’t use it for display. Entirely as a backend.Some things could be changed. Things like externalizing search which would make things more modular. Or database not being tied to SDB/TDB so have a different triple store. Would like ability to swap things in and out. We replicate the VIVO SOLR for back end purposes.
- Mike - a deployment pattern could be that there is no front end. So could have a non vivo front end like Brown. So facts on demand and you put them where you want them. Not all sites want a front end. Just facts.
- Andrew/Mike - research intelligence system
- Don - are we discussing graph, LOD, and semantics
- Mike - semantics allow swapping out entities
Actions
Previous Actions
...