Date
Links
Permanent Wiki Page: https:// goo.gl/6HQ14S
Attendees
Graham Triggs, Duraspace
Michaeleen Trimarchi (NCAR)
Eric Meeks (UCSF)
Marijane White (OHSU)
Rob Nelson (Duke)
Benjamin Gross (UNAVCO)
Steven McCauley (Brown)
Justin Littman (GWU)
CU Boulder (Don, Alex)
Keith Battleson (VT)
Paul Friedman (Northwestern)
Announcements
Discussion items
| Time | Item | Who | Notes |
|---|---|---|---|
| 10m | Intro | Graham Triggs | Introduction and general announcements |
| 5m | VIVO 1.9.1 | Graham Triggs | Minor pom corrections and SEO improvements |
| 10m | VIVO 1.10 / 2.0 | Graham Triggs | Initial progress report and issues |
| 35m | "Perfect" VIVO | Graham Triggs | What would the perfect VIVO be? |
VIVO 1.9.1
A couple of minor issues have been reported with the pom.xml (e.g. Not building correctly on Windows due to character set encoding issues).
After adding OpenVIVO to Google Webmaster Tools and reviewing the results, there are some minor changes that can be made to the templates so that Google can parse the structured data correctly.
As a result, the intention is to release 1.9.1 soon to address these issues.
VIVO 1.10 / 2.0
New branches with Jena 3.1.0 - these libraries operate as RDF 1.1 by default.
Jena now also incorporates the json-ld libraries, and updates them. The default serialisation is not directly comparable to the existing serialisation.
"Perfect" VIVO
In the last 10 years, a lot has changed in the way web applications are built, and the expectations people have of them. RESTful APIs and JSON for integration and automation, responsive web pages, dynamic loading of web page content, etc.
At the same time, we've learnt a lot of lessons about the current architecture, areas that might not work, have scalability challenges, etc.
So, if we were starting from a completely blank slate, what should VIVO do? What architecture should we implement, what things should not be reimplemented?
Notes
Don
Portable schema / structure (import ontologies)
Form where you can do CRUD
Import bulk data
Agnostic of a domain space
Simple, not complex
Steve
Domain agnostic
Brown uses Vitro, not VIVO
Vitro is powerful - not many tools that let you manipulate graph data
Would like Vitro built out more
Support a number of APIs (e.g. expose SOLR, expose SPARQL)
Justin
Feels odd that we need to write our own DB admin system
Feels like we’ve made a bad choice in modelling with semantic data
Look at other NoSQL options
Steve
Graph databases - not a lot that is off the shelf
Tight coupling between database and application is a problem
Don
Ontology has got to be very complicated - things should be kept simple
Eric
What are we willing to give up?
Three tools in VIVO
- domain agnostic semantic tool (limited audience)
- profiling tool (researchers)
- data sharing
Steve
Maybe semantic web isn’t the answer - document store
Don
More emphasis on Vitro - where I can import any version of the ontology
Marijane
Ontologies represent complex information, with subgraphs
Eric
These systems have cost / value - needs to have a wide audience
Justin
Current VIVO - cost is really high
Don
Use case - over LASP, we didn’t have publication, facutly - found and use an Ontology.
Eirc
Does Vitro become a stronger RDF tool, VIVO something else?
Useful to be able to spit out multiple document formats, be able to add Drupal front ends, etc.
Don
Excited to use TPF - be able to fo BI over multiple instances
Alex
Expert finding - would be great to address this
Recent JIRA Tickets
GitHub Pull Requests
Call-in Information
Calls are held every Thursday at 1 pm eastern time – convert to your time at http://www.thetimezoneconverter.com
Date: Every Thursday, no end date
Time: 1:00 pm, Eastern Daylight Time (New York, GMT-04:00)
Meeting Number: 198 167 928
To join the online meeting
If requested, enter your name and email address.
Click "Join".
1. Call in to the meeting:
+1-415-655-0001 (Call-in toll number (US/Canada))
2. Enter the access code:
198 167 928 #
