Domain Hierarchy

To provide mobile users with ability for defining navigational integration, the semantic conflict among data of different WISs must be resolved automatically on their PDA units even if they disconnect their PDA units from the network. In this section, we present the domain-domain relationship construction called domain hierarchy and an associated algorithm for downloading minimal domains. Thereafter, using the downloaded metadata, a necessary functions on PDA side to resolve conflict semantic is described.

Concept of Domain Hierarchy:


Figure 1


A domain hierarchy (DH) is a metadata repository shared and maintained among all areas in a given network. Figure 1 shows an example of the domain hierarchy, which is maintained by two areas. The domain hierarchy consists of two components:
  1. multiple local domain hierarchies (LDHs); each LDH is maintained individually in each area, and
  2. a common domain hierarchy (CDH); this is shared by all areas. When multiple areas share the same CDH, these areas are called a region. The domains in each LDH are defined for describing format/meaning of data used in that area while the domains in the CDH are defined as a set of standard data formats/meaning for data exchanging among data of those areas.
As described earlier, all WISs are wrapped into a unified form called an interface definition. Attributes and arguments of access methods are mapped to the domains in the local domain hierarchy of the area as shown in Figure 2(see details in Section Interface Definition). Moreover, domains of each LDH are linked to the domains in the CDH for providing semantic convertibility among data of WISs in different areas of the same region.


Figure 2


Construction:

Now, we describe how to build a domain hierarchy. Domains are organized into a hierarchical structure, where a type of hierarchical relationship is an one-to-one relationship (data-format conversion), or an is-a relationship, or a part-of relationship. Therefore, for any given domain D, its parent domain is equal to, is more general than, or contains D. The hierarchy links (depicted by bold links in Figure 2) represent such hierarchical relationships.

As a result, for any given domain D, D has a hierarchical relationship with its parent. However, D may have other relationships with some domains D'i (i = 1,...,n). These relationships are described as point-to-point links (depicted by fine links in Figure 2 between D and D'i. Therefore, D can have one hierarchy link to its parent and several point-to-point links to D'i. (In implementation, each link is described by conversion functions for converting semantics between the two associated domains.) We refer to a specification that describes these links (with their conversion functions) as the domain rule of D.




Figure 3


Here, we describe how to build the domain hierarchy that allows each local area to be able to extend its local domain hierarchy independent of other areas. Figure 3 shows the way of construction of the domain hierarchy. Let a square in each domain be link definition symbol. This symbol specifics that the domain rule of one domain describes the link with its conversion functions associated with another domain. The way to construct a domain hierarchy is shown as follows:
  1. A hierarchy link is described in a domain rule of a child domain.
  2. A point-to-point link is described on both side domains if they are in the same LDH or CDH.
The first policy helps a developer to concentrate on new domains that are being added into the system. The parent domains need not to know their children. Therefore, new domains in each area (LDH) can be added into the system without informing anyone. On the other hand, the second policy broadens the range of conversion between domains regardless of any directions of conversions.

Matcher

To generate query command for defining navigational integration, we provide mobile users with a tool called Matcher on a mobile unit.

Conflict Resolution:




Figure 4


In our scheme, let two given domains be S and R. A conversion path between S and R is assured to exist if there is a domain that is:
  1. an ancestor of both domains (In this case, X is the shared domain); or
  2. an ancestor of one domain linked by a point-to-point link of an ancestor of the other domain. In other word, there is only one point-to-point link between ancestors of both domains (In this case, S2 is the shared domain).
  3. a domain linked by point-to-point links from the ancestors of S and R (In this case, Y is the shared domain).
Let us call such a domain a shared domain(SD). Let Si be the parent domain of Si-1 and S1 be the parent domain of S0. Likewise, let Ri be the parent domain of Ri-1 and R1 be the parent domain of R0. The sequence of conversion methods can be determined via the conversion path between S0 and R0 via SD as follows: 



S0 -> S1-> ... -> Sn -> SD -> Rm-> ... -> R1 -> R0 
 

using asequence of conversion functions: 


MS0 -> MS1-> ... -> MSn -> MRm-> ... -> MR1 -> MR0

where MD is the conversion function described in the domain rule of D.

Conversion paths are not always legal. If a conversion path causes a many-to-many relationship between a start domain and a destination domain, unexpected data will emerge. Such a conversion path is regarded illegal. The matcher must consider this restriction when finding a conversion path.

Example:

Here we are ready to show a query command defining navigational integration with conflict resolution. The following query command describes navigational integration from a given department page of the first WIS to find the laboratory detail from the Laboratory DB of the second WIS: 

from   I in ISPage, L in LabBuilding 
source ISPage of ISInformation on http://HOST2/cgi-bin/execute.pl,
       LabBuilding of ISLab on http://HOST3/cgi-bin/execute.pl 
where  ISPage ->getISPage() 
and    LabBuilding->getByConds('','',&L:Lab2JLab(&I:LabD2Lab(I->{depts}->{dept}=>Department->{laboratories}->{labName})))
In this command, getByConds is the public method defined in the interface definition of the second WIS; this method is the major function of this WIS. The path expression I->{depts}->{dept}=>Department->{laboratories}->{labName} extracts the laboratory names appearing in the department Web page. Due to the semantic conflict between laboratory data in WIS1 and the required argument of the method getByConds() of WIS2 (LabDomain and JLab), the LabD2Lab and the Lab2JLab functions are inserted to resolve this conflict in order that data of WIS1 are converted into data of WIS2. The snapshot of execution is shown in Figure 5.


Figure 5

Last modified: Mon Apr 24 18:24:26 JST 2000