Date
Attendees
Violeta Ilik, Brian Lowe, Jim Blake, Damaris Murry, Benjamin Gross, Alvin Hutchinson
, Mike Conlon- () Indicates who will be taking minutes
Discussion items
| Time | Item | Who | Notes |
|---|---|---|---|
| 50 | Review each version of the “VIVO Data - what and from where” page created by each member of the TF. Versions of the page to be found in the Google Drive designated for this task force. | All |
|
| 20 | Decide on our top level plan - Mike Conlon comments | Mike |
|
Meeting notes:
Benjamin Gross version:
A lot of data overlap. Difficult time deciding what to include on the page and the objective of the page. (You’re not alone; many in agreement).
BG, DM: Moving links from the bottom of the page (further reading) to be embedded in the body might be more helpful.
Some links might be created by macros and difficult to deal with.
JB - Some links are created manually and some (children) are created by macros.
Jim Blake version - added table of contents and used more structured headings.
Tried to start with Level 1 at the beginning.
Cut out a lot of words using standard editing, (re)moving parenthetic items and shortening sentences. Replaced table with images.
PDF file is not an image but an export of the confluence page (linked in the notes)
BG selected content while JB changed styles, etc.
Violeta Ilik version- Changed headings (but likes JB’s heading changes better).
Maybe standardized language for “automated data entry”, "manual data entry", introduced Karma briefly.
Emphasized standardized data, people's and organization's identifiers/codes, etc. uniformity
Left untouched the “What is different about VIVO”
In "What data can VIVO accept" part used illustrations for simple and gradually more complicated data sets (organizations, person, positions and publications).
JB - Both VI and Benjamin have brought up the issue of where the information belongs. This points out the need for a top-down plan to revise documentation.
BG - Diagrams, Karma, etc. belongs in the documentation but maybe not this page. Same with JB’s page so that these can be split into smaller pages.
Brian Love version - Had questions about where to put things and how to split. Thought about omitting 2nd section (Automated Ingest) entirely but ended up tightening things up entirely.
Main Goal: Tried to include practical step-by-step illustrations for data ingest. Seems like this might be a self-contained unit with links to other pages. More inviting to see illustrations than a large body of text.
2nd section might be more useful separated out in a more detailed page.
DM and VI: screen shots are helpful
JB: Great to include possible problems if ingest fails. “What to look for” Instructions and information are mixed together. (Description and instruction).
Damaris Murry version: Not clear from the title who this page is for but tried to more clearly address the who, what and how of data ingest. Had a lot of questions for the reader to ask them to think about before they begin. List of headings addressing issues that new users need to know about.
JB: Visually this is striking. Addresses high level concepts while other revisions got into language, copy editing, structure, details, etc.
DM: Like all documentation, it isn’t always clear who the document is aimed at. Information gets jumbled based on author and what stage the user is in.
VI : Reminded us that Mike asked not only for technical documentation but planning, outreach, data ingest documentation, etc.
BG: Primary question is: Who is this page for and is it in the right place?
JB: Seems like we might want to encourage the top-level conceptual page and child pages be more technical.
JB: Looking at wildly different versions and approaches
BL: keep coming back to problem of initial structure without going off on what could be a long description of something of questionable value for the page.
What to explain and what to leave alone (explaining RDF, for example).
DM: how do we help people to not waste time and effort and make the right decisions before they spend too much time.
JB: like the idea of manual data entry and dump data to learn what it looks like.
JB:torn by practicality. If we wait for an overall plan, we’ll never start. Skills needed are comparable to a professional software developer. Struck by visual impact of what DM did in her revision.
BL: default Confluence styling detracts from content and structure to make things look visually unappealing
BL: Feels like we are getting hints from the listserv that people are trying VIVO for projects outside of traditional university research management tool. Language should perhaps reflect that. How do we structure that at the top level to get the right people (and their different projects) to the right documentation.
VL: BL’s page with screen shots and recipe approach is what we are missing.
Joined by Mike C. at 3:50 ET (due to Skype/call/confusion issue).
MC: Page is addressed to newcomers. We were looking for something that was data-oriented and accessible to newcomers and project managers at new sites. “Where to start,” type page.
Installation is only the first step. Larger implementation plan is getting data in and integrating with the institution.
Action items
- Create a rough outline (run it by Mike before proceeding)
- Invite Jon C-R to join us at the next meeting
