[an error occurred while processing this directive]
The javadocs of the API is included in the distribution file. You can access the online version here.
There are couple of example OWL-S files here http://www.mindswap.org/2004/owl-s/services.shtml. These services are all grounded in actual WSDL services and can be executed with the API. These are simple service descriptions to show different features in OWL-S such as how to define XSLT transformations in groundings, how to define CompositeProcesses and data flows and so on.
The examples directory in the distribution file contains example code that shows how to use these service descriptions in the API.
There are two interfaces defined for reading and writing OWL files, OWLReader and OWLWriter. These are simple interfaces that provide the basic functionality of reading and writing OWL files. OWLReader's and Writers can be created via the static methods createReader() and createWriter() on the OWLFactory class. The OWLReader will read in an OWL file from a variety of inputs and produces an OWLOntology object. Alternatively, the OWLWriter class can write an OWLOntology object to a number of different outputs.
Also, an OWLKnowledgeBase can be created using the OWLFactory class. An OWLKnowledgeBase has several read methods which read the specified ontology into the KB. However, it also provides special read methods such as readService(URI) and readAllServices(URI) for reading in OWL-S descriptions. These methods return the Service found at the specfied URI and the list of Services found at a URI respectively.
Here is some example code to show you how to use the OWLReader, OWLWriter and OWLKnowledgeBase classes to read in OWL files and OWL-S descriptions. For more details, see the examples provided with the OWL-S API.
// create the URI of a known service for us to read in
|
A simple validator is provided with the OWL-S API. It is located in the org.mindswap.owls.validator package. The OWLSValidator class provides a method validate() which takes the URI to an ontology, or a OWLKnowledgeBase to validate. It looks for common structural errors in the OWL-S description. The validator returns an OWLSValidatorReport upon validation which contains all the information about the validation, including whether or not the service(s) found are valid, and any error or warning messages. This report can be written to any output stream, or the Map of OWLSValidatorMessages can be iterated over to get at the validation results.
// create a new validator
|
Sometimes it is desirable to use cached versions of the files rather than downloading the remote files. The OWLCache class provides the functionality for this purpose. OWLCache.setLocalCacheDirectory(String) specifies a directory to find the cached files. The cache dir should include a file named service.idx that has the mappings from URI's to local file names. This index file is a text file where each line is in the format
[service description url]=[local filename]
The ':' characters in the url's should be escaped as "\:". See
Properties.load() for more details about the file format. You may choose
to add file entries one by one using the
OWLCache.addCachedFile() function. When there is a cache entry for a file,
the cached version is only used when the original file cannot be found (e.g.
no connection). It is also possible to give more priority to cached files and
try to get the remote file only if there is no cached version. See
OWLCache.setForced(boolean) for this functionality. Remember to include an
xml:base statement in your cached files so that URIs generated from your local
file will be exactly same as the remote one.
Executing a service means executing the process it has. The process should
have a valid grounding specification in order to invoke the service
successfully. The WSDL and UPnP groundings are supported by the API. A process
is executed by the
ProcessExecutionEngine.execute(Process,
ValueMap)
function where second parameter specifies the values for
input parameters. This function returns another
ValueMap which contains the output value bindings. The following
code segment shows an example of executing a service:
// create an execution engine
|
The above is a simple example where the input is a simple XML Schema string.
However, some services will have complex inputs that are represented by OWL
classes. In this case, the value of input parameter can be set to the RDF/XML
representation of the complex input. See
RunService.java in the examples directory
for more examples of this kind.
It is possible to monitor the progress of a service's execution.
ProcessMontior defines a minimal set of functions for this
purpose which are called when a service begins, finishes or fails execution.
Simply use the ProcessExecutionEngine.addMonitor(ProcessMonitor)
to add a monitor to the execution engine. See
RunService.java in the examples directory
for an example of how to use the listener.
It is possible to create service descriptions, profiles or processes
programmatically.
OWLSFactory provides functions to create any of these structures.
CreateSequence.java in the examples directory
shows an example of how to do this. The following code snippet shows the main
idea:
/**
|
Every resource in the API (Service,
Profile,
Process, etc.) extends
OWLIndividual which provides very basic functionalities to get and set
object and data properties for any OWL resource. If additional information is
required about the resources then the underlying RDF model can be queried.
Right now, API is built on top of Jena so the function getImplementation() will return the corresponding
resource in the Jena model.
Each service description is loaded into a separate
Jena model where the model contains the imports closure of the service
description, i.e. each ontology service description imports is also in that
model. OWLModel provides a getImplementation() function that will
return the underlying Jena Model. Individual OWLModel's can be accessed by the OWLKnowledgeBase
they are a part of, stand-alone when created using OWLFactory.
In the future releases it is planned to add support for
OWL API.
The API contains a package
org.mindswap.wsdl that provides support for reading and executing
WSDL services. Execution of OWL-S services is achieved through this package.
The WSDL functionality is based on Axis
package version 1.1. The main functionality added to Axis is the ability to
execute services with complex inputs dynamically without a need to create
stubs or extra code. The SOAP messages are created from the string
representation of XML Schema complex type. This invocation method is not
robust but works for most of the cases.