litvinovg/vivo
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Mergin 3856 3851 3838 3830 3829 3828 3827 from vivo 1.4 branch

Browse source
This commit is contained in:
briancaruso 2011-12-14 22:20:23 +00:00
parent 9bb0904dd7
commit 8275adc10f
15 changed files with 1749 additions and 312 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

631
doc/install.html
View file

File diff suppressed because it is too large Load diff

2
doc/license.txt
View file

@ -22,4 +22,4 @@ DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

222
doc/list_view_configuration_guidelines.txt Normal file
View file

@ -0,0 +1,222 @@
List view configuration guidelines
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------------------
REGISTERING THE LIST VIEW
-------------------------
A custom list view is associated with an object property in the RDF files in
the directory /vivo/productMods/WEB-INF/ontologies/app/loadedAtStartup.
To register a list view, create a new .rdf or .n3 file in that directory.
The file must be well formed RDF/XML or N3.
Example of registering a new association in a file named newListViews.n3:
<http://vivoweb.org/ontology/core#authorInAuthorship>
<http://vitro.mannlib.cornell.edu/ontologies/display/1.1#listViewConfigFile>
"listViewConfig-authorInAuthorship.xml" .
Place this file in /vivo/productMods/WEB-INF/ontologies/app/loadedAtStartup,
redeploy and restart tomcat to put the new custom list view in effect.
-----------------
REQUIRED ELEMENTS
-----------------
- list-view-config: root element
- query-select: sparql query used to retrieve data
- template: the name of the template used to display a single property statement
-----------------
OPTIONAL ELEMENTS
-----------------
- query-construct: one or more construct queries used to construct a model that the
select query is run against
- postprocessor: a Java class that postprocesses the data retrieved from the query before
sending it to the template. If no postprocessor is specified, the default
postprocessor will be invoked.
-----------------
CONSTRUCT QUERIES
-----------------
- Because SPARQL queries with multiple OPTIONAL clauses are converted to highly inefficient
SQL by the Jena API, one or more construct queries should be included to improve query
performance. They are used to construct a model significantly smaller than the entire
dataset that the select query can be run against with reasonable performance.
- The construct queries themselves should not contain multiple OPTIONAL clauses, to prevent
the same type of inefficiency. Instead, use multiple construct queries to construct a
model that includes all the necessary data.
- In the absence of any construct queries, the select query is run against the
entire dataset. If your select query does not involve a lot of OPTIONAL clauses, you do not
need to include construct queries.
- The construct queries must be designed to collect all the data that the
select query will request. They can be flexibly constructed to contain more data than
is currently selected, to allow for possible future expansion of the SELECT and to
simplify the WHERE clause. For example, one of the construct queries for core:hasRole
includes:
CONSTRUCT {
?role ?roleProperty ?roleValue .
...
} WHERE {
?role ?roleProperty ?roleValue .
...
}
That is, it includes all the properties of the role, rather than just those currently
selected by the select query.
- The ordering of the construct queries is not significant.
----------------
THE SELECT QUERY
----------------
---------------------------------
General select query requirements
---------------------------------
- Use a SELECT DISTINCT clause rather than a simple SELECT. There can still be cases where
the same individual is retrieved more than once, if there are multiple solutions to the
other assertions, but DISTINCT provides a start at uniqueness.
- The WHERE clause must contain a statement ?subject ?property ?object, with the variables
?subject and ?property named as such. For a default list view, the ?object variable must
also be named as such. For a custom list view, the object can be given any name, but it must be
included in the SELECT terms retrieved by the query. This is the statement that will be edited
from the edit links.
------------------------------------------------------------
Data which is required in public view, optional when editing
------------------------------------------------------------
- Incomplete data can result in a missing linked individual or other critical data (such as
a URL or anchor text on a link object). When the user has editing privileges on the page,
these statements are displayed so that the user can edit them and provide the missing data.
They should be hidden from non-editors. Follow these steps in the select query to ensure
this behavior:
- Enclose the clause for the linked individual in an OPTIONAL block.
- Select the object's localname using the ARQ localname function, so that the template can
display the local name in the absence of the linked individual. Alternatively, this can be
retrieved in the template using the localname(uri) method.
- Require the optional information in the public view by adding a filter clause which ensures
that the variable has been bound, inside tag <critical-data-required>. For example:
OPTIONAL { ?authorship core:linkedInformationResource ?infoResource }
This statement is optional because when editing we want to display an authorship that
is missing a link to an information resource.
Then add:
<critical-data-required>
FILTER ( bound(?infoResource) )
</critical-data-required>
The Java code will preprocess the query to remove the <critical-data-required> tag,
either retaining its text content (in public view) or removing the content (when
editing), so that the appropriate query is executed.
-------------------------------
Collated vs. uncollated queries
-------------------------------
- The query should contain <collated> elements, which are used when the property is
collated. For uncollated queries, the fragments are removed by a query preprocessor. Since any
ontology property can be collated in the Ontology Editor, all queries should contain the
following <collated> elements:
- A ?subclass variable, named as such, in the SELECT clause. If the ?subclass variable
is missing, the property will be displayed without collation.
SELECT DISTINCT <collated> ?subclass </collated> ...
- ?subclass must be the first term in the ORDER BY clause.
ORDER BY <collated> ?subclass </collated> ...
- Include the following in the WHERE clause, substituting in the relevant variables for
?infoResource and core:InformationResource:
<collated>
OPTIONAL { ?infoResource a ?subclass
?subclass rdfs:subClassOf core:InformationResource .
}
</collated>
- Postprocessing removes all but the most specific subclass value from the query result set.
- Alternatively (and preferably):
<collated>
OPTIONAL { ?infoResource vitro:mostSpecificType ?subclass
?subclass rdfs:subClassOf core:InformationResource .
}
</collated>
Automatic postprocessing to filter out all but the most specific subclass will be removed
in favor of this implementation in the future.
- Both collated and uncollated versions of the query should be tested, since the collation value
is user-configurable via the ontology editor.
----------------------
Datetimes in the query
----------------------
- To retrieve a datetime interval, use the following fragment, substituting the appropriate variable for
?edTraining:
OPTIONAL { GRAPH ?g9 { ?edTraining core:dateTimeInterval ?dateTimeInterval }
OPTIONAL { ?dateTimeInterval core:start ?dateTimeStartValue .
?dateTimeStartValue core:dateTime ?dateTimeStart
}
OPTIONAL { ?dateTimeInterval core:end ?dateTimeEndValue .
?dateTimeEndValue core:dateTime ?dateTimeEnd
}
}
- The variables ?dateTimeStart and ?dateTimeEnd are included in the SELECT clause.
- Many properties that retrieve dates order by end datetime descending (most recent first). In this
case, a postprocessor must apply to sort null values at the top rather than the bottom of the list,
which is the ordering returned by the SPARQL ORDER BY clause in the case of nulls in a descending order.
In that case, the variable names must be exactly as shown to allow the postprocessor to do its work.
------------
THE TEMPLATE
------------
- To ensure that values set in the template on one iteration do not bleed into the next statement:
- The template should consist of a macro that controls the display, and a single line that invokes the macro.
- Variables defined inside the macro should be defined with <#local> rather than <#assign>.
- To allow for a missing linked individual, the template should include code such as:
<#local linkedIndividual>
<#if statement.org??>
<a href="${url(statement.org)}">${statement.orgName}</a>
<#else>
<#-- This shouldn't happen, but we must provide for it -->
<a href="${url(statement.edTraining)}">${statement.edTrainingName}</a> (no linked organization)
</#if>
</#local>
The query must have been constructed to return orgName (see above under "General select query requirements"),
or alternatively the template can use the localname function: ${localname(org)}.
- If a variable is in an OPTIONAL clause in the query, the display of the value in the template should
include the default value operator ! to prevent an error on null values.

203
doc/release.html Normal file
View file

@ -0,0 +1,203 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<meta charset="utf-8">
<title>VIVO Release 1 V1.4 Announcement</title>
<link rel="stylesheet" href="./css/doc.css" media="screen">
</head>
<body>
<div id="branding" role="banner">
<h1 class="vivo-logo"><a href="http://vivoweb.org"><span class="displace">VIVO</span></a></h1>
</div>
<div id="wrapper-content" role="main">
<h1>VIVO Release 1 V1.4 Announcement</h1>
<small>
December 10, 2011
</small>
<toc>
<ul> <!-- filled out by js --> </ul>
</toc>
<div class="wiki-content">
<!-- last edited by Jon Corson-Rikert on Dec 11, 2011 -->
<h4><a
name="VIVORelease1.4AnnouncementDRAFT-Overview"></a>Overview</h4>
<p>VIVO 1.4 introduces two significant new features as well as
extending development begun in previous releases. Proxy
editing allows any VIVO user to designate another user as his
or her proxy for review or update, a much-requested feature,
and VIVO 1.4 also includes the ability to annotate VIVO
entries with terms from controlled vocabularies using external
terminology services. </p>
<h4><a
name="VIVORelease1.4AnnouncementDRAFT-Proxyediting"></a>Proxy
editing</h4> <p>VIVO now allows anyone with a VIVO profile to
delegate editing privileges for his or her entry to another
user, or proxy. Proxy-based editing facilitates adoption and
updating of VIVO in settings where researchers do not have the
time to maintain their own entries and wish to delegate
editing to specific persons. Proxy editing also supports
granting a VIVO user the rights to edit other entities such as
specific organizations, furthering sustainability by
controlled distribution of editing responsibility. Proxy
privileges can be managed by VIVO administrators on behalf of
multiple users or by an individual user on his or her own
behalf.</p>
<h4><a
name="VIVORelease1.4AnnouncementDRAFT-Linkingtoexternalvocabularies"></a>Linking
to external vocabularies</h4> <p>Many people have requested
support for associating terms from established controlled
vocabularies with people, publications, grants, organizations,
and other types of data in VIVO. While small taxonomies or
vocabularies may most easily be imported in their entirety
into VIVO, a number of the more popular controlled
vocabularies are very large in proportion to the number of
terms likely to be referenced within a single VIVO
instance. Incorporating terms by reference helps keep terms in
sync as these vocabularies continue to evolve and is more
consistent with linked data principles.
</p>
<p>
Stony Brook University's Department of Medical
Bioinformatics, led by Dr. Moisés Eisenberg, hosts an RDF
version of the National Library of Medicine's Unified
Medical Language System or UMLS
(<a href="http://www.nlm.nih.gov/research/umls/"
class="external-link"
rel="nofollow">http://www.nlm.nih.gov/research/umls/</a>). Through
a 2011 VIVO mini-grant, Stony Brook has developed a web
service that accepts incoming term requests from VIVO and
returns one or more matching UMLS concepts with stable
URIs. VIVO displays the label associated with the UMLS
concept but the concept's URI ensures that references remain
unambiguous, even across multiple VIVO instances at
different institutions.</p>
<p>
The interface from VIVO to the UMLS service has been
implemented to allow linking to additional vocabulary services such as
GEMET (<a href="http://www.eionet.europa.eu/gemet"
class="external-link"
rel="nofollow">http://www.eionet.europa.eu/gemet</a>), and we will
offer additional choices in upcoming releases. </p>
<h4><a name="VIVORelease1.4AnnouncementDRAFT-Visualizations"></a>Visualizations</h4>
<p>The VIVO 1.4 release features a novel science maps visualization that supports the comparison of publication profiles of up to three organizations.</p>
<p>All science map visualizations also now feature the updated
basemap of science that uses 10 years of publication data
(2001-2010) from Elsevier's Scopus and Thomson Reuters' Web of
Science. The UCSD map was originally created by the Regents
of the University of California and SciTech Strategies in
2008. It was updated by SciTech Strategies, L'Observatoire des
sciences et des technologies, and Indiana University's
Cyberinfrastructure for Network Science Center (CNS) in
2011.</p>
<h4><a name="VIVORelease1.4AnnouncementDRAFT-Ontologychanges"></a>Ontology changes</h4>
<p>Ontology changes from 1.3 to 1.4 were relatively minor,
including an update to the Geopolitical Ontology and changes
to support linking to external vocabulary references as
described above. Changes for each release are documented on
the VIVO wiki on Sourceforge
at <a href="http://sourceforge.net/apps/mediawiki/vivo/index.php?title=Ontology"
class="external-link"
rel="nofollow">http://sourceforge.net/apps/mediawiki/vivo/index.php?title=Ontology</a>.</p>
<p>With version 1.4, the VIVO ontology will be submitted to
the Bioportal (<a href="http://www.bioontology.org/bioportal"
class="external-link"
rel="nofollow">http://www.bioontology.org/bioportal</a>), an
open repository of ontologies hosted by the National Center
for Biomedical Ontology, to facilitate access and
dissemination.</p>
<h4><a name="VIVORelease1.4AnnouncementDRAFT-Freemarkerconversion"></a>Freemarker conversion</h4>
<p>VIVO 1.4 continues the major effort begun with version 1.2
and continued in 1.3 to convert VIVO's entire user-facing code
base from Java Server Pages (JSPs) to FreeMarker, the Java
template engine library
(<a href="http://freemarker.sourceforge.net/"
class="external-link"
rel="nofollow">http://freemarker.sourceforge.net/</a>). FreeMarker
more cleanly separates internal application programming logic
from page display, making the VIVO application more
understandable and extensible, especially for developers new
to VIVO. The entire user-facing editing system has been
refactored for VIVO 1.4 to simplify the configuration of
custom forms and allow more rigorous code testing and data
verification.</p>
<h4><a name="VIVORelease1.4AnnouncementDRAFT-Improveddiagnostics"></a>Improved diagnostics</h4>
<p>VIVO 1.4 features improved diagnostic messages to help with
configuration issues. As VIVO starts up, it runs a series of
tests looking for common configuration errors. If VIVO finds a
problem it will display an error or warning message in the
browser, instead of the VIVO home page. These start-time
diagnostics and prominent display make it even easier to
install VIVO.</p>
<h4><a name="VIVORelease1.4AnnouncementDRAFT-Vitroasastandaloneapplication"></a>Vitro as a standalone application</h4>
<p>VIVO extends the underlying Vitro open-source semantic web
application with the VIVO ontology, software customizations
specific to the VIVO ontology, and visual theming. With
version 1.4 of VIVO, the underlying Vitro software has been
packaged for use independently of the VIVO ontology. Vitro
supports ontology creation and editing as well as importing
existing ontologies, and is an excellent tool for populating
ontologies with instance data, for publishing RDF as linked
data, and for hands-on teaching about ontologies and semantic
web concepts.</p>
</div> <!-- wiki content -->
<div id="footer" role="contentinfo">
<p class="copyright">
<small>
All Rights Reserved <a href="license.txt">see license</a>
</small>
</p>
<div id="nav" role="navigation">
<ul id="footer-nav" role="list">
<li role="listitem">
<a href="http://vivoweb.org/about">About</a>
</li>
<li role="listitem">
<a href="http://vivoweb.org/contact">Contact Us</a>
</li>
<li role="listitem">
<a href="http://www.vivoweb.org/support" target="blank">Support</a>
</li>
</ul>
</div>
</div>
<script>
function init(){
//fill out TOC
var tocList = document.querySelector('toc>ul');
var h4Anchors = document.querySelectorAll('a[name]');
for( var i = 0 ; i < h4Anchors.length ; i++){
var a = document.createElement('a');
a.href= '#' + h4Anchors[i].name;
a.textContent = h4Anchors[i].parentNode.textContent
var li = document.createElement('li');
li.appendChild( a );
tocList.appendChild(li);
}
}
window.onload = init;
</script>
</body>
</html>

54
doc/upgrades.html Normal file
View file

@ -0,0 +1,54 @@
<!DOCTYPE html>
<html lang="en">
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<meta charset="utf-8">
<title>Upgrading VIVO</title>
<link rel="stylesheet" href="./css/doc.css" media="screen">
</head>
<body>
<div id="branding" role="banner">
<h1 class="vivo-logo"><a href="http://vivoweb.org"><span class="displace">VIVO</span></a></h1>
</div>
<!-- Start of content -->
<div id="wrapper-content" role="main">
<h1>Upgrading VIVO</h1>
<div>
December 10, 2011
</div>
<p>
The following documents describe how to upgrade VIVO.
</p>
<ul>
<li><a href="upgrade-1.0.txt">upgrade-1.0.txt</a></li>
<li><a href="upgrade-1.1.1.txt">upgrade-1.1.1.txt</a></li>
<li><a href="upgrade-1.1.txt">upgrade-1.1.txt</a></li>
<li><a href="upgrade-1.2.html">upgrade-1.2.html</a></li>
<li><a href="upgrade-1.3.html">upgrade-1.3.html</a></li>
<li><a href="upgrade-1.4.html">upgrade-1.4.html</a></li>
</ul>
</div>
<!-- #wrapper-content -->
<div id="footer" role="contentinfo">
<p class="copyright">
<small>
All Rights Reserved <a href="license.txt">see license</a>
</small>
</p>
<div id="nav" role="navigation">
<ul id="footer-nav" role="list">
<li role="listitem">
<a href="http://vivoweb.org/about">About</a>
</li>
<li role="listitem">
<a href="http://vivoweb.org/contact">Contact Us</a>
</li>
<li role="listitem">
<a href="http://www.vivoweb.org/support" target="blank">Support</a>
</li>
</ul>
</div>
</div>
</body>
</html>

119
flsdb2.deploy.properties Normal file
View file

@ -0,0 +1,119 @@
# -----------------------------------------------------------------------------
#
# VIVO deployment properties
#
# This file is provided as example.deploy.properties.
#
# Save a copy of this file as deploy.properties, and edit the properties as
# needed for your deployment.
#
# -----------------------------------------------------------------------------
#
# This namespace will be used when generating URIs for objects created in the
# editor. Change it to reflect your own domain. For example, Cornell's
# namespace is http://vivo.cornell.edu/individual/
#
# Note: it is essential that this namespace end with a trailing slash.
#
Vitro.defaultNamespace = http://vivo.ufl.edu/individual/
#
# Where is the Vitro core directory?
# In most deployments, this is set to ./vitro-core, but internal developers may
# prefer to set it to ../vitro
# Examples:
# vitro.core.dir = ./vitro-core
# vitro.core.dir = ../vitro
# vitro.core.dir = /usr/local/vitro/trunk
vitro.core.dir = ../vitrotrunk
#
# The base install directory for your Tomcat server. The VIVO application
# will be deployed in the /webapps directory below this base.
#
tomcat.home = /usr/local/tomcat
#
# The name of the VIVO application. This will be used as the name of the
# subdirectory within your Tomcat server's /webapps directory. It also appears
# in the URL for the application. For example, http://my.vivo.server/vivo
#
webapp.name = vivo
#
# The location where the VIVO application will store uploaded files
# (usually images). You should arrange for these files to be backed up in some
# way.
#
upload.directory = /usr/local/vivo/data/flsdb2/uploads
#
# The location where the VIVO application will create its Lucene search
# index.
#
LuceneSetup.indexDir = /usr/local/vivo/data/flsdb2/luceneIndex
#
# SMTP host which the "Contact Us" form can use to send mail. If this is left
# empty, the "Contact Us" form will be disabled.
#
Vitro.smtpHost =
#
# The basic parameters for a database connection. Change the end of the
# URL to reflect your database name (if it is not "vitro"). Change the username
# and password to match the authorized database user you created. Increase the
# maximum size of the database connection pool if you need to serve a greater
# number of concurrent page requests.
#
VitroConnection.DataSource.url = jdbc:mysql://localhost/flsdb2
VitroConnection.DataSource.username = root
VitroConnection.DataSource.password = RedRed
#
# Parameters to change in order to use VIVO with a database other than
# MySQL.
#
VitroConnection.DataSource.dbtype = MySQL
VitroConnection.DataSource.driver = com.mysql.jdbc.Driver
VitroConnection.DataSource.validationQuery = SELECT 1
#
# The maximum size of the database connection pool. Increase this
# value to support a greater number of concurrent page requests
# with SDB. It is not necessary to adjust this value when using the
# RDB configuration.
#
VitroConnection.DataSource.pool.maxActive = 320
#
# The Jena triple store technology to use. SDB is Jena's SPARQL database;
# this setting allows RDF data to scale beyond the limits of the JVM heap.
# Set to RDB to use the older Jena RDB store with in-memory caching.
#
VitroConnection.DataSource.tripleStoreType = SDB
#
# The name of your first admin user for the VIVO application. The password for
# for this user is initially set to "defaultAdmin", but you will be asked to
# change the password the first time you login.
#
initialAdminUser = defaultAdmin
#
# How is a logged-in user associated with a particular Individual? One way is
# for the Individual to have a property whose value is the username of the user.
# This is the name of that property.
#
selfEditing.idMatchingProperty = http://vivo.mydomain.edu/ns#networkId
#
# If an external authentication system like Shibboleth or CUWebAuth is to be
# used, these properties say how the login button should be labeled, and which
# HTTP header will contain the user ID from the authentication system. If such
# as system is not to be used, leave these commented out. Consult the
# installation instructions for more details.
#
externalAuth.buttonText = Log in using BearCat Shibboleth
externalAuth.netIdHeaderName = remote_userID

119
large.deploy.properties Normal file
View file

@ -0,0 +1,119 @@
# -----------------------------------------------------------------------------
#
# VIVO deployment properties
#
# This file is provided as example.deploy.properties.
#
# Save a copy of this file as deploy.properties, and edit the properties as
# needed for your deployment.
#
# -----------------------------------------------------------------------------
#
# This namespace will be used when generating URIs for objects created in the
# editor. Change it to reflect your own domain. For example, Cornell's
# namespace is http://vivo.cornell.edu/individual/
#
# Note: it is essential that this namespace end with a trailing slash.
#
Vitro.defaultNamespace = http://vivo.cornell.edu/individual/
#
# Where is the Vitro core directory?
# In most deployments, this is set to ./vitro-core, but internal developers may
# prefer to set it to ../vitro
# Examples:
# vitro.core.dir = ./vitro-core
# vitro.core.dir = ../vitro
# vitro.core.dir = /usr/local/vitro/trunk
vitro.core.dir = ../vitrotrunk
#
# The base install directory for your Tomcat server. The VIVO application
# will be deployed in the /webapps directory below this base.
#
tomcat.home = /usr/local/tomcat
#
# The name of the VIVO application. This will be used as the name of the
# subdirectory within your Tomcat server's /webapps directory. It also appears
# in the URL for the application. For example, http://my.vivo.server/vivo
#
webapp.name = vivo
#
# The location where the VIVO application will store uploaded files
# (usually images). You should arrange for these files to be backed up in some
# way.
#
upload.directory = /usr/local/vivo/large/uploads
#
# The location where the VIVO application will create its Lucene search
# index.
#
LuceneSetup.indexDir = /usr/local/vivo/large/luceneIndex
#
# SMTP host which the "Contact Us" form can use to send mail. If this is left
# empty, the "Contact Us" form will be disabled.
#
Vitro.smtpHost =
#
# The basic parameters for a database connection. Change the end of the
# URL to reflect your database name (if it is not "vitro"). Change the username
# and password to match the authorized database user you created. Increase the
# maximum size of the database connection pool if you need to serve a greater
# number of concurrent page requests.
#
VitroConnection.DataSource.url = jdbc:mysql://localhost/vivotestinglarge
VitroConnection.DataSource.username = root
VitroConnection.DataSource.password = RedRed
#
# Parameters to change in order to use VIVO with a database other than
# MySQL.
#
VitroConnection.DataSource.dbtype = MySQL
VitroConnection.DataSource.driver = com.mysql.jdbc.Driver
VitroConnection.DataSource.validationQuery = SELECT 1
#
# The maximum size of the database connection pool. Increase this
# value to support a greater number of concurrent page requests
# with SDB. It is not necessary to adjust this value when using the
# RDB configuration.
#
VitroConnection.DataSource.pool.maxActive = 320
#
# The Jena triple store technology to use. SDB is Jena's SPARQL database;
# this setting allows RDF data to scale beyond the limits of the JVM heap.
# Set to RDB to use the older Jena RDB store with in-memory caching.
#
VitroConnection.DataSource.tripleStoreType =SDB
#
# The name of your first admin user for the VIVO application. The password for
# for this user is initially set to "defaultAdmin", but you will be asked to
# change the password the first time you login.
#
initialAdminUser = defaultAdmin
#
# How is a logged-in user associated with a particular Individual? One way is
# for the Individual to have a property whose value is the username of the user.
# This is the name of that property.
#
selfEditing.idMatchingProperty = http://vivo.mydomain.edu/ns#networkId
#
# If an external authentication system like Shibboleth or CUWebAuth is to be
# used, these properties say how the login button should be labeled, and which
# HTTP header will contain the user ID from the authentication system. If such
# as system is not to be used, leave these commented out. Consult the
# installation instructions for more details.
#
externalAuth.buttonText = Log in using BearCat Shibboleth
externalAuth.netIdHeaderName = remote_userID

15
productMods/semantic.cache Normal file
View file

@ -0,0 +1,15 @@
;; Object productMods/
;; SEMANTICDB Tags save file
(semanticdb-project-database-file "productMods/"
:tables (list
(semanticdb-table "counter.jsp"
:major-mode 'html-mode
:tags '(("Linkage Information" section (:members (("'Person'-'InformationResource' linkages" section nil nil [1329 2369]) ("'Person' entities which published 'InformationResource' entities" section nil nil [2369 3292]) ("'InformationResource' entities" section nil nil [3292 4292]) ("'Person'-'ConferencePaper' linkages" section nil nil [4292 5323]) ("'Person' entities which published 'ConferencePaper' entities" section nil nil [5323 6230]) ("'ConferencePaper' entities" section nil nil [6230 7222]) ("'Person'-'AcademicArticle' linkages" section nil nil [7222 8249]) ("'Person' entities which published 'AcademicArticle' entities" section nil nil [8249 9152]) ("'AcademicArticle' entities" section nil nil [9152 10007]) ("'Person'-'Grant' linkages" section nil nil [10007 10849]) ("'Person' entities which are (co-)investigators on 'Grant' entities" section nil nil [10849 11691]) ("'Grant' entities" section nil nil [11691 12527]) ("'Person'-'CourseSection' linkages" section nil nil [12527 13358]) ("'Person' entities which teach 'CourseSection' entities" section nil nil [13358 14193]) ("'CourseSection' entities" section nil nil [14193 15236]) ("Total co-author linkages" section nil nil [15236 16200]) ("Unique co-author linkages" section nil nil [16200 17126]) ("Total co-investigator linkages" section nil nil [17126 18002]) ("Unique co-investigator linkages" section nil nil [18002 18005]))) nil [438 441]))
:file "counter.jsp"
:pointmax 18148
)
)
:file "semantic.cache"
:semantic-tag-version "2.0pre4"
:semanticdb-version "2.0pre4"
)

146
scripps.deploy.properties Normal file
View file

@ -0,0 +1,146 @@
# -----------------------------------------------------------------------------
#
# VIVO deployment properties
#
# This file is provided as example.deploy.properties.
#
# Save a copy of this file as deploy.properties, and edit the properties as
# needed for your deployment.
#
# -----------------------------------------------------------------------------
#
# This namespace will be used when generating URIs for objects created in the
# editor. Change it to reflect your own domain. For example, Cornell's
# namespace is http://vivo.cornell.edu/individual/
#
# Note: it is essential that this namespace end with a trailing slash.
#
Vitro.defaultNamespace = http://caruso-laptop.mannlib.cornell.edu:8090/vivo/individual/
#
# Where is the Vitro core directory?
# In most deployments, this is set to ./vitro-core (It is not uncommon for this
# setting to point elsewhere in development environments).
# Examples:
# vitro.core.dir = ./vitro-core
# vitro.core.dir = ../vitro
# vitro.core.dir = /usr/local/vitro/trunk
vitro.core.dir = ../vitrotrunk
#
# The base install directory for your Tomcat server. The VIVO application
# will be deployed in the /webapps directory below this base.
#
tomcat.home = /usr/local/tomcat
#
# The name of the VIVO application. This will be used as the name of the
# subdirectory within your Tomcat server's /webapps directory. It also appears
# in the URL for the application. For example, http://my.vivo.server/vivo
#
webapp.name = vivo
#
# URL of Solr context used in local VIVO search. Should consist of
# scheme + servername + port + contextpath + "solr"
#
vitro.local.solr.url = http://localhost:8080/vivosolr
#
# The location where the VIVO application will store the data that it creates.
# This includes uploaded files (usually images) and the Lucene search index.
#
vitro.home.directory = /usr/local/vivo/data
#
# Email parameters which VIVO can use to send mail. If these are left empty,
# the "Contact Us" form will be disabled and users will not be notified of
# changes to their accounts.
#
email.smtpHost = smtp.my.domain.edu
email.replyTo = vivoAdmin@my.domain.edu
#
# The basic parameters for a database connection. Change the end of the
# URL to reflect your database name (if it is not "vitrodb"). Change the username
# and password to match the authorized database user you created.
#
VitroConnection.DataSource.url = jdbc:mysql://localhost/scripps
VitroConnection.DataSource.username = root
VitroConnection.DataSource.password = RedRed
#
# The maximum number of active connections in the database connection pool.
# Increase this value to support a greater number of concurrent page requests.
#
VitroConnection.DataSource.pool.maxActive = 40
#
# The maximum number of database connections that will be allowed
# to remain idle in the connection pool. Default is 25%
# of the maximum number of active connections.
#
VitroConnection.DataSource.pool.maxIdle = 10
#
# Parameters to change in order to use VIVO with a database other than
# MySQL.
#
VitroConnection.DataSource.dbtype = MySQL
VitroConnection.DataSource.driver = com.mysql.jdbc.Driver
VitroConnection.DataSource.validationQuery = SELECT 1
#
# The email address of the root user for the VIVO application. The password
# for this user is initially set to "rootPassword", but you will be asked to
# change the password the first time you log in.
#
rootUser.emailAddress = root@myDomain.com
#
# How is a logged-in user associated with a particular Individual? One way is
# for the Individual to have a property whose value is the username of the user.
# This value should be the URI for that property.
#
selfEditing.idMatchingProperty = http://vivo.mydomain.edu/ns#networkId
#
# If an external authentication system like Shibboleth or CUWebAuth is to be
# used, these properties say how the login button should be labeled, and which
# HTTP header will contain the user ID from the authentication system. If such
# a system is not to be used, leave these commented out. Consult the
# installation instructions for more details.
#
externalAuth.buttonText = Log in using BearCat Shibboleth
externalAuth.netIdHeaderName = remote_userID
#
# The temporal graph visualization can require extensive machine resources.
# This can have a particularly noticable impact on memory usage if
# - The organization tree is deep,
# - The number of grants and publications is large.
# VIVO release 1.2 guards against this impact by disabling the temporal graph
# visualization unless the "visualization.temporal" flag is set to "enabled".
#
# visualization.temporal = enabled
#
# The temporal graph visualization is used to compare different organizations/people
# within an organization on parameters like number of publications or grants.
# By default, the app will attempt to make its best guess at the top level
# organization in your instance. If you're unhappy with this selection, uncomment out
# the property below and set it to the URI of the organization individual you want to
# identify as the top level organization. It will be used as the default whenever the
# temporal graph visualization is rendered without being passed an explicit org.
# For example, to use "Ponce School of Medicine" as the top organization:
# visualization.topLevelOrg = http://vivo.psm.edu/individual/n2862
#
# visualization.topLevelOrg = http://vivo.mydomain.edu/individual/topLevelOrgURI
#
# Default type(s) for Google Refine Reconciliation Service
# The format for this property is id, name; id1, name1; id2, name2 etc.
# See Service Metadata from this page http://code.google.com/p/google-refine/wiki/ReconciliationServiceApi
# for more information.
Vitro.reconcile.defaultTypeList = http://vivoweb.org/ontology/core#Role, core:Role; http://vivoweb.org/ontology/core#AcademicDegree, core:Academic Degree; http://purl.org/NET/c4dm/event.owl#Event, event:Event; http://vivoweb.org/ontology/core#Agreement, core:Agreement; http://vivoweb.org/ontology/core#Location, core:Location; http://xmlns.com/foaf/0.1/Organization, foaf:Organization; http://xmlns.com/foaf/0.1/Person, foaf:Person; http://vivoweb.org/ontology/core#InformationResource, core:Information Resource

37
tomcat7.deploy.properties Normal file
View file

@ -0,0 +1,37 @@
####### Deploy properties #########################################
vitro.core.dir = ../vitrotrunk
tomcat.home = /usr/local/apache-tomcat-7.0.11
webapp.name = vivo
vitro.local.solr.url = http://localhost:8090/vivosolr
vitro.local.solr.ipaddress.mask = 127\.0\.0\.1,[0:]+:1[^:]*,
vitro.home.directory = /usr/local/vivo/vitrodb
####### Vivo configuration properties #############################
Vitro.defaultNamespace = http://localhost:8080/vivo/
email.smtpHost = smtp.mydomain.edu
email.replyTo = vivoAdmin@mydomain.edu
VitroConnection.DataSource.url = jdbc:mysql://localhost/vitrodb
VitroConnection.DataSource.username = root
VitroConnection.DataSource.password = RedRed
VitroConnection.DataSource.pool.maxActive = 40
VitroConnection.DataSource.pool.maxIdle = 10
VitroConnection.DataSource.dbtype = MySQL
VitroConnection.DataSource.driver = com.mysql.jdbc.Driver
VitroConnection.DataSource.validationQuery = SELECT 1
rootUser.emailAddress = root@root.com
selfEditing.idMatchingProperty = http://vivo.mydomain.edu/ns#networkId
visualization.temporal = enabled
Vitro.reconcile.defaultTypeList = http://vivoweb.org/ontology/core#Role, core:Role; http://vivoweb.org/ontology/core#AcademicDegree, core:Academic Degree; http://purl.org/NET/c4dm/event.owl#Event, event:Event; http://vivoweb.org/ontology/core#Agreement, core:Agreement; http://vivoweb.org/ontology/core#Location, core:Location; http://xmlns.com/foaf/0.1/Organization, foaf:Organization; http://xmlns.com/foaf/0.1/Person, foaf:Person; http://vivoweb.org/ontology/core#InformationResource, core:Information Resource

34
vivo14.cornell.deploy.properites Normal file
View file

@ -0,0 +1,34 @@
#Environment.build=development
Vitro.defaultNamespace = http://caruso-laptop.mannlib.cornell.edu:8080/vivo/individual/
vitro.core.dir = ../vitrotrunk
tomcat.home = /usr/local/tomcat
webapp.name = vivo
vitro.local.solr.url = http://localhost:8080/vivosolr
vitro.home.directory = /usr/local/vivo/data
email.smtpHost = smtp.my.domain.edu
email.replyTo = vivoAdmin@my.domain.edu
VitroConnection.DataSource.url = jdbc:mysql://localhost/vivotesting
VitroConnection.DataSource.username = root
VitroConnection.DataSource.password = RedRed
VitroConnection.DataSource.pool.maxActive = 40
VitroConnection.DataSource.pool.maxIdle = 10
VitroConnection.DataSource.dbtype = MySQL
VitroConnection.DataSource.driver = com.mysql.jdbc.Driver
VitroConnection.DataSource.validationQuery = SELECT 1
rootUser.emailAddress = vivo_root@mydomain.edu
selfEditing.idMatchingProperty = http://vivo.mydomain.edu/ns#networkId
externalAuth.buttonText = Log in using BearCat Shibboleth
externalAuth.netIdHeaderName = remote_userID
Vitro.reconcile.defaultTypeList = http://vivoweb.org/ontology/core#Role, core:Role; http://vivoweb.org/ontology/core#AcademicDegree, core:Academic Degree; http://purl.org/NET/c4dm/event.owl#Event, event:Event; http://vivoweb.org/ontology/core#Agreement, core:Agreement; http://vivoweb.org/ontology/core#Location, core:Location; http://xmlns.com/foaf/0.1/Organization, foaf:Organization; http://xmlns.com/foaf/0.1/Person, foaf:Person; http://vivoweb.org/ontology/core#InformationResource, core:Information Resource

118
vivoAi.deploy.properties Normal file
View file

@ -0,0 +1,118 @@
# -----------------------------------------------------------------------------
#
# VIVO deployment properties
#
# This file is provided as example.deploy.properties.
#
# Save a copy of this file as deploy.properties, and edit the properties as
# needed for your deployment.
#
# -----------------------------------------------------------------------------
#
# This namespace will be used when generating URIs for objects created in the
# editor. Change it to reflect your own domain. For example, Cornell's
# namespace is http://vivo.cornell.edu/individual/
#
# Note: it is essential that this namespace end with a trailing slash.
#
Vitro.defaultNamespace = http://caruso-laptop.mannlib.cornell.edu:8090/vivo/individual/
vitro.home.directory = /usr/local/vivo/vivoAiHome
vitro.local.solr.url = http://localhost:8080/vivosolr
rootUser.emailAddress = bob@example.com
#
# Where is the Vitro core directory?
# In most deployments, this is set to ./vitro-core, but internal developers may
# prefer to set it to ../vitro
# Examples:
# vitro.core.dir = ./vitro-core
# vitro.core.dir = ../vitro
# vitro.core.dir = /usr/local/vitro/trunk
vitro.core.dir = ../vitrotrunk
#
# The base install directory for your Tomcat server. The VIVO application
# will be deployed in the /webapps directory below this base.
#
tomcat.home = /usr/local/tomcat
#
# The name of the VIVO application. This will be used as the name of the
# subdirectory within your Tomcat server's /webapps directory. It also appears
# in the URL for the application. For example, http://my.vivo.server/vivo
#
webapp.name = vivo
#
# The location where the VIVO application will store uploaded files
# (usually images). You should arrange for these files to be backed up in some
# way.
#
upload.directory = /usr/local/vivo/data/uploads
#
# SMTP host which the "Contact Us" form can use to send mail. If this is left
# empty, the "Contact Us" form will be disabled.
#
Vitro.smtpHost =
#
# The basic parameters for a database connection. Change the end of the
# URL to reflect your database name (if it is not "vitro"). Change the username
# and password to match the authorized database user you created. Increase the
# maximum size of the database connection pool if you need to serve a greater
# number of concurrent page requests.
#
VitroConnection.DataSource.url = jdbc:mysql://localhost/vivoAi
VitroConnection.DataSource.username = root
VitroConnection.DataSource.password = RedRed
#
# Parameters to change in order to use VIVO with a database other than
# MySQL.
#
VitroConnection.DataSource.dbtype = MySQL
VitroConnection.DataSource.driver = com.mysql.jdbc.Driver
VitroConnection.DataSource.validationQuery = SELECT 1
#
# The maximum size of the database connection pool. Increase this
# value to support a greater number of concurrent page requests
# with SDB. It is not necessary to adjust this value when using the
# RDB configuration.
#
VitroConnection.DataSource.pool.maxActive = 320
#
# The Jena triple store technology to use. SDB is Jena's SPARQL database;
# this setting allows RDF data to scale beyond the limits of the JVM heap.
# Set to RDB to use the older Jena RDB store with in-memory caching.
#
VitroConnection.DataSource.tripleStoreType = SDB
#
# The name of your first admin user for the VIVO application. The password for
# for this user is initially set to "defaultAdmin", but you will be asked to
# change the password the first time you login.
#
initialAdminUser = defaultAdmin
#
# How is a logged-in user associated with a particular Individual? One way is
# for the Individual to have a property whose value is the username of the user.
# This is the name of that property.
#
selfEditing.idMatchingProperty = http://vivo.mydomain.edu/ns#networkId
#
# If an external authentication system like Shibboleth or CUWebAuth is to be
# used, these properties say how the login button should be labeled, and which
# HTTP header will contain the user ID from the authentication system. If such
# as system is not to be used, leave these commented out. Consult the
# installation instructions for more details.
#
externalAuth.buttonText = Log in using BearCat Shibboleth
externalAuth.netIdHeaderName = remote_userID

120
vivojira.deploy.properties Normal file
View file

@ -0,0 +1,120 @@
# -----------------------------------------------------------------------------
#
# VIVO deployment properties
#
# This file is provided as example.deploy.properties.
#
# Save a copy of this file as deploy.properties, and edit the properties as
# needed for your deployment.
#
# -----------------------------------------------------------------------------
#
# This namespace will be used when generating URIs for objects created in the
# editor. Change it to reflect your own domain. For example, Cornell's
# namespace is http://vivo.cornell.edu/individual/
#
# Note: it is essential that this namespace end with a trailing slash.
#
Vitro.defaultNamespace = http://caruso-laptop.mannlib.cornell.edu:8080/vivo/individual/
vitro.home.directory = /usr/local/vivo/vivojira
#
# Where is the Vitro core directory?
# In most deployments, this is set to ./vitro-core, but internal developers may
# prefer to set it to ../vitro
# Examples:
# vitro.core.dir = ./vitro-core
# vitro.core.dir = ../vitro
# vitro.core.dir = /usr/local/vitro/trunk
vitro.core.dir = ../vitrotrunk
#
# The base install directory for your Tomcat server. The VIVO application
# will be deployed in the /webapps directory below this base.
#
tomcat.home = /usr/local/tomcat
#
# The name of the VIVO application. This will be used as the name of the
# subdirectory within your Tomcat server's /webapps directory. It also appears
# in the URL for the application. For example, http://my.vivo.server/vivo
#
webapp.name = vivo
#
# The location where the VIVO application will store uploaded files
# (usually images). You should arrange for these files to be backed up in some
# way.
#
upload.directory = /usr/local/vivo/vivojira/uploads
#
# The location where the VIVO application will create its Lucene search
# index.
#
LuceneSetup.indexDir = /usr/local/vivo/vivojira/luceneIndex
#
# SMTP host which the "Contact Us" form can use to send mail. If this is left
# empty, the "Contact Us" form will be disabled.
#
Vitro.smtpHost =
#
# The basic parameters for a database connection. Change the end of the
# URL to reflect your database name (if it is not "vitro"). Change the username
# and password to match the authorized database user you created. Increase the
# maximum size of the database connection pool if you need to serve a greater
# number of concurrent page requests.
#
VitroConnection.DataSource.url = jdbc:mysql://localhost/vivojira
VitroConnection.DataSource.username = root
VitroConnection.DataSource.password = RedRed
#
# Parameters to change in order to use VIVO with a database other than
# MySQL.
#
VitroConnection.DataSource.dbtype = MySQL
VitroConnection.DataSource.driver = com.mysql.jdbc.Driver
VitroConnection.DataSource.validationQuery = SELECT 1
#
# The maximum size of the database connection pool. Increase this
# value to support a greater number of concurrent page requests
# with SDB. It is not necessary to adjust this value when using the
# RDB configuration.
#
VitroConnection.DataSource.pool.maxActive = 320
#
# The Jena triple store technology to use. SDB is Jena's SPARQL database;
# this setting allows RDF data to scale beyond the limits of the JVM heap.
# Set to RDB to use the older Jena RDB store with in-memory caching.
#
VitroConnection.DataSource.tripleStoreType =RDB
#
# The name of your first admin user for the VIVO application. The password for
# for this user is initially set to "defaultAdmin", but you will be asked to
# change the password the first time you login.
#
initialAdminUser = defaultAdmin
#
# How is a logged-in user associated with a particular Individual? One way is
# for the Individual to have a property whose value is the username of the user.
# This is the name of that property.
#
selfEditing.idMatchingProperty = http://vivo.mydomain.edu/ns#networkId
#
# If an external authentication system like Shibboleth or CUWebAuth is to be
# used, these properties say how the login button should be labeled, and which
# HTTP header will contain the user ID from the authentication system. If such
# as system is not to be used, leave these commented out. Consult the
# installation instructions for more details.
#
externalAuth.buttonText = Log in using BearCat Shibboleth
externalAuth.netIdHeaderName = remote_userID

120
wcmcrdb.deploy.properties Normal file
View file

@ -0,0 +1,120 @@
# -----------------------------------------------------------------------------
#
# VIVO deployment properties
#
# This file is provided as example.deploy.properties.
#
# Save a copy of this file as deploy.properties, and edit the properties as
# needed for your deployment.
#
# -----------------------------------------------------------------------------
#
# This namespace will be used when generating URIs for objects created in the
# editor. Change it to reflect your own domain. For example, Cornell's
# namespace is http://vivo.cornell.edu/individual/
#
# Note: it is essential that this namespace end with a trailing slash.
#
#Vitro.defaultNamespace = http://vivo.mydomain.edu/individual/
Vitro.defaultNamespace = http://vivo.med.cornell.edu/individual/
#
# Where is the Vitro core directory?
# In most deployments, this is set to ./vitro-core, but internal developers may
# prefer to set it to ../vitro
# Examples:
# vitro.core.dir = ./vitro-core
# vitro.core.dir = ../vitro
# vitro.core.dir = /usr/local/vitro/trunk
vitro.core.dir = ../vitrotrunk
#
# The base install directory for your Tomcat server. The VIVO application
# will be deployed in the /webapps directory below this base.
#
tomcat.home = /usr/local/tomcat
#
# The name of the VIVO application. This will be used as the name of the
# subdirectory within your Tomcat server's /webapps directory. It also appears
# in the URL for the application. For example, http://my.vivo.server/vivo
#
webapp.name = vivo
#
# The location where the VIVO application will store uploaded files
# (usually images). You should arrange for these files to be backed up in some
# way.
#
upload.directory = /usr/local/vivo/wcmcrdb/data/uploads
#
# The location where the VIVO application will create its Lucene search
# index.
#
LuceneSetup.indexDir = /usr/local/vivo/wcmcrdb/data/luceneIndex
#
# SMTP host which the "Contact Us" form can use to send mail. If this is left
# empty, the "Contact Us" form will be disabled.
#
Vitro.smtpHost =
#
# The basic parameters for a database connection. Change the end of the
# URL to reflect your database name (if it is not "vitro"). Change the username
# and password to match the authorized database user you created. Increase the
# maximum size of the database connection pool if you need to serve a greater
# number of concurrent page requests.
#
VitroConnection.DataSource.url = jdbc:mysql://localhost/wcmcrdb
VitroConnection.DataSource.username = root
VitroConnection.DataSource.password = RedRed
#
# Parameters to change in order to use VIVO with a database other than
# MySQL.
#
VitroConnection.DataSource.dbtype = MySQL
VitroConnection.DataSource.driver = com.mysql.jdbc.Driver
VitroConnection.DataSource.validationQuery = SELECT 1
#
# The maximum size of the database connection pool. Increase this
# value to support a greater number of concurrent page requests
# with SDB. It is not necessary to adjust this value when using the
# RDB configuration.
#
VitroConnection.DataSource.pool.maxActive = 320
#
# The Jena triple store technology to use. SDB is Jena's SPARQL database;
# this setting allows RDF data to scale beyond the limits of the JVM heap.
# Set to RDB to use the older Jena RDB store with in-memory caching.
#
VitroConnection.DataSource.tripleStoreType = RDB
#
# The name of your first admin user for the VIVO application. The password for
# for this user is initially set to "defaultAdmin", but you will be asked to
# change the password the first time you login.
#
initialAdminUser = defaultAdmin
#
# How is a logged-in user associated with a particular Individual? One way is
# for the Individual to have a property whose value is the username of the user.
# This is the name of that property.
#
selfEditing.idMatchingProperty = http://vivo.mydomain.edu/ns#networkId
#
# If an external authentication system like Shibboleth or CUWebAuth is to be
# used, these properties say how the login button should be labeled, and which
# HTTP header will contain the user ID from the authentication system. If such
# as system is not to be used, leave these commented out. Consult the
# installation instructions for more details.
#
externalAuth.buttonText = Bogus Login
#externalAuth.netIdHeaderName = remote_userID

121
wcmcsdb.deploy.properties Normal file
View file

@ -0,0 +1,121 @@
# -----------------------------------------------------------------------------
#
# VIVO deployment properties
#
# This file is provided as example.deploy.properties.
#
# Save a copy of this file as deploy.properties, and edit the properties as
# needed for your deployment.
#
# -----------------------------------------------------------------------------
#
# This namespace will be used when generating URIs for objects created in the
# editor. Change it to reflect your own domain. For example, Cornell's
# namespace is http://vivo.cornell.edu/individual/
#
# Note: it is essential that this namespace end with a trailing slash.
#
#Vitro.defaultNamespace = http://vivo.mydomain.edu/individual/
Vitro.defaultNamespace = http://vivo.med.cornell.edu/individual/
#
# Where is the Vitro core directory?
# In most deployments, this is set to ./vitro-core, but internal developers may
# prefer to set it to ../vitro
# Examples:
# vitro.core.dir = ./vitro-core
# vitro.core.dir = ../vitro
# vitro.core.dir = /usr/local/vitro/trunk
vitro.core.dir = ../vitrotrunk
#
# The base install directory for your Tomcat server. The VIVO application
# will be deployed in the /webapps directory below this base.
#
tomcat.home = /usr/local/tomcat
#
# The name of the VIVO application. This will be used as the name of the
# subdirectory within your Tomcat server's /webapps directory. It also appears
# in the URL for the application. For example, http://my.vivo.server/vivo
#
webapp.name = vivo
#
# The location where the VIVO application will store uploaded files
# (usually images). You should arrange for these files to be backed up in some
# way.
#
upload.directory = /usr/local/vivo/wcmcsdb/data/uploads
#
# The location where the VIVO application will create its Lucene search
# index.
#
LuceneSetup.indexDir = /usr/local/vivo/wcmcsdb/data/luceneIndex
#
# SMTP host which the "Contact Us" form can use to send mail. If this is left
# empty, the "Contact Us" form will be disabled.
#
Vitro.smtpHost =
#
# The basic parameters for a database connection. Change the end of the
# URL to reflect your database name (if it is not "vitro"). Change the username
# and password to match the authorized database user you created. Increase the
# maximum size of the database connection pool if you need to serve a greater
# number of concurrent page requests.
#
VitroConnection.DataSource.url = jdbc:mysql://localhost/wcmc
VitroConnection.DataSource.username = root
VitroConnection.DataSource.password = RedRed
#
# Parameters to change in order to use VIVO with a database other than
# MySQL.
#
VitroConnection.DataSource.dbtype = MySQL
VitroConnection.DataSource.driver = com.mysql.jdbc.Driver
VitroConnection.DataSource.validationQuery = SELECT 1
#
# The maximum size of the database connection pool. Increase this
# value to support a greater number of concurrent page requests
# with SDB. It is not necessary to adjust this value when using the
# RDB configuration.
#
VitroConnection.DataSource.pool.maxActive = 320
#
# The Jena triple store technology to use. SDB is Jena's SPARQL database;
# this setting allows RDF data to scale beyond the limits of the JVM heap.
# Set to RDB to use the older Jena RDB store with in-memory caching.
#
VitroConnection.DataSource.tripleStoreType = SDB
#
# The name of your first admin user for the VIVO application. The password for
# for this user is initially set to "defaultAdmin", but you will be asked to
# change the password the first time you login.
#
initialAdminUser = defaultAdmin
#
# How is a logged-in user associated with a particular Individual? One way is
# for the Individual to have a property whose value is the username of the user.
# This is the name of that property.
#
selfEditing.idMatchingProperty = http://vivo.mydomain.edu/ns#networkId
#
# If an external authentication system like Shibboleth or CUWebAuth is to be
# used, these properties say how the login button should be labeled, and which
# HTTP header will contain the user ID from the authentication system. If such
# as system is not to be used, leave these commented out. Consult the
# installation instructions for more details.
#
externalAuth.buttonText = Bogus Login
#externalAuth.netIdHeaderName = remote_userID