Your SlideShare is downloading. ×
  • Like
Semantic Web Services for Computational Mechanics : A Literature Survey and Research Proposal
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Semantic Web Services for Computational Mechanics : A Literature Survey and Research Proposal


Issue Date: Nov-2003 …

Issue Date: Nov-2003

Type: Technical Report

Publisher: Asian Institute of Technology


Published in Education , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. SEMANTIC WEB SERVICES FOR COMPUTATIONAL MECHANICS by Thiti VacharasintopchaiA dissertation proposal submitted in partial fulfillment of the requirements for the degree of Doctor of Engineering Examination Commitee: Dr. William Barry (Chairman) Prof. Worsak Kanok-Nukulchai Prof. Vilas Wuwongse Dr. Voratas Kachitvichyanukul Nationality: Thai Previous Degrees: B. Eng. (Civil Engineering) Chulalongkorn University Bangkok, Thailand M. Eng. (Structural Engineering) Asian Institute of Technology Bangkok, Thailand Scholarship Donor: Royal Thai Government Followship Asian Institute of Technology School of Civil Engineering Thailand November 2003 i
  • 2. ii
  • 3. TABLE OF CONTENTSChapter Title Page Title Page i Table of Contents iii List of Figures v List of Tables vii 1 Introduction 1 1.1 Background 1 1.2 Problem Statement 4 1.3 Objectives 4 1.4 Scope 5 1.5 Research Approach 5 1.6 Contributions 5 2 FEM and the Need towards Distributed Computing 7 2.1 Formulation of the Finite Element Method 7 2.2 Parallel Computing and Applications in Computational Mechanics 10 2.3 Towards an Application of Distributed Computing Technique 10 3 Distributed Computing 13 3.1 Distributed Computing Concepts 13 3.2 Methods of Problem Decomposition 13 3.2.1 Data Distribution 13 3.2.2 Algorithmic Distribution 14 3.2.3 Load Balancing 16 3.3 Applications in Scientific Computing 16 3.3.1 SETI@home Project 17 3.3.2 Grid Computing 18 4 Web Services 21 4.1 The Web Services Architecture 21 4.2 Applications of Web Services in Scientific Computing 23 5 The Semantic Web 25 5.1 General 25 5.2 Resource Description Framework (RDF) 28 5.2.1 Introduction 28 5.2.2 An RDF Statement 28 5.2.3 Identification of Resources 28 5.2.4 The RDF Model 28 5.2.5 Defining RDF Vocabularies 29 5.3 DAML+OIL 31 5.4 DAML-S: Semantic Markup for Web Services 36 5.5 Inferences – Making Use of Resources and Ontologies 38 6 XML Declarative Description 41 6.1 Declarative Description Theory 41 iii
  • 4. 6.1.1 Specialization Systems 41 6.1.2 Declarative Descriptions 42 6.1.3 Semantics of Declarative Descriptions 42 6.1.4 Equivalent Transformations 43 6.2 XML Declarative Description 44 6.2.1 XML Elements and XML Expressions 44 6.2.2 Formulation of XML Declarative Description 45 6.2.3 XML Equivalent Transformation 46 6.3 Ontology Modeling and Inference with XDD 497 Methodology 55 7.1 A Semantic Web Services Framework for Computational Mechanics 55 7.2 An Overview of the Research Tasks 58 7.3 Infrastructure Design and Development 58 7.3.1 Construction of Domain Ontologies 58 7.3.2 Construction of Ontology Mapping Facilities 59 7.3.3 Construction of Service Enactment Facilities 62 7.4 Application Web Services Development 63 7.4.1 Design of XML Schemas and Ontologies 65 7.4.2 Construction of DAML-S Ontology Instances and WSDL Documents 65 7.4.3 Implementation and Deployment of Application Web Services 66 7.5 Illustrative Applications of the Framework 66 References 83 Index 91 iv
  • 5. LIST OF FIGURESFigure Title Page 3.1 Problem Decomposition: Data Distribution 14 3.2 Problem Decomposition: Algorithmic Distribution 15 3.3 Problem Decomposition: Hybrid Distribution Method 1 15 3.4 Problem Decomposition: Hybrid Distribution Method 2 16 3.5 Model of the NASA X-38 Crew Return Vehicle (Barnard et al., 1999) 19 3.6 Mach Contours for the X-38 Crew Return Vehicle (Barnard et al., 1999) 19 4.1 Conceptual Web Services Model (Basha et al., 2002) 22 4.2 Roles of SOAP, WSDL and UDDI in Web Services Architec- ture (Basha et al., 2002) 23 5.1 Example of an HTML Document 26 5.2 HTML Document in Figure 5.1 as Rendered on a Web Browser 26 5.3 Example of an RDF Description 27 5.4 A Simple RDF Statement (adapted from W3C, 2003b) 29 5.5 Several RDF Statements about Resources (adapted from W3C, 2003b) 30 5.6 A Vehicle Class Hierarchy (adapted from W3C, 2003b) 31 5.7 An RDF/XML Encoding that Corresponds to Figure 5.6 (W3C, 2003b) 32 5.8 An Instance of a Class Defined in Figures 5.6 and 5.7 (W3C, 2003b) 32 5.9 Definition of Properties Corresponding to Classes in Figures 5.6 and 5.7 (adapted from W3C, 2003b) 33 5.10 An Instance of a Class using Properties Defined in Figure 5.9 (W3C, 2003b) 34 5.11 An Example of daml:Restriction Construct 36 5.12 Upper Levels of DAML-S Ontology (DAML-S, 2003b) 39 5.13 Semantic Web Stack Diagram (W3C, 2002) 40 5.14 Definition of XML Namespace 40 6.1 Typical Structure and Syntax of an XET Program (Anutariya et al., 2002) 48 6.2 XDD Description Modeling the Ontology Definitions of Class Person (Suwanapong, 2001) 50 6.3 XDD Description Modeling the Ontology Instances of Class Person (Suwanapong, 2001) 50 6.4 XDD Description Modeling the Ontology Axiom daml:inverseOf (Suwanapong, 2001) 51 6.5 An XET Program Corresponding to the XDD Descriptions in Figures 6.2 to 6.4 (Part 1 of 2) 52 6.6 An XET Program Corresponding to the XDD Descriptions in Figures 6.2 to 6.4 (Part 2 of 2) 53 6.7 Information Derived from the XDD Descriptions in Figures 6.2 to 6.4 (Suwanapong, 2001) 54 v
  • 6. 7.1 An Overview of the Proposed Semantic Web Services for Com- putational Mechanics Framework 677.2 The Multi-tier System Architecture adopted in the SWSCM Framework (adapted from Cyran, 2002) 687.3 Example of a Material Ontology 697.4 The DAML-S Ontology 707.5 A Service Profile Hierarchy for Computational Mechanics Ap- plication Web Services 717.6 A Hierarchy of Matrices Involved in Computational Mechanics 717.7 DAML-S Ontology Instance Describing Matrix Inversion Service 727.8 DAML-S Ontology Instance Describing Ma- trix Inversion Service 727.9 DAML-S Ontology Instance Describing Matrix Inversion Service 737.10 DAML-S Ontology Instance Describing Matrix Inversion Service 737.11 WSDL Description of a Matrix Inversion Web Service by Num- (adapted from Sintopchai et al., 2003) (Part 1 of 2) 747.12 WSDL Description of a Matrix Inversion Web Service by Num- (adapted from Sintopchai et al., 2003) (Part 2 of 2) 757.13 Model of a Structure to be Analyzed by a Structural Analysis Agent 767.14 Example of an Input Data that Represents the Model in Fig- ure 7.13 (Part 1 of 2) 777.15 Example of an Input Data that Represents the Model in Fig- ure 7.13 (Part 2 of 2) 787.16 DAML-S Ontology Instance Describing Finite Element Ser- vice by Structural Analysis Agent B 797.17 Preliminary Schedule for the Proposed Research Tasks 80 vi
  • 7. LIST OF TABLESTable Title Page 5.1 Comparison between RDF(S) and DAML+OIL (DAML, 2002) 34 6.1 Definition of the XML Expression Alphabet (Wuwongse et al., 2000) 45 6.2 Definition of the Basic Specialization Mapping Operator νX (Wuwongse et al., 2000) 47 7.1 Examples of Mathematical and Physical Ontologies Related to Key Operations in Computational Mechanics 60 7.2 Examples of Conceptual Ontologies Related to Key Opera- tions in Computational Mechanics 61 7.3 Examples of Axioms Related to Key Operations in Computa- tional Mechanics 61 7.4 Summary of Matrix Inversion Service Profiles in Figures 7.7 to 7.10 63 7.5 Preliminary List of Application Web Services to be Developed 64 7.6 Expenditure Estimates for the Proposed Research 81 vii
  • 8. viii
  • 9. CHAPTER 1 INTRODUCTION1.1 Background In performing the analysis of structures using numerical methods, computers mustbe closely guided by human users. For example, consider the case of finite element anal-yses, at first we have to examine a real world problem and model it as a problem domainand boundary conditions subjected to applied forces. We may have to consult many designcodes or experimental results to obtain the forces for the analysis. Next, we have to discretizethe problem domain, either manually or through the help of automatic meshing software be-fore letting the computer compute and assemble the element stiffness matrices, apply theboundary conditions and solve for nodal solutions. We also have to use our experience andjudgment to select the element types and the constitutive models for the material and problembeing considered, examine the accuracy of the analysis results and, if necessary, repeat theentire process to obtain accurate results. Moreover, for large and complex analyses, runningan entire process may take hours or days and special visualization techniques such as ani-mating graphics or virtual reality may be needed to effectively interpret the analysis results.This situation may be more complicated in the case that there exist incompatibilities betweeninput and output data format of software components employed, and may be tedious, take alot of time, and lead to inaccurate analyses if performed by inexperienced users. Solutions are available to improve the performance and user-friendliness of structuralanalysis software. One could be modifying or inventing a new formulation of the analysismethod. Another could be using computer technologies to improve computing performanceand the interaction between computers and users. One example of the former is the develop-ment of meshless methods such as the element-free Galerkin method (EFGM) (Belytschkoet al., 1994) which is an analysis procedure that avoids the need for meshing by employinga moving least-squares technique (Lancaster and Salkauskas, 1981) in approximating thefield quantities of interest. An example of the latter is the application of parallel computingtechniques into the finite element analysis procedure, cf. Adeli and Kamal (1993) and Ya-gawa et al. (1991), so that complex analyses are performed in shorter time. Improvementof user-friendliness in structural analysis software may come at the cost of an increase incomputational requirement, thus in some cases combination of the two solutions is also con-sidered. For example, a parallel computing technique was employed to make analyses usingEFGM analyses more practical to users (Barry and Vacharasintopchai, 2001b). Distributed computing technologies, in particular, Web Services (W3C, 2003d) andthe Semantic Web (Berners-Lee et al., 2001), are available in computer science to help unifyand utilize the scattered resources, such as personal computers, clusters, supercomputers,databases or knowledge-bases, and can be applied in structural engineering to make numer-ical analysis of structures performed in a fast, accurate and more automated manner. WithWeb Services and the Semantic Web, we wil not have to be actively involved in the analysesby feeding the computers all the data and elaborate instructions, but instead be involved in aless active way by giving simple instructions to the computers, watching them work for us,and making a final decision on the results. With the advent of high-speed networks and thematurity of researches in artificial intelligence, the Internet is not just a hyper-library for usto search for information nor a communication tool for us to send emails or messages. Wecould use the Internet as a very large platform for scientific computations with the help ofintelligent software agents that collaborate to accomplish a given task. Web Services and the Semantic Web, two technologies built on top of the Internet, 1
  • 10. are technologies that “will transform the web from a collection of information into a dis-tributed computational device” (Fensel and Bussler, 2002). Web services are a new breedof Web application that enables collaboration on the Web. They are self-contained, self-describing, modular applications that can be published, located, and invoked across the Web.Web services perform functions, which can be anything from simple requests to complicatedprocesses. Once a Web service is deployed, other applications (and other Web services) candiscover and invoke the deployed service (Tidwell, 2000). The Semantic Web, on the otherhand, is a technology that enables computers accessing data on the Web to be intelligent. Upto now, the World Wide Web has developed rapidly as a medium of documents for peoplerather than of information that can be manipulated automatically by computers. By augment-ing Web pages with data targeted at computers and by adding documents designed solely forcomputers, the Web will be transformed into the Semantic Web where computers can find themeaning of semantic data by following hyperlinks to definitions of key terms and rules forreasoning about them logically (Berners-Lee et al., 2001). The combination of Web Servicesand Semantic Web technologies, termed Semantic Web Services (McIlraith et al., 2001), willenable automated discovery, execution, composition, and interoperation of web services toaccomplish any tasks requested by human users. Automation is not achieved by humanshard-coding programs into software agents but rather by the agents themselves through rea-soning processes that lead to understanding. Such reasoning and automated operation arebased on ontologies, which are the formal, explicit specifications of shared conceptualiza-tions of the world (Broekstra et al., 2002) and, like web pages, can be individually publishedand linked to other ontologies across the Internet. In terms of numerical analysis of structures, Semantic Web Services may be appliedto assist human users in the analysis and design of structures as in, but not limited to, thefollowing scenario: • At first one examines a real world problem, defines the problem domain for the analy- sis, and inputs the data as well as important analysis keywords into a structural analysis software agent, which is a web service that performs analysis of structures on behalf of human users or other agents. The keywords may be related to material types such as mild steel, aluminum, reinforced concrete or ASTM1 A36 steel, material charac- teristics such as linear elastic, elastoplastic, viscoelastic, or viscoplastic, modes of analysis such as static, dynamic, buckling, or fracture, or boundary conditions such as cantilever, simply-supported, three-edge fixed supported, building codes such as the Uniform Building Code (UBC) and the National Building Code (NBC), and design specifications such as the American Institute of Steel Construction (AISC) specifica- tions, the American Concrete Institute (ACI) specifications, and the British Standards (BS) specifications. • Next, the agent consults its ontology to understand the user’s request and construct a set of problem parameters to perform an analysis. For example, if the user instructs the agent to find the maximum service stresses of an ASTM A36 steel plate with dimen- sions of 1.00 m wide by 200 cm long with a quarter inch thickness simply supported on all edges and subjected to the residential floor live load spec- ified in the latest version of UBC code, 1 American Society for Testing and Materials 2
  • 11. the agent would consult its ontology to identify the parameters required for a typical stress analysis, which are the nodal coordinates, modulus of elasticity, Poisson’s ratio, vector of applied forces, and boundary conditions, and then prepare the parameters to perform the analysis accordingly. Specifications of the boundary conditions, i.e. simply-supported, are available in the boundary condition ontology. Specifications of the design live load, i.e. UBC residential live load on floors, are available in the building code ontologies accessible to the agent. In the same manner, modulus of elasticity, yield stress, and ultimate strength of the ASTM A36 steel are also specified in the ASTM standard material ontology. If the keywords used in the building code ontologies or material ontologies are different from the ones that the agent knows, the agent can infer from the ontologies that define those keywords and identify the one that specifies the parameter needed. Differences among units of measurements, i.e. meters, centimeters and inches, will also be arbitrated since the agent can identify meters, centimeters, and inches as units of lengths and consult the measurement ontology.• The agent would consult its process ontology and understand that maximum stresses in typical analyses can be derived from nodal displacement solutions obtained by a finite element analysis. Inferences on the process ontology also suggests the agent that, to perform a finite element analysis, it needs to discretize the problem domain, which, in this case, is the geometry of the plate given by the user, into a mesh consisting of a number of nodes and their connectivities. After discretization, it needs a global stiff- ness matrix, which is constructed by assembling the element stiffness matrices derived from nodal coordinates and material properties, and a global force vector, which is constructed by assembling the element force vectors derived from nodal coordinates and specifications of forces, including the live load it obtained from the building code ontology.• The agent would consult the process ontology further that once it obtains the global stiffness matrix and the global force vector, it needs to set up a linear system of equa- tions, apply the boundary conditions obtained from the boundary condition ontology, and solve the system of equations to obtain the vector of nodal displacements. It then needs to find the derivatives of the nodal displacements to obtain stresses in the plate and search for the maximum values of stresses as requested by the human user.• During the analysis, the agent is aware that it cannot solve the linear system of equa- tions nor search for the maximum values of stresses efficiently because the agent was originally designed to solve some other types of problems. Therefore, it seeks the help of other agents. It starts by making a request to a service registry for a list of available software agents that offer solutions to linear system of equations and the ones that can identify maximum values from a list of given floating point numbers. The service reg- istry would return to the agent the requested list which includes the estimated time to get results from the agents, the characteristics of the input, e.g. dense matrices, sparse matrices, banded matrices, and the formats of input and output data. The agent would consult the list, reason and select the best third-party agent for each operation, prepare the suitable input data for each agent, request them to perform the computations on its behalf, convert the results back to its own format, and utilize the results in its struc- tural analysis procedure in the same manner as it would do with the results from its own subroutines. 3
  • 12. 1.2 Problem Statement Semantic Web Services, which is the combination of Web Services and the SemanticWeb technologies, can be used to improve the performance and user-friendliness of structuralanalysis software as well as the collaboration among them by enabling intelligent agent-based analyses of structures in a parallel and distributed manner. The realization of such aparadigm with an example described at the end of Section 1.1 involves issues in the followingareas: 1. Representation of knowledge in scientific computing and structural engineering 2. Modeling of structural analysis processes such as the processes in the finite element methods or meshless methods 3. Description of software agents for automatic discovery and delegation of analysis tasks 4. Design of languages and mechanisms for communications among software agents 5. Design of the services registry broker to support automatic discovery and collaboration of software agents. Knowledge and tools in structural engineering and computer science, and in par-ticular, computational mechanics and artificial intelligence, are required in this study. Theformer are required to construct ontologies in scientific computing and structural engineeringas well as to model structural analysis processes. The latter are required to properly designand construct the ontologies as well as to reason on them.1.3 Objectives The primary objective of this study is to construct and implement a framework for auser-friendly intelligent structural analysis paradigm that enables collaboration of structuralanalysis software agents on sequential and parallel computers by means of the Semantic WebServices technology. To fulfill the primary objective, the following secondary objectives areto be achieved: 1. To capture and construct the domain ontologies in scientific computing and structural engineering, which include (a) the ontology on quantities such as scalars, vectors, matrices, tensors and the op- erations on them (b) the ontology on measurements such as lengths, forces, masses and the conver- sions between different units such as SI units and US customary units (c) the ontology on material properties such as strength properties and elastoplastic or viscoplastic properties (d) the ontology on geometric properties such as those of points, lines, triangles, rectangles, boxes, and tetrahedra. (e) the ontology in computational mechanics domain such as nodes, displacements, stresses, strains, and boundary conditions. 4
  • 13. 2. To capture and construct the process ontologies in computational mechanics such as discretization, formulation of shape functions, formulations of element stiffness ma- trices and their assembly, applications of the boundary conditions, solutions of the system of equations, and calculations of stresses and strains 3. To examine and apply available techniques in computer science, which include de- scriptions of software agents, agent communication languages, and services registry brokering, to create a mechanism that enables automatic discovery and collaboration among the structural analysis software agents. 4. To demonstrate and evaluate the usability of the framework by implementing the pro- posed components and applying them to selected classes of analysis problems.1.4 Scope The goal of this study is to propose a framework for Semantic Web Services in com-putational mechanics and to provide an implementation to demonstrate its usability. Thestudy will involve semantic collaboration of structural analysis software agents located onsequential and parallel computer clusters on the Internet to solve problems in linear elasticityand elastoplasticity. The SI and the US customary units of measurements, loadings from theUBC building code, load factors from ACI and AISC structural design manuals, and materialproperties specified in ASTM standards will be supported in the implementation by means ofontologies. In the computer science aspect, networking security issues will not be taken intoaccount. Implementation of the software components will utilize efficient and appropriatealgorithms. However, exhaustive searches and uses of the most optimal ones will be of lessconcern.1.5 Research Approach Semantic Web Services is an area in the Extensible Markup Language (XML) (Brayet al., 2000; Fallside, 2001; Thompson et al., 2001; Biron and Malhotra, 2001) family of tech-nologies. Therefore, all software components that comprise the structural analysis agents andthe services registry broker will be based on state-of-the-art XML technologies and will beimplemented in the Java programming language which is the prevalent programming lan-guage among the XML community. The Message-Passing Interface (MPI) software library(MPI, 1995) for parallel programming will be used in the implementation of the softwarecomponents on parallel computer clusters. Modeling of processes, representation of knowl-edge, and inference capabilities of the software agents will be by means of XML DeclarativeDescription (Wuwongse et al., 2001) and XML Equivalent Transformation (XET) (Anutariyaet al., 2002), which are a unified modeling language for the Semantic Web and the associatedcomputation and inference engine, respectively.1.6 Contributions This study will try to improve human-to-machine and machine-to-machine collabora-tion on structural analysis problems across the Internet using Web and artificial intelligencetechnologies. The result of this study will be a framework that turns the Internet into alarge platform for numerical analysis of structures where distributed software agents or webservices individually developed and located on heterogeneous computer platforms, e.g. per-sonal computers, parallel computer clusters, and supercomputers, with different specializa- 5
  • 14. tions can cooperate on analysis tasks in a unified manner using the shared conceptualizationsdefined by ontologies. This framework would improve knowledge sharing and collaborationamong researchers and implementors in structural engineering field. It may be further linkedwith other works in the Semantic Web and Web Services research and commercial areas,thus making numerical analysis of structures more accessible and applicable to the public. 6
  • 15. CHAPTER 2 FEM AND THE NEED TOWARDS DISTRIBUTED COMPUTING2.1 Formulation of the Finite Element Method The finite element method (FEM) is a numerical procedure for analyzing structuresand continua. Usually the problems addressed are too complicated to be solved satisfactorilyby classical analytical methods. The finite element procedure produces many simultaneousalgebraic equations, which are generated and solved on computers ranging from personalcomputers to mainframe and super computers (Cook et al., 1989). The formulation of typical displacement-based finite element methods from Cooket al. (1989) is presented in this section. In the displacement-based finite element method,displacements are taken as the dependent variables with the total potential energy of a bodyΠ p as the associated functional. An admissible displacement field is defined in a piecewisefashion such that displacements within any elements are interpolated from nodal degree offreedoms (d.o.f.) of that element. The total potential energy functional is then evaluated interms of nodal d.o.f. Using the principle of stationary potential energy, we write dΠ p = 0 andobtain a simultaneous system of algebraic equations to be solved for nodal d.o.f. Detailedderivation of the displacement-based finite element method is as follows: The total potential energy in a linearly elastic body is described as: 1 T Πp = ε E ε − εT E ε0 + εT σ0 dV − uT F dV − uT Φ dS − DT P (2.1) V 2 V Sin which u = u v w T , the displacement field ε = εx εy εz γxy γyz γzx T , the strain field E = the material property matrix ε0 , σ0 = initial strains and initial stresses F = Fx Fy Fz T , body forces Φ = Φx Φy Φz T , surface tractions D = nodal d.o.f. of the structure P = loads applied to d.o.f. by external agencies S,V = surface area and volume of the structure The material property matrices E for isotropic materials are given as (1 − ν)c νc νc   0 0 0  νc (1 − ν)c νc 0 0 0  νc νc (1 − ν)c 0 0 0    E =  (in three dimensions) (2.2a)  0 0 0 G 0 0   0 0 0 0 G 0 0 0 0 0 0 G E E where c = and G = , (1 + ν)(1 − 2ν) 2(1 + ν) 1−ν ν   0 E  ν E= 1−ν 0  (for plane strain conditions), (2.2b) (1 + ν)(1 − 2ν) 1−2ν 0 0 2 7
  • 16. 1 ν   0 E  E= ν 1 0  (for plane stress conditions). (2.2c) 1 − ν2 1−ν 0 0 2E and ν in the above expressions are Young’s modulus of elasticity and Poisson’s ratio,respectively. Displacements within an element are interpolated from element nodal d.o.f. d, u = Nd (2.3)where N is the shape function matrix. For 4-noded plane rectangular bilinear element (2.3) is specialized as   u1    v1      u N1 0 N2 0 N3 0 N4 0   = u2 (2.4) v 0 N1 0 N2 0 N3 0 N4  .  . .     v  4where subscripts 1 . . . 4 respectively denote the first node to the fourth node of the planeelement. For an element of 2a wide by 2b long, each Lagrange’s shape function Ni abovehas the form (a ± x)(b ± y) Ni = (2.5) 4ab For 8-noded solid rectangular trilinear element (2.3) is specialized as    u1      v1         u N1 0 0 N2 0 0 . . . w     1 v =  0 N1 0 0 N2 0 . . . u (2.6)  2 w 0 0 N1 0 0 N2 . . .  .     .   .        w  8where subscripts 1 . . . 8 respectively denote the first node to the eight node of the brick ele-ment. For an element of 2a wide by 2b long by 2c thick, each Ni above has the form (a ± x)(b ± y)(c ± z) Ni = (2.7) 8abc The strains are obtained from displacements by differentiation. Thus ε = ∂u yields ε = Bd, where B = ∂N (2.8) Relation between strains and displacements in the equation above is given in two andthree dimension respectively by ∂  0 0  εx   ∂x ∂     0  εy    0     ∂ ∂y   εx  0  ∂x    0 0 ∂ u    εz   ∂ u εy =  0 ∂y  =  ∂ ∂ ∂z  v  and (2.9)  v γxy   ∂y ∂x 0    γxy ∂ ∂     w γyz    ∂y ∂x   0 ∂ ∂     ∂z ∂y  γzx     ∂ ∂ ∂z 0 ∂x 8
  • 17. Substitution of (2.3) and (2.8) into (2.1) yields 1 numel T numel Πp = ∑ 2 n=1 d n kn d n − ∑ d n ren − DT P T (2.10) n=1where summation symbols indicate that we include contributions from all numel elements ofthe structure. Element stiffness matrix k and element load vector re are derived, respectively,from k= B T EB dV (2.11) Ve re = B T E ε0 dV − B T σ0 dV + N T F dV + N T Φ dS (2.12) Ve Ve Ve Sewhere Ve denotes the volume of an element and Se denotes its surface. In the surface integral,N is evaluated on Se . Every d.o.f. in an element vector d also appears in the vector of global d.o.f. D. Thus,when k and re of every element are expanded to structure size, D can replace d in (2.10).Equation (2.10) becomes 1 Π p = DT K D − DT R (2.13) 2where numel numel K= ∑ kn and R = P+ ∑ re n (2.14) n=1 n=1 Summations indicate assembly of element matrices by addition of overlapping terms.Making Π p in (2.13) stationary with respect to small changes in the Di we obtains ∂Π p =0 (2.15) ∂D KD = R (2.16)Matrix equation (2.16) is a set of simultaneous algebraic equations to be solved for d.o.f. D. From the formulation presented above, the finite element procedure for linear elasticproblems is summarized. Given a description of the problem which consists of a problemdomain, a specification of body forces, surface tractions, initial stresses, initial strains, andprescribed boundary conditions, the problem domain is divided into a finite number of partsor elements identified by nodes and their connectivities. The goal of the displacement-basedfinite element procedure is to obtain the displacement at the nodes D by solving the simulta-neous system of equations (2.16). The global stiffness matrix K and the global load vector inthis equation are assembled from their element counterparts, which are the element stiffnessmatrices and the element load vectors obtained by evaluating Equations (2.11) and (2.12),respectively. The global stiffness matrix K is singular by its nature. It cannot be invertednor can a unique set of nodal displacements D be obtained by solving the equations. Thephysical reason for this is that rigid-body motion is still possible. Without supports, thestructure will float away even if the smallest external load is applied. Thus, prescribed dis-placement boundary conditions are applied to the system of equations after assemblies tomake them solvable. Once the nodal displacements are obtained, strains within an elementare derived from ε = Bd in Equation (2.8). Stresses are obtained by multiplying the strainvector by the corresponding material property matrices E presented earlier. For nonlinearproblems in elastoplasticity, Equation (2.16) becomes K (D) D = R(D) and displacementsare incrementally solved in an iterative manner. 9
  • 18. Accuracy of the finite element methods depends on many factors such as the basisof shape functions used for interpolation, the fineness of discretization of the problem do-main, and constitutive models of the materials. More accurate constitutive models givesmore accurate responses of a structure to given applied loads whereas finer discretizationsand higher order of bases make responses of the structure closer to the ones that would beobtained if it was a continuum. For large and complex analysis problems such as nonlinearanalyses of three dimensional bodies, the increased accuracy may come at the expense of asignificantly increase in analysis time, which could be hours or days. Thus, techniques fromcomputer science such as parallel and distributed computing are often applied to improve theperformance of computer-aided structural analyses. The next sections present an overviewof parallel computing technique and a discussion which leads to the need for an applicationof distributed computing techniques in structural engineering.2.2 Parallel Computing and Applications in Computational Mechanics Parallel computing is a field in computer science that deals with how to accomplisha task faster by dividing it into a set of subtasks assigned to multiple workers (Kumar et al.,1994). It differs but is closely related to distributed computing which is the field that dealswith techniques to spread a computational task across several programs, processes or pro-cessors (Brown, 1994). Distributed computing is mainly concerned with problems such asreliability, security, and heterogeneity which are generally regarded lightly in parallel com-puting, however, the basic task of developing programs that can run on many computers atthe same time is a parallel computing problem (Foster, 1995). Parallel software needs a parallel computing platform to run. In the past, the platformis available on expensive time-shared parallel supercomputers such as Cray-1 or IBM SP-2(Foster, 1995) only. This made parallel computing a field that not all people can have accessto. Beginning in 1990s the development of cluster computing technology which enables per-sonal computers connected to a high-speed local area network to form a virtual parallel com-puter has made it possible for the public to have access to parallel computing environments.Toolkits such as the Parallel Virtual Machine (PVM) library (PVM, 2002) and the MessagePassing Interface (MPI) library (MPI, 1995) enable the communication and coordination ofprocessors by means of message passing. The libraries provide routines to initiate and con-figure a messaging environment as well as sending and receiving of data between processorscomprising a virtual parallel computer (Baker and Buyya, 1999). A parallel computer basedon the message-passing cluster technology is classified as the Multiple Instruction stream,Multiple Data stream (MIMD) type in parallel computing taxonomy (Kumar et al., 1994;Foster, 1995). Cluster-type parallel computer is now a less expensive alternative platformfor parallel scientific computing with applications ranging from biomedicine (Warfield et al.,2002), computational fluid dynamics (Gropp et al., 2001), fracture mechanics (Heber et al.,2001) to meshless analysis of structures (Barry and Vacharasintopchai, 2001b).2.3 Towards an Application of Distributed Computing Technique History suggests that as a particular technology satisfies known applications, newapplications will arrive that are enabled by that technology and that will demand the devel-opment of new technology (Foster, 1995). A personal computer in 2001 is as fast as a su-percomputer of 1990 (Foster, 2002a). But in 1990 analysts were satisfied with approximatesolutions while in 2001 analysis of large structures with minor details taken into account arepreferred. In some applications, only one personal computer or one small cluster of personal 10
  • 19. computers may not be powerful enough to solve a problem. One parallel supercomputer maynot deliver enough power for real-time simulation of natural phenomena with increasinglycomplex problem formulation. More computational power from many computers may beneeded to perform the analysis in a given amount of time. In some tasks, special analysis en-gines or visualization modules may be required but are not accessible on a local computer. Insome cases, knowledge or information necessary for an analysis may not be available locally.Computational power, proprietary analysis or visualization modules, and knowledge or in-formation are collectively termed resources. In order to utilize the scattered resources suchthat the ever-increasing application demand is satisfied, a technique in distributed computingfrom computer science is necessary. The next chapter presents an overview of developmentsin distributed computing. 11
  • 20. 12
  • 21. CHAPTER 3 DISTRIBUTED COMPUTING3.1 Distributed Computing Concepts Distributed computing is an area in computer science that deals with the spreading ofa computational task across several programs, processes or processors (Brown, 1994). Thereare many forms of distributed computing with many different reasons for each and a widerange of research activity in the area. The forms of distributed computing can be classifiedby the benefits that they offer. Based on Brown (1994), the benefits are listed as follows: 1. By splitting the solution to a specific problem into a number of steps, we can use existing general-purpose programs to handle some of these steps, and so reduce the amount of new code we have to write. We may often be able to avoid writing any new code altogether. This benefit is referred to as tool building. 2. By using several processors concurrently, we can solve the problem more quickly than if we used a single processor. This benefit is referred to as concurrency. 3. If the problem itself is sometimes of the form “Do A, B and C in parallel”, the most natural solution may be to use separate parallel processes to perform A, B and C. Forcing the solution into a strictly sequential form for execution by a single process is unnatural and makes it harder to understand. This benefit is referred to as parallelism. 4. Sometimes, the resources needed to solve the problem are themselves spread around among several computers on a network. In distribute computing context, we can view the network as a whole as a collection of shared resources. This benefit is referred to as resource sharing.3.2 Methods of Problem Decomposition To benefit from distributed computing techniques, a problem has to be decomposedinto pieces so that the solution may be distributed. In the following, various methods todecompose a problem, as described in (Brown, 1994), will be presented.3.2.1 Data Distribution The first way of distributing an application is to divide the input data set into pieces,and hand each piece to a separate process, as shown in Figure 3.1. This is known as datadistribution or domain decomposition. Data distribution divides the input data set amongseveral processors. The code is replicated on each processor and each does the same op-erations but on a different piece of data. Depending on the amount of input data and thenature of the problem, there will be an upper limit on the number of processors which can beusefully employed and a lower limit on the smallest amount of data that can sensibly be pro-cessed on each processor. The limits are related to ordering and synchronization of the tasksdistributed to each processor. Consider a number of tasks with many processors processingdata on each task. Some data may need to be processed by other tasks and we cannot haveall of these tasks performed simultaneously. Information from other processors performingthe same task may be necessary to process a set of data on a given processor, and thus aprocessor may have to wait for other processors in processing a set of data. The former isan issue on ordering whereas the latter is an issue on synchronization. Two terms are used 13
  • 22. Processor A Processor B Processor C Figure 3.1: Problem Decomposition: Data Distributionto categorize problems based on their synchronization requirements. Loosely coupled prob-lems are problems that do not require frequent synchronization of activity and the exchangeof data among processors while tightly coupled problems are the opposite. The couplingdegree is very important for problems that involve a large number of processors because itdetermines the extent to which one can achieve a speed-up which is linearly related to thenumber of processors.3.2.2 Algorithmic Distribution The second way for distributing a problem solution is algorithmic distribution orfunctional decomposition. In this method, various tasks are operated in a pipeline manner,as illustrated in Figure 3.2. An analogy for algorithmic distribution is the production linesin manufacturing factories. The key characteristic of algorithmic distribution is that eachprocessor sees the same data items but performs a different operation on them. In a multi-processor implementation, this is the situation when each processor is running different code.The number of processors that can be employed in this way is limited by the number of steps(or processes) in the pipeline, and is usually quite small. It does not grow as the size of theinput data set increases. Loose synchronization is inherited with algorithmic distribution.In Figure 3.2, when Process A receives so much input data that its production rate cannotmatch the input capacity of Process B, Process B will have to wait for Process A. This causesa bottleneck problem and data distribution techniques may be employed in the process or thewhole pipeline, as shown in Figures 3.3 and 3.4 to alleviate this problem. 14
  • 23. Process A Process B Process C Figure 3.2: Problem Decomposition: Algorithmic Distribution Process A1 Process A2 Process B Process C Process A3Figure 3.3: Problem Decomposition: Hybrid Distribution Method 1 15
  • 24. Process A1 Process B1 Process C1 Process A2 Process B2 Process C2 Figure 3.4: Problem Decomposition: Hybrid Distribution Method 23.2.3 Load Balancing When a computing task is to be spread across multiple processors for concurrent ex-ecution, it is desirable to make sure that each processor has an equal amount of work todo. If some processors are given less work than the others, they will finish sooner and beidle until the others are done. In some applications using data distribution, load balancing iseasily achieved by giving each processor an equal amount of input data. This would work ifeach data item is equally expensive to process and each process has the same performance orproduction rate but it is not generally true for all applications and environments. For manyapplications each data item does not take equal time to process and the performance of eachprocessor on a network is typically not equal. Thus, a load balancing strategy needs to beemployed to maximize the performance of the whole distributed computing system. Oneapproach for load balancing on data distribution is to divide the data into many more piecesthan the number of processors, and allow the processors to get themselves a new piece of datawhen they are ready. This approach is sometimes called a processor farm and was, for exam-ple, implemented in Barry and Vacharasintopchai (2001a). Load balancing for a pipelined,algorithmic decomposition of a problem is more difficult than its data decomposition coun-terpart because we cannot usually fine tune the workload of each processor by adjusting theboundaries between the tasks that they perform. In this case, the hybrid methods discussedearlier may be employed to achieve better load balancing among processors.3.3 Applications in Scientific Computing With the advent of numerical methods, analyses of natural phenomena have reliedheavily on the use of digital computers. Procedures for such analyses involve discrete mod-els that depend on sizes of the problems and desired accuracy of the solutions, rather thanin closed forms usually found in the past. In some applications, as sizes of the problems 16
  • 25. grow centralized computing cannot be used to solve the problems efficiently. Researchersand practitioners have then turned to distributed computing as a means to solve the problemsin a more natural and efficient way. Up to now, scientific computing has been a predom-inantly application-driven area for distributed computing. In this section, two importantachievements in this area, namely, the SETI@home project and grid computing, will besummarized.3.3.1 SETI@home Project SETI@home Project (Anderson et al., 2002), a famous project for its application ofpublic-resource computing, is a project in a research area called the Search for Extraterres-trial Intelligence (SETI). SETI is an area whose goal is to detect intelligent life outside theEarth. SETI@home project is based on the radio SETI approach which uses radio telescopesto listen for narrow-bandwidth radio signals from space. The signals are not known to occurnaturrally, so a detection would provide evidence of extraterrestrial technology. In contrastto radio SETI projects in the past that used special-purpose supercomputers located at thetelescope to perform data analysis, the project uses a virtual supercomputer composed of alarge number of personal computers connected to the Internet. During the design of the SETI@home project, the designers were aware of the poten-tially high network bandwidth associated with the analysis. Network bandwidth consump-tion increases as the frequency range and the resolution of the search is increased. Therefore,they limited the frequency range and resolution of the search to the ones that are just enoughto capture a significant sign of intelligence. It was reported that, compared to other radioSETI projects, SETI@home covers a narrower frequency range but does a more thoroughsearch in that range. The computational strategy of SETI@home can be described as follows. At the cen-tral server complex, the radio signal data is divided into work units of the same sizes. Thesework units are distributed by a multithreaded data/result server to a client program runningon the participants’ computers via the Internet using a HTTP-based protocol. The reasonfor a HTTP-based protocol is to facilitate the clients whose Internet connections are behindfirewalls. The client program, downloadable from SETI@home web site, computes a result,which is a set of candidate signals, returns it to the server for post-processing, and gets an-other work unit. All clients work on their own without any communication among them andneed Internet connections only while downloading the source data from the server or viceversa. The client program can be configured to compute only when the host is idle or to com-pute constantly at a low priority. The program periodically writes its state to a disk file andreads the file on startup so that progress is made even if the host is frequently turned off. Theproject also does redundant calculation by assigning each work unit to be processed multi-ple times. By employing an approximate consensus policy at the central server to choose acanonical result for a particular work unit, results from faulty processors and from malicioususers can be identified and discarded. A relational database management system is employedto manage information about source data, work units, results, users, and other aspect of theproject. SETI@home has proven to be a socially successful distributed computing project.The project began in 1998 with 400,000 participants and the number of participants hadgrown to over 3.8 millions by July 2002. Between July 2001 and July 2002 SETI@homeparticipants processed 221 million work units in 12 months and the average throughput was27.36 Tera FLOPS or 27.36 × 1012 floating point operations per second. 17
  • 26. 3.3.2 Grid Computing Grid computing is a recent field in distributed computing. The term grid was intro-duced in the 1990s to denote a proposed distributed computing infrastructure for advancedscience and engineering (Foster et al., 2001). The grid is a new class of computing infras-tructure built on the Internet and the World Wide Web. It provides scalable, secure andhigh-performance mechanisms for discovering and negotiating access to remote comput-ing resources (Foster, 2002a). Through resource sharing among geographically distributedgroups, it is possible for scientific communities to collaborate on a very large scale. Foster(2002b) gave a definition of the grid as a hardware and software infrastructure that providesdependable, consistent, pervasive, and inexpensive access to high-end computational capa-bilities. In Foster et al. (2001), the definition was refined to address social and policy issues.It was stated that grid computing is concerned with the coordinated resource sharing andproblem solving in dynamic, multi-institutional virtual organizations and that the sharing isnot primarily in file exchange but rather is the direct access to computers, software, data,and other resources, as required by a range of collaborative problem-solving and resource-brokering strategies. Many distributed computing technologies have emerged over the past decade as aresult of the prosperity of the Internet. Currently these technologies are of great intereststo the commerial and the scientific communities and some of them have been termed grids.To help distinguish grid computing technologies from the rest, Foster (2002b) proposed anidentification checklist and explained that a grid computing technology must possess thefollowing properties: 1. Coordination of resources that are not subjected to centralized control: A grid must integrate and coordinate resources and users that live in different control domains, e.g. different administrative units of the same company, different companies, or different countries. 2. Uses of standard, open, general-purpose protocols and interfaces: A grid must be built from multi-purpose protocols and interfaces that address fundamental issues such as authentication, authorization, resource discovery and resource access. It is important that these protocols and interfaces be standard and open to prevent application-specific systems. 3. Delivery of nontrivial qualities of service: A grid must allow its constituent resources to be used in a coordinated fashion to deliver various qualities of service, relating for example to response time, throughput, availability, and security, including co- allocation of multiple resource types to meet complex user demands and result in the synergy of the combined system. A list of major projects in grid computing can be found in Foster (2003a) and Foster(2003b). Two large-scale grid deployments that are worth-mentioning and are being under-taken within the scientific community are NASA’s Information Power Grid (IPG, 2003) andthe TeraGrid (Catlett, 2002). The Information Power Grid is a project funded by the Com-puting, Information, and Communications Technology (CICT) program at NASA Ames Re-search Center to link the resources between NASA Ames Research Center, NASA GlennResearch Center, National Science Foundation (NSF) Partnerships for Advanced Computa-tional Infrastructure (PACI) program at the National Center for Supercomputing Applica-tions, the NSF PACI program at the San Diego Supercomputing Center, Argonne National 18
  • 27. Figure 3.5: Model of the NASA X-38 Crew Return Vehicle (Barnard et al., 1999) Figure 3.6: Mach Contours for the X-38 Crew Return Vehicle (Barnard et al., 1999)Laboratory, and Information Sciences Institute in the United States. The TeraGrid is a projectbeing constructed to link major academic sites in the U.S. which include California Instituteof Technology (Caltech) for data collection analysis facilities, Argonne National Labora-tory (ANL) for visualization facilities, San Diego Supercomputing Center (SDSC) for datastorage facilities, National Center for Supercomputing Applications (NCSA) and PittsburgSupercomputing Center (PSC) for computational facilities. The work described in Barnardet al. (1999) is an example of computational fluid dynamics (CFD) experiments performedon the Information Power Grid. In this work, a virtual machine comprised of parallel su-percomputers, linked by a grid infrastructure, was chosen to execute a CFD application in-volving the accurate prediction of high-speed viscous flow around a geometrically-complexthree-dimensional body shown in Figures 3.5 and 3.6. Problems of this nature challenge thecapabilities of the most advanced single-processor platforms available. Large-scale multi-processor computer systems offer a powerful tool to solve large and complex problems; butthey may still not suffice, and gaining exclusive access to them is difficult in practice. Most major grid projects utilize the community-based, open-source Globus Toolkit(Foster, 2002a), which provides the basic infrastructure for grid operations. The GlobusToolkit has now become the de facto standard for grid computing (Globus, 2003a). Spon-sored by the U.S. Department of Defense, Department of Energy, National Science Foun-dation, NASA, IBM, Microsoft and Cisco Systems Corporation (Globus, 2003b; Ungaro,2003), the project has been announced for support by at least 12 companies. The grid com- 19
  • 28. munity has also formed their own organization called the Global Grid Forum. Currentlywith more than 5,000 members world-wide, the Global Grid Forum is a significant body forsetting standards and development in the field (GGF, 2003). 20
  • 29. CHAPTER 4 WEB SERVICES4.1 The Web Services Architecture Web Services (W3C, 2003d) is a new distributed computing architecture that uses theInternet as the medium for communication. The fundamental concept of Web Services is tobuild computer software by making use of Remote Procedure Calls (RPC) to objects or sub-routines over the Internet or a network. It differs from other previous distributed computingtechnologies in the use of platform-independent standards such as the Hypertext TransferProtocol (HTTP) (Fielding et al., 1999) and the eXtensible Markup Language (XML) (Brayet al., 2000; Fallside, 2001; Thompson et al., 2001; Biron and Malhotra, 2001) which allowservice providers to completely hide the implementation details from the clients. The clientsneed to know the Unified Resource Locator (URL) (Berners-Lee et al., 1994) of the serviceand the data types used for the method1 calls but does not need to know how the service isimplemented in order to make use of it (Basha et al., 2002). The architecture of Web Servicesas described in (Basha et al., 2002) is presented as follows. Web Services architecture makeextensive use of the XML language. The readers are referred to standard textbooks on XMLsuch as Harold (2001) for detailed information. A typical model of Web Services architecture is illustrated in Figure 4.1. Threeroles, namely, service provider, service consumer and service registry, and three operations,namely, publishing, finding and binding, are involved in the Web Services model. Descrip-tions of the roles are as follows:Service Provider – A service provider is an entity that creates the Web Service. Typically, the service provider exposes certain functionality in their organization as a Web Ser- vice for any organization to invoke. To reach full potential of a Web Service, the service provider needs to do two tasks. First, it needs to describe the Web Service in a standard format understandable by all organizations that will be using that Web Service. Next, it needs to publish the details about its Web Service in a central registry that is publicly available to everyone.Service Consumer – A service consumer is any organization that uses the Web Service provided by a service provider. The service consumer can know the functionality of a Web Service from the description made available by the service provider. To retrieve these details, the service consumer makes a search in the registry where the service provider had published its Web Service description. The service consumer is able to get from the service description the description of the mechanism to bind to the service provider’s Web Service and in turn to invoke that Web Service.Service Registry – A service registry is a central location where the service provider can list its Web Services, and where a service consumer can search for Web Services. Service providers usually publish their Web Service capabilities in the service registry for service consumers to find and then bind to their Web Service. Information such as organization details, the Web Services that it provides, and the brief details about each Web Service including technical details is typically stored in the service registry. As mentioned above, three operations fundamental to Web Services architecture are“finding”, “binding”, and “publishing”. The architecture aims to achieve inter-application 1A subroutine in object-oriented programming paradigm 21
  • 30. Find Service Registry Publish Service Bind Service Provider Consumer Web Service Description Figure 4.1: Conceptual Web Services Model (Basha et al., 2002)communication irrespective of the programming language the application is written in, theplatform the application is running on, etc. To make this happen, the standards for eachof these three operations and a standard way for a service provider to describe their WebService irrespective of the programming languge used are needed. These standards are listedas follows: • A standard way to describe Web Services – The Web Service Description Language (WSDL) (W3C, 2001) is a standard that uses XML format to describe Web Services. The WSDL document for a Web Service defines the methods that are present in the Web Service, the input/output parameters for each of the methods, the data types, the network transport protocol used and URL of the end point at which the Web Service will be hosted. • A standard protocol to publish or find Web Services – The Universal Description, Discovery, and Integration (UDDI) standard (OASIS, 2002) provides a way for service providers to publish details about their organization and the Web Services that they provide to a central registry. It also provides a standard for service consumers to find service providers and details about their Web Services. Publication of the details is the “description” part of the UDDI and finding of such details is the “discovery” part of it. • A standard protocol for applications to bind to Web Services – The Simple Object Access Protocol (SOAP) (W3C, 2000) is a lightweight2 XML mechanism used to exchange information between applications regardless of the operating systems, pro- gramming languages, or object models employed in developments of the applications. The roles of SOAP, WSDL and UDDI within the context of Web Services architec-ture is presented in Figure 4.2. Each of the layered blocks in the figure builds upon the blockbeneath it. The labels shown on the left identify the concepts in the architecture and thoseon the right identify actual technologies being used in the implementations. The TransportNetwork layer is responsible for making Web Services accessible by using any of the trans-port protocols available such as the Hypertext Transfer Protocol (HTTP) and the Simple Mail 2 with small amount of overhead instructions 22
  • 31. Service Publication/Discovery UDDI Service Description WSDL XML Messaging SOAP HTTP, SMTP, FTP or HTTPS Transport Network TCP/IPFigure 4.2: Roles of SOAP, WSDL and UDDI in Web Services Architecture (Basha et al.,2002)Transfer Protocol (SMTP) (Klensin, 2001). The XML Messaging layer defines the messageformat that is used for application communication, with SOAP as the standard commonlyused by Web Services. The Service Description layer provides a mechanism for a serviceprovider to describe the functionality that a Web Service provides. The Service Publication TMand Discovery layer acts like a Yellow Pages where service providers publish the links totheir WSDL documents describing the Web Services they provide and the instructions to TMmake use of them. Service consumers, on the contrary, use these Yellow Pages to searchfor Web Services suitable for their needs and make use of them according to the instructionsgiven by service providers.4.2 Applications of Web Services in Scientific Computing Web Services has been involved in many area of scientific computing ranging fromcomputational infrastructure developments (Chiu et al., 2002; van Engelen, 2003) to finiteelement analysis a coupled fluid, thermal, and mechanical fracture problem (Chew et al.,2003). Chiu et al. (2002) investigated the limitations of SOAP for high-performance scien-tific computing and presented an improved implementation of the SOAP specification moresuitable to applications in this area. van Engelen (2003) investigated the usability, interoper-ability, and performance issues of SOAP/XML-based Web Services for scientific computingand addressed key issues important for deployment of high-performance and mission-criticalservices. It was reported that a successful deployment of Web Services in scientific comput-ing may be achieved by limiting the communication overhead of XML encoding throughdefining optimized XML data representations and by applying message chunking, compres-sion, routing, and streaming techniques in the communication between services. In Chewet al. (2003), crack propagation of a rocket engine segment subjected to high Reynolds num-ber, chemically reacting gas flow was studied. One of the most significant efforts in this areais the standardization attempt by the Global Grid Forum to create the Open Grid ServiceArchitecture specification (OGSA) (Foster and Gannon, 2003), which is the global standardfor interoperations among the grid community. According to Foster and Gannon (2003), 23
  • 32. SOAP and WSDL, two important components of Web Services, are adopted in this standard.Since there are already a significant number of scientific computing projects that rely ongrid computing infrastructures, with NASA’s Information Power Grid and the TeraGrid askey projects in the area, imposition of such a standard implies a significant increase in thenumber of scientific computing applications that rely on Web Services technology. 24
  • 33. CHAPTER 5 THE SEMANTIC WEB5.1 General The World Wide Web has turned into a hyper-library where accesses to the very largecollection of information are ubiquitous, in both academic and non-academic worlds. Thesuccess of the Web may be reflected by the ever-increasing electronic versions of documentssuch as books, magazines, and journals. Since its invention in 1992 (Berners-Lee et al.,1992), HyperText Markup Language (HTML) (W3C, 1999a) has been the standard for pub-lication of documents on the Web. HTML is a collection of tags that are used to specifyhow a document is to be displayed on web browsers. Examples of HTML tags are thosepresented in Figure 5.1, such as <title>, <b>, and <table> that tell web browsers to dis-play the title of a web page, a text in bold typeface, and a table with specified numbers ofrows and columns, respectively. One drawback of using HTML as the sole representation ofdocuments is that, from the point of view of computers, no semantics1 can be extracted fromsuch documents. Pieces of information embedded inside a document can be extracted by hu-mans reading them on web browsers but, to computers, the document itself does not providemuch information other than a stream of characters with extra specifications on how they areto be rendered on web browsers. The HTML code in Figure 5.1 would be rendered as a tableof mechanical properties for steel, aluminum, and copper as shown in Figure 5.2. Humanswould have no trouble understanding that the modulus of elasticity of steel, aluminum, andcopper, are 200 GPa, 70 GPa, and 120 GPa, respectively. With some basic background in en-gineering, human readers would also understand that these moduli of elasticity are specificproperties of materials, which are used to relate stresses to strains developed inside them.Computers, on the other hand, would have no clue what the contents of this table mean and,as a consequence, could not make any use of them unless programmers explicitly specifyhow information from a particular HTML code of a particular web site can be extracted andused. In the example in Figure 5.1, to extract the modulus of elasticity of aluminum from thetable, the computer may be programmed to use a pattern matching technique to get the character string (not a number) that lies between the second pair of <td>, </td> tags located inside the pair of <tr>, </tr> tags whose first pair of <td>, </td> tags contains the string aluminum. The example above is for the case that involves only one document on the Web. Inthe real world, searching for information on the Web often involves multiple documents anddata sources. This means that, in a non-automated way, humans would have to read andexamine these web pages and extract the embedded information, or, in an automated way,programmers would have to examine various patterns of HTML codes and provide hard-coded routines to extract information from various web pages. These tasks are tedious ifthey involve ten to twenty documents from restricted searches on web sites and are nextto impossible on unrestricted searches over the Internet, where a search for “mechanical TMproperties” on Google returns hundreds thousands of web pages, with a potential that theHTML code of each one is constantly being changed due to the decentralized architecture ofthe Web. The Semantic Web (Berners-Lee et al., 2001), a vision for the next generation of theWorld Wide Web, is the Web in which information presented are useful not only for humans 1 the relationship between words or symbols and their intended meanings (Microsoft, 1997) 25
  • 34. <html> <head> <title>Material Properties</title> </head> 5 <body> <b>Mechanical properties</b> of materials are presented as follows: <br/> <table> <tr>10 <td>Material</td> <td>Young’s Modulus (GPa)</td> <td>Yield Stress (MPa)</td> </tr> <tr>15 <td>Steel</td> <td>200</td> <td>240</td> </tr> <tr>20 <td>Aluminum</td> <td>70</td> <td>60</td> </tr> <tr>25 <td>Copper</td> <td>120</td> <td>260</td> </tr> </table>30 </body> </html> Figure 5.1: Example of an HTML Document $ Mechanical properties of materials are presented as follows: Material Youngs Modulus (GPa) Yield Stress (MPa) Steel 200 240 Aluminum 70 60 Copper 120 260 & % Figure 5.2: HTML Document in Figure 5.1 as Rendered on a Web Browser 26
  • 35. <rdf:RDF xmlns:rdf=""> <rdf:Description about=""> <Creator>Glenn Smith</Creator>5 </rdf:Description> </rdf:RDF> Figure 5.3: Example of an RDF Description but also machines. According to an article by Tim Berners-Lee, the inventor of the Web, and his colleagues (Berners-Lee et al., 2001), by augmenting Web pages with data targeted at computers and by adding documents solely for computers, we would be able to transform the Web into the Semantic Web where computers find the meaning of semantic data on a web page by following hyperlinks to definitions of key terms and rules for reasoning about them logically. Computers will be able to understand pieces of information on web pages rather than merely presenting them to users, and will be able to manipulate such information on their own. Explicit representation of the semantics underlying data, programs, pages, and other web resources, will enable a knowledge-based web that provides a qualitatively new level of service. Automated services will improve in their capacity to assist us in achieving our goals by understanding more of the content on the Web and thus provide more accurate filtering, categorization, and search of information sources (Ding et al., 2002). Eventually, computers could then be able to help us make better use the enormous information scattered on the Internet in a more efficient and less tedious way. According to (Berners-Lee et al., 2001), for the Semantic Web to function, computers must have access to structured collections of information and sets of inference rules that they can use to conduct automated reasoning. In artificial intelligence, such collections are called knowledge representation systems. Enabling such systems on the Web involves syntactic and semantic descriptions of data. Syntactic description is achieved by making use of the eXtensible Markup Langauge (XML) which allows users to add arbitrary structure to their documents by using tags, the hidden labels such as <youngs modulus> or <yield stress> that annotate web pages or sections of text on a page. Computer programs can make use of these tags in many ways but programmers would also have to know in advance the intended meaning of each tag, which is created, adopted, or used by document writers, as XML does not say anything about these meanings. Semantic description, the meaning description of an XML tag, is expressed by on- tology representation languages such as the Resource Description Framework (RDF) (W3C, 1999c) and DAML+OIL (DAML, 2001). Ontologies are encoded in sets of triples in a gram- matical form like the subject, verb and object of an elementary sentence. The triples can be written using XML tags. For example, in RDF, a document makes assertions that a particular thing (such as a person) has properties (such as “is the author of”) with certain values (such as a Web page). An example of RDF descriptions using XML tags is shown in Figure 5.3. In the following sections, RDF and DAML+OIL ontology representation languages as well as the mechanisms to make inferences on ontologies will be presented. 27
  • 36. 5.2 Resource Description Framework (RDF)5.2.1 Introduction The Resource Description Framework (RDF) is an XML application2 for representinginformation about resources on the World Wide Web. RDF was first developed for represent-ing metadata about Web resources, such as the title, author, and modification date of a Webpage, but, by generalizing the concept of a Web resource, RDF can also be used to representinformation about things that can be identified on the Web, even if they cannot be directlyretrieved on the Web. Intended for situations in which information needs to be processed byapplications rather than being displayed to people, RDF provides a common framework forexpressing the information such that it can be exchanged without loss of meaning. In thefollowing, concepts about RDF, as described in W3C (2003b), will be presented.5.2.2 An RDF Statement RDF is based on the idea that the things being described have properties which havevalues, and that resources can be described by making statements that specify those prop-erties and values. For a particular statement, the part that identifies the thing the statementis about is called the subject. The part that identifies the property of charateristic of thesubject that the statement specifies is called the predicate. The part that identifies the valueof that property is called the object. RDF statements may be represented in both graphicaland non-graphical ways. Figure 5.3 presented earlier is an RDF statement about the au-thor of a Web site encoded in RDF/XML, which is the XML version of RDF representationand is the machine-processable way to represent an RDF statement. The English statementcorresponding to the figure is “ has a Creator whose valueis Glenn Smith.” The subject for this statement is Thepredicate is Creator and the object is Glenn Smith.5.2.3 Identification of Resources RDF uses Uniform Resource Identifiers (URIs) (Berners-Lee et al., 1998), the gen-eralization of the Uniform Resource Locators (URLs) (Berners-Lee et al., 1994) commonlyused on web browsers, as the basis of its mechanism to uniquely identify subjects, predi-cates, and objects in statements. To be precise, RDF uses URI references (URIref), whichis a URI with an optional fragment identifier separated by the symbol #. For example, theURI reference consists of the URI, which is a web page that contains informa-tion about many people, and the fragment identifier 85740, which specifically identifies theinformation about people whose identification number is 85740. RDF defines a resource asanything that is identifiable by a URI reference. According to the specification (Berners-Leeet al., 1998) URIs and URIrefs can be used to identify things that can be accessed onlineas well as the ones that cannot. Thus, using URIrefs allows RDF to describe practicallyanything, and to state relationships between them as well.5.2.4 The RDF Model Although RDF may be represented in graphical and non-graphical ways, RDF state-ments are fundamentally modeled as graphs. RDF models statements as nodes and arcs ina graph. An RDF statement is represented by (1) a node for the subject, (2) a node for the 2 A markup language defined by XML. XML is a meta-markup language or the language that is used todefine markup languages (Harold, 2001). 28
  • 37. Figure 5.4: A Simple RDF Statement (adapted from W3C, 2003b)object, and (3) an arc for the predicate, directed from the subject node to the object node.Groups of statements are represented by corresponding groups of nodes and arcs. Figure 5.4 shows an example of a simple RDF statement. Figure 5.5 shows a groupof RDF statements that modify the statement in Figure 5.4 with the following statements: has a creation-date whose value is August 16, 1999. has a language whose value is English. The name of the staff specified by 85740 is Glenn Smith. He is 27 years old. Objects in RDF statements may be either URIrefs or literals, which are constant val-ues of character strings to represent property values. Literals may not be used as subjects orpredicates in RDF statements. In RDF graphs, nodes that are URIrefs are shown as ellipseswhereas nodes that are literals are shown as boxes. URIrefs are used in Figures 5.4 and 5.5 to explicitly specify, for example, that thepredicate creator is to be strictly interpreted by the definition in, and the object is strictly the staff of whose iden-tification number is 85740. Using URIrefs as subjects, predicates, and objects in RDF state-ments supports the development and use of a shared vocabulary on the Web, since peoplecan discover and begin using vocabularies already used by others to describe things, thusreflecting a shared understanding of concepts.5.2.5 Defining RDF Vocabularies RDF provides a way to express statements about resources using named propertiesand values. However, it lacks the capability to define terms or vocabularies to describespecific classes of resources nor the properties to be used specifically on them. Such classesand properties can be described as an RDF vocabulary by using RDF Schema (RDFS) (W3C,2003c). RDF Schema provides the facilities needed to describe classes and properties, andto indicate which classes and properties are expected to be used together. It provides a typesystem for RDF, which is similar in some aspects to the type systems in object-orientedprogramming languages. RDF Schema allows resources to be defined as instances of one ormore classes and allows classes to be organized in a hierarchical fashion. 29
  • 38. August 16, 1999 English Glenn Smith 27 Figure 5.5: Several RDF Statements about Resources (adapted from W3C, 2003b)Classes RDF Schema uses classes to refer to the kinds of things to be described. A class inRDF Schema corresponds to the generic concept of a type or category, or a class in object-oriented programming languages. RDF classes can be used to represent any category ofthings, ranging from people, Web pages, document types, to abstract concepts. Classesare described by using the RDF Schema resources rdfs:Class and rdfs:Resource, and theproperties rdf:type and rdfs:subClassOf. The resources that belong to a class are called theinstances to that class. As an illustration, a hierarchy of classes in RDF Schema in graphnotation and the corresponding RDF/XML encoding are presented in Figures 5.6 and 5.7.An RDF/XML encoding that represents an instance of a class defined in the figures is alsoshown in Figure 5.8.Properties RDF Schema uses the RDF class rdf:Property, and the RDF Schema properties rdfs:-domain, rdfs:range, and rdfs:subPropertyOf to specifically describe properties that character-ize classes of things. All properties in RDF are described as instances of class rdf:Property.RDF Schema also provides vocabulary for describing how properties and classes are in-tended to be used together in RDF data, with the RDF Schema properties rdfs:range andrdfs:domain as the most important information to describe application-specific properties. The rdfs:range property is used to restrict that the values of a particular property areinstances of a specified class or given by a specific type of literals. The rdfs:domain prop-erty is used to indicate that a particular property applies to a specified class. Data typesof literals specified in rdfs:range are defined externally to RDF and RDF Schema. Datatypes may be defined by XML Schema data typing mechanisms (Biron and Malhotra, 2001)and are referred to in RDF statements by their URIrefs. Statements with rdfs:range serveto document the existence of data types and to indicate explicitly that they are to be usedin the schemas. Similar to classes, RDF Schema also provides a way to make specializa-tion on properties. The specialization relationship between two properties is described by 30
  • 39. Figure 5.6: A Vehicle Class Hierarchy (adapted from W3C, 2003b)the rdfs:subPropertyOf. As an illustration, definition of properties that corresponds to theclasses defined in Figures 5.6 and 5.7 as well as an instance of a class that makes use of suchproperties are presented in Figures 5.9 and 5.10, respectively.5.3 DAML+OIL RDF was developed at about the same as XML by the World Wide Web Consortium(W3C), which is the organization that controls standards on the Internet. RDF was usedto complement XML as a language for modeling semi-structured metadata and enablingknowledge-management applications (Ouellet and Ogbuji, 2002), and was adopted as an en-abling technology for the Semantic Web when it was first introduced (Berners-Lee et al.,2001). However, as researches on the Semantic Web went on, it was found that RDF andits RDF Schema extension could be used as the bases for development of ontologies, butthey alone do not provide enough facilities such that practical artificial intelligent systemsmay be implemented. In particular, RDF Schema can be used as the basic tool to define vo-cabulary, structure and constraints for expressing metadata about Web resources. However,its expressivity is not sufficient for complete ontological modeling and reasoning (Broekstraet al., 2002). DAML+OIL is an attempt to address the problems mentioned above. DAML+OIL,a language created on top of RDF and RDF Schema, is a joint effort by the US DefenseAdvanced Research Projects Agency (DARPA) Agent Markup Language Program (DAML,2003) and the Ontology Inference Layer (OIL) Project (Broekstra et al., 2002) to provide alanguage for expressing “far more sophisticated classifications and properties of resources”than RDFS (Ouellet and Ogbuji, 2002). A comparison between the features provided byRDF and RDF Schema and those provided by DAML+OIL is presented in Table 5.1. 31
  • 40. <?xml version="1.0"?> <!DOCTYPE rdf:RDF [<!ENTITY xsd "">]> <rdf:RDF xmlns:rdf="" 5 xmlns:rdfs="" xml:base=""> <rdf:Description rdf:ID="MotorVehicle"> <rdf:type rdf:resource=""/>10 </rdf:Description> <rdf:Description rdf:ID="PassengerVehicle"> <rdf:type rdf:resource=""/> <rdfs:subClassOf rdf:resource="#MotorVehicle"/>15 </rdf:Description> <rdf:Description rdf:ID="Truck"> <rdf:type rdf:resource=""/> <rdfs:subClassOf rdf:resource="#MotorVehicle"/>20 </rdf:Description> <rdf:Description rdf:ID="Van"> <rdf:type rdf:resource=""/> <rdfs:subClassOf rdf:resource="#MotorVehicle"/>25 </rdf:Description> <rdf:Description rdf:ID="MiniVan"> <rdf:type rdf:resource=""/> <rdfs:subClassOf rdf:resource="#Van"/>30 <rdfs:subClassOf rdf:resource="#PassengerVehicle"/> </rdf:Description> </rdf:RDF> Figure 5.7: An RDF/XML Encoding that Corresponds to Figure 5.6 (W3C, 2003b) <?xml version="1.0"?> <rdf:RDF xmlns:rdf="" xmlns:ex="" 5 xml:base=""> <ex:MotorVehicle rdf:ID="companyCar"/> </rdf:RDF> Figure 5.8: An Instance of a Class Defined in Figures 5.6 and 5.7 (W3C, 2003b) 32
  • 41. <?xml version="1.0"?> <!DOCTYPE rdf:RDF [<!ENTITY xsd "">]> <rdf:RDF xmlns:rdf="" 5 xmlns:rdfs="" xml:base=""> <rdfs:Class rdf:ID="Person"/>10 <rdfs:Datatype rdf:about="&xsd;integer"/> <rdf:Property rdf:ID="registeredTo"> <rdfs:domain rdf:resource="#MotorVehicle"/> <rdfs:range rdf:resource="#Person"/>15 </rdf:Property> <rdf:Property rdf:ID="rearSeatLegRoom"> <rdfs:domain rdf:resource="#PassengerVehicle"/> <rdfs:range rdf:resource="&xsd;integer"/>20 </rdf:Property> <rdf:Property rdf:ID="driver"> <rdfs:domain rdf:resource="#MotorVehicle"/> </rdf:Property>25 <rdf:Property rdf:ID="primaryDriver"> <rdfs:subPropertyOf rdf:resource="#driver"/> </rdf:Property>30 </rdf:RDF> Figure 5.9: Definition of Properties Corresponding to Classes in Figures 5.6 and 5.7 (adapted from W3C, 2003b) 33
  • 42. <?xml version="1.0"?> <!DOCTYPE rdf:RDF [<!ENTITY xsd "">]> <rdf:RDF xmlns:rdf="" xmlns:ex="" 5 xml:base=""> <ex:PassengerVehicle rdf:ID="johnSmithsCar"> <ex:registeredTo rdf:resource=""/>10 <ex:rearSeatLegRoom rdf:datatype="&xsd;integer">127</ex:rearSeatLegRoom> <ex:primaryDriver rdf:resource=""/> </ex:PassengerVehicle>15 </rdf:RDF> Figure 5.10: An Instance of a Class using Properties Defined in Figure 5.9 (W3C, 2003b) Table 5.1: Comparison between RDF(S) and DAML+OIL (DAML, 2002) Dimension RDF(S)a DAML+OIL Bounded Lists Yes Yes Cardinality Constraints Yes Class Expressions Yes Data Types Yes Yes Defined Classes Yes Enumerations Yes Equivalence Yes Extensibility Yes Yes Formal Semanticsb Yes Yes Inheritance Yes Yes Inference Yes Local Restrictions Yes Qualified Constraints Yes Reification Yes Yes a RDF and RDF Schema b Formal semantics is the study of language meaning using mathematical and logical formalisms (ILLC, 2003). Formalism is the mathematical or logical structure of a scientific argument as distinguished from its subject matter (Collins, 2000). 34
  • 43. DAML+OIL extends the expressivity of RDF and RDF Schema in many aspects.Based on DAML (2002), discussion on the extended capabilities that DAML+OIL providesis presented as follows:Cardinality Constraints and Qualified Constraints DAML+OIL provides the constructs daml:cardinality, daml:minCardinality, and daml:maxCardinality, which allow one to specify the number of occurences of properties in a certain class. It also provides the data type daml:UniqueProperty which allows one to specify that a property be unique, meaning that there can only be one value of the property for each instance (Ouellet and Ogbuji, 2002). DAML+OIL also provides the constructs that allow qualified restrictions such as “at most 3 of the children of X are of type Doctor” by using the daml:hasClassQ, daml:cardinalityQ, daml:minCardinalityQ, and daml:maxCardinalityQ constructs.Class Expressions DAML+OIL provides the constructs daml:unionOf, daml:disjointUnionOf, daml:intersectionOf, and daml:complementOf, which allow one to express the relationship between classes. For example, given a group of classes A and B, it is possible to state that class C is the daml:disjointUnionOf A and B. As a result, if both A and B are defined as the subsets of C, it is asserted that neither A nor B has any properties in common.Defined Class DAML+OIL allows new classes to be defined based on property values or other restrictions of an existing class or class expressions. For example, a class Child can be defined based on the properties of the class Person with a restriction that age < 18.Enumeration DAML+OIL provides built-in support for enumerations (Ouellet and Ogbuji, 2002). An enumeration defines a class by giving an explicit list of its member. It restricts the value space of a property to a certain set of values. For example, the gender of a person can only be either Male or Female. In DAML+OIL, enumeration of property types is possible with the daml:oneOf construct (Gil and Ratnakar, 2002).Equivalence To support reasoning across ontologies and knowledge bases, DAML+OIL allows definition of necessary and suffient conditions for class membership. The con- ditions specify a class definition that can be used to recognize whether an instance belongs to a class, or to classify whether a class is a subclass of another class (Gil and Ratnakar, 2002). In DAML+OIL, equivalence of classes and instances is expressed by the daml:equivalentTo and daml:sameClassAs constructs.Inference In addition to equivalence, DAML+OIL also provides constructs to provide ad- ditional information for reasoning engines such as daml:TransitiveProperty, daml:inverseOf, and daml:UnambigousProperty. 35
  • 44. <daml:Class rdf:ID="A"> <rdfs:subClassOf> <daml:Restriction> <daml:onProperty rdf:resource="#p"/>5 <daml:hasValue rdf:resource="#v1"/> </daml:Restriction> </rdfs:subClassOf> </daml:Class> Figure 5.11: An Example of daml:Restriction Construct daml:TransitiveProperty is used to specify that a property is transitive on its class hier- archy. If p is a property of class A, B is a subclass of A, and C is a subclass of B, then C also has the property p. daml:inverseOf allows the specifications of inverse relation- ships between properties. For example, if A is the father of B, then B is a child of A. Thus, when an assertion is made on a property, another assertion can be implicitly in- ferred on the inverse. daml:UnambigousProperty allows the specification of a property that identifies a resource. Local Restriction RDF associates rdfs:domain and rdfs:range constraints with a property, whereas DAML+OIL allows daml:Restriction constraints to be associated with a Class– property pair. In DAML+OIL, by daml:Restriction classes can be a subclass of anony- mous classes. Consider an example in Figure 5.11, by property restriction, class A is defined as the subclass of an unidentified class whose property p has the value v1 . In effect, class A becomes a subclass of all resources that have at least one property p whose value value is v1 . DAML+OIL has been widely accepted by researchers on the Semantic Web as the language to model ontologies. In scientific computing, a suite of DAML+OIL ontologies have been developed to describe Web Services and data in computational biology3 (Wroe et al., 2003). A revised version of DAML+OIL is now adopted by W3C in an effort to create Web Ontology Language (OWL) (W3C, 2003a), the standard language for ontological representation. Currently being in its final draft revisions, OWL will be recommended by W3C as the language to represent ontologies on the Semantic Web in the near future. 5.4 DAML-S: Semantic Markup for Web Services DAML+OIL is the markup language that enable the creation of ontologies for any domain and the instantiation of these ontologies in the description of specific Web sites (DAML-S, 2003b). With such a markup language, it is possible to provide unambiguous description of contents and resources on the Web. Among the resources, Web Services are one of the most important resources on the Web since they not only provide information to users, but also enable them to effect changes in the world (Ankolenkar et al., 2002) such as the sale of a product of the control of a physical device (DAML-S, 2003b). Based on Berners-Lee et al. (2001), with the assistance of a software agent, the Se- mantic Web should enable users to locate, select, employ, compose, and monitor Web Ser- vices automatically. The integration of the Semantic Web and Web Services results in a 3 a.k.a. bioinformatics 36
  • 45. research area called Semantic Web Services (McIlraith et al., 2001) which attempts to de-scribe Web Services in a knowledge-based manner in order to use them for a variety ofpurposes, including discovery and search, evaluation, selection, composition, execution, andmonitoring (Grosof et al., 2003). For a software agent to make use of Web Services andin turn offer services to its users, it needs a computer-interpretable descriptions of the ser-vices and the means by which the services are accessed. These descriptions can be achievedby employing a set of basic classes and properties for declaring and describing services onWeb sites. DAML+OIL provides the ontology modeling facilities to make such descriptionspossible (DAML-S, 2003b). The DAML Services (DAML-S) language is an effort by theDAML Services Coalition (DAML-S, 2003a) to use DAML+OIL in defining such an ontol-ogy. Description of DAML-S as given in DAML-S (2003b) is presented as follows: In DAML-S, services can be simple or primitive, meaning that they invoke only asingle Web Service that does not reply on another Web Service and the only interaction be-tween the user and the service is only a simple response. Services can be complex, meaningthat they are composed of multiple primitive services and often require interactions betweenthe user and the services so that the user can make choices and provide information condi-tionally. DAML-S are designed to enable tasks such as: 1. Automatic Web Service Discovery With DAML-S, the information necessary for Web Service discovery could be specified as computer-interpretable semantic markup at the service Web sites. To enable discoveries, a service registry or an ontology- enabled search engine could be used to automatically locate the services from their Web sites, or the servers hosting the services could proactively advertise themselves in DAML-S with a service registry known as the middle agent, so that requesters can find it when they query the registry. DAML-S provides declarative advertisements of service properties and capabilities that can be used for automatic service discovery. 2. Automatic Web Service Invocation Automatic Web Service invocation involves the automatic execution of an identified Web Service by a computer program or an agent. Execution of a Web Service can be thought of as a collection of function calls. DAML- S provides a declarative, computer-interpretable Application Program Interface (API) for executing these function calls. Upon interpreting the markup, a software agent would be able to understand what input is necessary to the service call, what informa- tion will be returned, and how to execute the service automatically. 3. Automatic Web Service Composition and Interoperation This task involves the automatic selection, composition, and interoperation of Web Services to perform some task, given a high-level description of an objective. With DAML-S, the information necessary to select and compose services will be encoded at the service Web sites. DAML-S provides declarative specifications of the prerequisites and consequences of individual service use. Software agent can thus manipulate these specifications, to- gether with a specification of the objectives of the task, to achieve the task automati- cally. In addition to the three tasks above, the DAML Service Coalition also envisions an-other task called Automatic Web Service Execution Monitoring but has not yet provided itin the current version of DAML-S4 . This task involves the provision of descriptors for theexecution of services and will be useful in the situation when services take some time to 4 DAML-S verion 0.9 (DAML-S, 2003b) 37
  • 46. completely execute and the users want to know the status of their requests during the period.Web Service Execution Monitoring will provide the ability to find out where in the processthe request is and whether any unanticipated problems have appeared. The upper levels of DAML-S ontology are presented in Figure 5.12. The structureof ontology is motivated by the need to provide three essential types of knowledge about aservice, namely, 1) What the service does, 2) How the service works, and 3) How to use theservice. The class Service provides the reference point for declaring Web Services. One in-stance of Service will exist for each distinct published service. The class Service possessesthree properties, namely, presents, describedBy, and supports. The classes ServiceProfile,ServiceModel, and ServiceGrounding, are the respective ranges of these properties. The ServiceProfile tells “what the service does”. It gives the types of informationneeded by an agent seeking for a service to determine whether a service meets its need.The information is of three basic types, namely, the identification of the organization thatprovides the service, the description of the function that the service computes, such as theinputs, outputs, preconditions, and expected results, and a host of properties to describe fea-tures of the service, such as the classification of the service, the quality rating, and otherinformation which includes the estimate of maximum response time and the geographic ra-dius of a service. The ServiceModel tells “how the service works”. It describes what happens whenthe service is carried out. This description may be used in four different ways by an agentseeking for a service: 1) to perform a more in-depth analysis whether the service meets itsneed, 2) to compose service descriptions from multiple services to perform a specific task,3) to coordinate the activities of different participant during the course of service enactment,and 4) to monitor the execution of the service. A ServiceGrounding specifies the details of how an agent can access a service byspecifying a communication protocol, message formats, the port5 number, as well as thetechnique to encode the data to be exchanged. A grounding can be thought of as a mappingfrom an abstract to a concrete specification of the service description elements required forinteracting with the service. The DAML-S concept of grounding is consistent with WSDLconcept of binding presented earlier in Section 4.1. The upper ontology for services specifies two cardinality constraints. One is that aService can be described by at most one ServiceModel and another is that a ServiceModelmust be accompanied by at least one supporting ServiceGrounding. The cardinality for theproperties presents and describedBy is not specified as it may be useful for some servicesto provide partial charaterization and some services to offer multiple profiles or multiplegroundings.5.5 Inferences – Making Use of Resources and Ontologies Figure 5.13 illustrates the layered architecture of the Semantic Web from the pointof view of the World Wide Web Consortium. According to the figure, XML tags and XMLnamespaces6 are used to encode information to be published on the Web. Using XML, theseinformation are represented in the format <uri ref:tagname>textual information</uri ref:tagname>,such as 5 An entrance to or exit for a data network (AHD, 1992) 6 see definition in Figure 5.14 38
  • 47. Resource provides Service supports presents describedBy ServiceProfile ServiceGrounding What the How to access it service does ServiceModel How it works Figure 5.12: Upper Levels of DAML-S Ontology (DAML-S, 2003b) <dc:TITLE>Glenn Smith</dc:TITLE>,in which the URIref dc is defined by xmlns:dc="".The Unicode character set (Unicode, 2003), the standard for encoding multi-language textin documents, is used to encode these information. Once stored on the Web, the informationare termed resources and are referred to and accessed by their respective URIs. Semanticdescription of the XML tags are provided by the RDF Model and Syntax (RDF M&S), RDFSchema, and ontology representation languages such as DAML+OIL, as discussed earlier.Ontologies can be viewed as knowledge bases on the Web. They can be useful only if theyare consulted during decision processes. Thus, a key requirement for the Semantic Webarchitecture overall is to be able to layer rules on top of ontologies by creating and reasoningwith rule-bases that mention vocabulary specified by ontological knowledge bases (Grosofand Horrocks, 2003). Reasoning processes are performed by software reasoning enginesand their respective logic frameworks. Information obtained from reasoning processes areproofs, which, once encrypted and accompanied by electronic signatures of the informationproviders, are considered authentic and trustful, and hence can be used with confidence byother users on the Semantic Web. In the next chapter, XML Declarative Description (XDD)(Wuwongse et al., 2001), an XML-based knowledge representation capable of modelingaxioms7 and rules and as well as reasoning on XML-encoded ontologies8 will be discussed. 7 A self-evident principle or one that is accepted as true without proof as the basis for argument (AHD,1992) 8 such as ontologies encoded in DAML+OIL language 39
  • 48. Figure 5.13: Semantic Web Stack Diagram (W3C, 2002)XML NamespaceAn XML namespace is a collection of tag names identified bya URI reference (W3C, 1999b) in the form <uri ref:tagname>,such as <rdf:Description> in Figure 5.3. <rdf:Description>is a tag name defined in the rdf namespace whose URIref is Uses of XMLnamespaces prevent collision and ambiguity of tag names when the namesdefined by many sources are used together inside an XML document. Figure 5.14: Definition of XML Namespace 40
  • 49. CHAPTER 6 XML DECLARATIVE DESCRIPTIONIn this chapter, XML Declarative Description (XDD) (Wuwongse et al., 2001), an XML-based knowledge representation founded on the Declarative Description (DD) theory (Akama,1993), which can be used to model axioms and rules, as well as to make inferences on on-tologies, will be discussed. First, Declarative Description (DD) theory, the logical theory onwhich XDD is based, and Equivalent Transformation (ET) (Akama et al., 1998), the associ-ated computational model, will be presented. After that, XDD and its inference mechanism,together with XML Equivalent Transformation (XET) (Anutariya et al., 2002), the associatedprogramming language, will be introduced.6.1 Declarative Description Theory Declarative Description (DD) theory is an axiomatic theory inspired by the conceptof conventional logic programs with an attempt to cover a wider variety of data domains.According to Wuwongse et al. (2000), DD theory may be used as a template for developingdeclarative semantics for declarative descriptions in many specific data domains. Descriptionof DD theory, as presented in Wuwongse et al. (2000), is given below.6.1.1 Specialization Systems First, the concept of specialization system is introduced.Definition 6.1 Let A , G , and S be respectively the sets of objects, ground objects1, special-izations, and µ be a mapping from S to partial map(A ) (i.e., the set of all partial mappingson A ). The quadruple A , G , S , µ is a specialization system under the conditions: 1. ∀s1 , s2 ∈ S , ∃s ∈ S : µ(s) = µ(s1 ) ◦ µ(s2), 2. ∃s ∈ S , ∀a ∈ A : µ(s)(a) = a, 3. G ⊂ A ,where µ(s1 ) ◦ µ(s2 ) is the composite mapping of the partial mappings µ(s1 ) and µ(s2 ). Theset G is called the interpretation domain. The conditions (1) to (3) intuitively mean that: 1. For all specializations s1 and s2 , there exists a specialization s such that the corre- sponding partial mapping of s is the composition of the two mappings that correspond to s1 and s2 , 2. There exists a specialization which does not change any objects (identity specializa- tion), and 3. Ground objects are objects. Let Γ = A , G , S , µ be a specialization system. When µ is clear from the context,i.e. when there is no danger of confusion, for θ ∈ S , µ(θ)(a) will be written simply as aθ. Ifthere exists b such that aθ = b, θ is said to be applicable to a, and a is specialized to b by θ.For a ∈ A , let rep(a) denote the set of all ground objects which can be specialized from a: rep(a) = {aθ | θ ∈ S , aθ ∈ G } . (6.1) 1 ground objects are objects that do not contain variables 41
  • 50. 6.1.2 Declarative Descriptions A declarative description on Γ and other related concepts are defined by the follow-ing: Let a set K be comprised of the constraint predicates. A constraint on Γ is a formulaq(a1 , . . . , an ), where q is a constraint predicate in K and ai is an object in A . Given a groundconstraint q(g1 , . . . , gn ), gi ∈ G , its truth and falsity are assumed to be predetermined. Denotethe set of all true ground constraints by Tcon . A specialization θ is applicable to a constraintq(a1 , . . . , an ) if θ is applicable to a1 , . . . , an . The result of q(a1 , . . ., an )θ is the constraintq(a1 θ, . . . , an θ); and q(a1 , . . . , an ) is said to be specialized to q(a1 θ, . . . , an θ) by θ. The notionof constraints introduced here is useful for defining restrictions on objects in A .Definition 6.2 A clause on Γ is a formula of the form H ← B1 , B2 , . . . , Bn (6.2)where n ≥ 0. H is an object in A and Bi is an object in A or a constraint on Γ. H is calledthe head and (B1 , B2 , . . . , Bn ) is called the body of the clause. A declarative description orsimply a description on Γ is a (possibly infinite) set of clauses on Γ. Let C be a clause (H ← B1 , B2 , . . . , Bn ). If n = 0, C is called a unit clause. If n > 0,C is called a non-unit clause. The head of C is denoted by head(C). The sets of all objectsand constraints in the body of C are respectively denoted by ob ject(C) and con(C). Letbody(C) = ob ject(C) ∪ con(C). A clause C is an instance of C iff 2 there is a specializationθ ∈ S such that θ is applicable to H, B1 , B2 , . . . , Bn and C = Cθ = (Hθ ← B1 θ, B2 θ, . . ., Bn θ).A clause C is a ground clause iff C is comprised only of ground objects and ground con-straints.6.1.3 Semantics of Declarative Descriptions Let P be a declarative description on Γ. The mapping TP on the power-set 2G , whichmaps a subset of G into another subset of G , is defined by:Definition 6.3 For each X ⊂ G a ground object g is contained in TP (X ) iff there exist aclause C ∈ P and a specialization θ ∈ S such that Cθ is a ground clause the head of which isg and all the objects and constraints in the body of which belong respectively to X and Tcon ,i.e. TP (X ) = head(Cθ) | C ∈ P, θ ∈ S, Cθ is a ground clause, (6.3) ob ject(Cθ) ⊂ X , con(Cθ) ⊂ Tcon . Based on TP , the meaning of P is defined as follows:Definition 6.4 Let P be a declarative description on Γ. The meaning of P, denoted by M (P),is defined by ∞ M (P) = [TP ]n (∅) (6.4) n=1where ∅ is the empty set. [TP ]1 (∅) = TP (∅) and [TP ]n (∅) = TP [TP ]n−1 (∅) . 2 if and only if 42
  • 51. 6.1.4 Equivalent Transformations Equivalent Transformation (ET) is a computational paradigm that is based on thesemantics preserving transformations (or equivalent transformations) of declarative descrip-tions by employing the definition:Transformability of Declarative DescriptionsDefinition 6.5 A declarative description P1 is said to be transformed equivalently into adeclarative description P2 if they have exactly the same meaning, i.e., M (P1 ) = M (P2 ). Computations in ET paradigm are defined by means of equivalent transformationrules (ET rules), which are applied to the object and constraint components of a target clause(Wuwongse et al., 2000). According to Akama et al. (2002), such computations involvetwo components: a program specification and a program. A program specification, simplycalled a specification, is a pair D, Q , where D is a declarative description, called a definitionpart, and Q is a set of declarative descriptions, each of which is called a query part. Thedefinition part D provides general knowledge about a problem domain and describes somespecific problem instances. A query part in Q specifies a question with regard to the contentof the definition part D. For each query part Q in Q , the pair D, Q is regarded as a problemdescription covered by the specification D, Q , and a declarative meaning is associatedwith each problem description. On the contrary, a program, is a set of procedural rewritingrules (or ET rules), each of which defines a transformation operation on a set of declarativedescriptions. Computations are performed by successive transformations of a given querypart by application of ET rules so as to derive a simpler query part from which the answers tothe specified query are readily obtained. In other words, let P1 be the declarative descriptionof a given query part and M (P1 ) be its associated meaning. The paradigm applies ET rulesin order to successively transform ET rules ET rules ET rules ET rules P1 − − − P2 − − − P3 − − − . . . − − − Pn − −→ − −→ − −→ − −→while maintaining the conditions M (P1 ) = M (P2 ) = M (P3 ) = . . . = Pnuntil the description Pn , the meaning of which contains the desired statements or solutions,is obtained (Anutariya et al., 2002).General Form of ET Rules The general form of an ET rule is defined as follows:Definition 6.6 (Akama et al., 2001) The general ET rule is of the form (n ≥ 0): rulename : H, {Cs} → {Es1 }, Bs1 ; → {Es 2 }, Bs 2 ; ··· → {Esn }, Bsn .in which rulename is the name of a rule; H is an object called the head; Cs is a (possiblyempty) sequence of executable objects called the applicability condition part; each Es i are 43
  • 52. (possibly empty) sequences of executable objects called an execution part; each pair of Esiand Bsi are (possibly empty) sequences of objects called a body of the rule. The rulename ,the applicability condition part, and the execution parts are optional. Assume that we are given an object b in the body of a definite clause C. An ET ruleis applicable to the object b iff the head H matches the object b by a specialization θ, i.e.Hθ = b, and Cs θ is true3 . When the rule is applied to a clause C at an object b, C producesless than or equal to n clauses. Each new clause is obtained after Es i θ is executed successfullywith an answer specialization σ by replacing bσ in Cσ with Bs i θσ. The theoretical foundationthat verifies the validity and correctness of the ET transformations is presented in Akamaet al. (2001).6.2 XML Declarative Description XML Declarative Description (XDD) was developed by extending the format andstructure of conventional XML elements with variables, resulted in a new structure calledXML expressions, and place them in the context of DD theory. In this section, XML expres-sions and the formulation of XDD, as given in Wuwongse et al. (2000), will be presented.6.2.1 XML Elements and XML Expressions Conventional XML elements are ground, i.e. they do not contain variable, and havethe forms: 1. empty element: <t a1 = v1 . . . am = vm /> 2. simple element: <t a1 = v1 . . . am = vm > vm+1 </t> 3. nested element: <t a1 = v1 . . . am = vm >e1 . . . en </t>where n, m ≥ 0, t is an element type (or tag name), ai is a distinct attribute name, vi is a stringof characters (or simply a string), and ei is an XML element. Let ΣX be the XML expression alphabet comprised of the sets defined in Table 6.1.XML expressions are defined by the following definition:Definition 6.7 An XML expression on ΣX takes one of the following forms: 1. evar 2. <t a1 = v1 . . . am = vm pvar1 . . . pvark /> 3. <t a1 = v1 . . . am = vm pvar1 . . . pvark > vm+1 </t> 4. <t a1 = v1 . . . am = vm pvar1 . . . pvark > e1 . . . en </t> 5. <ivar> e1 . . . en </ivar>where evar ∈ VE , k, m, n ≥ 0, t, ai ∈ (N ∪VN ), pvari ∈ VP , vi ∈ (C∗ ∪VS ), ivar ∈ VI , and ei areXML expressions on ΣX . The order of the attribute-value pairs a1 = v1 . . . am = vm and the order of the P-variables pvar1 . . . pvark are immaterial whereas the order of the expressions e1 . . . en is im-portant. XML expressions with variables are non-ground XML expressions and those without 3 recall the shortened form of the specialization operator µ(θ)(a) ≡ aθ introduced on page 41 44
  • 53. Table 6.1: Definition of the XML Expression Alphabet (Wuwongse et al., 2000) Symbols Set Elements Conditions Specialization Objects C Characters ’$’ ∈ C N/A N Namesa All names not beginning N/A with “$N:” VN Name variables Names beginning with Element types or attribute (N-variables) “$N:” names in N VS String variables Names beginning with Strings in C∗b (S-variables) “$S:” VP Attribute-value-pair Names beginning with Sequences of variables (P-variables) “$P:” attribute-value pairs VE XML-expression Names beginning with Sequences of XML variables (E-variables) “$E:” expressions VI Intermediate-expression Names beginning with Parts of XML expressions variables (I-variables) “$I:” a Names can be either element types or attribute names b C∗ is the set of character strings.variables are ground XML expressions or XML elements. An expression of the 2nd , 3rd , and4th form is a t-expression, whereas that of the 5th form is an ivar-expression. A groundt-expression is a t-element. When n = 0, an expression <t a1 = v1 . . . am = vm pvar1 . . . pvark > </t> of the fourthform is considered identical to the expression <t a1 = v1 . . . am = vm pvar1 . . . pvark /> of thesecond form. The parts enclosed by < and >, </ and >, or < and /> are respectively starttags, end tags and empty-element tags, and are collectively referred to as tags. ai is anattribute name when ai ∈ N, and is an attribute-name variable when ai ∈ VN .6.2.2 Formulation of XML Declarative DescriptionVariable Instantiation A variable instantiation is defined by basic specializations, each of which has theform (v, w) where v specifies the name of the variable to be specialized, and w specifies thespecializing value. 45
  • 54. XML Specializing Generation SystemDefinition 6.8 Let ∆X = AX , GX , CX , µX be an XML specialization generation system, whereAX is the set of all XML expressions on ΣX , GX is the set of all ground XML expressions onΣX , CX is the union of the sets: 1. (VN ×VN ) ∪ (VS ×VS ) ∪ (VP ×VP ) ∪ (VE ×VE ) ∪ (VI ×VI ), 2. VP × (VN ×VS ×VP ) ∪ VE × (VE ×VE ) , 3. (VP ∪VE ) × ε ∪ (VI × {ε}), and 4. (VN × N) ∪ (VS × Σ∗ ) ∪ (VE × AX ) ∪ VI × (VN ×VP ×VE ×VE ×VI ) ,where {ε} denotes the null symbol. Let a ∈ AX and c ∈ CX , the basic specialization mappingoperator νX : CX → partial map(AX ) is defined in Table 6.2, and the elements of CX are callbasic specializations.XML Specialization SystemDefinition 6.9 Based on ∆X , let ΓX = AX , GX , SX , µX be an XML specialization system, ∗where SX = CX , i.e. the set of all sequences on CX . For each a ∈ AX , µX : SX → partial map(AX )is defined by 1. µX (λ)(a) = a, where λ denotes the null sequence, and 2. µX (c · s)(a) = µX (s) νX (c)(a) , where c ∈ CX and s ∈ SX .The mapping µX is called the specialization operator, and µX (s)(a) is defined for each a ∈ AXand s ∈ SX , only if all basic specializations in s are successively applicable to a. Definitions 6.7 and 6.8 are the bases for Definition 6.9, which is the XML versionof the specialization systems presented in Section 6.1.1. After such a specialization systemis defined, definitions of XML clauses, XML declarative descriptions, and the semantics ofan XML declarative description are obtained by direct application of the DD theory usingDefinitions 6.2, 6.3, and 6.4, respectively.6.2.3 XML Equivalent Transformation XML Equivalent Transformation (XET) is a declarative programming language found-ed on XDD theory which can directly and succinctly manipulate XML data without a neces-sity for data conversion (Anutariya et al., 2001, 2002). XET was developed by integrationof the XDD language, the ET computational paradigm, and XML syntax. It naturally uni-fies documents, programs, data, and, with its computational and reasoning services, alsounifies document processing and transformation, program execution, and query processing,the three functions of which are important for manipulations of information on the SemanticWeb. In the followings, description of XET as presented in Anutariya et al. (2002) will begiven. An XET program is comprised of a set of XET rules and XML elements or documents,which are regarded as the data of facts associated with the program. Each XET rule has asimilar structure to an ET rule given in Definition 6.6 except that every component of anXET rule can be an arbitrary XML expression. The typical structure and syntax of an XETprogram, the tags and attribute names of which are defined in the xet namespace, is presentedin Figure 6.1. 46
  • 55. Table 6.2: Definition of the Basic Specialization Mapping Operator νX (Wuwongse et al.,2000) Types Basic Specializations c in CX Methods by which νX (c)(a) Applicability is obtained from a Conditions 1. Variable Renaming c = (v, u) ∈ Replacement of all (VN ×VN ) ∪ (VS ×VS ) ∪ (VP × occurrences of v in a by u VP ) ∪ (VE × VE ) ∪ (VI × VI ) 2. Variable Expansion 2.1 P-variable c = (v1 , (nvar, svar, v2 )) Simultaneous replacement of For every tag ∈ VP × (VN × VS × VP) all occurrences of v in a by in a the sequence of the pair containing v, nvar = svar and the that tag does P-variable v . not contain nvar as an attribute name 2.2 E-variable c = v1 , (v1 , v2 ) Simultaneous replacement of ∈ VE × (VE × VE ) each occurrence of v in a by the sequence v1 v2 . 3. Variable Removal 3.1 P- or E-variable c = (v, ε) ∈ (VP ∪VE ) × {ε} Removal of each occurrence of v in a. 3.2 I-variable c = (v, ε) ∈ VI × {ε} Removal of each occurrence of <v> and each occurrence of </v> in a. 4. Variable Instantiation 4.1 N-variable c = (v, b) ∈ VN × N Simultaneous replacement of For every tag each occurrence of v in a in a by b. containing v as an attribute- name variable, that tag does not contain b as an attribute name 4.2 S- or E-variable c = (v, b) Simultaneous replacement of ∈ (VS × Σ∗ ) ∪ (VE × AX ) each occurrence of v in a by b 4.3 I-variable c = v, (nvar, pvar, evar1, Simultaneous replacement of evar2 , v ) ∈ each occurrence of the VI × (VN ×VP ×VE ×VE ×VI ) v-expression <v>e1 . . . en </v> in a by the nvar-expression <nvar pvar> evar1 <v > e1 . . . en </v > evar2 </nvar> . 47
  • 56. <xet:Program xmlns:xet=""> <xet:RuleClassOrder>Priority Levels</xet:RuleClassOrder> 5 <xet:Fact> Fact_1 ... Fact_k </xet:Fact>10 <xet:Rule name=RuleName_1 priority=RulePriority_1> <xet:Head> HeadElement </xet:Head>15 <xet:Condition> CondElement_1 ... CondElement_k </xet:Condition>20 <xet:Body> BodyElement_1_1 ... BodyElement_1_m1 </xet:Body>25 <xet:Body> BodyElement_2_1 ... BodyElement_2_m2 </xet:Body>30 . . . <xet:Body> BodyElement_n_135 ... BodyElement_n_mn </xet:Body> </xet:Rule> .40 . . <xet:Rule name=RuleName_r priority=RulePriority_r> ... </xet:Rule>45 </xet:Program> Figure 6.1: Typical Structure and Syntax of an XET Program (Anutariya et al., 2002) 48
  • 57. xet:Fact is used to specify application data and is comprised of ground XML expres-sions. An xet:Rule is used to specify an XET rule and is comprised of the following compo-nents defined in xet namespace: name specifies the name of the rule. priority specifies the pri-ority of the rule in case that many conflicting rules are to be applied simultaneously. xet:Headcontains a HeadElement, which either specifies an XML expression pattern to be matchedand transformed or defines an event to be monitored for execution of the rule. The optionalxet:Condition contains a list of CondElements, which are the applicability conditions thatmust be satisfied for execution of the rule. CondElements may either be the predicates builtinto XET or the ones defined by the users. Body contains zero or more BodyElements, eachof which is either an XML element to be matched with the head of the other rules in theprogram, a query about XML elements in the program, or an XET built-in or user-definedfunction. All variables in XET rules are prefixed with their variable-type specification, forexample, an S-variable named uri is represented by Svar-uri in XET programs. Given an XDD description for a particular problem, a set of XET rules for imple-mentation of such a problem can directly be derived. Therefore, an XDD description canalso be regarded as an XET program specification. Computation and execution of an XETprogram follow those in the ET paradigm. A given problem is executed by successivelyapplying semantics-preserving transformation rules (or XET rules) to an XDD descriptionthat describes the problem until a desirable XDD description yielding the answer is obtained.Such a procedure is based on the basis defined in Definition Ontology Modeling and Inference with XDD With respect to Figure 5.13, ontologies and rules, the key enables for the SemanticWeb can be modeled and manipulated under the framework of XDD. Ontologies definitionsand ontology instances, represented in languages such as RDF(S) and DAML+OIL, can bemodeled as XML unit clauses (or facts) in the form (H ← ∅). Their hierarchical rela-tionships and ontological axioms, such as symmetry and inverse, can be modeled as XMLnon-clauses in the form (H ← B1 , B2 , . . . , Bn ). Specific rules, constraints, and restrictionson the information can also be represented and imposed by a corresponding set of XMLnon-unit clauses. Declarative Description theory, the theory which underlies XDD, can beregarded as the logical framework in Figure 5.13. Thus, XDD and the XET programminglanguage can be readily used to implement the Semantic Web. An example of inferences on RDF(S) and DAML+OIL ontologies using XDD ispresented as follows: consider the DAML+OIL ontology definition of class Person in Fig-ure 6.2. Ontology instances of the class are given in Figure 6.3. An XDD descriptionof the ontology axiom daml:inverseOf, used in the definition of the class, as proposed bySuwanapong (2001), is presented in Figure 6.4. Other axiomatic descriptions of ontologymodeling constructs, such as rdfs:subPropertyOf and daml:TransitiveProperty, are also avail-able in the proposal. In XDD, Figures 6.2 and 6.3 are regarded as XML unit clauses whereasFigure 6.4 is regarded as a non-unit clause. These XDD descriptions can respectively betransformed into an XET program shown in Figures 6.5 and 6.6. Once, processed by anXET processor, additional information implied by the semantics of the XDD descriptionscan be extracted as shown in Figure 6.7. 49
  • 58. <daml:Class rdf:ID="Person"> <rdfs:label>person</rdfs:label> </daml:Class> 5 <daml:ObjectProperty rdf:ID="hasChild"> <rdfs:domain rdf:resource="#Person"/> <rdfs:range rdf:resource="#Person"/> </daml:ObjectProperty>10 <daml:ObjectProperty rdf:ID="hasParent"> <rdfs:domain rdf:resource="#Person"/> <rdfs:range rdf:resource="#Person"/> <daml:inverseOf rdf:resource="#hasChild"/> </daml:ObjectProperty>15 <daml:UniqueProperty rdf:ID="age"> <rdfs:domain rdf:resource="#Person"/> </daml:UniqueProperty> Figure 6.2: XDD Description Modeling the Ontology Definitions of Class Person (Suwanapong, 2001) <Person rdf:ID="JACK"> <age>52</age> <hasChild rdf:resource="#JOHN"/> </Person> 5 <Person rdf:ID="JOHN"> <age>29</age> <hasChild rdf:resource="#JILL"/> </Person>10 <Person rdf:about="JILL"> <age>7</age> </Person> Figure 6.3: XDD Description Modeling the Ontology Instances of Class Person (Suwanapong, 2001) 50
  • 59. <$N:classB rdf:about=$S:resourceY> $E:resourceXElmt <$S:propertyR rdf:resource=$S:resourceX/> 5 </$N:classB> ←− <daml:ObjectProperty rdf:ID=$S:propertyR>10 <daml:inverseOf rdf:resource=$S:propertyP/> $E:inversePropertyElmt </daml:ObjectProperty>, <$N:classA rdf:ID=$S:resourceX>15 <$S:propertyP rdf:resource=$S:resourceY/> $E:resourceXElmt </$N:classA>, <$N:classB rdf:ID=$S:resourceY>20 $E:resourceYElmt </$N:classB>. Figure 6.4: XDD Description Modeling the Ontology Axiom daml:inverseOf (Suwanapong, 2001) 51
  • 60. <xet:Program xmlns:xet=""> <xet:RuleClassOrder>1 2 3 4</xet:RuleClassOrder> 5 <xet:Fact> <!-- Ontology Definitions --> <daml:Class rdf:ID="Person"> <rdfs:label>person</rdfs:label>10 </daml:Class> <daml:ObjectProperty rdf:ID="hasChild"> <rdfs:domain rdf:resource="#Person"/> <rdfs:range rdf:resource="#Person"/> </daml:ObjectProperty>15 <daml:ObjectProperty rdf:ID="hasParent"> <rdfs:domain rdf:resource="#Person"/> <rdfs:range rdf:resource="#Person"/> <daml:inverseOf rdf:resource="#hasChild"/> </daml:ObjectProperty>20 <daml:UniqueProperty rdf:ID="age"> <rdfs:domain rdf:resource="#Person"/> </daml:UniqueProperty> <!-- Ontology Instances -->25 <Person rdf:ID="JACK"> <age>52</age> <hasChild rdf:resource="#JOHN"/> </Person> <Person rdf:ID="JOHN">30 <age>29</age> <hasChild rdf:resource="#JILL"/> </Person> <Person rdf:about="JILL"> <age>7</age>35 </Person> </xet:Fact> <!-- to be continued on next figure --> Figure 6.5: An XET Program Corresponding to the XDD Descriptions in Figures 6.2 to 6.4 (Part 1 of 2) 52
  • 61. <!-- continued from the previous figure --> <xet:Rule name="inverseOf" priority="4"> 5 <!-- Head H --> <xet:Head> <Nvar-classB rdf:about=Svar-resourceY> Evar-resourceXElmt <Svar-propertyR rdf:resource=Svar-resourceX/>10 </Nvar-classB> </xet:Head> <!-- Body B1 --> <xet:Body>15 <daml:ObjectProperty rdf:ID=Svar-propertyR> <daml:inverseOf rdf:resource=Svar-propertyP/> Evar-inversePropertyElmt </daml:ObjectProperty> </xet:Body>20 <!-- Body B2 --> <xet:Body> <Nvar-classA rdf:ID=Svar-resourceX> <Svar-propertyP rdf:resource=Svar-resourceY/>25 Evar-resourceXElmt </Nvar-classA> </xet:Body> <!-- Body B3 -->30 <xet:Body> <Nvar-classB rdf:ID=Svar-resourceY> Evar-resourceYElmt </Nvar-classB> </xet:Body>35 </xet:Rule> </xet:Program> Figure 6.6: An XET Program Corresponding to the XDD Descriptions in Figures 6.2 to 6.4 (Part 2 of 2) 53
  • 62. <Person rdf:about="JOHN"> <age>29</age> <hasChild rdf:resource="#JILL"/> <hasParent rdf:resource="#JACK"/> 5 <Person> <Person rdf:about="JILL"> <age>7</age> <hasParent rdf:resource="#JOHN"/>10 </Person> Figure 6.7: Information Derived from the XDD Descriptions in Figures 6.2 to 6.4 (Suwanapong, 2001) 54
  • 63. CHAPTER 7 METHODOLOGY7.1 A Semantic Web Services Framework for Computational Mechanics The proposed framework of Semantic Web Services for computational mechanics(SWSCM) is illustrated in Figure 7.1. A multi-tier system architecture for the framework ispresented in Figure 7.2. The multi-tier system architecture is a generalization of the three-tier client/serversystem architecture, an architecture of which software systems are structured into three tiersor layers, namely, user interface, business logic or application logic, and database. Layersmay have one or more components. For example, there can be one or more user interfacesin the top tier, each user interface may communicate with more than one application in themiddle tier at the same time, and the applications in the middle tier may use more than onedatabase at a time. Components in a tier may run on a computer that is physically separatefrom the other tiers, communicating with the other components over a computer network(Microsoft, 1997). They may also run on the same computer and be logically separatedinto processes, communicating with the others over messaging infrastructures built into anoperating system. In the multi-tier architecture, components in a tier may also communicatewith other components of the same tier. For example, application in the middle tier mayrequest other applications, which are also in the middle tier, to provide computations on itsbehalf. From the system architecture point of view, the framework comprises four compo-nents, namely, a client, an application Web Service, a knowledge base server, and an optionaldatabase server.Client A client, the user-interface tier in the architecture, is the component where end-users interact with application Web Services in the framework. It is used to initiate a re- quest for an operation to be performed by application Web Services and to present results of the operation to the users. The client can be a web browser or other end-user application, with or without graphical user-interfaces.Application Web Service An application Web Service, the application-logic tier in the frame- work, is the component that provides services to the clients or other Web Services. Ser- vices are provided by employing computing modules, knowledge bases and databases accessible locally, or by delegating tasks to the others. An application Web Service is called an agent if the services provided are accomplished mainly by making use of other Web Services. It is called a special-purpose Web Service, or simply a Web Service, if the services provided are accomplished mainly by making use of local fa- cilities. Application Web Services identify and make use of the others by consulting their local services ontologies, possibly encoded in DAML-S language, or by assis- tance of a service registry broker, which is a special-purpose Web Service that help other Web Services advertise themselves, as well as helping each of them identify and make use of the others. Communications between application Web Services are by means of SOAP messages transported over HTTP protocol.Knowledge Base Server A knowledge base server, a component of the database tier in the architecture, is the component where ontologies, URIrefs to ontolgies, rules, and an inference engine are stored. A knowledge base server is accessbile locally to an appli- cation Web Service and provides reasoning supports to the Web Service. 55
  • 64. Database Server A database server, another component of the database tier in the architec- ture, is the optional component where raw or unprocessed data relevant to the operation of an application Web Service are stored. A database server is accessible locally to an application Web Service and provides support for queries against such data during the operation of the Web Service. Referred to Figure 7.1 and the paradigm discussed in Section 1.1 on pages 2–3, whenan assistance is needed during a structural design process or an assessment of structural per-formance, a user open a web browser or a client application to connect to a structural analysisagent, which may be recommended by a colleague or discovered from an advertisement on TM TMsearch engines such as Google or Yahoo. Four stages of operations are involved from themoment an agent is identified by a user until the moment the agent presents the user therequested results, namely, a data input stage, a service planning stage, a service executionand monitoring stage, and a result presentation stage. Operations at each stage are describedas follows:Data Input Stage Through user interfaces provided by the agent, the user supply the data that model the real world structure being considered as well as the desired results. The former include the shape and dimensions of the structure, the type of material of which it is built, the boundary conditions, and the external forces to which it is subjected. The latter are specifications such as stresses at particular points, contour plots of particular stress components, or evaluation whether the structure can safely withstand the given loading conditions. The user may explicitly specify directions and magnitudes of the external forces or ask the agent to use the forces specified by a design code that governs the area where the structure is located. He or she needs not explicitly provide all the data and may omit some of them if they can be implied from other input data.Service Planning Stage When the user finishes providing the input data, the agent analyzes the user requests and consults the local knowledge base server, where process ontolo- gies reside, to identify local computing modules that produce the results requested by the user. If it is found that a particular request cannot be handled locally, a service registry broker is consulted to identify Web Services or other agents that can handle such a request. A service registry broker may inform the agent of such Web Services and agents by means of SOAP messages containing URIrefs to their DAML-S ontology instances. If the service registry broker returns a list of more than one Web Services or agents that can handle a request, the agent would consult its knowledge base server to select the most appropriate one based on descriptions in the DAML-S ServiceProfile such as quality rating, maximum response time, and geographic radius of the service. After all computing modules and third-party application Web Services are identified, the agent compares the input data provided by the user against the those required by the computing modules and application Web Services. The format of the required input data, as well as that of the output data, are specified in WSDL documents published on the Internet. Mismatched input data items are arbitrated by consulting the agent’s local knowledge base server or by making requests for information from knowledge bases of other agents or Web Services. For example, if the user specifies dimensions of the structure in SI units but the computing modules of the agent are developed for Imperial units, 56
  • 65. the agent would consult its knowledge base and look for ontology instances of SI units and convert the dimensions specified by the user into the ones in Imperial units so that they can be handled by local computing modules. Differences between keywords recognized by agents, Web Services, and users, such as modulus of elasticity versus Young’s modulus, are arbitrated by ontology mapping facilities available on knowledge base servers. General data items are also made more specific and precise by consulting the agent’s local knowledge base server or by making requests for information from knowledge bases of other agents or Web Services. For example, if the user requests that external forces to be applied to the structure conform to those specified in the latest revision of UBC Building Code and the agent’s local knowledge base does not contain such a building code, it would consult a service registry broker and be directed to respective Web Service of a government agency that provides loading information from UBC Building Codes. Such information is provided by Web Service of the government agency through queries against ontology instances on its local knowledge base server. By consulting process ontologies stored on knowledge base servers, the agent then create a service execution plan, which is a list of computing modules, agents, and Web Services to be executed, sequentially or in parallel, to deliver end results requested by the user.Service Execution and Monitoring Stage The service execution plan created in the ser- vice planning stage contains ServiceGrounding information extracted from DAML-S ontology instances of respective computing modules and application Web Services. As discussed in Section 5.4, a ServiceGrounding description specifies the details of how services can be accessed by an agent. Such details include message formats and URIs, the explicit specifications of communication protocol, network address, and port number to be contacted upon service requests. Thus, in this stage, the agent prepare in- put data suitable for particular computing modules and application Web Services, and accordingly invoke them by the methods specified in their ServiceGrounding descrip- tions. Preparation of input data is performed by means of adaptations and conversions of the output from preceding service executions, with the assistance of ontologies, on- tology instances, and ontology mapping facilities. Monitoring of services that require substantial time for data processing is expected to be achieved by monitoring compo- nents of DAML-S ServiceModel constructs expected to be included in the final version of DAML-S markup language.Result Presentation Stage In the last stage of operations, the agent presents the results to the user in the requested formats. The results obtained from the service execution and monitoring stage are in XML format that conforms to an XML schema provided and adopted by the agent. If the user-interface client is an end-user application, the results in XML format are directly downloaded to the application, and are further formatted and displayed to the user by computing modules and application logics embedded in the client. If the user-interface client is a web browser, the agent renders the results into HTML format and present them on the client web browser. The HTML code presenting the results may also contain URIrefs to graphical plots, pictures, or video clips which are generated in the previous stage by visualization Web Services using raw data obtained from the results themselves. 57
  • 66. 7.2 An Overview of the Research Tasks The tasks indentified from the objectives described in Chapter 1 and the frameworkdiscussed previously are listed as follows: 1. Infrastructure Design and Development (a) Construction of domain ontologies related to computational mechanics so that knowledges relevant to general operations of the framework components are cap- tured, (b) Construction of ontology mapping facilities to be utilized by local knowledge base servers of application Web Services, (c) Construction of service enactment facilities to enable semantic service advertise- ment, discovery, composition, execution, and monitoring among application Web Services. 2. Application Web Services Development For each application Web Service, (a) Design of XML Schemas for input, intermediate, and output data, as well as definition of DAML+OIL ontologies to describe the meaning of data items, (b) Construction DAML-S ontology instances to support and control operations of the application Web Service, (c) Implementation and deployment of application Web Services using particular tools and programming languages. 3. Illustrative Applications of the Framework (a) Application of the application Web Services to solve illustrative problems in lin- ear elasticity and elastoplasticity. A preliminary schedule for the proposed research tasks and the estimates of expen-ditures are respectively presented in Figure 7.17 and Table 7.6. Detailed description of eachtask is presented in the following sections.7.3 Infrastructure Design and Development As discussed in Chapter 1, the XML Declarative Description (XDD) framework andits XML Equivalent Transformation (XET) inference engine, the two of which are presentedin Chapter 6, will be employed to implement the proposed framework. Thus, contruction ofthe infrastructure components will be such that they fit into the framework of XDD.7.3.1 Construction of Domain Ontologies Construction of domain ontologies involve the capture of basic knowledges relatedto the general operations in computational mechanics. Using the concepts presented in Sec-tion 5.2 and 5.3, hierarchies of DAML+OIL ontology classes and their instances, as well asaxioms, will be designed and constructed. Examples of ontologies related to key operationsin computational mechanics are listed in Tables 7.1 and 7.2. Those of the axioms are listedin Table 7.3. First, the definition of each entity and relationships among them will be inves-tigated. Statements that define entities and relationships will be produced using RDF(S) and 58
  • 67. DAML+OIL constructs. Next, class diagrams similar to the one in Figure 5.6 will be createdto model the entities and relationships. XML encodings of such models, in DAML+OIL lan-guage, can be directly derived from the class diagrams. In the XDD framework, DAML+OILdomain ontologies are regarded as ground XML expressions (or facts). Axioms such as theones in Table 7.3 will be transformed into non-ground XML expressions containing RDF(S)and DAML+OIL constructs. These domain ontologies and axioms can be further used inknowledge base servers to support the operations of application Web Services.7.3.2 Construction of Ontology Mapping Facilities A preliminary example of domain ontology described previously is presented in Fig-ure 7.3. Specifically, the figure contains an ontology of terms related to engineering mate-rials, which include Material, MaterialProperty, MathQuantity, PhysicalQuantity, UnitOfMea-surement, Stress, Strain, and related subclasses and superclasses. To illustrate the situationin which ontology mapping is needed, consider the case when structural analysis agents Aand B in Figure 7.1 are collaborating on a task requested by an end-user. Agent B adopts amaterial-related ontology shown as solid lines in Figure 7.3 whereas Agent A adopts an on-tology developed by someone else. Upon consulting process ontologies on the local knowl-edge base, Agent B finds that a tensile modulus of elasticity is required to perform the re-quested task. By consulting its local knowledge base, Agent A also knows in advance thata Young’s modulus is required for the requested task. Therefore, together with the analysisrequest, Agent A has submitted Agent B a Young’s modulus of the material which consti-tutes the structure to be analyzed. A term conflict occurs because Agent B needs a “tensilemodulus of elasticity” while a “Young’s modulus” is supplied by Agent A. To resolve this problem, a specification of the intended meaning is to be supplied bythe party intiating a communication and to be acknowledged by the party receiving messages.When Agent A submits the Young’s modulus parameter to Agent B, it needs to specify aURIref to the Internet location where the term “Young’s modulus” is defined. In other words,Agent A needs to supply Agent B a URIref that points to the ontology adopted by itself. Uponarrival of the message, Agent B needs to verify, by investigating the ontology accessible atthe specified URIref, whether the term “Young’s modulus” used by Agent A and the term“tensile modulus of elasticity” used by itself actually refer to the same concept or not. From the ontology identified as solid lines in Figure 7.3, TensileModulusOfElas-ticity that Agent B expects from Agent A is a subclass of ModulusOfElasticity which re-lates TensileStress to TensileStrain by an Equation named Hooke’s Law specified at According to the ontology adopted by Agent A, TensileMod-ulusOfElasticity hasUnit of GPa (109 N/m2 ), which is a subclass of the forcePerUnitArea unit,a subclass of the DerivedUnit rooted from UnitOfMeasurement. Upon investigating at the URIref specified by Agent A, Agent B discovers that Youngs-Modulus used by Agent A is a PhysicalQuantity that relates TensileStress to TensileStrainby the Equation named Hooke’s Law specified at andhasUnit of ksi (kips per square inch), which is a subclass of the forcePerUnitArea unit, asubclass of the DerivedUnit rooted from UnitOfMeasurement. Since TensileModulusOfElasticity and YoungsModulus (1) are both subclasses of Phys-icalQuantity, (2) both relate TensileStress to TensileStrain by the Equation named Hooke’sLaw specified at, and (3) are both subclasses of the for-cePerUnitArea unit, a subclass of the DerivedUnit rooted from UnitOfMeasurement, it can bededuced that the “tensile modulus of elasticity” used by Agent B and the “Young’s modulus”used by Agent A actually refer to the same concept. Thus, Agent B may accept the value of 59
  • 68. Table 7.1: Examples of Mathematical and Physical Ontologies Related to KeyOperations in Computational Mechanics Ontology Names Examples of Subclasses 1. Quantities mathematical quantities, physical quantities 2. Mathematical quantities scalar, vector, matrix, tensor 3. Geometrical entities one-dimensional entities, two-dimensional entities, three-dimensional entities 3.1 One-dimensional entities point 3.2 Two-dimensional entities line, triangle, rectangle, square, circle, ellipse 3.3 Three-dimensional entities box, cube, sphere, tetrahedral, cone, paraboloid, surfaces 4. Physical quantities base physical quantities, derived physical quantities 4.1 Base physical quantities length, mass, time, electric current, thermodynamic temperature, amount of substance, luminous intensity 4.2 Derived physical quantities area, volume, velocity, acceleration, force, pressure, stress, strain 5. System of measurements International system of measurement (SI), Imperial system of measurement 6. Unit of measurements base units, derived units 6.1 Base units meter, inch, foot, yard, kilogram, pound, kips, second, minute, Farenhiet, Celcius, Kelvin 6.2 Derived units square meter, cubic feet, meter per second, mile per hour, Newton, pound (lbf), Pascal, psi, ksi 7. Materials metallic material, non-metallic material 8. Material characteristics isotropic, anisotropic 9. Material properties ultimate stress, ultimate strain, yield stress, yield strain, modulus of elasticity, Poisson’s ratio, isotropic strain hardening parameter, kinematic strain hardening parameter 60
  • 69. Table 7.2: Examples of Conceptual Ontologies Related to Key Operations inComputational Mechanics Ontology Names Examples of Subclasses 1. Mathematical concepts coordinate system, Cartesian coordinate, polar coordinate, space, reference point, coordinate transformation, mapping, approximation, interpolation 2. Computational mechanics concepts discretization, element, load, stiffness, boundary conditions, response, displacementTable 7.3: Examples of Axioms Related to Key Operations in ComputationalMechanics Categories Example of Axioms 1. Governing conditions equilibrium, conservation of energy 2. Material behaviors elasticity, plasticity, visoelasticity, viscoplasticity 3. Loadings dead load, live load, wind load, gravity load, lateral load 4. Characters of matrices sparse matrix, dense matrix, banded matrix 61
  • 70. “Young’s modulus” from Agent A as its “tensile modulus of elasticity” value and proceedon the analysis request. Agent B may also add the term YoungsModulus to its local ontologyspecifying that this term specified by the URIref employed by Agent A is the sameClassAsthe term TensileModulusOfElasticity employed by itself. Specification of ontologies adopted by the involved agents is one part of a researcharea in Agent Communication Languages. Deduction that one class is the same class as an-other class is obtained by manipulating XML-encoded DAML+OIL ontologies, accessibleat local knowledge base server or downloadable from particular URIrefs. Thus, the task ofconstructing facilities for ontology mapping becomes the task of investigating and creatingan agent communication language or a mechanism that allows an agent who initiates a com-munication to inform its recipients of the URIref that points to the ontology adopted by itself,and the task of creating an XET program comprising of non-ground XML expressions andadditional XET rules such that deduction on DAML+OIL ontologies in the fashion discussedearlier is possible.7.3.3 Construction of Service Enactment Facilities Construction of the service enactment facilities involves the design and implemen-tation of a mechanism to support semantic advertisement, discovery, composition, execu-tion, and monitoring of application Web Services using the constructs in DAML-S ontologywhose definitions and relations are presented in Figure 7.4. As an illustration, considerthe situation in the service planning stage when a software agent needs assistance from anapplication Web Service to determine the inverse of a sparse matrix involved in its opera-tions. Upon consulting a service registry broker for “matrix inversion services”, supposethat four application Web Services, namely the ones by,,, and, are identified and the URIrefs to their DAML-S ontol-ogy instances are reported by the service registry broker. After following the URIrefs, theagent finds that DAML-S descriptions of those application Web Services are as presented inFigure 7.7 to 7.10. A summary of important DAML-S descriptions is presented in Table 7.4,and the ontologies that describe solution methods and the input matrices are respectivelydefined in Figures 7.5 and 7.6. The computations being performed by the agent are based on numerical methods.Referred to Table 7.4, upon consulting its knowledge base, the agent makes the followingdecisions: • The agent would not choose the service by because 1. it takes general matrices as the input which means that it is not optimized for sparse matrices, and 2. direct matrix inversion method generally gives exact solutions at the expense of longer computation time, which, in this case, is not necessary since the results will be governed by numerical procedures being employed by the agent. • The agent would also not choose the service by because, although the service is based on an iterative method, which is suitable for the agent, it takes dense matrices as the input which means that advantages of sparse matrices are not taken into account. Thus, this service is not suitable for the agent. • The agent prefers the service by to the one by because, although both offer services optimized for sparse matrices, the service by 62
  • 71. Table 7.4: Summary of Matrix Inversion Service Profiles in Figures 7.7 to 7.10 Service Provider Solution Method Input Type Quality Rating Direct method General matrix A Iterative method Sparse matrix A Iterative method Dense matrix A Iterative method Sparse matrix B is more reliable because it receives higher quality rating from Comp- MechRating, which is a service rating agency recognized by the agent. From the decisions presented, the agent thus chooses to request for the inverse ofits matrix from the application Web Service by To make use of the ap-plication Web Service, the agent would follow the ServiceGrounding description of the ser-vice. Specifically, in Figure 7.8, the agent would investigate the NumMethOrgMatInvWOR,which is the service grounding description that maps the conceptual matrix inversion pro-cess of to its corresponding getInverse operation defined in WSDL doc-ument, the content of which is presented in Fig-ures 7.11 and 7.12. By inspecting the getInverse operation in the WSDL document, the agentwould be informed accordingly that it can request for a matrix inverse operation by sending aSOAP message to usingthe message defined between lines 29–34 of Figure 7.11. Composition of application Web Services may be performed in a similar manner bysuccessively repeating the above procedure in the service planning stage. Monitoring ofservice executions during the service execution and monitoring stage may be performed byapplication Web Services assigning to the agents, for a particular request, a unique URL towhich they can send SOAP request messages and receive informative SOAP messages aboutthe status of the request, as well as a URIref to the DAML+OIL ontology that describes sucha status. Construction of the service enactment facilities is thus to devise a series of non-ground XML expressions and XET rules that is capable of delivering the presented reasoningfunctionalities.7.4 Application Web Services Development After the infrastructure components for the proposed framework are developed, de-tailed implementation of application Web Services will be designed and constructed. Ap-plication Web Services will be developed such that heterogeneous operations among them,which require the uses of infrastructures developed in the previous section, are exhibited. Apreliminary list of application Web Services to be developed and the types of services thatthey provide, which correspond to the service profile hierarchy in Figure 7.5, are presentedin Table 7.5, with a tentative schedule for the development of each presented in Figure 7.17. An application Web Services can be regarded as a subroutine in the procedural pro-gramming paradigm, driven and supported by knowledge bases comprised of ontologies andrules. Thus, being a subroutine in the procedural programming paradigm, the formats (or,formally, the schemas) of input and output data, as well as intermediate data and detailedimplementaion in programming languages, are necessary. Being driven and supported byknowledge bases, construction of ontologies and rules that drive and support the operation is 63
  • 72. Table 7.5: Preliminary List of Application Web Services to be DevelopedService Name Description Profile Classa InterfacesCompMechRegistry service registry broker for ServiceRegistryBroker SOAP requests the prototype systemAgentAWebService front-end structural StructuralAnalysisService Web browser analysis agent interface for end-users, SOAP requestsAgentBFemService specializes in finite FiniteElement- SOAP requests element methods for AnalysisService problems in elasticity and elastoplasticityLSESolver specializes in solving LinearSystemOf- SOAP requests linear systems of equations EquationsSolverNLSESolver specializes in solving NonlinearSystemOf- SOAP requests non-linear systems of EquationsSolver equationsSIMeasureService provides information on SI MeasurementInfoService SOAP requests unitsUSMeasureService provides information on MeasurementInfoService SOAP requests US customary unitsASTMMaterialService provides information on MaterialInfoService SOAP requests ASTM material standardsUBCInfoService provides information on DesignStandard- SOAP requests the Uniform Building InfoService CodeACIInfoService provides information on DesignStandard- SOAP requests the ACI building code InfoService requirementsAISCInfoService provides information on DesignStandard- SOAP requests the AISC design InfoService specificationsa See definitions in Figure 7.5 64
  • 73. also needed. The following subsections explain these aspects in detail.7.4.1 Design of XML Schemas and Ontologies The schemas (or formats) of input, intermediate, and output data are important tointeroperations among application Web Services and clients, as well as local operations ofthe application Web Services themselves. Schemas can be regarded as structure definitions inthe C programming language, or class definitions in object-oriented programming languages,such as C++ and Java. An application Web Service takes input data from its client, processesit, and presents the output back to the client, which could be another application Web Serviceor an end-user client, in a broader sense. It locally stores intermediate data and transforms itso that it conforms to the input format specified by other application Web Services when itneeds any assistance from the others. Exchanges of these data require shared understandings of each schema element amongthe involved parties. In a simple case, shared understandings can be achieved when each ofthe two parties adopts the same schema. In a more complex case, when each of the partiesadopts its own schema, terms and concepts in the schema need to be arbitrated and mappedby using ontologies and rules, as discussed in Section 7.3.2. As described in Section 7.1, application Web Services, a key component in the pro-posed framework, will communicate via SOAP, an XML-based protocol. As such, the tasksinvolved in the design of XML schemas and ontologies are to define the schema of input,output, and intermediate data, using the XML Schema definition language, and to provideDAML+OIL ontological descriptions of the terms and concepts in the schema, to supportarbitration between parties adopting different set of schemas. An example of XML Schema definition for input and output data is that betweenlines 11–27 of Figure 7.11, which defines SOAPMatrix used in the SOAP input and outputmessages defined between lines 29–34 of the same figure. As another example, an input datathat represents the structural model in Figure 7.13 is presented in Figures 7.14 and 7.15. Thekeywords youngsModulus, poissonRatio, and density used in the figures are as defined bythe DAML+OIL material ontology presented in Figure 7.3, with youngsModulus being aninstance of YoungsModulus, poissonsRatio being an instance of PoissonsRatio, and densitybeing an instance of Density, respectively.7.4.2 Construction of DAML-S Ontology Instances and WSDL Documents DAML-S ontology instances and WSDL documents can be regarded as the blueprintsthat control the operations of application Web Services and how they interact with the oth-ers. A preliminary example of a DAML-S ontology instance that controls the operationsof AgentBFemService in Table 7.5, which is an application Web Service that specializes infinite element methods, is presented in Figure 7.16. An example of WSDL document thatspecifies the schemas of input and output data as well as how a Web Service can be accessedis presented in Figures 7.11 and 7.12. Application Web Services inform other application Web Services of their identities,capabilities, and quality of service through instances of DAML-S ServiceProfile subclassesadvertised on and made accessible by service registry brokers. Application Web Servicesinterested in other application Web Services may inspect the ParameterDescription instancesavailable in service profiles to determine whether the input, output, precondition, and effectof the services match their requirements. Once a decision is made to select a particularservice, detailed descriptions, such as the schemas of input and output data, the URI to whicha SOAP request message is submitted, and the URI from which the SOAP response message 65
  • 74. is received, can be further investigated from the instances of DAML-S ServiceGroundingsupported by that service. During the operation of an application Web Service, its instances of DAML-S Ser-viceModel, particularly those of AtomicProcess, SimpleProcess, CompositeProcess, Pro-cessComponent, and ControlConstruct, are also used to control how process components (orthe computing modules in Figure 7.2) interact to accomplish services that it offers. For each process defined in the service model, an application Web Service can de-termine whether it can handle the process by itself by verifying whether a correspondingatomic process grounding exists in its ServiceGrounding instances. If such an atomic pro-cess grounding does not exist, the application Web Service, through the assistance of aservice registry broker, can create one that maps to the URI of a service provided by theothers. Hence this also explains how semantic composition of application Web Services isperformed.7.4.3 Implementation and Deployment of Application Web Services To provide a heterogeneous prototype environment, application Web Services listedin Table 7.5 will be developed and deployed, per their respective DAML-S and WSDLblueprints from the previous section, on various platforms and environments that supportXML SOAP messaging. These include the platforms and environments such as: 1. Java Servlets1 on PC-based servers2 running Windows XP operating system, 2. Java Servlets on PC-based servers running Linux operating system, 3. Java Servlets on parallel computer clusters running Linux operating system, and 4. Microsoft .NET3 Web Services on PC-based servers running Windows XP operating system. Application Web Services based on Java Servlet technology will be implementedin the Java programming language using open-source XML SOAP messaging toolkits suchas Apache Axis (Apache, 2003) by the Apache software foundation. Those based on Mi-crosoft .NET technology will be implemented in proprietary languages by Microsoft, suchas Visual Basic .NET or C#. Software libraries necessary for scientific computations, such asoperations on matrices and solution to linear systems of equations, will be non-commercialones from the public domain.7.5 Illustrative Applications of the Framework The prototype system, with infrastructure components developed and applicationWeb Services deployed, will be applied to problems in linear elasticity and elastoplasticity. Itwill be applied to problems for which closed form solutions are available in the literature toverify the validity of the framework and itself, and will be applied to general problems, withor without closed-form solutions, as a demonstration. Accuracy of the results for problemswith closed-form solutions can be determined by comparison with closed-form solutions.Accuracy of the ones without closed-form solutions can be determined by comparing againstthe results from well-accepted finite element analysis software. 1 (see Sun, 2003) 2 typicalpersonal computers configured to perform a server role in the distributed computing paradigm 3 (see Microsoft, 2003) 66
  • 75. Domain Ontology ACI Design & Metric System of Construction Measurement Manuals Domain Ontology AISC Design & US Customary Construction System of Measurement Manuals Institutions Sensors Scalar SI Measurement Vectors Building Code Service Profile Matrices Ontologies Tensors Operations British Building Code Quality Rating Material Properties Ontologies General Knowledge in NBC Building Code JIS Material Scientific Computing Government Agencies Specifications Institutions KB UBC Building Code ASTM Material Specifications FEM Input/Output Schemas Analysis Process Service Registry Boundary Ontologies Conditions Knowledge Broker Bases Analysis Types: Matrix Ontology67 (KB) static, dynamic, fracture, etc. Solution Techniques Analysis Rules KB Process etc. Ontologies Structural Analysis Agent “A” KB Structural Analysis Pictu Agent “B” Movie User & Web Browser res s Equation Solver Service Visualization Real World Process Process Problems Ontologies Ontologies KB KB Visualization Service Special-purpose Service Figure 7.1: An Overview of the Proposed Semantic Web Services for Computational Mechanics Framework
  • 76. Database Components Processing Text-based Query Data Application DB DB DB Local Local Local Database Database Database Server Server Server Client Query Answer Application Logic Components Web Browser Computing Computing Computing Module A Module B Module n Request ... Response Application Application Application Client Web Service 1 Web Service 2 Web Service n Query Answer Knowledge Base GUI-based Components Application Inference Engine Ontologies Rules KB KB KB Local Local Local Client Knowledge Base Knowledge Base Knowledge Base Server Server ServerFigure 7.2: The Multi-tier System Architecture adopted in the SWSCM Framework(adapted from Cyran, 2002) 68
  • 77. sc sc sc sc BaseUnit forcePerUnitArea sc sc UnitOfMeasurement Equation daml:Thing ksi sc DerivedUnit sc sc sc sc sc Scalar Response GPa sc sc sc UltimateStrength Quantity sc Material Property sc Vector sc Stress Strain ShearStrain PoissonsRatio sc sc sc sc sc hasProperty sc Compressive- sc representedBy sc MathQuantity BrittleMaterial Strength Matrix sc MaterialProperty sc sc hasUnit AxialStrain PlasticModulus sc hasUnit sc sc hasUnit sc ShearStrength PhysicalQuantity sc DuctileMaterial sc sc sc sc sc Density ShearStress TensileStrain Isotropic- sc sc PlasticModulus sc sc sc sc sc TensileStrength Base- PhysicalQuantity AxialStress CompressiveStrain ElasticMaterial FractureToughness Kinematic- sc Derived- PlasticModulus PhysicalQuantity sc Length sc sc TensileStress sc sc sc InelasticMaterial Mass sc CompressiveStress69 ModulusOfElasticity ProportionalLimit sc sc Area sc LinearElasticMaterial sc hasUnit sc sc hasUnit sc Shear- sc Shear- Time ProportionalLimit Volume Pressure ModulusOfElasticity rdf:_2 NonlinearElasticMaterial rdf:_1 Tensile- Tensile- ProportionalLimit ModulusOfElasticity Legend sca rel : sc sca YieldStrength terms.daml#relates hasEquation sc : daml:subClassOf rel rdf:parseType sca : daml:sameClassAs YoungsModulus rel : dummy node Foreign term HookesLaw daml:collection mapped into local ontology Note Default namespace: “Hooke’s Law” materials.daml# Figure 7.3: Example of a Material Ontology
  • 78. daml:toClass rdf:type rdf:type rdf:type rdf:type xsd:string Resource providedBy daml:first daml:Restriction Service supports daml:Restriction ServiceGrounding daml:onProperty daml:onProperty daml:onProperty daml:toClass daml:toClass presents xsltTransformationString sc daml:first daml:rest sc sc daml:onProperty describedBy WsdlInputMessage- sc daml:toClass Map sc daml:List Legend ServiceModel ServiceProfile sc sc WsdlOutputMessage- sc daml:rest sc : daml:subClassOf WsdlOutputMessage- Map MapList sca : daml:sameClassAs wsdlVersion : dummy node WsdlMessageMap wsdlMessagePart wsdlDocument xsd:anyURI WsdlInputMessage- wsdlOutputs MapList operation wsdlOutputMessage xsd:anyURI WsdlOperationRef xsltTransformationURI portType wsdlInputs xsd:anyURI ProcessPowerSet daml:subClassOf WsdlAtomicProcess- Grounding wsdlOperation wsdlInputMessage WsdlGrounding damlsParameter hasAtomicProcessGrounding damlsProcess xsd:string has_process daml:subClassOf AtomicProcess- xsd:string xsd:string serviceName PowerSet ProcessControlModel ParameterPowerSet daml:Thing daml:Thing textDescription hasControlModel ratingName True, False qualityRating xsd:string daml:subClassOf TestValue hasProcess Profile rating ProcessModel contactInformation daml:collection sc QualityRating conditionValue rdf:parseType webURL rdf:_2 time:Interval ProcessPowerSet daml:subClassOf xsd:string name physicalAddress serviceParameter TestCondition sc daml:onProperty sca title Actor DAndBRating ControlConstruct rdf:type during70 ServiceParameter rdf:_1 xsd:string timeout phone xsd:string sc Literal email sParameter nextProcessComponent ratingName Dun and Bradstreet sc time:Instant daml:Restriction serviceParameterName daml:hasValue fax sc currentProcessComponent daml:unionOf Rating sc sc startTime name sc sc parameter xsd:string sc sc sc endTime xsd:string serviceCategory xsd:string sc daml:Thing sc input daml:collection Process AverageResponseTime ProcessComponent composedOf output parameter Sequence currentStatus participant xsd:string (input/output/ daml:disjointUnionOf daml:Thing daml:toClass rdf:type ConditionalOutput precondition/effect) sParameter rdf:parseType MaxResponseTime sc daml:List sParameter Split sc daml:Restriction rdf:_1 daml:Thing ParameterDescription Duration daml:onProperty sc components sc Duration precondition AtomicProcess parameterName sc refersTo ServiceCategory ProcessComponent- sc daml:item effect Condition Split-Join List rdf:_2 rdf:_1 code GeographicRadius realizes realizedBy xsd:string components daml:collection sParameter rdf:_3 value categoryName ParameterPowerSet ProcessControlStatus SimpleProcess components taxonomy Unordered ProcessComponent- xsd:string Country ConditionalEffect Bag rdf:parseType Completed daml:collection components rdf:_6 expandsTo xsd:string daml:oneOf sc rdf:_1 collapsesTo rdf:_5 1 Choice components Canceled rdf:_2 rdf:_4 CompositeProcess rdf:parseType sc chooseFrom daml:cardinality xsd:string Ready rdf:_3 rdf:_2 xsd:string Aborted daml:onProperty invocable daml:intersectionOf components Iterate Ongoing Suspended computedInput computedPrecondition categoryName components NAICS rdf:type UNSPSC computedOutput computedEffect composedOf NAICS If-Then-Else xsd:boolean taxonomy else then ifCondition Condition daml:Restriction categoryName UNSPSC whileProcess daml:Thing ProcessComponent Repeat-While whileCondition untilProcess untilCondition Repeat-Until Figure 7.4: The DAML-S Ontology
  • 79. damls:Profile sc sc sc ComputationService ServiceRegistryBroker InformationService sc sc sc sc sc sc StructuralAnalysis- MeasurementInfo- DesignStandardInfo- VisualizationService MathematicalService Service Service Service sc sc sc MaterialInfoService EquationSolver FiniteElement- sc IntegralService AnalysisService sc sc sc PolynomialEquation- Solver ClosedForm- SystemOfEquations- AnalysisService Solver sc sc LinearSystemOf- NonlinearSystemOf- MatrixService EquationsSolver EquationsSolver sc sc MatrixDeterminant- MatrixInversion- Service Service sc sc DirectMatrix- IterativeMatrix- InversionService InversionServiceFigure 7.5: A Service Profile Hierarchy for Computational Mechanics Application WebServices daml:Thing sc Scalar Quantity Vector sc sc sc sc MathQuantity Matrix sc sc sc SparseMatrix DenseMatrix BandedMatrix Figure 7.6: A Hierarchy of Matrices Involved in Computational Mechanics 71
  • 80. DirectMatrix- InversionService damls:Service QualityRating damls:WsdlGrounding sc presents sc ScienceNetMatInv- damls:WsdlAtomic- sc sc Profile ProcessGrounding qualityRating supports rating ScienceNetMatInv ScienceNetMatInv- WsdlGrounding CompMechRating Class A describedBy sc hasAtomicProcessGrounding ScienceNetMatInv- ScienceNetMatInv- WAPG damls:WsdlOperationRef sc ProcessModel damls:ProcessModel hasProcess wsdlOperation damlsProcess sc ScienceNetMatInv- sc ScienceNetMatInv- damls:AtomicProcess Process WOR input operation Matrix 7.7: DAML-S Ontology Instance Describing Matrix Inversion Service IterativeMatrix- InversionService damls:Service QualityRating damls:WsdlGrounding sc presents sc NumMethOrgMatInv- damls:WsdlAtomic- Profile sc sc ProcessGrounding qualityRating supports rating NumMethOrgMatInv NumMethOrgMatInv- WsdlGrounding CompMechRating Class A describedBy sc hasAtomicProcessGrounding NumMethOrgMatInv- NumMethOrgMatInv- WAPG damls:WsdlOperationRef sc ProcessModel damls:ProcessModel hasProcess wsdlOperation damlsProcess sc NumMethOrgMatInv- sc Process NumMethOrgMatInv- damls:AtomicProcess WOR input operation SparseMatrix matInv.wsdl#getInverseFigure 7.8: DAML-S Ontology Instance Describing Matrix InversionService 72
  • 81. IterativeMatrix- InversionService damls:Service QualityRating damls:WsdlGrounding sc presents sc OptimizeComMatInv- damls:WsdlAtomic- Profile sc sc ProcessGrounding qualityRating supports rating OptimizeComMatInv OptimizeComMatInv- WsdlGrounding CompMechRating Class A describedBy sc hasAtomicProcessGrounding OptimizeComMatInv- OptimizeComMatInv- WAPG damls:WsdlOperationRef sc ProcessModel damls:ProcessModel hasProcess wsdlOperation damlsProcess sc OptimizeComMatInv- sc Process OptimizeComMatInv- damls:AtomicProcess WOR input operation DenseMatrix matinverse.wsdl#opInverseFigure 7.9: DAML-S Ontology Instance Describing Matrix Inversion Service IterativeMatrix- InversionService damls:Service QualityRating damls:WsdlGrounding sc presents sc NumRecpNetMatInv- damls:WsdlAtomic- Profile sc sc ProcessGrounding qualityRating supports rating NumRecpNetMatInv NumRecpNetMatInv- WsdlGrounding CompMechRating Class B describedBy sc hasAtomicProcessGrounding NumRecpNetMatInv- NumRecpNetMatInv- WAPG damls:WsdlOperationRef sc ProcessModel damls:ProcessModel hasProcess wsdlOperation damlsProcess sc NumRecpNetMatInv- sc Process NumRecpNetMatInv- damls:AtomicProcess WOR input operation SparseMatrix matrixInverse.wsdl#doInverseFigure 7.10: DAML-S Ontology Instance Describing Matrix InversionService 73
  • 82. <wsdl:definitions xmlns="" xmlns:xs="" xmlns:wsdl="" xmlns:http="" 5 xmlns:mime="" xmlns:soap="" xmlns:soapenc="" xmlns:nmeth="" targetNamespace="">10 <wsdl:types> <xs:schema xmlns="" targetNamespace=""> <import namespace=""/> <complexType name="TwoDimArrayOfDoubles">15 <complexContent> <restriction base="soapenc:Array"> <attribute ref="soapenc:arrayType" wsdl:arrayType="xs:double[][]"/> </restriction> </complexContent>20 </complexType> <complexType name="SOAPMatrix"> <sequence> <element name="matrix" nillable="true" type="nmeth:TwoDimArrayOfDoubles"/>25 </sequence> </complexType> </xs:schema> </wsdl:types> <message name="getInverseRequest">30 <part name="srcMatrix" type="nmeth:SOAPMatrix"/> </message> <message name="getInverseResponse"> <part name="getInverseReturn" type="nmeth:SOAPMatrix"/> </message> Figure 7.11: WSDL Description of a Matrix Inversion Web Service by (adapted from Sintopchai et al., 2003) (Part 1 of 2) 74
  • 83. <portType name="MatrixService"> <operation name="getInverse" parameterOrder="srcMatrix"> <input name="getInverseRequest" message="nmeth:getInverseRequest"/> <output name="getInverseResponse" message="nmeth:getInverseResponse"/> 5 </operation> </portType> <binding name="MatrixServiceSoapBinding" type="nmeth:MatrixService"> <soap:binding style="rpc" transport=""/>10 <operation name="getInverse"> <soap:operation/> <input> <soap:body use="encoded" encodingStyle=""15 namespace=""/> </input> <output> <soap:body use="encoded" encodingStyle=""20 namespace=""/> </output> </operation> </binding> <service name="MatrixService">25 <port name="MatrixWS" binding="nmeth:MatrixServiceSoapBinding"> <soap:address location=""/> </port> </service>30 </wsdl:definitions> Figure 7.12: WSDL Description of a Matrix Inversion Web Service by (adapted from Sintopchai et al., 2003) (Part 2 of 2) 75
  • 84. Y in 6.00 in 3 .00 5.00 in Z 1.00 in X 10.0 kN in 1 .0 0Figure 7.13: Model of a Structure to be Analyzed by a Structural Analysis Agent 76
  • 85. <?xml version="1.0" encoding="UTF-8"?> <input> <problemParams> <analysisMode>3D</analysisMode> 5 <basisOrder>2</basisOrder> <quadratureOrder>2</quadratureOrder> </problemParams> <materials> <material id="Steel">10 <youngsModulus unit="GPa">200</youngsModulus> <poissonRatio>0.25</poissonRatio> <yieldStress unit="MPa">240</yieldStress> <density unit"kg/mˆ3">7850</density> </material>15 </materials> <geometry> <startPoint> <point coordType="cartesian" unit="inch" x1="0.00" x2="0.00" x3="0.00"/> </startPoint>20 <endPoint> <point coordType="cartesian" unit="inch" x1="6.00" x2="5.00" x3="3.00"/> </endPoint> <numCells x1="12" x2="10" x3="6"/> </geometry>25 <boundaryConds> <forces> <nodalForce id="fn01"> <point coordType="cartesian" unit="inch" x1="6.00" x2="0.00" x3="3.00"/> <direction coordType="cartesian">X</direction>30 <magnitude unit="kN">10.0</magnitude> </nodalForce> <nodalForce id="fn02"> <point coordType="cartesian" unit="inch" x1="6.00" x2="0.00" x3="2.25"/> <direction coordType="cartesian">X</direction>35 <magnitude unit="kN">10.0</magnitude> </nodalForce> <nodalForce id="fn03"> <point coordType="cartesian" unit="inch" x1="6.00" x2="1.00" x3="3.00"/> <direction coordType="cartesian">X</direction>40 <magnitude unit="kN">10.0</magnitude> </nodalForce> <nodalForce id="fn04"> <point coordType="cartesian" unit="inch" x1="6.00" x2="1.00" x3="2.25"/> <direction coordType="cartesian">X</direction>45 <magnitude unit="kN">10.0</magnitude> </nodalForce> </forces> Figure 7.14: Example of an Input Data that Represents the Model in Figure 7.13 (Part 1 of 2) 77
  • 86. <displ id="dn01"> <point coordType="cartesian" unit="inch" x1="0.00" x2="0.00" x3="0.00"/> <direction coordType="cartesian">X</direction> <dispVal unit="cm">0.00</dispVal> 5 </displ> <displ id="dn02"> <point coordType="cartesian" unit="inch" x1="0.00" x2="0.00" x3="0.00"/> <direction coordType="cartesian">Y</direction> <dispVal unit="cm">0.00</dispVal>10 </displ> <displ id="dn03"> <point coordType="cartesian" unit="inch" x1="0.00" x2="0.00" x3="0.00"/> <direction coordType="cartesian">Z</direction> <dispVal unit="cm">0.00</dispVal>15 </displ> <displ id="dn04"> <point coordType="cartesian" unit="inch" x1="6.00" x2="5.00" x3="3.00"/> <direction coordType="cartesian">X</direction> <dispVal unit="cm">0.00</dispVal>20 </displ> <displ id="dn05"> <point coordType="cartesian" unit="inch" x1="6.00" x2="5.00" x3="3.00"/> <direction coordType="cartesian">Y</direction> <dispVal unit="cm">0.00</dispVal>25 </displ> <displ id="dn06"> <point coordType="cartesian" unit="inch" x1="6.00" x2="5.00" x3="3.00"/> <direction coordType="cartesian">Z</direction> <dispVal unit="cm">0.00</dispVal>30 </displ> </boundaryConds> <postProcSpecs> <dispLoc> <point coordTyp="cartesian" unit="inch" x1="6.00" x2="1.00" x3="3.00"/>35 <point coordTyp="cartesian" unit="inch" x1="6.00" x2="2.00" x3="3.00"/> <point coordTyp="cartesian" unit="inch" x1="6.00" x2="3.00" x3="3.00"/> <point coordTyp="cartesian" unit="inch" x1="6.00" x2="4.00" x3="3.00"/> <point coordTyp="cartesian" unit="inch" x1="6.00" x2="5.00" x3="3.00"/> </dispLoc>40 <stressLoc> <point coordTyp="cartesian" unit="inch" x1="6.00" x2="1.00" x3="3.00"/> <point coordTyp="cartesian" unit="inch" x1="6.00" x2="2.00" x3="3.00"/> <point coordTyp="cartesian" unit="inch" x1="6.00" x2="3.00" x3="3.00"/> <point coordTyp="cartesian" unit="inch" x1="6.00" x2="4.00" x3="3.00"/>45 <point coordTyp="cartesian" unit="inch" x1="6.00" x2="5.00" x3="3.00"/> </stressLoc> </postProcSpecs> </input> Figure 7.15: Example of an Input Data that Represents the Model in Figure 7.13 (Part 2 of 2) 78
  • 87. FiniteElement- AnalysisService damls:Service AgentBFemService- damls:WsdlGrounding DiscretizeWAPG QualityRating sc presents sc AgentBFemService- hasAPG AgentBFemService- sc GForceWAPG sc Profile supports qualityRating hasAPG rating AgentBFemService hasAPG AgentBFemService- WsdlGrounding AgentBFemService- CompMechRating Class A GStiffnessWAPG describedBy hasAtomicProcessGrounding hasAPG AgentBFemService- BoundaryWAPG sc AgentBFemService- damls:ProcessModel AgentBFemService- SolutionWAPG hasProcess ProcessModel sc damls:WsdlAtomic- hasProcess wsdlOperation ProcessGrounding hasProcess Discretization- AtomicProcess hasProcess sc hasProcess damlsProcess Solution- AgentBFemService- damls:WsdlOperationRef AtomicProcess SolutionWOR GForceAtomicProcess operation Boundary- AtomicProcess GStiffness- AtomicProcess processes.wsdl#getSolution rdf:_1 rdf:_5 rdf:_2 damls:Composite- rdf:_3 rdf:_4 MainFemProcess sc Process daml:toClass daml:toClass damls:listOfInstancesOf sc daml:Restriction rdf:type rdf:type daml:intersectionOf daml:onProperty rdf:parseType daml:Restriction rdf:_2 daml:onProperty rdf:_1 daml:collection damls:composedOf rdf:parseType damls:components damls:Sequence daml:collectionFigure 7.16: DAML-S Ontology Instance Describing Finite Element Service by StructuralAnalysis Agent B 79
  • 88. 2003 2004 2005 Task Description 4th Term 5th Term 6th Term 7th Term 8th Term 9th Term Dec. Jan. Feb. Mar. Apr. May June July Aug. Sept. Oct. Nov. Dec. Jan. Feb. Mar. Apr. May June July Aug. Infrastructure Design and Development Research Begins 1. Construction of domain ontologies 2. Construction of ontology mapping facilities 3. Construction of service enactment facilities 4. Deployment of the infrastructure and test cases First progress report to examination committee 1st Progress Report Application Web Services Development 4. Design of master plan for application Web Services 5. Development of CompMechRegistry 6. Development of AgentAWebService 7. Development of AgentBFemService Second progress report to examination committee 2nd Progress Report80 8. Development of LSESolver and NLSESolver 9. Development of SIMeasureService 10. Development of USMeasureService 11. Development of ASTMMaterialService Third progress report to examination committee 3rd Progress Report 12. Development of UBCInfoService 13. Development of ACIInfoService 14. Development of AISCInfoService 15. Deployment of the prototype system and test cases Fourth progress report to examination committee 4th Progress Report Documentation Tasks 16. Preparation of the thesis and mandatory web site Final thesis defense Final Defense Figure 7.17: Preliminary Schedule for the Proposed Research Tasks
  • 89. Table 7.6: Expenditure Estimates for the Proposed Research Item Cost (Baht) Laboratory equipment 10,000 Textbooks and article reprints 10,000 Photocopies 5,000 Transportation and communications 3,000 Thesis binding 2,000 Total 30,000 81
  • 90. 82
  • 91. REFERENCESAdeli, H. and Kamal, O. (1993). Parallel Processing in Structural Engineering. Elsevier, U.K., 1993.AHD (1992). The American Heritage Dictionary of the English Language. Houghton Mifflin Company, third edition, 1992.Akama, K. (1993). Declarative semantics of logic programs on parameterized representation systems. Advances in Software Science and Technology, 5:45–63, 1993.Akama, K., Shimitsu, T., and Miyamoto, E. (1998). Solving problems by Equivalent Trans- formation of Declarative Programs. Journal of the Japanese Society of Artificial Intelli- gence, 13(6):944–952, 1998. In Japanese.Akama, K., Koike, H., and Mabuchi, H. (2001). A theoretical foundation of program synthesis by Equivalent Transformation. In Perspectives of System Informatics, vol- ume 2244 of Lecture Notes in Computer Science, pages 131–139. Springer Verlag, Heidelberg, 2001. Available online: papers/paper1.pdf. [Downloaded: October 8, 2003].Akama, K., Nantajeewarawat, E., and Koike, H. (2002). Program synthesis based on the Equivalent Transformation computation model. In Proceedings of the 12th International Workshop on Logic Based Program Development and Transformation (LOPSTR 2002), pages 285–304, Madrid, Spain, 2002. Available online: http://assam.cims.hokudai. [Downloaded: October 8, 2003].Anderson, D. P., Cobb, J., Korpela, E., Lebofsky, M., and Werthimer, D. (2002). SETI@home: An experiment in public-resource computing. Communications of the ACM, 45(11):56–61, November 2002. Available online: http://setiathome.ssl.berkeley. edu/cacm/cacm.html. [Downloaded: December 13, 2002].Ankolenkar, A., Burstein, M., Hobbs, J. R., Lassila, O., Martin, D. L., McDermott, D., McIl- raith, S. A., Narayanan, S., Paolucci, M., Payne, T. R., and Sycara, K. (2002). DAML-S: Web Service description for the Semantic Web. In Proceedings of the First International Semantic Web Conference (ISWC), Sardinia, Italy, June 2002.Anutariya, C., Wuwongse, V., Akama, K., and Wattanapailin, V. (2001). Semantic Web modeling and programming with XDD. In Proceedings of the First Semantic Web Work- ing Symposium (SWWS’01), pages 161–180, California, USA, July 2001. Available on- line: [Downloaded: October 9, 2003].Anutariya, C., Wuwongse, V., and Wattanapailin, V. (2002). An Equivalent-Transformation- based XML Rule Language. In Proceedings of the International Workshop on Rule Markup Languages for Business Rules in the Semantic Web, Sardinia, Italy, June 2002. Available online: [Down- loaded: July 21, 2003].Apache (2003). Apache Axis 1.1 Release Candidate 1. Apache Software Foundation, 2003. Available online: 83
  • 92. Baker, M. and Buyya, R. (1999). Cluster computing: the commodity supercomputer. Software–Practice and Experience, 29(6):551–576, 1999. Available online: http: //, S., Biswas, R., Saini, S., der Wijngaartand M. Yarrow, R. V., Zechter, L., Fos- ter, I., and Larsson, O. (1999). Large-scale distributed computational fluid dynamics on the Information Power Grid using Globus. In Proceedings of Frontiers ’99, 1999. Available online: [Downloaded: June 6, 2003].Barry, W. and Vacharasintopchai, T. (2001a). A queue server approach to parallelizing the Element-Free Galerkin Method. In Proceedings of the Fifth Annual National Sympo- sium on Computational Science and Engineering, Bangkok, Thailand, June 2001. Na- tional Electronics and Computer Technology Center of Thailand. ISBN 974-229-024-5.Barry, W. and Vacharasintopchai, T. (2001b). A parallel implementation of the Element-Free Galerkin Method. In Proceedings of the Eight East Asia-Pacific Conference on Structural Engineering and Construction (EASEC-8), Singapore, December 2001. Nanyang Techno- logical University.Basha, S., Cable, S., Galbraith, B., Hendricks, M., Irani, R., Milbery, J., Modi, T., Tost, A., and Toussaint, A. (2002). Professional Java Web Services. Wrox Press, Ltd., 2002. ISBN 1-861003-75-7.Belytschko, T., Lu, Y. Y., and Gu, L. (1994). Element-free galerkin methods. International Journal for Numerical Methods in Engineering, 37:229–256, 1994.Berners-Lee, T., Fielding, R., and Masinter, L. (1998). RFC2396 Uniform Resource Identi- fiers (URI): Generic Syntax. The Internet Engineering Task Force (IETF), August 1998. Available online: [Downloaded: August 29, 2003].Berners-Lee, T., Masinter, L., and McCahill, M. (1994). RFC1738 Uniform Resource Lo- cators (URL). The Internet Engineering Task Force (IETF), December 1994. Available online: [Downloaded: August 29, 2003].Berners-Lee, T., Cailliau, R., Groff, J.-F., and Pollermann, B. (1992). World-Wide Web: The information universe. Electronic Networking: Research, Applications and Policy, 1(2): 74–82, 1992. Available online: [Downloaded: September 3, 2003].Berners-Lee, T., Hendler, J., and Lassila, O. (2001). The Semantic Web. Scientific American, 284(5):34–43, May 2001.Biron, P. V. and Malhotra, A. (2001). XML Schema Part 2: Datatypes. World Wide Web Consortium (W3C), May 2001. Available online: xmlschema-2. [Downloaded: June 23, 2003].Bray, T., Paoli, J., Sperberg-McQueen, C. M., and Maler, E. (2000). Extensible Markup Language XML 1.0 (Second Edition). World Wide Web Consortium (W3C), October 2000. Available online: [Downloaded: June 23, 2003]. 84
  • 93. Broekstra, J., Klein, M., Decker, S., Fensel, D., van Harmelen, F., and Horrocks, I. (2002). Enabling knowledge representation on the Web by extending RDF Schema. Computer Networks, 39(5):609–634, 2002.Brown, C. (1994). UNIX Distributed Programming. Prentice Hall, 1994. ISBN 0-13- 075896-5.Catlett, C. (2002). TeraGrid Primer. The TeraGrid Project, September 2002. Available on- line: [Down- loaded: June 10, 2003].Chew, P., Chrisochoides, N., Gopalsamy, S., Heber, G., Ingraffea, T., Luke, E., Neto, J., Pingali, K., Shih, A., Soni, B., Stodghill, P., Thompson, D., Vavasis, S., and Wawrzynek, P. (2003). Computational science simulations based on Web Services. In Proceedings of International Conference on Computational Science 2003, St. Petersburg, Russian Feder- ation and Melbourne, Australia, June 2003. Available online: http://www.cs.cornell. edu/stodghil/papers/iccs03.pdf. [Downloaded: September 3, 2003].Chiu, K., Govindaraju, M., and Bramley, R. (2002). Investigating the limits of SOAP performance for scientific computing. In Proceedings of 11th IEEE International Sym- posium on High Performance Distributed Computing (HPDC-11), Edinburgh, Scot- land, July 2002. Available online: soap-hpdc2002/soap-hpdc2002.pdf. [Downloaded: September 3, 2003].Collins (2000). The Collins English Dictionary. HarperCollins Publishers, 2000.Cook, R. D., Malkus, D. S., and Plesha, M. E. (1989). Concepts and Applications of Finite Element Analysis. John Wiley & Sons, New York, 1989. ISBN 0-471-84788-7.Cyran, M. (2002). Oracle9i Database Concepts, Release 2 (9.2), chapter 6: Application Architecture. Oracle Corporation, 2002.DAML (2001). DAML+OIL Language Specification. The Defense Advanced Research Projects Agency Agent Markup Language (DAML) Program, March 2001. Available on- line: [Downloaded: September 19, 2003].DAML (2002). Language feature comparison, The Defense Advanced Research Projects Agency Agent Markup Language (DAML) Program, August 2002. Available on- line: [Downloaded: September 29, 2003].DAML (2003). The DAML homepage, The Defense Advanced Research Projects Agency Agent Markup Language (DAML) Program, June 2003. Available online: http://www. [Downloaded: September 29, 2003].DAML-S (2003a). DAML-S DAML Services homepage, The DAML Services Coalition, September 2003. Available online: [Downloaded: October 1, 2003].DAML-S (2003b). DAML-S: Semantic markup for Web Services. Technical report, The DAML Services Coalition, June 2003. Available online: services/daml-s/0.9/daml-s.pdf. [Downloaded: July 10, 2003]. 85
  • 94. Ding, Y., Fensel, D., Klein, M. C. A., and Omelayenko, B. (2002). The Semantic Web: Yet another hip? Data and Knowledge Engineering, 41(2–3):205–227, June 2002. Available online:˜ying/download/dke2001.pdf.Fallside, D. C. (2001). XML Schema Part 0: Primer. World Wide Web Consortium (W3C), May 2001. Available online: [Downloaded: June 23, 2003].Fensel, D. and Bussler, C. (2002). The Web Service Modeling Framework WSMF. Technical report, Vrije Universiteit Amsterdam, 2002. Available online: http://gunther.smeal. [Downloaded: July 17, 2003].Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and Berners-Lee, T. (1999). RFC2616 Hypertext Transfer Protocol – HTTP/1.1. The Internet Engineering Task Force (IETF), June 1999. Available online: [Downloaded: August 29, 2003].Foster, I. and Gannon, D. (2003). The Open Grid Services Architecture Platform. The Global Grid Forum, 2003. Available online: ggf7/drafts/draft-ggf-ogsa-platform-2.pdf. [Downloaded: June 16, 2003].Foster, I., Kesselman, C., and Tuecke, S. (2001). The anatomy of the Grid: Enabling scal- able virtual organizations. International Journal of Supercomputer Applications, 15(3), 2001. Available online: [Downloaded: June 6, 2003].Foster, I. (1995). Designing and Building Parallel Programs: Concepts and Tools for Par- allel Software Engineering. Addison-Wesley Publishing Company, 1995. ISBN 0-201- 57594-9. Available online:, I. (2002a). The Grid: A new infrastructure for 21st century science. Physics Today, 55 (2), February 2002. Available online: html. [Downloaded: June 10, 2003].Foster, I. (2002b). What is the Grid? A three point checklist. July 2002. Available online:˜foster/Articles/ WhatIsTheGrid.pdf. [Downloaded: April 29, 2003].Foster, I. (2003a). The Grid: Computing without bounds. Scientific American, 288(4):78–85, April 2003.Foster, I. (2003b). Selected major Grid application and deployment projects in science and engineering, 2003. Available online:˜foster/ grid-projects. [Downloaded: April 29, 2003].GGF (2003). The Global Grid Forum website, The Global Grid Forum, 2003. Available online: [Downloaded: June 13, 2003].Gil, Y. and Ratnakar, V. (2002). A comparison of (semantic) markup languages. In Proceed- ings of the Fifteenth International Florida Artificial Intelligence Research Society Con- ference, pages 413–418, Pensacola Beach, Florida, USA, May 2002. AAAI Press. ISBN 1-57735-141-X. Available online: semanticweb/flairs02_comparison.pdf. [Downloaded: September 30, 2003]. 86
  • 95. Globus (2003a). The Globus Project website, The Globus Project, 2003. Available online: [Downloaded: June 13, 2003].Globus (2003b). The Globus Toolkit website, The Globus Project, 2003. Available online: [Downloaded: June 16, 2003].Gropp, W. D., Kaushik, D. K., Keyes, D. E., and Smith, B. F. (2001). High-performance parallel implicit CFD. Parallel Computing, 27(4):337–362, 2001. Available online: [Downloaded: July 29, 2003].Grosof, B. N. and Horrocks, I. (2003). Description Logic Programs: Combining logic programs with Description Logic. Working paper, Center for eBusiness, MIT Sloan School of Management, Cambridge, MA, USA, June 2003. Available online: http: // [Downloaded: October 3, 2003].Grosof, B. N., Horrocks, I., Volz, R., and Decker, S. (2003). Description Logic Programs: Combining logic programs with Description Logic. In Proceedigns of the 12th International World Wide Web Conference (WWW2003), Budapest, Hungary, May 2003. Available online: Grosof_Logic.pdf. [Downloaded: October 3, 2003]. MIT eBusiness Working Paper #192.Harold, E. R. (2001). XML Bible. IDG Books Worldwide, 2nd edition, 2001.Heber, G., Dolgert, A. J., Alt, M., Mazurkiewicz, K. A., and Stringer, L. (2001). Fracture Mechanics on the Intel Itanium Architecture. Technical report, Intel Corporation, 2001. Available online: [Downloaded: July 29, 2003].ILLC (2003). The Logic and Language Links (LoLaLi) project, Institute for Logic, Lan- guage and Computation (ILLC), University of Amsterdam, 2003. Available online: [Downloaded: September 29, 2003].IPG (2003). What is the IPG? Information Power Grid Project, NASA, October 2003. Available online: [Downloaded: June 11, 2003].Klensin, J. (2001). RFC2821 Simple Mail Transfer Protocol (SMTP). The Internet Engi- neering Task Force (IETF), April 2001. Available online: rfc2821.txt. [Downloaded: September 13, 2003].Kumar, V., Grama, A., Gupta, A., and Karypis, G. (1994). Introduction to Parallel Comput- ing: Design and Analysis of Algorithms. The Benjamin/Cummings Publishing Company, 1994. ISBN 0-8053-3170-0.Lancaster, P. and Salkauskas, K. (1981). Surfaces generated by moving least squares method. Mathematics of Computation, 37(155):141–158, July 1981.McIlraith, S. A., Son, T. C., and Zeng, H. (2001). Semantic Web Services. IEEE In- telligent Systems. Special Issue on the Semantic Web, 16(2):46–53, March/April 2001. Available online: [Down- loaded: June 17, 2003]. 87
  • 96. Microsoft (1997). Microsoft Press Computer Dictionary. Microsoft Press, third edition, 1997.Microsoft (2003). Microsoft .NET, Microsoft Corporation, 2003. Available online: http: // [Downloaded: November 5, 2003].MPI (1995). MPI: A Message-Passing Interface Standard. Message Passing Interface Fo- rum, June 1995. Available online: mpi-report.html. [Downloaded: July 28, 2003].OASIS (2002). Universal Description, Discovery & Integration (UDDI) Specification Ver- sion 2. Organization for the Advancement of Structured Information Standards (OA- SIS) Consortium, 2002. Available online: uddi-spec/tcspecs.shtml#uddiv2.Ouellet, R. and Ogbuji, U. (2002). Introduction to DAML: Part 1, January 2002. Available online: [Down- loaded: September 25, 2003].PVM (2002). PVM: Parallel Virtual Machine. The PVM Project, Oak Ridge National Laboratory, November 2002. Available online: home.html. [Downloaded: July 28, 2003].Sintopchai, T. V., Barry, W., and Wuwongse, V. (2003). XML Web Services for scientific computing applications. Technical report, Asian Institute of Technology, 2003. Available online:˜st029284/papers/matrix-ws-paper.pdf.Sun (2003). Java Servlet Technology. Sun Microsystems, Inc., 2003. Available online:, S. (2001). Intelligent Web Services. Master’s thesis, Computer Science and Information Management Program, School of Advanced Technologies, Asian Institute of Technology, Thailand, December 2001.Thompson, H. S., Beech, D., Maloney, M., and Mendelsohn, N. (2001). XML Schema Part 1: Structures. World Wide Web Consortium (W3C), May 2001. Available online: [Downloaded: June 23, 2003].Tidwell, D. (2000). Web Services: the Web’s Next Revolution. IBM Corporation, November 2000. Available online: ws-dw-wsbasics-i.html. [Downloaded: July 17, 2003].Ungaro, P. (2003). IBM’s view of grid computing. Presentation, High Performance Com- puting Department, IBM Systems Group, March 2003. Available online: http://www. [Downloaded: June 4, 2003].Unicode (2003). The Unicode Standard, Version 4.0.0. The Unicode Consortium, 2003. Available online: [Downloaded: October 6, 2003].van Engelen, R. A. (2003). Pushing the SOAP envelope with Web Services for scientific computing. In Proceedings of the International Conference on Web Services (ICWS) 2003, Las Vegas, Nevada, USA, June 2003. Available online: http://www.cs.fsu. edu/˜engelen/icws03.pdf. [Downloaded: September 3, 2003]. 88
  • 97. W3C (1999a). HyperText Markup Language (HTML) 4.01 Specification. World Wide Web Consortium (W3C), December 1999. Available online: (1999b). Namespaces in XML. World Wide Web Consortium (W3C), January 1999. Available online: [Downloaded: October 4, 2003].W3C (1999c). Resource Description Framework (RDF) Model and Syntax Specification. World Wide Web Consortium (W3C), February 1999. Available online: http://www. [Downloaded: September 19, 2003].W3C (2000). Simple Object Access Protocol (SOAP) 1.1. World Wide Web Consortium (W3C), 2000. Available online: (2001). Web Service Definition Language (WSDL) 1.1. World Wide Web Consortium (W3C), 2001. Available online: (2002). Semantic Web stack diagram, 2002. Available online: DesignIssues/diagrams/sw-stack-2002.png. [Downloaded: October 3, 2003].W3C (2003a). OWL Web Ontology Language Overview. World Wide Web Con- sortium (W3C), August 2003. Available online: CR-owl-features-20030818. [Downloaded: September 19, 2003]. W3C Candidate Recommendation.W3C (2003b). RDF Primer. World Wide Web Consortium (W3C), September 2003. Available online: [Down- loaded: September 22, 2003]. W3C Working Draft.W3C (2003c). RDF Vocabulary Description Language 1.0: RDF Schema. World Wide Web Consortium (W3C), September 2003. Available online: WD-rdf-schema-20030905. [Downloaded: September 24, 2003]. W3C Working Draft.W3C (2003d). Web Services Architecture. World Wide Web Consortium (W3C), May 2003. Available online: [Downloaded: July 30, 2003]. W3C Working Draft.Warfield, S. K., Talos, F., Tei, A., Nabavi, A., Ferrant, M., Black, P. M., Jolesz, F. A., and Kikinis, R. (2002). Real-time registration of volumetic brain MRI by biomechanical simulation of deformation during Image Guided Neurosurgery. Computing and Visualiza- tion in Science, 5:3–11, 2002. Available online: 8000/pages/ppl/warfield/papers/2002/warfield-2002-cvs-appeared.pdf. [Downloaded: July 29, 2003].Wroe, C., Stevens, R., Goble, C., Roberts, A., and Greenwood, M. (2003). A suite of DAML+OIL ontologies to describe bioinformatics Web Services and data. Interna- tional Journal of Cooperative Information Systems, 12(2):197–224, 2003. Available on- line: pdf. [Downloaded: July 22, 2003].Wuwongse, V., Akama, K., Anutariya, C., and Nantajeewarawat, E. (2000). A foundation for XML databases: Data model. Technical Report CS-KR-00-01 (2000), Knowledge Rep- resentation Laboratory, Asian Institute of Technology, Thailand, 2000. Available online: 89
  • 98. [Downloaded: October 7, 2003].Wuwongse, V., Anutariya, C., Akama, K., and Nantajeewarawat, E. (2001). XML Declar- ative Description (XDD): A language for the Semantic Web. IEEE Intelligent Sys- tems, 16(3):54–65, May/June 2001. Available online: Publications/ieee-is.pdf. [Downloaded: July 21, 2003].Yagawa, G., Soneda, N., and Yoshimura, S. (1991). A large scale finite element analysis using domain decomposition method on a parallel computer. Computers and Structures, 38(5/6):615–625, 1991. 90
  • 99. INDEXagent, 2, 55 Formal semantics, 34algorithmic distribution, 14 functional decomposition, 14applicability condition part, 43application logic, 55 ground, 44application Web Service, 55 ground clause, 42attribute name, 45 ground objects, 41attribute-name variable, 45 ground XML expressions, 45basic specialization mapping operator, 46 head, 42, 43 HTTP, 21basic specializations, 45, 46bind (Web Service), 21 identity specialization, 41body, 42, 44 instance, 42bottleneck problem, 14 intelligent, 2boxes, 29 interpretation domain, 41business logic, 55 isotropic materials, 7 ivar-expression, 45category, 30class definitions, 65 knowledge base server, 55classes, 30 knowledge representation systems, 27clause, 42client, 55 literals, 29collaboration, 2 load balancing, 16concurrency, 13 logic frameworks, 39constraint, 42 Loosely coupled, 14data, 46 multi-tier, 55data distribution, 13 nested element, 44data input, 56 non-ground XML expressions, 44database, 55 non-unit clause, 42database server, 55declarative description, 42 object, 28declarative programming language, 46 objects, 41definition part, 43 Ontologies, 39degree of freedoms, 7 ontologies, 2describe (Web Service), 21 ontology mapping facilities, 57description, 42document processing and transformation, parallelism, 13 46 pattern matching, 25documents, 46 PC-based servers, 66domain decomposition, 13 predicate, 28 problem description, 43ellipses, 29 process ontology, 3empty element, 44 processor farm, 16empty-element tags, 45 program, 43end tags, 45 program execution, 46equivalent transformation rules, 43 program specification, 43equivalent transformations, 43 programs, 46execution part, 44 proofs, 39 91
  • 100. properties, 30 Unicode, 39publish (Web Service), 21 unit clause, 42 URI references, 28query part, 43 URIs, 39query processing, 46 user interface, 55RDF Model and Syntax (RDF M&S), 39 Web resource, 28RDF Schema, 39 Web Service, 55reasoning, 2 Web Services, architecture of, 21Remote Procedure Calls (RPC), 21 WSDL, 22resource, 28resource sharing, 13 XET program, 46result presentation, 56 XET rules, 46rules, 39 XML, 21 XML application, 28search engines, 56 XML clauses, 46Semantic Web Services, 37 XML declarative descriptions, 46semantics of an XML declarative descrip- XML elements, 44 tion, 46 XML expression, 44service consumer, 21 XML expression alphabet, 44service execution and monitoring, 56 XML expressions, 44service execution plan, 57 XML namespaces, 38service planning, 56 XML specialization generation system, 46service provider, 21 XML specialization system, 46service registry, 3, 21 XML tags, 38service registry broker, 55services ontologies, 55signatures, 39simple element, 44SOAP, 22special-purpose Web Service, 55specialization operator, 46specializations, 41specification, 43speed-up, 14start tags, 45stationary potential energy, principle of, 7structure definitions, 65subject, 28t-element, 45t-expression, 45tags, 45tier, 55tightly coupled, 14tool building, 13type, 30UDDI, 22understand, 27 92