Ontology Web Services

Added to the ontology semantics which describe soap style web services.

OWL Classes consist of the following:

1. http://www.miamidade.gov/ontology#WebService - Top level class which describes the service. A service has zero or more inputs, and outputs.
2. http://www.miamidade.gov/ontology#WebParameter - Web Service inputs and outputs must be of this type.
3. http://www.miamidade.gov/ontology#WebArgumentMapping - A class that allows for the decoupling of WebService parameters and the arguments that are to be used as values for/of parameters.
4. http://www.miamidade.gov/ontology#WebArgument - An argument to be used in a WebArgumentMapping.

Describing a WebService in the ontology:

Step 1: Create an individual of type http://www.miamidade.gov/ontology#WebService. Specify the following data properties: Wsdl (URL of the wsdl document), Endpoint(The url at which to invoke the service), PortName(Taken from the wsdl document), SOAPAction(Taken from wsdl document), Namespace (Taken from wsdl document), ServiceName (Taken from wsdl document).

Step 2: Create all inputs and output parameters as individuals. WebParameters have the following data properties: ParameterName(arbitrary name for the parameter), XPathExpression (An xpath expression pointing to an xml node containing the data for this parameter. Must be prefixed or use default prefix of :), DataType(The data type for this parameter).

Step 3: Add all inputs and outputs to the WebService created in step 1. Inputs and Outputs are added as object properties hasInput(WebParameter) and hasOutput(WebParameter).

Step 4: Create all WebArgument(s) as individuals. There more than likely will be a 1-1 match of WebArgument(s) to WebParameter(s). A WebArgument has the following data properties: ArgumentType ("input" or "output"), ArgumentIndex (Index at which to expect the argument). A WebArgument also has the following object property: parameter (WebParameter) the web parameter to which this argument references.

Step 5: Create a WebArgumentMapping individual. Add all WebArgument(s) created in Step 4 as object properties using the 'hasArgument' property. Add one final object property 'forWebService' and select the individual service created in Step 1.

 

Java Execution Class and usage

import org.sharegov.cirm.services.OWLWebServiceCall;

...

public void test()

{

OWLIndividual svc = individual("GeoAddressToXYService");

OWLWebServiceCall call = new  OWLWebServiceCall(svc);

OWLDataFactory df = MetaService.get().getDataFactory();

OWLLiteral[] args = new OWLLiteral[]{''111 NW 1 ST"};

System.out.println(call.execute(args));

}

...

Rest Execution Endpoint

http://localhost:8182/services/all - All Web services described in ontology

Output(application/json): ["http://www.miamidade.gov/ontology#GarbageTruckRouteCheckService","http://www.miamidade.gov/ontology#GeoAddressToXYService"]

http://localhost:8182/services/GeoAddressToXYService - Display service details.

Output(application/json): Lengthy...

http://localhost:8182/services/GeoAddressToXYService/description - Displays argument mappings.

Output(application/json): Lengthy...

http://localhost:8182/services/GeoAddressToXYService/call?argument=111%20NW%201%20ST - Executes a call to this web service.

Output(application/json):["111 NW 1 ST","920433.62502828","525114.81238802"]

 

As Pellet BuiltIn

While attempting to create a Pellet Builtin to invoke webservices from within rules as function calls we faced the following issue: If using a reasoner from within the Custom Function to reason over the ontology that contained the Custom Function call a circular loop is created in which the reasoner will continuously call the custom function. Thus, the Builtin is incomplete. 

 

GeoAddressToXYService

This is a service provided by ETSD/GIS. It takes an address as an input and outputs X,Y. It was modeled to proof pre-existing web services.