Ontolink (Ontology-Linker) is a knowledge integration tool that can be used to specify semantic and syntactic mappings/transformations between concepts present in different ontologies. Currently, its main purpose is to act as an intermediate translation engine for web-service discovery and composition in STEER.

Upon launching the application, the following windows appear in the main MDI interface:

Knowledge Domain Window: This window displays a list of ontologies and web-services (under two separate tabs). To add an ontology (or web-service) to its respective list, you need to click on the 'Add' button and enter the URL for the ontology (or web-service DAML-s description) in the text-field. In the ontology list, each ontology has as its child nodes those web-services that refer to that ontology as a parameter in the DAML-s description of the web-service. This way the user can clearly see which ontologies would be useful to map based on their actual usage in web-services.

If any modifications are made to the ontology/web-services list, you need to save the new list by selecting the corresponding option from the menu at the top of the window. Note that the ontologies / web-services are not saved locally, only their reference URL is stored.

In order to open an ontology to view its classes and properties, you need to click on the 'Open' button which displays a new ontology tree window (as shown below):

Ontology Tree Window: The tree displays the concepts in the ontology hierarchically (each class node has its subclasses and properties as child nodes) with the prefix C used to denote classes and P for properties. The root node of the tree is the base URL of the ontology. The number in parenthesis following the class name denotes the number of web-services that refer to the class in its DAML-s description. In order to obtain more information about a particular ontological concept (such as its comment, restrictions etc), you need to click on the 'Get More Information' button at the bottom of the window. The remaining buttons are used to add specific concepts to the operand/parameter lists in the Ontology Mapping window (described later)

In order to specify mappings between concepts in two ontologies, you first need to open the ontologies (by selecting them and clicking 'Open' from the Knowledge Domain window as described earlier) in order to get their ontology trees. You then need to click on the corresponding concepts in the ontology trees and add them to the respective operand lists in the Ontology Mapping window. Finally, you need to specify the type of mapping between them (using DAML operators) and/or specify the transformation script using a particular language (such as XSLT). This process can be explained in detail using the example below:

Suppose you have two ontologies - Profile and Contact that define the same concept Birth-date differently. In Profile the concept is a class called BirthDate that has three properties - DayOfBirth, MonthOfBirth, YearOfBirth and in the Contact ontology, the concept is a class called DateOfBirth with a single property called DOBvalue.

You need to specify mappings at two levels:

Semantic Level i.e. Profile:BirthDate <daml:sameClassAs> Contact:DateOfBirth

Syntactic Level i.e. Contact:DOBvalue = xslt:concat(Profile:MonthOfBirth, Profile:DayOfBirth, Profile:YearOfBirth)

Process (step-wise):

1. Open the two ontologies (Profile and Contact) to get their ontology trees.

2. Click on the concerned concepts (nodes) in the trees and add it to operand list 1 and 2 respectively i.e. select the node BirthDate (in Profile) and click Add->Op#1 to add it to operand list 1 in the Ontology Mapping window. Then select the node DateOfBirth (in Contact) and click Add->Op#2 to add it to operand list 2 in the Ontology Mapping window.

3. To specify the Semantic Mapping, choose an appropriate DAML-mapping construct (in this case daml:sameClassAs) from the drop-down list box in the Ontology Mapping window as shown and then click the 'Add DAML Mappings' button. The program adds this mapping to a table in a new window and you can sort all the user-defined mappings in the table by clicking on the respective column header at the top of the table. Note that you can obtain a DAML file that represents all the mappings from the table by selecting the 'File->Convert to DAML' option from the menu at the top of the Mapping Table window. (see screenshots below)

4. In order to specify the Syntactic Mapping, select the respective concepts from the Profile ontology (MonthOfBirth, DayOfBirth, YearOfBirth in sequence) and add them to operand list #1 (also called source list) as described in step 2. Then select the target concept DOBValue (from Contact) and add it to operand list #2. Finally, select a transformation language (uptil version 3.0 of Ontolink, the only transformation script language supported is XSLT) and an appropriate transformation function (in this case concat) and click on the 'Add Transformation Script' button. The program automatically generates the required script and adds it to a text box in the Transformation Script window as shown. (see screenshots below)

Note: A good XSLT tutorial that describes all the transformation functions (with examples) supported by Ontolink, can be found here.

This window is divided into 2 panes:

Left-pane - displays the XSLT script created from the user-defined transformations (from the Ontology Mapping window) in the text-box as shown and has buttons to insert this script into the main stylesheet

Right-pane - contains an interface that can be used to specify conditions (using logical expressions) and loops for the XSLT script. Use of this interface is explained in detail using an example:

Suppose you need to specify a set of XSLT transformations that is to take effect only under certain circumstances. i.e. Following from the previous example, suppose you need to specify the birthdate translation from Profile to Contact ontologies, only for each instance of class profile and only when the name property of this instance is 'Aditya'. Furthermore when these conditions match, you also need to create a dummy instance of class contact in the output. This entire operation can be done step-wise as follows (see screenshot below):

1. Select the 'for-each' condition from the corresponding listbox as shown. Then drag and drop the profile class from the Profile ontology on to the test-element field as shown. Finally, click the button titled 'Add Expression Below' to add this loop statement to the main expression box below.

2. Select the 'if' condition from the corresponding listbox as shown. Then drag and drop the name property from the Profile ontology on to the test-element field as shown. Select the = operator from the operator listbox, and then type 'Aditya' in the matchwith-element field. Finally, click the button titled Add Expression Below to add this conditional statement to the main expression box below.

3. Drag and drop the contact class from the Contact ontology directly on to the main expression text box (this step is required since you need to create an instance in the output of class contact).

4. In this last step, select the XSLT expression from the script window in the left-pane and press the 'Envelope...' button in the right-pane (below the expression text box) to get the desired result i.e. the for-loop, if-condition and new instance are all integrated with the selected XSLT script (with the requisite starting and ending tags added correctly) as shown below.

Though the use of this window has been covered in earlier sections, there are some additional features that need to be explained:

1. The parameter fields (3) are used in certain XSLT transformation functions such as substring which require additional parameters in addition to the source node. In order to insert a particular concept (node) from its ontology tree into the parameter field, select the node and then click the 'Add Param->' button after specifying the index (1-3) of the respective field.

2. You can create an xsl:variable for a particular transformation by checking the appropriate box, and later use this variable in other transformations (thereby nesting transformations). The drop-down list box displays all user-defined variables with their associated transformations, and you can use any variable from this list in another transformation by typing its name directly in the parameter field for that transformation.

A combined use of both the features mentioned above is shown in the screenshot below. As can be seen, the user has already created a variable called $X6 that uses the normalize-space XSLT function. The user then uses this variable as parameter 1 along with parameter 2 (#) for the substring-after XSLT function (which requires two parameters). Again, checking the 'Create Variable for Expression' option causes a new XSL variable to be created, $X7, that stores the substring-after expression. Hence, for example, if the value of email ($X5) is ' adikal@hotmail.com ', then $X6 takes the value 'adikal@hotmail.com' (since it normalizes space) and $X7 takes the value 'hotmail.com' (since it uses substring-after '@').  

Note that whenever you create a variable for an expression as shown below, you should not specify a target element (since the new variable created is a sort of target). Also note, that you don't need to specify source elements if the parameter fields are filled. In this case, the program substitutes the source with parameter 1 ($X6 acts as the source in this case).  

Once an XSLT script is created that specifies the transformation from the source ontology concept(s) to the target ontology concept(s), you need to add it to the main XSL stylesheet (shown below) by clicking on the corresponding button in the Transformation Script window.

After the entire XSL stylesheet is ready (i.e. it contains all the required XSLT scripts) you need to create a DAML-S translator web-service that embeds the XSL stylesheet in its Grounding information. This can be done by clicking on the corresponding menu item (Service->Create...) at the top of the XSL Stylesheet window.

This brings up a simple form (shown below) that you need to fill in order to create the web-service, wherein you specify attributes such as name of the service, a short textual description, and input and output parameters for the service. In our example, since the translation is from the profile class in one ontology to the contact class in another, you need to drag and drop the classes from their respective ontology trees on to the input and output fields as shown. Finally clicking on the 'Create Service' button causes the program to create the web-service (.daml file) and store it in the same folder as Ontolink.

The purpose of this window is to help the user find possible matches between concepts in two ontologies (specified by the user) using various heuristic techniques. However, in the current version (3.0) only syntactic techniques (sub-string matching) are supported. In future versions, we hope to use a DAML reasoner with strong inferencing capability in order to identify more complex matches. Currently, the user selects two ontologies from the knowledge domain (using the drop-down list boxes), specifies a mapping algorithm and clicks the 'Generate Suggestions' button. The program automatically determines all possible matches between concepts in the two ontologies using the algorithm and displays them in a tabular fashion as shown. Its left to the user to decide on whether a particular mapping is valid or not and to use it accordingly

.

Sometimes you need to look at instance data from an ontology in order to see what values some properties take, in order to specify the transformation functions accurately. In this case, you can open the instance data (.daml file) by selecting the appropriate menu option 'File->Load XML/DAML Instance' from the menu at the top of Ontolink desktop pane and browsing and loading the file.

Marshaling / Unmarshaling Problem:

The problem of marshaling (or unmarshaling) in web-service execution  requires transformation of a semantic object  (which is an instance of a class referred to by in the DAML-S description of the web-service) to XML data represented using an XML schema that is referred to in the WSDL description. This transformation can also be specified in Ontolink using a process similar to the ontology-mapping process explained earlier. The difference in this case being, instead of opening two ontologies, you need to open the required XML schema by selecting the menu option 'File->Load XML Schema' from the menu at the top of the Ontolink desktop pane besides opening the Ontology you need to map it with. The subsequent process of specifying XSLT transformations between the two entities (XML schema and ontology) using the Ontology Mapping interface remains the same. (see screenshot below)

Here the XML schema is part of the WSDL document and hence the .wsdl file is loaded using the 'File->Load XML Schema' menu option. The schema is shown in its tree format on the left and the ontology to be mapped with is opened on the right. In this case, as can be seen above, the mapping specified is an XSLT concat transformation that concatenates the four XML source nodes (street, city, state, zipCode) into the single DAML property node Address. 

WSDL2DAML-S Translation:  

Using the WSDL-DAML mapping capability explained above OntoLink can be used to generate DAML-S descriptions from WSDL descriptions. This translator helps you generate a DAML-S service for a WSDL operation. The generated DALM-S service will have a process model that contains a single AtomicProcess description. This process will be grounded to the input WSDL operation. User only needs to specify the textual descriptions for the service, parameters and mappings between DAML types and XML Schema types (explained below). WSDL2DAMLS translator can be opened using the 'File->WSDL2DAMLS Translator' menu option. (see screenshot below)