Calls are held every Thursday at 1 pm eastern daylight time (GMT-5) – convert to your time at http://www.thetimezoneconverter.com

These calls now use WebEx – see the "Call-in Information" at the bottom of this page.

Please add additional agenda items or updates --

Jon Corson-Rikert will be leading this week's call.

VIVO 1.5.1

VIVO 1.5.1 was released Monday, October 15. Many thanks to all who contributed through bug reporting, development, and testing.

Updates

  • Brown
  • Colorado
  • Cornell
  • Duke
  • EPA
  • Florida
  • Indiana
  • NYU
  • Penn
  • UCSF
  • Weill - identified orphan dateTimeValue and problematic special characters.

Useful link from Stacy Rickel on fixing Harvester ingest of special characters:

http://sourceforge.net/mailarchive/message.php?msg_id=29088083

Quote from Ian Boston:

I think, when the transfer utility reads the XML-RDF file ( with a
<?xml version="1.0" encoding="UTF-8"?> at the top), it uses a
InputStream and for some reason guesses the char encoding incorrectly,
and does byte[]->String using the ascii encoder.

This is the only place in the harvest where Jenna is being asked to
read from a file. All the other places are via a RecordHandler or a
TDB.

CV parsing at Brown

Ted Lawless from Brown will discuss the procedures they have in place for parsing the standard format CVs that have been required of faculty at Brown, including what the vendor (Backstage) does and the workflow for cleanup, mapping, and loading the resulting data into VIVO.

Moving to Git/GitHub, Converting the Wiki

Jon CR and Jim Blake met Wednesday 10/24 with Jonathan Markow and Bill Branon of DuraSpace to plan migration of this wiki (Mediawiki on SourceForge) to Confluence hosted on DuraSpace. DuraSpace will be setting up a server for testing the migration and weeding out of content that may be out of date and not reflect current VIVO or Harvester or ontology capabilities or interfaces. While Confluence supports a more hierarchical view of content than Mediawiki, it also supports tagging pages as well as full-text search of their content.
If SourceForge decides not to discontinue support for hosted apps like Mediawiki, the current wiki will still have value for some time as a record of the activities of the NIH-funded VIVO project, but moving to DuraSpace is an opportunity to re-focus the content on the community vs. grant-driven model of development and support.
Another option used by other DuraSpace projects is to maintain a documentation wiki 'trunk' that can be copied into a separate wiki as of each major release to serve as a stable repository of documentation current at the time of release.

DuraSpace has also established two Jira spaces at jira.duraspace.org. They do not support anonymous editing or issue creation in Confluence or Jira, but anyone may create an account in Confluence and accounts are shared between the two systems. We will establish VIVO user groups within Confluence and Jira to maintain consistent permissions.

Notable Development List Traffic

Custom uri's --'http://vivo.university.edu/individual/2000/01/01 is not in a legal default namespace, so a direct request for it will result in a not found error. An example of a URI that should work fine is http://vivo.university.edu/individual/date-2000-01-01 . Here, there are no non-name characters following the "/individual/", and the local name does not begin with a digit.

  • Fuseki – When you install Fuseki according to the document, it is set up as read only; Fuseki will not accept any updates. Does the startup switch override the config contents? If the fuseki server is started with -update, will it indeed allow updates? Can anybody confirm this, as Michael at CU's LASP is not finding this to be true in his environment.
  • Ingesting UTF-8 data using Vivo Harvester 1.3 – does the last step, a 'harvester-transfer -o vivo.model.xml -r data/vivo-additions.rdf.xml' corrupt the data? See discussion thread
  • Scripting web interface changes to VIVO – When we want to make front end changes to Vivo, for example, changing the order of menus, we log on to our instance of Vivo and use the Site Admin to change Classes or Class Groups. For example, we can change the Display rank by opening the Class, clicking ‘Edit Class’, change the Display Rank and click ‘Submit Changes’. We have several of these changes we have to make, and when we make the changes it is very time consuming. We have to make the changes on our Development environment, then our Test environment and eventually Production environment. On Production we would like to make these changes very quickly to reduce the time that Vivo is offline to our users. Is there a way to save these kinds of front end changes, and import them all into our environments instead of having to do each change one by one? We are using Vivo 1.4. Also, do you know the difference between tbox and abox? Do you know how to create new Class Groups by updating a file?

You could easily persist these changes to a file by creating annotations to the ontologies.
For example, you could create a file called localAnnotations.n3 and place it in the folder: productMods/WEB-INF/ontologies/user/tbox/
There should already be some annotation files in this directory that you could use as a guide.

Call-in Information

Topic: VIVO weekly developer call

Date: Every Thursday, no end date

Time: 1:00 pm, Eastern Daylight Time (New York, GMT-04:00)

Meeting Number: 645 873 290

To join the online meeting

To view in other time zones or languages, please click the link: https://cornelluniversity.webex.com/cornelluniversity/j.php?ED=161711167&UID=1278154642&PW=NMWM4ZDNhYWZm&ORT=MiMxMQ%3D%3D

To join the audio conference only

Access code:645 873 290

last meeting | next meeting

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.