...
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
...
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
Matijane
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
...