vivo-project / vivo Goto Github PK
View Code? Open in Web Editor NEWVIVO is an extensible semantic web application for research discovery and showcasing scholarly work
Home Page: http://vivoweb.org
License: BSD 3-Clause "New" or "Revised" License
VIVO is an extensible semantic web application for research discovery and showcasing scholarly work
Home Page: http://vivoweb.org
License: BSD 3-Clause "New" or "Revised" License
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).
Migrated from VIVO-40
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.
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.
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-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.
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.
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.
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-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-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.
Migrated from VIVO-44
Migrated from VIVO-33
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.
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-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-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.
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.
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:
<#-- $This file is distributed under the terms of the license in /doc/license.txt$ -->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-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.
Migrated from VIVO-41
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.
Migrated from VIVO-39
Migrated from VIVO-43
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.
Brian Lowe (Migrated from VIVO-24) said:
The "all values from" / "some values from" dropdowns need to allow the choice of owl:Thing.
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-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.
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.
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-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:
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.
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).
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.
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-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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.