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
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>