...
(Alex) As the VIVO community continues to grow, we should examine the content and format of our weekly calls. I think that it's great to have around 50 opportunities each year to come together virtually and share our progress and challenges. I hope that you agree in having a single weekly meeting as compared to splitting back into dev and impl calls, but how can we best achieve this while giving a growing number of VIVO implementors a voice? While also addressing other special topics and issues from the mailing list?
One idea is to do a full round of status updates every other week, and to have folks use the wiki and publicly shared Google Doc to add their updates in advance. Then we could focus on the highlights during the call. Every other week we could focus more on development issues and other special topics. Every week we'd seek to address highlights from the mailing lists.
What are some other suggestions? Maybe ideas taken from other distributed communities or large research projects?
NIH would like to link RePORTER to institutional faculty profiles
From: Weber, Griffin M [mailto:griffin_weber@hms.harvard.edu]
Sent: Sunday, July 14, 2013 9:47 PM
Subject: FW: NIH would like to link RePORTER to institutional faculty profiles
...
I'm not sure if you've seen this. NIH now has a way to bulk link your institution's faculty URIs to their RePORTER records. Chris Dorney (cc'd) from Boston University was the first to use this feature by sending them all the URIs from his BU Profiles site with the attached Excel template. You might want to forward it to VIVO sites. I imagine that if faculty URIs are linked to RePORTER, then it could also make it easier in the future for SciENcv to link to institution based profiles.
(Chris) You can see the general announcement of what was done in an issue of The ReSource (http://report.nih.gov/resource/issue7/#rep177), as well as on one of their blogs (http://nexus.od.nih.gov/all/2013/04/26/making-the-link-with-report/). You can just email them the file - Jim's contact info is on the template (also on Google Docs) . It's a nice way to drive more traffic to your sites.
Notable implementation and development list issues
VSTO ontology slowing down web app
- (Tyler) We are having trouble implementing the VSTO ontology into our local vivo web app at LASP. Basically I create a new jena model for the vsto.owl ontology and then I import the ontology and attach it to the tbox. Doing this successfully integrates VSTO with our existing ontologies, but the entire web app is considerably slowed down. It goes from taking a second to load a page to taking about 30 seconds to load a page. Has anyone had this issue before and do they have any tips to speed things up?
- (BrianL) This isn't documented anywhere, but that "attach to TBox" button is a remnant of an earlier feature designed for local testing and ingest work, not for production deployment of an ontology. Enabling it causes access to the entire TBox to become vastly more inefficient. We'll plan to remove it in 1.6 because it no longer serves an important purpose. What you probably want to do is add the VSTO file(s) to the /WEB-INF/filegraph/tbox directory and restart Tomcat. Each file will be loaded into its own separate graph, and if you change the files on the filesystem and restart, the triple store will be automatically updated. You should see no performance hit using this method; in fact you'll notice this is how the main VIVO ontology itself is loaded.
Jira server DuraSpace JIRA key VIVO-237
Adding link to institutional repository
- (Giuseppe) I'm starting to look at ways to add a link to an institutional repository (we use ePrints, but I know of many using DSpace). We'd be ok with a link to the actual human-readable page. What namespace/attribute is commonly used to represent this kind of links? Any experience?
- (Nick) If the only purpose is a human readable link, you could use the web pages link option (the button near the title). Using this option you create a vivo:webpage pointer to a webpage individual, which you could label "Repository version" or something like that. The webpage individual uses vivo:linkURI (actual url) and core:URLLink (type) which are the designated atributes for linking out of Vivo I think.
- (Patrick) Here at Duke, we added a functional property in our local extension called duke:onlineContent that contains the string of the link. I'm not saying that is a better solution, but wanted to respond to your request for how others are implementing that.
- (Giuseppe) My only worry in asking was if there's a standard way, to let our system be interoperable with others. However, I guess there can be workarounds to make such a property in two different namespaces match, so it shouldn't be a problem.
- (Graham) I'll add that when I added the same for the Bournemouth implementation, I also added a 'Symplectic' ontology, with a 'repositoryURL' property (amongst a couple of other things). The advantage of doing it this way is that you can customise the SPARQL and templates, allowing you to retrieve specifically that property, and mark / link records in lists that have content in the repository, and not just displaying it as an opaque link. I don't know if there is an existing ontology, or whether the ontology changes that have been discussed for VIVO, would provide a natural home for storing a variety of links for a single publication - ultimately, you could have reasons for storing: a) a link to the repository item b) direct links to content files in a repository c) links to publisher versions, amongst others.
vivo:realizedRole and vivo:contributingRole
...