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.
Notable implementation and development list issues
Adding link to institutional repository
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