-
Notifications
You must be signed in to change notification settings - Fork 0
Home
A VisKo package is a folder of documents including Java code that describes a chunk of knowledge about how to use visualization software capabilities. Packages are the preferred way of sharing visualization knowledge within the VisKo framework. VisKo packages enable machines to use/reuse knowledge encoded in the packages to automatically generate pipelines in support of visualization requests.
You are probably reading this document because you may be interested in one or more of the following:
- Package Aggregation: installing and reusing a package in your local VisKo server
- Package Development: developing or modifyng a VisKo package that encodes knowledge about some visualization capability that you know how to use; or
- Package Sharing: allowing members of the VisKo community to know about and use your packages. If that is your intention, we would like to mention that visko packages are shared over the web the same way one would share source code. For instance, the VisKo's official package website lists and provides access to some VisKo packages; also, packagefolders can bundled up and shared over the web, emailed, FTPed, etc.
Packages provide a way for VisKo contributors to modularize knowledge since VisKo servers just need to know about visualization capabilities that are seems as required by/beneficial to the community they are serving. In fact, it should be too much for a VisKo server to know and provide access to all possible visualization capability available out there. For instance, a VisKo server supporting a medical imaging community may benefit from knowledge that enables feature detection and segmentation in the area of chemical imaging while the same server may not benefit from knowledge in support of geographical information systems (GIS).
VisKo does not prescribe how one should modularize its visualization knowledge. Most VisKo packages have been developed with the intention of capturing the knowledge required to use a given visualization toolkit. For instance, many VisKo packages are associated with a specific toolkit such as VTK, Generic Mapping Tools (GMT), and NCAR Command Language (NCL). However, there are groups creating packages in support of specific visualization activities such as chemical imaging, computational material sciences, molecular dynamics, and geographical information processing among others. These latter initiatives may consist of inter-package knowledge spanning any number of toolkits and custom services.
In order to maintain and contribute knowledge to Visko, one may need to know about package registration, which may involve any of the following activities. Package development is the process that includes the capturing of a human's understanding of visualization capability and of the human use of this understanding to encode knowledge into a package. For instance, is a person knows how to use Visualization Toolkit (VTK) and this person follows the package development process described below in this document, this person will be developing a VisKo VTK package. Package aggregation is the process of adding the content of a package into a VisKo server. We call this an aggregation process because, at the end of the process, the knowledge encoded in a package is aggregated to the knowledge available in a server's knowledge base.
We assume that the VisKo Custom Package is the only package available in a newly installed VisKo instance. In this case, for example, let say that one wants to aggregate VisKo GMT that will enable the VisKo instance to use GMT services. Upon installing a VisKo server, you will end up cloning the repository VisKo-packages. All packages contained in this repository are considered by the VisKo package installer and will be aggregated. If you do not want a specific package or do not have visualization services backing a specific package, simply delete it from the visko-packages directory.
Assuming you have identified the set of packages you want aggregated please visit the package installation instructions.
NICK: one should be able to retract an aggregated visko package
NICK: visko servers should have a way of listing aggregated visko packages
Once you have followed the steps below, you will see that the package generates RDF describing the toolkit services in terms of the VisKo Ontology, which can then be aggregated with your VisKo knowledge base (see package installation above). Upon successful aggregation, your registered visualization services will be considered when answering visualization queries.
The rest of this Wiki describes the following:
- A little blurb about why VisKo currently only invokes Web services. The exposure of visualization capabilities including data manipulations in support of visualizations is one of the main challenges behind a systematic, scalable approach for handling visualizations as pursued by VisKo.
- The requirements for your service to be properly registered
- How to register visualization knowledge in a VisKo package that recognize and understand how to use your services -- Steps 1 - 5 below
This set of instructions assumes that you have published Web service that adheres to the service requirements and know the URL to its WSDL.
Purpose of Step: Expose toolkit operations as web services.
Purpose of Step: Build the directory structure of the package.
- Create a directory to store the package code. NICK: is this a project? In other words, how this code is going to be compiled? do we have an ant file for it?
- Prefix the name of the directory with package_ followed by the name of toolkit your are exposing, for example package_vtk
- Within your package, create another directory called rdfPackage. This is the directory that will contain the Java code that registers your services
- Setting up the environment: NICK: which jar files are required; where are these jar files; how they should be added to the project
Purpose of Step: Create the skeleton for the registration code.
- Within the directory rdfPackage create a Java source file named PackageSource.java
- The contents of PackageSource.java should contain the following skeleton code:
package package_test.rdfPackage;
import edu.utep.trustlab.visko.installation.packages.RDFPackage;
import edu.utep.trustlab.visko.installation.packages.rdf.PackageInputParameterBindings;
import edu.utep.trustlab.visko.installation.packages.rdf.PackageOperatorService;
import edu.utep.trustlab.visko.installation.packages.rdf.PackageWriter;
import edu.utep.trustlab.visko.ontology.pmlp.Format;
import edu.utep.trustlab.visko.ontology.viskoService.Toolkit;
import edu.utep.trustlab.visko.ontology.viskoView.VisualizationAbstraction;
import edu.utep.trustlab.visko.ontology.vocabulary.ViskoV;
public class PackageSource extends RDFPackage {
private static final class Resources {
}
@Override
public void populateToolkit() {
// TODO Auto-generated method stub
}
@Override
public void populateViewerSets() {
// TODO Auto-generated method stub
}
@Override
public void populateServices() {
// TODO Auto-generated method stub
}
@Override
public void populateParameterBindings() {
// TODO Auto-generated method stub
}
@Override
public String getWSDLURL() {
// TODO Auto-generated method stub
return null;
}
}
For reference, you can check out a GMT package that comes with VisKo, just to know what your skeleton code will eventually be populated with.
Purpose of Step: Populate the Resources inner class with resources such as Visualization Abstractions, Formats, and Types to characterize your services with.
- Identify the inner class Resources
- Add statements to populate any formats you know your services will input or output by calling PackageWriter.getFormat(String) method.
//some formats
private static final Format ps = PackageWriter.getFormat("https://raw.github.com/nicholasdelrio/visko/master/resources/formats/POSTSCRIPT.owl#POSTSCRIPT");
private static final Format netCDF = PackageWriter.getFormat("https://raw.github.com/nicholasdelrio/visko/master/resources/formats/NETCDF.owl#NETCDF");
private static final Format spaceSeparatedValues = PackageWriter.getFormat("https://raw.github.com/nicholasdelrio/visko/master/resources/formats/SPACESEPARATEDVALUES.owl#SPACESEPARATEDVALUES");
private static final Format esriGridded = PackageWriter.getFormat("https://raw.github.com/nicholasdelrio/visko/master/resources/formats/ESRIGRID.owl#ESRIGRID");
You can find a listing of formats here.
NICK: What should one do if a desired format is not listed?
- Add statements to populate any data or semantic types you know your services will input or output by calling PackageWriter.getDataType(String) method.
// some data and semantic types
private static final OntResource xyzData = PackageWriter.getDataType("http://rio.cs.utep.edu/ciserver/ciprojects/CrustalModeling/CrustalModeling.owl#d18");
private static final OntResource fieldTrmmedGravityData = PackageWriter.getDataType("http://rio.cs.utep.edu/ciserver/ciprojects/CrustalModeling/CrustalModeling.owl#FieldTrimmedGravityData");
private static final OntResource COARDS_2D_Grid = PackageWriter.getDataType("http://gmt.soest.hawaii.edu/gmt-data.owl#2D_Grid_COARDS");
You will generally populate these objects using URIs from your own ontologies, but you can try to reuse existing types that support our default set of pacakges here.
- Add statements to populate any visualization abstractions you know your mapper services will generate by calling PackageWriter.getView(String) method.
// visualization abstractions
private static final VisualizationAbstraction contourMap2D = PackageWriter.getView(ViskoV.INDIVIDUAL_URI_2D_ContourMap);
private static final VisualizationAbstraction rasterMap2D = PackageWriter.getView(ViskoV.INDIVIDUAL_URI_2D_RasterMap);
private static final VisualizationAbstraction pointMap2D = PackageWriter.getView(ViskoV.INDIVIDUAL_URI_2D_PointMap);
You can get a listing of registered visualization abstractions by inspecting the INDIVIDUAL_URIs contained in the class edu.utep.trustlab.visko.ontology.vocabulary.ViskoV;
Purpose of Step: Populate populateToolkit method
This particular method contains the code that will register the toolkit that is supporting the services you are registering.
- Follow the invocation pattern below and replace with specifics of your toolkit:
@Override
public void populateToolkit() {
Toolkit toolkit = getPackageWriter().createNewToolkit("gmt");
toolkit.setComment("Generic Mapping Tools");
toolkit.setLabel("Generic Mapping Tools");
}
Note the call to getPackageWriter(). This method inherited by the superclass edu.utep.trustlab.visko.installation.packages.RDFPackage, returns the RDF writer object. This object allows for the creation of visko:Toolkit, visko:ViewerSet, visko:Viewer, visko:Service, and visko:ParameterBinding. These objects will get automatically serialized into RDF by the package installer.
Purpose of Step: Populate populateViewerSets method if you have any viewers to register
- Follow the invocation pattern below and replace with specifics of your viewer set:
@Override
public void populateViewerSets() {
PackageViewerSet viewerSet = getPackageWriter().createNewViewerSet("internet-explorer");
viewerSet.setComment("Internet Explorer Web Browser");
viewerSet.setLabel("Internet Explorer");
Viewer viewer1 = viewerSet.createNewViewer("iexplorer-browser-image-viewer");
viewer1.setLabel("Internet Explorer Browser Image Viewer");
viewer1.setComment("Views a few standard image formats");
viewer1.addInputFormat(Resources.gif);
viewer1.addInputFormat(Resources.png);
viewer1.addInputFormat(Resources.jpg);
Viewer viewer2 = viewerSet.createNewViewer("iexplorer-pdf-viewer");
viewer2.setLabel("Adobe Portable Document Format (PDF) Viewer");
viewer2.setComment("Renders PDF document and allows for zooming.");
viewer2.addInputFormat(Resources.pdf);
}
- First create the ViewerSet, by calling getPackageWriter().createNewViewerSet and set annotations.
- A ViewerSet contains a number of Viewers, the components that actually present data given some format and type. These Viewers can be created by calling createNewViewer on the ViewerSet object.
Purpose of Step: Populate populateServices method to register the visualization services supported by the toolkit
- Follow the invocation pattern below and replace with specifics of your services. Note that if you call the setView(VisualizationAbstraction) method, the installer will assert that your service is a viskoO:Mapper.
public void populateServices() {
String wsdlURL = THE URL OF YOUR SERVICES' WSDL
String operationName = "grdcontour";
PackageOperatorService service1 = getPackageWriter().createNewOperatorService(null, operationName);
service1.setComment("Generates contour map from netCDF 2D gridded dataset");
service1.setLabel("GMT grdcontour");
service1.setWSDLURL(wsdlURL);
service1.setInputFormat(Resources.netCDF);
service1.setOutputFormat(Resources.ps);
service1.setView(Resources.contourMap2D);
service1.setInputDataType(Resources.COARDS_2D_Grid);
// not output type...system will set to owl:Thing
operationName = "surface";
PackageOperatorService service2 = getPackageWriter().createNewOperatorService(null, operationName);
service2.setComment("Employ tensioned splines to generate gridded data in netCDF from ascii tabular point data");
service2.setLabel("GMT surface");
service2.setWSDLURL(wsdlURL);
service2.setInputFormat(Resources.spaceSeparatedValues);
service2.setOutputFormat(Resources.netCDF);
service2.setInputDataType(Resources.fieldTrmmedGravityData);
service2.setOutputDataType(Resources.COARDS_2D_Grid);
service2.setAsInterpolator();
}
Purpose of Step: Populate populateParameterBindings method to register any hard-coded parameters associated with your services.
- Follow the invocation pattern below and replace with specifics of your parameter bindings:
@Override
public void populateParameterBindings() {
PackageInputParameterBindings bindings1 = getPackageWriter().createNewInputParameterBindings();
bindings1.addSemanticType(Resources.gravityData);
// for grd2xyz
bindings1.addInputBinding("grd2xyz", "N", "0");
// for grd2xyz_esri
bindings1.addInputBinding("grd2xyz_esri", "N", "0");
}
Purpose of Step: Aggregate your newly created package!!!
At this point you should have a fully or partially (depending on whether your populated the OPTIONAL code segments) functioning package code. The next step is to aggregate your package with the VisKo knowledge base supporting your VisKo server. Look up to the section Package Aggregation to learn how to do this.