GOALS

GECAD Ontology ALignment System

This work is partially supported by the Portuguese MCT-FCT project COALESCE (PTDC/EIA/74417/2006).

This work is being published in conferences, workshops and other knowledge disseminating events.

Copyright remains with the authors.

This information should not be copy-pasted without acknowledging its origins.
Please contact the
authors for information on how to use or reference this information.

Examples

Following you can find some examples that shows GOALS features. It might also help you to understand how GOALS really works.

This is a simple and common scenario where two ontologies are aligned by one matching algorithm† and further the generated correspondences are filtered using a threshold value. Finally, the filtered correspondences are saved into two different formats, i,e.: in the MATRIX internal format† and in the AlignmentAPI format.

Since there is an reference alignment you can evaluate matching results. In that sense, Example 1 is extended to include evaluation feature.

This example is similar to Example 2. However, it makes use of GOALS meta-component feature.† Therefore, MCUser1 is a meta-component corresponding to the workflow depicted in Figure 3:

So, exploiting MCUser1 the workflow specification would be changed accordingly.

Figure 1: Example 1 scenario.

Figure 2: Example 2 scenario.

Figure 3: Meta-Component 1 workflow (MCUser1).

Figure 4: Example 2 scenario using Meta-component MCUser1.

Now, imagine you are not satisfied with the evaluation results and you want to improve them by using an extra matching algorithm. Thus, you will also need to aggregate matchers results into just one Matrix to get an alignment. For that purpose, Ordered Weight Average (OWA) function is choose.

Figure 5: Example 4 scenario.

Well, if you still not satisfied with matching results, it is always possible to choose other matching algorithms or to evolve for a new and more complex workflow specification. For instance, you can evolve to the workflow depicted in Figure 6.

Figure 6: Example 5 scenario.

Note that, generated files content (MatrixFilterByThreshold1.gmtx and Matrix2AlignAPI1.rdf) only differs in format. Thus, you are invited to disable generation of one.

Note that, Figure 6 grouped both ontologies just for representation simplicity. Thus, Meta-Component, FalconMatcher1 and MatchersContainer1 have as input both ontologies.

MatchersContainer1 is a special component that is able to contain several matchers (as child's). Component input data is sent to childís and childís output is put all together in an Matrix array.

In order to easily reuse the matching process defined in Example 5 we have created another meta-component (MCUser2), which is depicted in Figure 7.

Figure 7: Meta-Component 2 workflow (MCUser2).

Note that, new meta-components might take advantage of existing meta-components. In case, MCuser2 takes advantage of MCUser1.

 

Using MCUser2, the workflow of Example 5 would be quite simplified as depicted in Figure 8.

Figure 8: Example 5 scenario using Meta-component MCUser2.

This example is similar to Example 6 but using other ontologies and consequently a different reference alignment. Therefore, we have just changed the URIís parameters of loaders components (OntologyLoader1, OntologyLoader2 and MatrixLoaderFromCSV1).