Date
Call-in Information
Time: 11:00 am, Eastern Time (New York, GMT-04:00)
To join the online meeting:
- Go to: https://lyrasis.zoom.us/my/vivo1
One tap mobile:
US: +16699006833,,9358074182# or +19292056099,,9358074182#
Or Telephone:
US: +1 669 900 6833 or +1 929 205 6099 or 877 853 5257
Meeting ID: 935 807 4182
International numbers available: https://zoom.us/u/aeANHanzED
Slack
- https://vivo-project.slack.com
- Self-register at: http://bit.ly/vivo-slack
- Self-register at: http://bit.ly/vivo-slack
Attendees
Indicating note-taker
- Benjamin Gross
- Brian Lowe
- Ralph O'Flinn
- Andrew Woods
- Nicolas Dickner
- Michel Héon
- Huda Khan
- Don Elsborg
- Bruce Herbert
- Rachid Belkouch
- Richard Outten
- Damaris Murry
- Julia Trimmer
Agenda
- Input on Product Direction for 2020
- Goal: agree on the set of near-term project priorities so that we can collaborate on moving the project in a mutually beneficial direction.
- Raw data from above graphic
- 19 - Data ingest
- 11 - Ease of installation
- 8 - Ease of upgrade
- 4 - Project documentation
- 13 - Internationalization (i18n)
- 6 - Modularization / Decoupling triple store
- 4 - Modularization / Decoupling asset store (e.g. image uploads)
- 5 - Modularization / Decoupling frontend
- 8 - RESTful API
- 2 - Notifications / Messaging
- 12 - Advanced role management (more granular permissions in Freemarker UI)
- 6 - More publication claiming options
- Community-provided ideas
- 1 - Analysis of information stored, new graphics
- 1 - Search engine optimization; also core VIVO ontology development to meet user needs outside of traditional universities
- 1 - Evolving the Capability Map . E.g.: improving the graphics, choosing the navigation attribute (e.g.: project)
- 1 - Updated ontology, Cornell Ontology editor, new standard templates for certain entity types (concepts, orgs, events, videos, publications etc.)
- 1 - more ORCID API functionality: importing data from ORCID, writing data to ORCID
- 1 - Ontology editing
- Comments on proposed priorities
Simple data ingest methods is a great way to get up and running fast. Working in a test environment with your own data REALLY make the understanding of the system way easier. Now, I only tinkered with the system a few days so take this for what it is.
Show new graphics and new analysis of the stored information could be interesting for develop.
Decoupling allows easier development, but often means more complicated administration. It's worth to keep this in mind. We were not able to install VIVO 1.11 for example. It's already more complicated then it was.
Data ingest
Data ingest should include better options for concepts, journals, conferences, and other data via VIVO itself, like the publication claim or concept import.
Continue decoupling; establish APIs. This positions for future work.
For i18n - put all linguistic terms in ontological form
Javed had an almost complete new interface for the ontology editor
Future topics
- Vitro JMS messaging approaches - redux
- Which architectural pattern should we take?
- What should the body of the messages be?
- Incremental development initiatives
- Integration test opportunities with the switch to TDB - requires startup/shutdown of external Solr ..via Maven
Tickets
Status of In-Review tickets
Notes
Andrew : Production Direction for 2020 was created by both VIVO Leadership Group and committers ; what’s needed is both comments on elements already there a well as new input ; importance to align institutional and community priorities
Andrew : item c of agenda details the poll and highlights the four two digits results ; data ingest seems like the top priority
Ralph : we must pick and support a default ingestion method
Andrew : why so many approaches?
Ralph : many practices in many institutions ; also, compatibility across different versions of VIVO; but support should be only for current version. No time to cover it all. (chat : also the reason I did my own thing is because I didn't understand what the heck was going on with the other options and rolled my own I could understand)
Richard : early versions of harvester weren’t satisfactory, so there was a need for customization;; also, variety of sources
Don : we do not have enough data on institutions practices ; need to focus on how the transforms work ; this should be uniformized (for the batch) ; VIVO is close to a functional SPARQL API for the real-timers
Bruce : Do we have a clear vision of the current use cases in the community?
Andrew : not really ; obviously diverse ; maybe we should coalesce around specific ones
Bruce : the point of diversity is to get a wider the adoption base ; potential users have minimal development to undertake
Don : like Huda, wants to have reference specs that are legible ; like the graphql spec defined by VIVO Scholar
Huda : +1
Michel : for UQAM, not an ETL process ; VIVO more a source of data amongst other institutional data sources, with data going back and forth ; interoperability is crucial, in an event driven environment, such as Apache Kafka.
Andrew : can we form a team of individuals / institutions to work out this item :
- collect use cases
- specify target entities that can be transformed into VIVO
- refining tools
Andrew : a larger sample of the community should be brought into it.
Damaris : creating an easy process is not like creating a perfect data model.
Ralph : Agrees ; keep the model simple and expand from there
Andrew : will make a call to the community ; meanwhile, we should focus on a subset of priorities
Michel : in UQAM, editing ontologies in Vitro will be a priority on medium term (more or less 1 year) ; i.e. creating new ontologies. UI needs improvements, graphical interface.
Andrew : need for a longer conversation ; but we should decide whether it is the role of VIVO.
Benjamin : (chat) It is convenient that VIVO is an ontology editor ; but I agree it's a question whether its appropriate or not
Andrew : does someone want to bring any item forward?
Don : updating indexes that have different structures? Different institutions are using different indexers, and time has to be devoted to maintenance and updates.
Ralph : making it a priority would make a lot of sense
Andrew : could there be someone in the community to champion this?
Julia : agrees ; ideas and input are great, but people need to get involved
Ralph : ease of upgrade ; this explains why VIVO is spread out over so many versions ; if not a priority, should be very high in the list of things to investigate
Brian : would rank Don’s indexes proposition before Advanced Role Management
Benjamin : (chat) I was also surprised to see advanced role management so popular. That hasn't been a need expressed to me by our clients.
Brian : need to simplify processes (ingestion, etc) -- actually, a need to step back and have a global look at processes, in order to identify the ones that are not necessary (anymore?)
Benjamin : RDF as an output of VIVO as opposed to an input and output
Don : +1 to RDF as output only
Richard : +1 to RDF as an output
Andrew: Are there any of the less popular priorities that are very important personally and would like to work on and would welcome community help?
Michel : We’d be ready to work on no 6 - decoupling of triplestore
Ralph : ready to champion the ingest
Actions