Calls are held every Thursday at 1 pm eastern time (GMT-5) – convert to your time at http://www.thetimezoneconverter.com – and note that the U.S. is on daylight savings time.
View and edit this page permanently at https://wiki.duraspace.org/x/p9YQAg, or use the temporal Google Doc for collaborative note taking during the call.
Alternating status updates and issues review on weekly calls
(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
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 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
Registering a custom list view
- Do custom XML files for list views go in our theme along with the custom .ftl files? As long as the filename is identical, will it pick them up?
- (Tim) Your custom xml files have to be in the /config directory; otherwise, the app will use the default list view.
- (Ted) The documentation in the wiki on Custom List View Configurations should be helpful. When adding a new custom listView (rather than editing an existing
view) it needs to be 'registered' in the vivoListViewConfig.rdf file. That was a stumbling block for us when we first attempted to create a custom view.
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.
-
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
- (Boliang) I created an organization object and want to add a contributor to it. There is an error showing "There are no entries in the system from which to select." It also happens to an event object when adding a participant. The contributor property in organization is vivo:contributingRole and the participant property is vivo:realizedRole. We are using vivo 1.5. I also deployed another vivo 1.6 in my local for testing. But I didn't found these two properties in vivo 1.6. Are they removed in vivo 1.6?
Proxy editing
- (Paul) Would someone please confirm for me that there is no existing way to allow a departmental administrator or admin assistant to function as a proxy editor with VIVO? I saw this wiki article but not much else: https://wiki.duraspace.org/display/VIVO/Delegate+someone+to+edit
- (Jim) Yes and no. Yes, any individual can designate another user to be a proxy editor for them, or any admin can manage the designation. An individual can do this by logging in, going to the drop-down under their name in the upper right, choosing "My Account" and "Who can edit my profile". An admin can do this by going to the "Site Admin" page and choosing "Manage Profile Editing". No, there is no way to establish a rule by which you say, "this person will function as proxy editor for all members of this department". Proxies must be established explicitly, rather than implicitly. Proxy editing by rule is still a wish-list item.
-
VIVO usage data
- (Bart) I've been asked by our School of Medicine Dean if there is any usage data for institutions that have a VIVO instance up and running. Please let me know if there is any data that you can share. She didn't ask for anything specific, anything quantitative or qualitative would be helpful. This information would be shared with SOM administration as well as other departments at the University of Virginia.
Jena source of slow MySQL queries for publications
(Mark) Folks - it would be great if anyone could replicate some behaviour we are seeing with respect to the MySQL queries generated by Jena for publications. We have been doing some profiling and are seeing some very suboptimal MySQL queries being generated. The situation is that each query seems to consist of pretty much every triple related to every publication, a theory somewhat borne out by the fact that the exact same query is issued every time for any publication you request. It is almost as if there is just a single standard query being done for all pubs, and then from that result set a temporary in memory graph is created, queried and then discarded ...
- (BrianL) Have you done any local customization of the SPARQL queries used to render publication pages, such as list views? My first guess would be that there's a SPARQL query somewhere with the triple patterns written in an order that leads to inefficient MySQL. VIVO should be passing all of the mission-critical SPARQL queries directly to SDB to optimize as it sees fit, but it seems that SDB doesn't always quite generate the SQL joins you might expect. It's also possible that you're seeing the result of a query that's being routed through more complex layers of Jena models, which usually forces each triple pattern to be evaluated one at a time and joined in Java. In these cases the order in which the query is written can have an enormous impact on performance (though sometimes these queries can be faster than the ones with complex SQL joins).
As an example, let's suppose the predicate in question is vivo:linkedAuthor. If you see a query like the following, where ?publication gets prebound to a particular publication URI, WHERE { } then rewriting it as WHERE { } so that the specific publication URI comes first might fix the problem. |
- (Mark) You were spot on - we had a misplaced union in a listview.
Desired functionality: user can trigger a change in in-page sort order
- The Weill Cornell team is interested in adding some advanced functionality to our VIVO person's profile pages. Here is the general idea: the user clicks on an option from a select menu which changes the sort order of an in-template SPARQL query. For example, instead of sort by year, the user clicks on another option which sorts by title. Has anyone done something like this? Do you have any example files you could share? If that's not possible, it would be great to know conceptually how one would execute this functionality.
Restricting user access to data from named graphs
- (Eliza) We have ingested some publication data to a named graph. The goal is to let the users view the data but not allowed to edit. Currently users are able to select the data from the named graph. And the changes they have made go to the kb2 graph. Even though we know the data in the named graph remain unchanged this way but from the users' perspective, they think they have changed the data. But we'd like it to be clear to the user that data from named graphs cannot be modified. Is there a way to configure VIVO so that all the publication data from the named graph are displayed as non-clickable text so that the users cannot even select? But at the same time, allowing the user to select and change only the data they have manually added to VIVO using the user interface?
- (Jim) This might be worth investigating, but it doesn't sound easy. The decision logic that determines whether a user may edit a value consists of:
- creating a RequestedAction: an instance of EditObjectPropertyStatement or EditDataPropertyStatement
- asking the Policy bundle whether the user is authorized for this action.
- modifying the display based on the answer
- It would be easy to write a Policy that disallows editing for any statement in a given graph, EXCEPT that the RequestedAction doesn't contain a graph identifier. It only contains the subject, object, and predicate of the statement. So the real question is: how hard would it be to include the graph identifier in the RequestedAction? Is the graph identifier even available to the code that creates the RequestedAction? How deeply do we have to >modify before we reach that info? Is this a feature that would interest others?
See the vivo-dev-all archive and vivo-imp-issues archive for complete email threads
VIVO 1.6
VIVO 1.6 release code freeze has been delayed to allow for integration of the new Integrated Semantic Framework ontology and preparation and testing of the necessary data migrations. Stay tuned at our weekly meetings for updates.
See the VIVO 1.6 release planning or VIVO 1.6 JIRA issues and please comment
VIVO 2013 Conference
- List of sessions and poster posted here (PDF)
- Register before July 19 for best rate and conference hotel availability
- Conference hotel is Hilton St. Louis at the Ballpark Hotel
- Wednesday night baseball game (Cardinals vs Pirates) and cold beer!
Updates
- Brown
- Colorado
- Cornell
- Duke
- Johns Hopkins
- Memorial
- RPI
- Scripps
- Stony Brook
- Texas A&M
- UCSF
- Virginia Tech
- Weill Cornell
Call-in Information
Date: Every Thursday, no end date
Time: 1:00 pm, Eastern Daylight Time (New York, GMT-04:00)
Meeting Number: 641 825 891
To join the online meeting
To join the audio conference only