Instruction Generation.

In the second step, particular ontology transformation instructions are generated in XML serialization given the specific binding and the transformation pattern, especially its pattern transformation part:

<pt>
  <eq op1="?A" op2="?D"/>
  <eq op1="?B" op2="?E"/>
  <eq op1="?C" op2="?F"/>
  <eq op1="?p" op2="?q"/>
  <ntp entity="?G">make_passive_verb(?C)+head_noun(?A)</ntp>
  <ntp entity="?D">?A</ntp>
  <ntp entity="?E">?B</ntp>
  <ntp entity="?q">?p</ntp>
</pt>

In this case entities are just transferred to the target ontology under the same name. Most axiom operations just remove and then add the same axiom given the equivalence of entities according to LI. An exception is the addition of a new axiom, !AcceptedPaper equivalentTo (hasDecision some Acceptance), connected with creation of a new class, AcceptedPaper, according to Ax of $OP2$. No operations on annotations were needed, as there are no singular removals (without complementary additions).

The resulting transformation instructions are serialized as follows:

<instructions>
  <oppl_script>
    <remove>hasDecision domain Paper</remove>
    <remove>hasDecision range Decision</remove>
    <remove>Acceptance subClassOf Decision</remove>
    <add>hasDecision domain Paper</add>
    <add>hasDecision range Decision</add>
    <add>Acceptance subClassOf Decision</add>
    <add>!AcceptedPaper equivalentTo (hasDecision some Acceptance)</add>
  </oppl_script>
  <entities>
    <rename type="ObjectProperty" original_name="hasDecision">
      hasDecision
    </rename>
    <rename type="Class" original_name="Paper">Paper</rename>
    <rename type="Class" original_name="Decision">Decision</rename>
  </entities>
  <annotations/>
</instructions>

This would be the output of InstructionGenerator RESTful service.

Finally, the cmt ontology would be transformed, given the transformation instructions, using the OntologyTransformation RESTful service. Aside the mentioned enrichment with named entity 'AcceptedPaper', the interface to OWL-API also cares for adding information relating this new entity to the original entity. Applying ontology matching on the ekaw ontology and the transformed cmt ontology we easily get, among others, the following simple correspondence:

cmt#AcceptedPaper=ekaw#Accepted_Paper

Although AcceptedPaper is not present in the original cmt, we can use the simple correspondence for getting a complex correspondence for the original cmt,

(cmt#hasDecision some cmt#Acceptance) = ekaw#Accepted_Paper

corresponding to the 'Class by Attribute Type' alignment pattern from [2,3].