Biology: A Characterization of the Mediator Concept. Uwe Radetzki1,, Armin B. Cremers1. Abstract: The interoperation of information from various data sources, ...
Mediator-based Interoperation in Computational Biology: A Characterization of the Mediator Concept Uwe Radetzki1, , Armin B. Cremers1
Abstract: The interoperation of information from various data sources, internet services and applications is a central topic in scientific research. Due to the fact that today interoperation requires a high degree of user knowledge and domain expertise in order to combine services in life science applications, we need a smarter mediator-based interoperation. In particular, biologists cannot answer questions by consultation of a single information source. In combining heterogeneous services we identify two different processes: an explicit user-defined biological business process and an implicit mediation process. In this context, mediators are subjects of the latter process, defining transformation steps in order to solve syntactic as well as semantic mismatches. Computational biology is a diverse and dynamic field. Therefore it is not possible to standardize data structures and working processes. Thus, one should simplify or standardize the mediation process. Based on an analysis of related mediator architectures we give a precise characterization of mediators in general. We identify several features a mediator has to provide. A major factor is the introspection mechanism in order to expose features of previously unknown mediators. This mechanism should be processable by users and machines, as far as possible. Introspection has to discover syntactic as well as semantic knowledge of the capabilities of a concrete mediator. We build an ontology-based mediator profile for this purpose. It is useful not only for generating concrete interface descriptions but also for specialized registries. Qualified mediator registries are a first step towards a smart mediation process.
Keywords: mediator-based interoperation, web services composition, ontologies
1
Introduction
The interoperation of information from various data sources, internet services and applications is a central topic in scientific research. In earlier work, motivated by geo-scientific modeling tasks, we have successfully implemented a mediator-based approach for connecting object database applications in a CORBA environment [16]. Today, this subject has gain much more significance due to the (r)evolution of the internet, the enhancement of communication technology, and the availability of information through the web [4, 9]. The aim of interoperation is to enrich the information content by combining related information in a meaningful manner. In this way, users will be supported effectively in making their decisions or planning future actions [19]. However, today interoperation often requires a high degree of user knowledge and domain expertise, in order to make heterogeneous and autonomous systems interact which in advance are not built for this purpose. Hence arises a smarter mediator-based interoperation, particulary in life science applications. The success of molecular biology research leads to new challenges: The number of available sources increases continuously, for instance the Molecular Biology Database Collection alone encompasses more than 340 databases [1]. And, even for similar information or algorithms, 1
Department of Computer Science III, University of Bonn, Roemerstr. 164, D-53117 Bonn, Germany, {ur,abc}@iai.uni-bonn.de, (+49) 228 73 4530
there remain significant differences in data types and formats, semantics, and structures [7]. Further, the rapid pace of change hinders the development of stable data formats and standards. Whenever new bio-technological methods arise, new species are sequenced and annotated, new databases and algorithms emerge. However, many problems biologists are dealing with, cannot be answered by consultation of a single information source. In fact, typically they need to combine information from various resources. Presently this must often be done manually. Taking into account that it is unreasonable to altogether standardize data structures and working processes of biologists, one should simplify or rather standardize the way, in which users can handle the interoperation process. We approach these issues by bringing together recent concepts of web services, mediators, and ontologies. In an open and flexible service-centric computing environment, called IRIS (Interoperability and Reusability of Internet Services) we support users in building new web services compositions. In this context, we try to keep in mind the level of computer training and knowledge of most biologists, who will work with this platform. In the present we concentrate on the identification of requirements for a generalized mediator concept. Other aspects of the IRIS environment have been described elsewhere [13, 14]. Before we go into detail, we give a illustrative example: A biologist tries to find out the function of a gene which corresponds to an expressed sequence tag (EST). For this reason, homologous proteins of the translated protein have to be identified. We assume that the user knows two different information sources – one service which retrieves the gene with respect to the EST, and another service which provides homology search within a protein database. Consequently the user may specify a biological business process as it is shown in figure 1. Because the EST bank only produces annotated sequence information and the protein database only expect proteins, we have both syntactic and semantic mismatches. web service
web service
EST-BANK (barley)
ProteinDatabase
user-defined business process Homologous Proteins
EST Annotation
Protein Mediation
1. p(Annotation)®DNA-Seq
mediation process
syntactic
2. GenScan(DNA-Seq)®Gene semantic Control Flow Data Flow
3. Translation(Gene)®Protein
Figure 1: A (simplified) biological business process and the required mediation process. Supposing that the user defines only reasonable processes between the different information sources, an intelligent system should detect syntactic and semantic conflicts as well as present them to the user or rather correct them automatically. In the former case the user should remove the conflicts in an interactive and cooperative manner. Thus, we can recognize two different processes: the explicit user-defined biological business process and the more internal and implicitly occurring mediation process. In the following we will 2
subsume computing environments, that support the user by the latter aspect, by the term mediator system. Again, we remark that these mediators are transformation units which solve conflicts between heterogeneous resources. They are no subject matter of the userdefined biological process, even if they are realized as a typical internet services, like the database services themselves. However, mediators alone cannot overcome the different forms of heterogeneity which encompass a technical, syntactic and semantic level [12]. Several other techniques like wrappers or adapters are also needed. Today, in the context of the world wide web, standardized web services are the method of choice for building such wrappers; we are convinced that in the near future every web-enabled data or method service is accessible through their standardized protocols based on XML and HTTP. Here we refer to the Simple Object Access Protocol (SOAP) or the Web Services Description Language (WSDL). In the following we summarize internet-enabled data or method services by the term web service. Clearly, whereas the technical and syntactical aspects of heterogeneity are reasonable well understood as part of the interoperation process, the focus has to be on semantic aspects [19]. Here we suggest that the method of ontologies has to be adequately combined with the mediator concept. The remainder of this paper is organized as follows: Section 2 describes related work in the field of mediator systems. Based on this comparison, in section 3 we give a characterization of mediators in general. A central part of the mediator facilities is the introspection mechanism which should provide syntactic as well as semantic information. For this purpose we define in section 4 an ontology-based mediator profile and describe a registry as application of such profiles. Finally, we summarize our contribution and give an outline of future challenges.
2
Mediator systems
Basically there are two kinds of mediator systems, but the limits are variable such that hybrid forms are possible. The first one encompasses mediators in distributed database systems like federated database management systems. In this context they are often combined with wrappers. These mediator systems support autonomy and data independence of the integrated data sources. The second kind of mediators are used in component software often in connection with adapters and bridges. Here, autonomy and independence of components are guaranteed. In the following, we will analyze the mediator approaches separately, in order to expose their characteristics. Of cause, there are quite a few related software platforms and database systems, but due to limitation of space we cannot reflect all of them. Further, data warehouse related systems like the Sequence Retrieval System (SRS) [21] are not described here, even though they use internal mediator-based concepts, too.
2.1
Mediators in distributed database systems
One of the most often cited definition of mediators is the one of Wiederhold [18]. He defines a mediator as a kind of software module that exploits encoded knowledge about some sets or subsets of data in order to create information for a higher layer of applications. 3
These mediators build an active layer between the user application and the databases. Mediators should be small and simple in order to stay maintainable by some experts. Further, they should provide some kind of introspection facility. Albeit very vague, some important features of mediators are identified. However, the original article does not specify exactly the introspection mechanism as well as some other important aspects of how to achieve mediation. Several systems have adopt the idea of a mediator architecture and we shall mention some prominent examples. The architecture of Naumann and Leser [9] supports query answering with incomplete results. The crucial point is that users are able to specify the level of incompleteness in a cooperative manner. For this reason density scores of attributes are introduced. Yan et al. [20] introduce a 2-tier architecture where the interoperation process is divided into two different tasks. Firstly, different data sources are homogenized, i.e. removing schematic discrepancies, secondly these data source can be integrated with respect to a defined view. In the latter case the semantic differences are resolved by the mediator author. For this purpose every mediator supports a variant of the relational algebra. However, due to the complexity of this algebra it is not suitable for end users directly. In a similar way, Chawathe et al. [5] specify a SQL-like query language and a selfdescribing object model for the mediators. One important aspect of their platform is that the mediators need not to process all available information of the connected data sources. Further, it is possible to arrange mediators in hierarchical layers. Thus, new mediators can be built up upon existing one. Qian and Lunt [12] use a mediator language which is based on first-order predicate calculus. Within this calculus the mediation author can define rules and relations in order to let the system automatically integrate different data sources. Carey et al. [4] define an object-oriented data model as intermediate model and therefore an object-oriented query language in order to resolve syntactic mismatches. One problem of all these approaches is that the user is stuck on a specific platform. For this and other reasons the reusability of developed mediators is restricted. Further, if any only simple introspection mechanisms are supported, which provide semantic knowledge of the mediator. The presented approaches above uses different mediation languages and data models. Today in the internet context one would substitute these by XML and XML-based query language, like XQuery. But one problem remains, the choice of language depends on the suitability to a given problem and not the other way around; several languages like XPath or XQuery are not adequate for complex mediation processes which are required in computational biology. A last point to remember is that these approaches take only databases into account, distributed algorithms are not considered.
2.2
Mediators in component software
A different definition of a mediator is given by Gamma et al. [6] in a mediator design pattern. They understand by a mediator an object that describes the interaction of a set of related objects. In this way, mediators increase the reusability of these sub modules, because non of them which take part into a complex interaction needs to now the other units. The interaction process as well as the sub modules can evolve independently from each other. Beach [2] depicts a software bus, via independent software components can be combined 4
by a publish-subscribe metaphor. His architecture addresses the message transportation, the data exchange and the transformation of data according to the consumer component. The inherent transformation of a mediator is declared declarative in a Prolog-like language. This language is practical for representing structural, i.e. syntactical, transformations rather than for semantical mappings. Related to this approach is the work of Radetzki et al. [15]. In their architecture a mediator framework supports the data exchange between heterogeneous, autonomous software components. Compared to Beach these mediators are represented as fully-fledged components. On the one hand more sophisticated semantic transformations are describable, but on the other hand the development is more complex. The aim of their approach is the possible customization facility of mediators in order to enhance the reusability. Because mediators can be composed, richer transformations are feasible. Preece et al. [11] introduce an agent-based mediator platform. In their attempt databases, integration entities, and users are represented by independent agents. Semantic mismatches are resolved by a common ontology where the local databases have to map their knowledge to. An interesting part of their architecture is a agent facilitator which acts as a kind of yellow pages service. Agents can register themselves with their capabilities with respect to the shared ontology. After that, other agents can query this facilitator to retrieve suitable agents for a specific purpose. Advertisement as well as querying is based on a constraint language. Despite its elegance the use of a shared ontology is critical, because not all local data sources can be mapped onto this ontology. That means, that the ontology has to be re-factored several times. Further, we are not convinced, that such common ontology exists at all. In the context of biology this may be slightly different, because several ontologies become de-facto standards, like the GeneOntology (GO). But even there not all concepts of specialized biological questions are documented. A brief overview of existing (biological) ontologies can be found in [8].
3
Characterization of mediators
In this section we specify the characteristics of mediators in general and define a mediator model wherein both views are reflected. One important part will be the introspection mechanism which is addressed by a special ontology-based profile. This profile is subject of section 4. In our context introspection means that someone (user or machine) can explore features of a previously unknown mediator. In general, mediators designate a transformation unit which acts as a broker (mediate) between independent and autonomous services. These services are often heterogene, providing different data structures and semantics as well as request facilities. Moreover, the mediation process should be executed implicitly as far as possible. In order to do not reinvent the wheel several times for a specific mediation step, it is crucial to support the reusability of mediators even for non specialists. To achieve this mediators have to provide several features. Adaptability, i.e. customization for a specific aim, is one relevant feature to reuse software modules. Platform and system independence is another important factor to accomplish this goal. Before we go into more detail, we can in principle observe two different classifications of mediators: The first classification divides them into syntactic and semantic adapting 5
transformation units. The former class is related to the view concept in database management systems. According to the internet and XML-based data representations prominent languages to realize these mediators are XPath in combination with XSLT and XQuery. The mediators of the second class have to overcome semantic mismatches. Their realization can often be more complex, thus a pure XML-bases approach is not suitable. Assume for instance the GenScan algorithm of Burge and Karlin [3] explained in the introductive example. This may be a mediator which translates DNA sequences into genes without introns. (The customization of this mediator may result in the specification of a species for which the algorithm is trained before.) The second classification which is orthogonal to the first one, assigns mediators to a domain specific class versus a domain unspecific class. That means some mediators can be useful in several domains, like an unit converter, whereas other are only valuable in a specific context, for instance a splicing mediator. In order to allow users or more intelligent systems adapting mediators to their specific needs, one requires a suitable introspection mechanism. This is true, because the mediator functionalities and the effects of customizing them are previously unknown. The introspection mechanism has to provide not only syntactical information but also semantic information of the capabilities of a concrete mediator. Further, the presented information has to be processable by end users and machines (as far as possible). The interface description of the introspection as well as the representation of the capabilities should use standardized protocols in order to be available on different systems. We divide the capabilities of a mediator into two parts, properties and functionalities. The former are used to modify and customize the latter according to specific needs. Standardized Mediator Interface
Specific Mediator Interface
100 high
% intuitive usage
0
% reuse
100
high
Properties Mediator Profile Functionalities low interface
unspecific
low 0
specific
complexity of adaption
context dependency
Figure 2: Component-based mediator model (left) and level of reuse versus intuitive usage (right).
Figure 2 (right) displays the forces pulling on the degree of reuse versus the degree of intuitive usage (based on Szyperski et al. [17]). These forces encompass basically the context dependency and the complexity of adaption of a concrete mediator. Let us consider two extreme representatives: A general XML document transformation unit, that takes as input an XML document and returns as output a new XML view of the given input document. The customization of this mediator may be a document in a concrete language like XQuery or Java-Script. Thus, this mediator will be positive characterized by its universal reusability and weak context dependency. But on the other hand, the adaption is more a programming process which cannot be realized by most end user or systems directly. 6
Hence, its intuitive usage is very restricted. In contrary assume a mediator that transforms data from the Bioinformatic Sequence Markup Language (BSML) into the Genomic Annotation, Visualization and Exchange (AGAVE) format. This mediator is very context dependent which results in a lesser reusability. Due to the fact that its customization is trivial, the intuitive usage is very easy. For the reasons explained above, a developer of a new mediator has to know these tradeoffs and deliberate about them in order to build most reusable and intuitive usable mediators. Further, because the mediation process could be very complex it should be possible to select the programming language based on the requirements of the mediation and not the other way around. Thus, it should be possible to build mediators language independently. That means the developer should be able to use a declarative languages, like Prolog or XQuery, as well as an imperative one, like Java or Perl. Using mediators in a service-centric computing environment unveil new characteristics. In a peer-to-peer service landscape it is reasonable to allow mobile or remote accessible mediators. On the one hand, mobility has the advantage that mediators can be executed in situ. Whereas on the other hand, remote accessibility permits mediators, which require a specific resource that is not available on every system. Note, however, if a mediator is developed by a third party and reused by somebody else, there are of cause security issues to be considered, but these orthogonal topics are not subject matter of this paper. Figure 2 (left) sketches the component-based model of a mediator. The darker section illustrates the general and unspecific part of the mediator. The lighter portions describe the specific capabilities of a concrete mediator, that means its realization. We propose WSDL as interface definition language for a concrete interface, because it is the current language used for defining web services. In this way it is possible to build new mediators by reusing previously existing algorithms which are realized as web services before. Mobility and support of different languages can be easily achieved by defining new bindings within WSDL documents. For a smooth transition from available algorithms and services into mediators, the general interface has to be simple as far as possible. In our model every mediator has just to provide a single operation within the port type definition of its WSDL document. This operation makes the concrete profile available: MediatorProfile getProfile(). In the next section we identify the information, a mediator profile has to provide. We further describe a mediator registry that directly benefits from such profiles.
4
Mediator profile and registry
The profile of a mediator has to offer network information in order to locate and execute the concrete mediator. Further, it has to make its intentional content available. This content should be processable by humans as well as by machines. On the one hand it should provide an abstract representation of the functionalities and properties, that means is interface. On the other hand, the content should supply applications and users with semantic knowledge. For instance, relationships to concepts of a common ontology have to be defined. We have decided to take an ontology-bases representation of the mediator profile. This allows us to take care of both syntactic and semantic information. The upper ontology, i.e. the ’schema’ of the profile, is illustrated in figure 3. In reality this ontology is declared 7
Thing
String
1 Thing
1
rangeOf
1
String
parameterName
1
hasConcept
textDescription
Parameter
Parameter
PropertyEffect textDescription
Parameter
n n
1
effectOn
propertyEffect
String
String
parameter
n outputParameter
n
MediationEffect
inputParameter
1
1
mediationEffect
1
textDescription
MediatorFunctionality MediatorProperty n
n propertyName
mediatorFunctionality
mediatorProperty
functionName
textDescription
1
1 String
1
String
String
MediatorProfile mediatorName
String
mediatorCategory
wsdl
1
developerInformation
textDescription
1
1
ServiceCategory
1 1
String
Actor
anyURI
Figure 3: Upper ontology of mediator profile.
in an XML dialect, called DAML+OIL. This makes the profile utilizable for humans and machines. At present, the DAML+OIL language is in a standardization process by the World Wide Web Consortium. In the center of the description is the MediatorProfile concept. This concept includes general information of the mediator like the developer information, the mediator name and the connection to the concrete WSDL document. Further, it provides information of the capabilities: MediatorProperty and MediatorFunctionality. The Parameter concept of a capability contains syntactic as well as semantic knowledge. The syntactic information is included by the rangeOf and parameterName relation. The more interesting semantic knowledge is encoded by the hasConcept relation. This points to a concept or instance of a concrete ontology, for instance into the GO. The concepts Actor and ServiceCategory are based on concepts of the DARPA Agent Markup Language - Services (DAML-S). We give a brief example of a gene prediction mediator. A strip down version of the profile is shown in figure 4: it shows a mediator functionality which is specified by its function name, input parameters, output parameters, and mediation effect. The inputs expected by the mediator are restricted to instances of the DNA concept as it is defined in a hypothetical biological ontology (BioOnt.daml). Currently, the mediation effect is specified only in textual manner, but can be enhanced if a commonly used ontology for biological effects is available. The mediator profiles can be applied in several contexts. For instance they can be used for introspection, for generating port type information of the WSDL document, or for advertising and retrieval of concrete mediators. The latter aspect will be briefly discussed.
8
predictGene Predicts a gene ... dnaSequence Genomic DNA. ... ... The biological effect of this mediator is the ...
Figure 4: Part of a profile for advertising a gene prediction mediator.
Mediator registry A mediator registry which acts as a kind of yellow pages service for mediators can use the profiles firstly for advertising new mediators and secondly for retrieving them in a cooperative manner. That means, retrieval processes use the same upper ontology to specify queries which depict the concrete needs of a mediator. The mediator registry we introducing here encompass three related information pools. The first pool stores information of the web services which take part in a concrete user-defined biological business process. Among other things their port type definitions are saved. The relationships between these services give evidence of ’semantic’ links, because they are specified by the user in the business process. These links are stored in the second pool. Further, this pool maintains the mediators needed to bridge the semantic and syntactic gaps as well as their property settings. Finally, the last pool contains the advertised mediator profiles. An algorithm for retrieving mediators in a mediation process is illustrated in figure 5. Parts of this algorithm are currently work in progress. The algorithm examines the concrete web services composition and identifies the web service activities which take part. Every new activity will be registered within pool_A. After that the registry searches for existing relationships between components of the composition in pool_B. For existing one the defined mediators and their property settings are loaded. If the relationships are not existing in pool_B they are inserted. The information of the 9
mediation(serviceComposition) { forall wsOp in serviceComposition do { wsOp not in pool_A then add wsOp to pool_A } forall l in links(wsOp1, wsOp2) of serviceComposition do { if l in pool_B then mediators = getCustomizedMediators(l) else { add l to pool_B MediatorProfile q = createQuery(l) mediators = retrieveMediators(q) customize(mediators) add mediator settings to pool_B } } }
Figure 5: Algorithm for retrieving mediators in a mediation process.
related web services are used to create a query mediator profile. That means, the algorithm tries to identify concepts in a common ontology (like GO) with respect to the port type information of the services. For retrieving the mediators we try to adapt the algorithm presented in Paolucci et al. [10]. This part of the algorithm works on pool_C. If no hits are found the user has to browse pool_C or has to specify a query profile oneself, perhaps in a cooperative or interactive way. Last but one the user has to customize the mediators. Finally, these information are stored within pool_B.
5
Conclusion and future challenges
In conclusion, the heterogeneity of data models, structures and working processes cannot be standardized, they stay individual with respect to local demands. Thus, we have proposed a mediator concept which simplifies or standardizes the interoperation process. Our concept supports adaptability and reusability of developed mediators. It does not restrict biologists by using only a special computing platform, but allow them to select a platform with regard to their specific requirements. Due to the fact that we separate the biological business process from the mediation process, users can focus on their core business. Primarily, the system should be responsible for the mediation process. Ontology-based mediation is of growing importance in the field of interoperability, particularly in computational biology. The presented registry is a first step on the track to smart mediation.
Acknowledgement We would like to thank Gabriele Witterstein and J¨org Zimmermann for their comments on an earlier draft of this paper and their good discussions on topics of biology and artificial intelligence. 10
References [1] Andreas D. Baxevanis. The molecular biology database collection: 2003 update. Nucl. Acids Research, 31(1):1–12, January 2003. [2] B. W. Beach. Connecting software components with declarative glue. In Proceedings of the 14th International Conference on Software Engineering (ICSE), pages 120–137, Melbourne, Australia, May 11-15 1992. ACM Press. [3] Christopher B. Burge and Samuel Karlin. Finding the genes in genomic DNA. Curr. Opin. Struct. Biol., 8:346–354, 1998. [4] M. J. Carey, L. M. Haas, P. M. Schwarz, M. Arya, W. F. Cody, R. Fagin, M. Flickner, A. W. Luniewski, W. Niblack, D. Petkovic, J. Thomas, J. H. Williams, and E. L. Wimmers. Towards heterogenous multimedia information systems: The Garlic approach. In Proceedings of the International Workshop on Research Issues in Data Engineering, pages 161–172, March 1995. [5] S. Chawathe, H. Garcia-Molina, J. Hammer, K. Ireland, Y. Papakonstantinou, J. Ullman, and J. Wisom. The TSIMMIS project: Integration of heterogeneous information sources. In Proceedings of IPSJ Conference, pages 7–18, Tokyo, Japan, October 1994. [6] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley, 1995. [7] A. A. Kanapin, W. Fleischmann, and R. Apweiler. Integration of biological databases: the example of interpro. In Nadia El-Mabrouk, Thomas Lengauer, and David Sankoff, editors, Currents in Computational Molecular Biology (RECOMB 2001), pages 227–228, Montreal, Canadia, 2001. Les Publications CRM. [8] Jacob K¨ohler and Steffen Schulze-Kremer. The Semantic Metadatabase (SEMEDA): Ontology based integration of federated melocular biological data sources. In Silico Biology, 2(0021), March 19 2002. [9] Felix Naumann and Ulf Leser. Cooperative query answering with density scores. In Proceedings of the Conference on Management of Data (COMAD 00), Pune, India, 2000. [10] Massimo Paolucci, Takahiro Kawamura, Terry R. Payne, and Katia Sycara. Semantic matching of web services capabilities. In First International Semantic Web Conference (ISWC), Sardinia, Italy, June 2002. [11] Alun D. Preece, Kit Ying Hui, W. A. Gray, P. Marti, Trevor J. M. Bench-Capon, D. M. Jones, and Zhan Cui. The KRAFT architecture for knowledge fusion and transformation. Knowledge Based Systems, 13(2-3):113–120, 2000. [12] Xiaolei Qian and Teresa F. Lunt. Semantic interoperation: A query mediation approach. Technical Report SRI-CSL-94-02, Computer Science Laboratory, SRI International, April 1994. [13] Uwe Radetzki, Sascha Alda, Thomas Bode, and Armin B. Cremers. First steps in the development of a web service framework for heterogeneous environmental information systems. In W. Pillmann and K. Tochtermann, editors, Proceedings of the 16th International Conference Informatics for Environmental Protection (EnviroInfo), volume 1, pages 384–391, Vienna, Austria, September 25-27 2002. ISEP.
11
[14] Uwe Radetzki, Thomas Bode, Gabriele Witterstein, Melanie Gnasa, and Armin B. Cremers. A service-centric computing environment for heterogeneous biological databases and methods. In Currents in Computational Molecular Biology (RECOMB 2003), Berlin, Germany, April 2003. in press. [15] Uwe Radetzki, Gabriele Witterstein, and Armin B. Cremers. An Integration Platform for Heterogeneous Services in Life Science Applications. In Workshop on Bioinformatics - 8th International Symposium on Methodologies for Intelligent Systems (ISMIS), Lyon, France, June 26 2002. [16] Sergey Shumilov, Andreas Thomsen, Armin B. Cremers, and Bj¨orn Koos. Management and visualization of large, complex and time-dependent 3D objects in distributed GIS. In Proceedings of the 10th International Symposium on Advances in Geographic Information Systems, McLean, USA, November 2002. [17] Clemens Szyperski, Dominik Gruntz, and Stephan Murer. Component Software: Beyond Object-Oriented Programming. Component Software Series. ACM Press, Addison-Wesley, second edition, 2002. [18] Gio Wiederhold. Mediators in the Architecture of Future Information Systems. IEEE Computer, 25(3):38–49, March 1992. [19] Gio Wiederhold. Mediation to Deal with Heterogeneous Data Sources. In Proceedings of Interoperating Geographic Information Systems, Second International Conference, Interop’99, volume 1580, pages 1–16, Zurich, Switzerland, March 1999. Springer LNCS. [20] Ling-Ling Yan, M. Tamer Oezsu, and Ling Liu. Accessing heterogeneous data through homogenization and integration mediators. In Proceedings of the Intern. Conference on Cooperative Information Systems (CoopIS), pages 130–139, Kiawah Island, North Carolina, 1997. [21] Evgeni M. Zdobnov, Rodrigo Lopez, Rolf Apweiler, and Thure Etzold. The EBI SRS serverrecent developments. Bioinformatics, 18(2):368–373, 2002.
12
