Jon Corson-Rikert (Migrated from VIVO-32) said:

See discussion on the Ontology Call 3/6/13; there are times when it would be more correct in OWL terms to let users create new classes rather than only individuals. The classic example of this would be to create a new Award or Honor class (e.g., a local teaching award given every year), and then subsequently create instances of that award by picking from a drop down list of available award classes. The current example brought up by Steven at Brown would be to create an OWL class for each course that has persistence across many individual semester classes.
It would also likely be necessary to add property statements to the OWL classes created; punning them as individuals would enable this in a more consistent manner with the rest of VIVO than using annotations.

Jim Blake (Migrated from VIVO-29) said:

Our revision info page displays either:

1. hard-coded values from the revisionInfo file, or
2. info taken from the SVN workspace.

(1) is still valid, but (2) makes no sense any more. Can we create revision info that is Git-oriented, meaningful, and useful?

Jim Blake (Migrated from VIVO-5) said:

Brian Caruso says that we are using that at Cornell -- it's easier to configure and you don't need to worry whether your version of mod_jk is the correct one.

Jim Blake (Migrated from VIVO-12) said:

Add properties to runtime.properties that allow the admin to force a language other than English, or to offer a selection of languages to the user.

Add GUI elements that will present the selection of languages to the user, and accept his selection.

Add a filter that will override the Locale in the HttpRequest with the Locale that the user has chosen, or that the admin has forced.

Jim Blake (Migrated from VIVO-46) said:

In PageRoutingFilter, Brian Caruso asks what to do besides logging the unrecoverable error. The answer is not clear.

Look at ExceptionResponseValues.java. It appears to be only useful if there is an exception.

Look at FreemarkerHttpServlet, including the Template enum, the handleException() and doException() methods. (Jon is not happy that error messages are e-mailed to the VIVO admin.)

Look at error-display.ftl, error-standard.ftl, error-email.ftl, error-message.ftl, error-titled.ftl
Look at error.jsp, error404.jsp, error500.jsp, etc.

Figure out what classes of errors there are, how to handle them, and then standardize on those methods and remove the others.

Document it on the Wiki

Brian Lowe (Migrated from VIVO-24) said:

The "all values from" / "some values from" dropdowns need to allow the choice of owl:Thing.

Jim Blake (Migrated from VIVO-4) said:

We still want to have a scanner that confirms that all source files contain the appropriate text. However, we no longer want to replace that text with something else. So the released file will be the same as the file in Git.

Check Fedora Commons source code for an appropriate statement.

Modify the scanner to look for that statement. Remove the capability to do replacements.

Modify the Release Project page.

Edit all source files to use the new text (scanner should fail before edit, succeed after edit).

Jim Blake (Migrated from VIVO-20) said:

When Simon starts it up in WebLogic, it tries to use SLF4J, but fails because WebLogic includes a different set of SLF4J libraries from the ones that we include. Why do we include them, anyway?

Jim Blake (Migrated from VIVO-22) said:

Creating a custom entry from is one of the most common tasks of those who customize VIVO. However, the task is not easy, and the mechanism is not obvious. Possible improvements:

• Improved documentation on the Wiki

• Create an abstract base class that contains utility methods to ease the task. The goal of the improvement would be to increase the clarity.

• Create a group of helper classes that essentially form an internal Domain-Oriented language for the developer to use in creating the form.

Other possibilities? Again, the area for improvement is not the mechanism, per se, but the ease of understanding what must be done to achieve a given result.

Stephen V. Williams (Migrated from VIVO-45) said:

When server admins perform maintenance on VIVO servers, they may shut down both the MySQL and Tomcat servers at the same time and bring them up at the same time resulting in MySQL not ready for Tomcat and VIVO getting stuck with an unable to connect to MySQL error.

If VIVO could check every half hour for a MySQL connection a 12am maintenance that causes this error would resolve itself without interaction before business at 8am.

Jim Blake (Migrated from VIVO-28) said:

Start with Brian Caruso's email of Friday, September 21, 2012 11:55 AM

Jim Blake (Migrated from VIVO-34) said:

Currently, Jon frequently creates these links manually, with the consequence that they would be broken if the pages are moved or reordered. We should be able to find or write a macro that will handle the details of this.

Migrated from VIVO-44

Jim Blake (Migrated from VIVO-38) said:

Securing a controller is easy. It will take almost as long to compile a list of unsecured controllers, as it will to fix them.

Jon Corson-Rikert (Migrated from VIVO-16) said:

Tim at Cornell has developed a tempate that produces horizontal tabs for VIVO property groups instead of the current vertical orientation that requires scrolling down to see the next group.

Richard from Duke asked on the dev call whether parts of the data not initially displayed could be lazy-loaded to perhaps improve performance of the initial rendering of a page.

Jim Blake (Migrated from VIVO-2) said:

Currently, the WAR target does not create a Solr WAR, nor does it create the contents of the Solr home directory. When the VIVO war is created, contains the address of the home directory, which cannot be overridden. It also contains the address of the Solr home directory, and the address of the VIVO log file.

The WAR target should create these artifacts:

1. vivo.war, which the implementer can deploy in any JEE servlet container
2. solr.war, which the implementer can deploy in any JEE servlet container
3. solrhome.tar, which the implementer can unpack into the desired solr home directory
   Right now, it seems that there is no need for a vivohome.tar

There must be some way for the user to specify the location of dependent directories when the WAR files are deployed. The connection between VIVO and Solr must be specified when the WAR files are deployed (or the solrhome.tar)

We must be able to install multiple VIVO instances and multiple Solr instances within the same JEE servlet container.

Ideally, the default deployment (Tomcat) should remain as easy as it is now.

The ant "war" target should not require properties that it will not use (e.g., tomcat.home, webapp.name)

This is the time to separate the build properties from the runtime properties. We need to be able to deploy the same WAR twice with different runtime properties.

How will these changes impact the OpenSocial installation procedure?

It is time to remove the default security on Solr. Both because it has been problematic, and because it uses a Tomcat-specific mechanism. It is also usually unnecessary in productions, since the Tomcat will be behind an Apache server. Document how to secure solr, if desired.

Thoroughly inspect install.html and the recent upgrade-1.6.html and setting_up_orng.html to be certain that the changes are properly reflected in these documents. Create a new section or a new doc that describes how to use the WAR target.

Stephen V. Williams (Migrated from VIVO-7) said:

Upgrade the current implementation of Solr from 3.1 to 3.6.2. This version contains numerous upgrades including a fix to the wild card issue where a user who enters jeff* will receive all entries for Jeffery, while Jeff* returns nothing.

http://searchhub.org/2011/11/29/whats-with-lowercasing-wildcard-multiterm-queries-in-solr/
http://search-lucene.com/m/YqQLa2rmVr51/25+December+2012&subj=+ANNOUNCE+Apache+Solr+3+6+2+released

Solr 4.0 has also been released and may also address the wild card issue.

Jim Blake (Migrated from VIVO-14) said:

I sent an appeal to the developer's list for them to show me the modifications they have made to our code. I hope to run diffs on these modifications to see where they made changes. Hopefully, we can gain insight into how VIVO should be made more configurable.

Jon Corson-Rikert (Migrated from VIVO-17) said:

Paul from Weill noticed in watching very large VIVO pages load that at least some time is devoted to loading the Google api for QR codes. Since the QR code is only displayed if a user clicks on the icon, could we only create the QR code if that happens?

Jim Blake (Migrated from VIVO-47) said:

It appears to be referenced only in PageRoutingFilter

Jim Blake (Migrated from VIVO-26) said:

Find an acceptable way to switch to the Apache 2 license. Stop expanding our source files on release, so the released files will be the same as what is in the repository.

Jim Blake (Migrated from VIVO-8) said:

Java 6 reaches end-of-life in February 13, and will no longer be updated by Oracle. This means that no additional security patches will be applied, if issues should be discovered:
http://www.oracle.com/technetwork/java/javase/eol-135779.html#Java6-end-public-updates

Test VIVO with Java 7 and change the install and upgrade docs to reflect that Java 6 is no longer supported.

Migrated from VIVO-39

Jon Corson-Rikert (Migrated from VIVO-31) said:

Is Google Analytics still relevant to VIVO in the post-NIH era? Yes -- it's common enough that I think we should point out how to configure it with a local key (or disable it)
Should it still refer to a page on Cornell's Confluence? No.
Should we move the page to the Confluence space at DuraSpace? Yes, but changed to document how an individual site can elect to customize the key or disable.
Should the installation document mention this? Yes
Should we modify the upgrade document to say that this only applies to the NIH-funded sites? No.
What does that mean, now? No longer relevant.

Jon Corson-Rikert (Migrated from VIVO-15) said:

UF had trouble doing a complete reindex with VIVO 1.5.1 and eventually tracked down a formfeed character that had been pasted into VIVO in 2011 from a PDF. The same error can't be triggered again by pasting into an editing form, but the bad data can be re-introduced by uploading an n-triples file, and still causes the indexing error.

This error may well predate 1.5 since they had been noticing that merged organizations had not been removed from the search index for some time while still running 1.4.1, so the index may not have been updating successfully.

The bad data has been removed, but to avoid this problem again it would be helpful to trap for characters that break the indexing, whether a bug in VIVO, in Jena, or in Solr. If VIVO could at least catch the exception and ignore the record rather than abort the indexing process that would be a big improvement.

Jim Blake (Migrated from VIVO-11) said:

Modify the TemplateLoader to optionally add "delimiter" strings to all Freemarker templates as they are loaded.

If the "developer.addFreemarkerDelimiters" flag is set, the TemplateLoader will insert HTML comments at the beginning and end of each template so a developer can use View Source in the browser and see what templates contributed which lines of the HTML.

The delimiters should contain a searchable key and the name of the template. Remember that templates can be deeply nested. For example:

...

The opening delimiter should not include a line-feed, so the line numbers in error messages will match those of the original file. This means that the first line will likely look like this:

Notice that the license tag is a Freemarker comment and will not show up in the View Source.

This issue doesn't apply to the closing delimiter, since the addition of lines at the end of the template will not affect the error messages.

Jim Blake (Migrated from VIVO-35) said:

Is this file still used? At least some of the values in it are not. Hopefully this includes the ones whose values are obsolete.

Nicholas Rejack (Migrated from VIVO-1110) said:

Currently abstracts are represented in VIVO via a data property, bibo:abstract. This neglects abstracts that are published separately or in journals of abstracts. In order to properly represent these, vivo:Abstract should be created as a class.

Issue discussed on 01/09/2013 ontology call with examples cited from University of Florida and Brown.

Brian Lowe (Migrated from VIVO-30) said:

Seems to work propertly when types are removed via other means. There may be something like a missing end event in a batched retraction.

Type additions seem to behave normally.

Jon Corson-Rikert (Migrated from VIVO-1090) said:

The open ontology issues for VIVO 1.6 can be found on the VIVO NIH Project issue tracker at https://issues.library.cornell.edu/browse/VIVOONT/fixforversion/10171.

Issues not resolved on the 10/31 ontology call need to be migrated here to make all the work planned for VIVO 1.6 fully visible as part of the VIVO incubator project.

Jim Blake (Migrated from VIVO-36) said:

Remove vivo/doc/list_view_configuration_guidelines.txt from the distribution and put all of its information into a Wiki page, under https://wiki.duraspace.org/display/VIVO/Site+Administrator+Guide

Take advantage of the wiki formatting capabilities for headings, bullet lists, code examples, etc.

Include a code example that shows the complete format of a config file (including postprocessor).

Brian Lowe (Migrated from VIVO-42) said:

When I upload restrictions or ranges with unions they're displayed correctly in the ontology editor, but the default object property form for individuals doesn't show me the values for the union. This used to work but seems to have gotten broken somewhere along the way.

Migrated from VIVO-41

Jim Blake (Migrated from VIVO-1) said:

vivo/doc/pgrade-1.5.html contains a reference to https://confluence.cornell.edu/display/ennsrd/Google+Analytics+for+UI

Should this page be moved and/or duplicated in the new VIVO wiki? How many other documents refer to it? Why doesn't install.html have a similar reference?

Also, note the reference in googleAnalytics.ftl (Vitro and VIVO)

Jim Blake (Migrated from VIVO-27) said:

Find a politically acceptable way to make this change.

Brian Lowe (Migrated from VIVO-21) said:

Symptoms as originally reported by Rohan Mathure:

=====

I am trying to build vivo using ant all. But one of the test keeps failing and I am not able to understand the reason why.

[java] TEST FAILED: test testGetUrlWithParams() in edu.cornell.mannlib.vitro.webapp.controller.freemarker.UrlBuilderTest: null expected:</vivo/individual?[home=1&name=Tom]> but was:</vivo/individual?[name=Tom&home=1]>

=====

UrlBuilderTest contains this assert:

Assert.assertEquals("/vivo/individual?home=1&name=Tom", UrlBuilder.getUrl(path, params));

but UrlBuilder's addParams(String url, ParamMap params, String glue) method just iterates over params.keySet() when assembling the URL. I see no evidence that HashMap's implementation is intended to guarantee an order for the key set iterator.

It's not immediately clear whether the test or the implementation should be changed here.

Jim Blake (Migrated from VIVO-49) said:

Not mentioned in Vitro web.xml

Commented out in VIVO web.xml, saying it's not ready for the v1.1 release.

Jim Blake (Migrated from VIVO-37) said:

Arve Solland at Griffith reported odd behavior on his dev and test sites, and tracked it down to unsecured pages. He sent an email directly to the VIVO development team at Cornell, rather than publicize a security flaw by sending it to the list.

This is a security issue that affects all public 1.5.1 sites, including VIVO Cornell.

1. Secure these pages, and any other unsecured Admin pages that we can find.
2. Make sure that developers know how to secure their pages -- Wiki page
3. Publish a security fix for this. Does it need to be a full point-release? Or is it enough to put it on GitHub? Can we provide a hot-patch to existing 1.5.1 sites? How?

Migrated from VIVO-40

Jim Blake (Migrated from VIVO-6) said:

Create a freemarker method or directive that will allow the template writer to provide the page title. Odd, since it must be included in the HTML header. Perhaps model after "headscripts" ? Surely there is a cleaner way to do both of these.

Migrated from VIVO-33

Jim Blake (Migrated from VIVO-3) said:

Without worrying about quality overall, at least fix the items that are no longer accurate. Like the first-time login (root, not admin).

Jim Blake (Migrated from VIVO-10) said:

Add code to interpret statements in the display model that assign DataGetters to templates. The DataGetters will be applied to the body map in the Environment. Because Freemarker uses a single Environment instance for a template and all of the sub-templates it includes, the data is available from the point where the template is included.

Brian Lowe (Migrated from VIVO-13) said:

Reported by Josh Spangler:

"There appears to be an issue with Resource URI’s that start with a number, but also have letters. For example, I have a URI that is “5WFPNS”. In the VIVO search results, the links created to this resource don’t have the “5” at the beginning and only link to “WFPNS”, which results in a “Individual not found” message. If I manually add the “5” back into the URL bar of the browser to make it “5WFPNS” the page then works and the individual is found. This appears to be an issue with the VIVO search/index. Is this a bug/limitation of VIVO? Is it possible to have Resource URI’s that start with a number or are just a number?"

brianjlowe:
The code should be creating links of the from /individual?uri={percent-encoded URI} in these cases, since these URIs involving digits can't be decomposed into normal namespace and local name parts. But this isn't happening properly.

Migrated from VIVO-43

Jim Blake (Migrated from VIVO-50) said:

Your comment indicates that it's time.

Jim Blake (Migrated from VIVO-25) said:

Tomcat doesn't object if web.xml says that the URI for a particular TLD file is "A", even thought the TLD file internally says that its URI is "B". Other containers do complain about this, either with simple warning messages, or with failure.

Either enhance the web.xml unit test to check for this, or write a startup smoke test to check for it.

Jon Corson-Rikert (Migrated from VIVO-23) said:

From: Brian J Lowe [email protected]
Subject: Re: [Vivo-dev-all] VIVO oddity
Date: February 25, 2013 11:15:45 AM EST
To: VIVO Development List [email protected], Jim Blake [email protected]
Reply-To: VIVO Development List [email protected]

Class groups and property groups can't currently be loaded as file graphs, but you can load them into the database directly from Ingest Tools > Manage Jena Models.

Locate the graph with URI
http://vitro.mannlib.cornell.edu/default/vitro-kb-applicationMetadata

or create it if it doesn't yet exist. Then upload your class groups with the "load RDF data" button.

We could make this kind of workflow easier if we added a feature that would serialize/restore a set of VIVO graphs in a quad format like TriG or TriX.

Jim Blake (Migrated from VIVO-19) said:

tags must contain upper-case values. All servlet classes must exist.

Can we check for these in Jenkins somehow? Or in the unit tests?

Jim Blake (Migrated from VIVO-18) said:

Installers have difficulty setting logging levels because they are looking for a file called log4j.properties, but our logging levels are set in default.log4j.properties.

To make it worse, we do in fact distribute two files called log4j.properties, but they exist in the unit test directories and are only used for unit tests.

Rename default.log4j.properties to log4j.properties. Change the build script to accept this. Change the wiki page https://wiki.duraspace.org/display/VIVO/The+VIVO+log+file and any other documentation to reflect this. Notify the development team of the change.