Líquido de Diálisis

0 50 100 150 200 250 300 350 400 0 200 400 600 800 1000 events ti m e( s )

Figure 5.12: Case 3 - DB Model Higher Bound

Case 3: DB model - Resource similarity - Higher bound 0 100 200 300 400 500 0 200 400 600 800 1000 events ti m e( s)

From experiments we can conclude that the performance for Case 1 and 2 is sufficient and response times of the system developed with this algorithm are under 2 seconds for several thousands events/resources. The complexity of Case 3 is O(n2_{) which can be considered as a sufficient complexity but real}

measures show that especially with the Jena DB model response times of such algorithms are dozens of seconds. We have suggested and implemented several improvements:

• Similarity measures performed by an algorithm can be moved to run separately in the background of the system, e.g. a resource similarity can be computed in advances for existing resources. Results of such similarity are stored in the Memory for further use. When a new resource is introduced, the system pre-computes only the similarity between the new introduced resource against existing resources. That can significantly improve the response time and the performance in case 3.

• Memory caching is suitable to reason. That can improve the performance by limitation of long-time DB accesses. The hybrid approach between the MEM model and the DB model will be suitable for a large system and performance requirements.

• When the Jena toolkit has long response time for more complicated and complex queries, the improvements are included in query optimization because a proper order of triples in WHERE clausule of the RDQL query can speed up the query execution.

The complexity of the algorithm is polynomial and thus we think that with improvement of Semantic tools such as Jena the performance for real commercial systems in the future can be sufficient.

Figure 5.13: Example for higher and lower bounds for Case 3

0 100 200 300 400 500 600 700 800 900 1000 0 2 4 6 8 10

5.1.2.2 Developed Similarity Matching Mechanism

The matter is to specify what is “sufficient similar” and what is the best algorithm for a similarity measurement. Basically, two resources are “sufficiently similar” when they describe the same context, but this precondition is too restrictive. It is necessary to allow users to implement much more complex matching methods. Such flexible can be achieved by providing the common Java interface and a general matching method that provides a basic sufficient functionality. The new functionality can be added or adjusted to the system by implementing the interface or extending the general method.

The similarity matcher interface is designed to allow a user to implement new methods for similarity evaluation. It provides two basic interfaces for measurement of a similarity degree, the first compares each and every parameters of resources and the second evaluates only one attribute of the resources.

To provide a more flexible similarity evaluation both interfaces can take a “filter” parameter. This parameter delivers a “filter” object that describes information about the resources categorized by its type. The simple implementation of a “filter” class stores only the couple resource type and its weight. This is important for the tuning of similarity match process. Moreover for this implementation it is enabled to set the parameter to null, in this case the weight of 1.0 is assigned to each resource.

The values of weight are real numbers limited from 0.0 to 1.0. The “filter” object provides methods to easily import the couples resource and weight. They can be obtained from the ontology (see Figure 5.14) or can be specified for each resource.

The general method of the implemented matching interface evaluates the similarity degree of two resources. As the evaluated resources need not be of the same type as is implied from the semantic matching process, it is necessary to implement an algorithm for the resources of different types that could contain completely different attributes, however, only objects of the same attributes will be put into evaluation. Due to a computational complexity, only the direct descendants are investigated, rather than to search the whole subtree of given resources.

General method based on Similarity Weights for different resource properties was developed as well. Figure 5.14 illustrates a generic structure of the SimilarityWeight ontology concept as well as concrete instances for one of the tested applications. As can be seen, weights can be defined for selected domain classes to perform similarity computation. Such weights are used when computing similarity between 2 resources. If properties of resources are matched the similarity value of such a property is summed to the entire similarity value. When specified by the description logic, the model consists of

SimilarityWeight class with properties domainClass.SimilarityWeight and the weight.SimilarityWeight property.

SimilarityWeight ⊆

domainClass.SimilarityWeight(Domain) ∩ weight.SimilarityWeight(String)

{simWeight} ∈ SimilarityWeight

Two Resources are similar to the value sim when for object properties of resources SimilarityWeights are defined and properties of resources are the same. The Summed weight.SimilarityWeight of such properties divided by match property count n equals sim.

{res1,res2} ∈ Resource

sim({res1,res2}) = fsim(

∀{propi} ≡ propertyi.Resource({res1}) ∩

∀{propj} ≡ propertyj.Resource({res2}) ∩

{propi} ≡ {propj} ∩ {propi} ∈ DomainClass ∩

DomainClass ⊆ Domain ∩

∃{simWeight} ∈ SimilarityWeight ∩

domainClass.SimilarityWeight(DomainClass) ∈ {simWeight} ∩ {weight} ≡ weight.SimilarityWeight(DomainClass) ∈ {simWeight};

Σij{weight}/n

)

5.2 Methods for presenting Ontological Knowledge to