Notes

Attendees

Notes

Ongoing disconnect between governance and development; little overlap in participation in these two spheres.
Attempt under way to reschedule leadership meeting so that it doesn’t conflict with the development call.
Estimating effort / providing additional information about items in 2c could help leadership group.
Sacha: where does VIVO Scholar fit in?

Andrew: currently thought of as an approach to iii. (improved front end).
Ralph: Scholar Discovery and UI are two totally different things; UI is optional.
William: UI is probably of less universal interest than the API.
Andrew: Scholar is addressing both iii. (front end) and iv. (APIs).

Andrew: combing through the documentation and making it better; not complete rewrite.

Documentation is a way for non-developers to get involved. Could have documentation sprints to bring in non-developers.
Could also be useful to put out call to community about what they find lacking in documentation.
Avoid answering repeated questions in mailing list / Slack.

Next sprint in three weeks: get branch into master. Also overdue for 1.12 release. Primary feature of release will likely be i18n work.

Notes from Slack are a good starting point for populating the wiki.
My goal is to come up with one good way of automating data entry with some sanity checking, using a technology that many people do or can understand, which we can support.
Michel: First part of effort should be documentation; compile recipes for how people can ingest from a variety of technologies.
Possibility of using simple, tabular database ahead of triplification.
Ralph: if people can get their data into our simple table format, we can turn it into triples.
William: Are there proposals for more generalized approaches?

Ralph: want to make sure that whatever gets produced doesn’t feel heavy and is something that the person starting out can easily use.

Andrew: common pattern to normalize data into database tables that reflect VIVO entities. Would be good to compare those tables and get to a “supported” set of database schemas for the staging area.

William: another database schema is another barrier to entry.
Brian: My priorities for data ingest would be built-in tools to build a VIVO from publicly-available data sources (ORCID, PubMed, CrossRef, etc.) before worrying about simplifying the process of transforming your own institutional data.
William: this is a tall order; Symplectic Elements already does a lot of this.
Rachid: not everyone can afford Elements.
Elements Harvester is open source (the harvester from Elements to VIVO)

...