SEMANTIC WEB SERVICES FOR COMPUTATIONAL MECHANICS

by

Thiti Vacharasintopchai

A dissertation proposal submitted in partial fulfillment ofthe requirements for thedegree of Doctor of Engineering

Examination Commitee: Dr. William Barry (Chairman)Prof. Worsak Kanok-NukulchaiProf. Vilas WuwongseDr. Voratas Kachitvichyanukul

Nationality: Thai

Previous Degrees: B. Eng. (Civil Engineering)Chulalongkorn UniversityBangkok, Thailand

M. Eng. (Structural Engineering)Asian Institute of TechnologyBangkok, Thailand

Scholarship Donor: Royal Thai Government Followship

Asian Institute of TechnologySchool of Civil Engineering

ThailandNovember 2003

i

ii

TABLE OF CONTENTS

Chapter Title Page

Title Page iTable of Contents iiiList of Figures vList of Tables vii

1 Introduction 11.1 Background 11.2 Problem Statement 41.3 Objectives 41.4 Scope 51.5 Research Approach 51.6 Contributions 5

2 FEM and the Need towards Distributed Computing 72.1 Formulation of the Finite Element Method 72.2 Parallel Computing and Applications in Computational

Mechanics 102.3 Towards an Application of Distributed Computing Technique 10

3 Distributed Computing 133.1 Distributed Computing Concepts 133.2 Methods of Problem Decomposition 13

3.2.1 Data Distribution 133.2.2 Algorithmic Distribution 143.2.3 Load Balancing 16

3.3 Applications in Scientific Computing 163.3.1 SETI@home Project 173.3.2 Grid Computing 18

4 Web Services 214.1 The Web Services Architecture 214.2 Applications of Web Services in Scientific Computing 23

5 The Semantic Web 255.1 General 255.2 Resource Description Framework (RDF) 28

5.2.1 Introduction 285.2.2 An RDF Statement 285.2.3 Identification of Resources 285.2.4 The RDF Model 285.2.5 Defining RDF Vocabularies 29

5.3 DAML+OIL 315.4 DAML-S: Semantic Markup for Web Services 365.5 Inferences – Making Use of Resources and Ontologies 38

6 XML Declarative Description 416.1 Declarative Description Theory 41

iii

6.1.1 Specialization Systems 416.1.2 Declarative Descriptions 426.1.3 Semantics of Declarative Descriptions 426.1.4 Equivalent Transformations 43

6.2 XML Declarative Description 446.2.1 XML Elements and XML Expressions 446.2.2 Formulation of XML Declarative Description 456.2.3 XML Equivalent Transformation 46

6.3 Ontology Modeling and Inference with XDD 49

7 Methodology 557.1 A Semantic Web Services Framework for Computational

Mechanics 557.2 An Overview of the Research Tasks 587.3 Infrastructure Design and Development 58

7.3.1 Construction of Domain Ontologies 587.3.2 Construction of Ontology Mapping Facilities 597.3.3 Construction of Service Enactment Facilities 62

7.4 Application Web Services Development 637.4.1 Design of XML Schemas and Ontologies 657.4.2 Construction of DAML-S Ontology Instances and

WSDL Documents 657.4.3 Implementation and Deployment of Application

Web Services 667.5 Illustrative Applications of the Framework 66

References 83

Index 91

iv

LIST OF FIGURES

Figure Title Page

3.1 Problem Decomposition: Data Distribution 143.2 Problem Decomposition: Algorithmic Distribution 153.3 Problem Decomposition: Hybrid Distribution Method 1 153.4 Problem Decomposition: Hybrid Distribution Method 2 163.5 Model of the NASA X-38 Crew Return Vehicle (Barnard et al.,

1999) 193.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) 224.2 Roles of SOAP, WSDL and UDDI in Web Services Architec-

ture (Basha et al., 2002) 23

5.1 Example of an HTML Document 265.2 HTML Document in Figure 5.1 as Rendered on a Web Browser 265.3 Example of an RDF Description 275.4 A Simple RDF Statement (adapted from W3C, 2003b) 295.5 Several RDF Statements about Resources (adapted from W3C,

2003b) 305.6 A Vehicle Class Hierarchy (adapted from W3C, 2003b) 315.7 An RDF/XML Encoding that Corresponds to Figure 5.6 (W3C,

2003b) 325.8 An Instance of a Class Defined in Figures 5.6 and 5.7 (W3C, 2003b) 325.9 Definition of Properties Corresponding to Classes in Figures 5.6

and 5.7 (adapted from W3C, 2003b) 335.10 An Instance of a Class using Properties Defined in Figure5.9

(W3C, 2003b) 345.11 An Example ofdaml:Restriction Construct 365.12 Upper Levels of DAML-S Ontology (DAML-S, 2003b) 395.13 Semantic Web Stack Diagram (W3C, 2002) 405.14 Definition of XML Namespace 40

6.1 Typical Structure and Syntax of an XET Program (Anutariyaet al., 2002) 48

6.2 XDD Description Modeling the Ontology Definitions of ClassPerson (Suwanapong, 2001) 50

6.3 XDD Description Modeling the Ontology Instances of ClassPerson (Suwanapong, 2001) 50

6.4 XDD Description Modeling the Ontology Axiomdaml:inverseOf(Suwanapong, 2001) 51

6.5 An XET Program Corresponding to the XDD Descriptions inFigures 6.2 to 6.4 (Part 1 of 2) 52

6.6 An XET Program Corresponding to the XDD Descriptions inFigures 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

7.1 An Overview of the Proposed Semantic Web Services for Com-putational Mechanics Framework 67

7.2 The Multi-tier System Architecture adopted in the SWSCMFramework (adapted from Cyran, 2002) 68

7.3 Example of a Material Ontology 697.4 The DAML-S Ontology 707.5 A Service Profile Hierarchy for Computational MechanicsAp-

plication Web Services 717.6 A Hierarchy of Matrices Involved in Computational Mechanics 717.7 DAML-S Ontology Instance DescribingScience.net Matrix

Inversion Service 727.8 DAML-S Ontology Instance DescribingNumMethods.org Ma-

trix Inversion Service 727.9 DAML-S Ontology Instance DescribingOptimize.com Matrix

Inversion Service 737.10 DAML-S Ontology Instance DescribingNumericalRecipe.net

Matrix Inversion Service 737.11 WSDL Description of a Matrix Inversion Web Service byNum-

Methods.org (adapted from Sintopchai et al., 2003) (Part 1 of 2) 747.12 WSDL Description of a Matrix Inversion Web Service byNum-

Methods.org (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

LIST OF TABLES

Table 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 Relatedto 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 637.5 Preliminary List of Application Web Services to be Developed 647.6 Expenditure Estimates for the Proposed Research 81

vii

viii

CHAPTER 1INTRODUCTION

1.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 modelit as a problem domainand boundary conditions subjected to applied forces. We mayhave 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 thereexist 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 newformulation 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 inshorter time. Improvementof user-friendliness in structural analysis software may come at the cost of an increase incomputational requirement, thus in some cases combinationof 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 scientificcomputations with the help ofintelligent software agents that collaborate to accomplish a given task.

Web Services and the Semantic Web, two technologies built ontop of the Internet,

1

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 enablescollaborationon 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 dataon the Web to beintelligent. Upto now, the World Wide Web has developed rapidly as a medium ofdocuments 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 Webwhere computers can find themeaning of semantic data by following hyperlinks to definitions of key terms and rules forreasoningabout 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 theagents themselves through rea-soning processes that lead to understanding. Such reasoning and automated operation arebased onontologies, 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 problemdomain for the analy-sis, and inputs the data as well as important analysis keywords into a structural analysissoftwareagent, which is a web service that performs analysis of structureson behalfof human users or other agents. The keywords may be related tomaterial types suchas mild steel, aluminum, reinforced concrete or ASTM1 A36 steel, material charac-teristics such as linear elastic, elastoplastic, viscoelastic, or viscoplastic, modes ofanalysis such as static, dynamic, buckling, or fracture, orboundary conditions such ascantilever, simply-supported, three-edge fixed supported, building codes such as theUniform Building Code (UBC) and the National Building Code (NBC), and designspecifications 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 tounderstandthe user’s request and construct aset of problem parameters to perform an analysis. For example, if the user instructsthe 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 simplysupported on all edges and subjected to the residential floorlive load spec-ified in the latest version of UBC code,

1American Society for Testing and Materials

2

the agent would consult its ontology to identify the parameters required for a typicalstress analysis, which are the nodal coordinates, modulus of elasticity, Poisson’s ratio,vector of applied forces, and boundary conditions, and thenprepare the parametersto perform the analysis accordingly. Specifications of the boundary conditions, i.e.simply-supported, are available in the boundary conditionontology. Specificationsof the design live load, i.e. UBC residential live load on floors, are available in thebuilding code ontologies accessible to the agent. In the same manner, modulus ofelasticity, yield stress, and ultimate strength of the ASTMA36 steel are also specifiedin the ASTM standard material ontology. If the keywords usedin the building codeontologies or material ontologies are different from the ones that the agent knows, theagent can infer from the ontologies that define those keywords and identify the one thatspecifies 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 itsprocess ontologyand understand that maximum stresses intypical analyses can be derived from nodal displacement solutions obtained by a finiteelement analysis. Inferences on the process ontology also suggests the agent that, toperform a finite element analysis, it needs to discretize theproblem domain, which, inthis case, is the geometry of the plate given by the user, intoa mesh consisting of anumber of nodes and their connectivities. After discretization, it needs a global stiff-ness matrix, which is constructed by assembling the elementstiffness matrices derivedfrom nodal coordinates and material properties, and a global force vector, which isconstructed by assembling the element force vectors derived from nodal coordinatesand specifications of forces, including the live load it obtained from the building codeontology.

• The agent would consult the process ontology further that once it obtains the globalstiffness matrix and the global force vector, it needs to setup 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 thenneeds to find the derivatives of the nodal displacements to obtain stresses in the plateand search for the maximum values of stresses as requested bythe 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 wasoriginally designed to solve some other types of problems. Therefore, it seeks the helpof other agents. It starts by making a request to aservice registryfor a list of availablesoftware agents that offer solutions to linear system of equations and the ones that canidentify 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 toget results from the agents, the characteristics of the input, e.g. dense matrices, sparsematrices, banded matrices, and the formats of input and output data. The agent wouldconsult the list, reason and select the best third-party agent for each operation, preparethe suitable input data for each agent, request them to perform the computations on itsbehalf, 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 itsown subroutines.

3

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 anduser-friendliness of structuralanalysis software as well as the collaboration among them byenabling 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 elementmethods 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 collaborationof software agents.

Knowledge and tools in structural engineering and computerscience, 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 structuralengineering, 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 elastoplasticor 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

2. To capture and construct the process ontologies in computational mechanics such asdiscretization, formulation of shape functions, formulations of element stiffness ma-trices and their assembly, applications of the boundary conditions, solutions of thesystem 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 registrybrokering, to create a mechanism that enables automatic discovery and collaborationamong 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 structuraldesign 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

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

CHAPTER 2FEM AND THE NEED TOWARDS DISTRIBUTED COMPUTING

2.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 thetotal 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 methodis as follows:

The total potential energy in a linearly elastic body is described as:

Πp =∫

V

(

12

εTEε− εT

Eε0+ εTσ0

)

dV−∫

VuTF dV−

∫

SuTΦdS−DTP (2.1)

in which u = bu v wcT, the displacement fieldε = bεx εy εz γxy γyz γzxc

T, the strain fieldE = the material property matrix

ε0,σ0 = initial strains and initial stressesF = bFx Fy Fzc

T, body forcesΦ = bΦx Φy Φzc

T, surface tractionsD = nodal d.o.f. of the structureP = loads applied to d.o.f. by external agencies

S,V = surface area and volume of the structure

The material property matricesE for isotropic materials are given as

E =

(1−ν)c νc νc 0 0 0νc (1−ν)c νc 0 0 0νc νc (1−ν)c 0 0 00 0 0 G 0 00 0 0 0 G 00 0 0 0 0 G

(in three dimensions) (2.2a)

where c =E

(1+ν)(1−2ν)and G =

E2(1+ν)

,

E =E

(1+ν)(1−2ν)

1−ν ν 0ν 1−ν 00 0 1−2ν

2

(for plane strain conditions), (2.2b)

7

E =E

1−ν2

1 ν 0ν 1 00 0 1−ν

2

(for plane stress conditions). (2.2c)

E 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)

whereN is the shape function matrix.For 4-noded plane rectangular bilinear element (2.3) is specialized as

{

uv

}

=

[

N1 0 N2 0 N3 0 N4 00 N1 0 N2 0 N3 0 N4

]

u1

v1

u2...

v4

(2.4)

where 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 functionNi abovehas the form

Ni =(a±x)(b±y)

4ab(2.5)

For 8-noded solid rectangular trilinear element (2.3) is specialized as

uvw

=

N1 0 0 N2 0 0 . . .0 N1 0 0 N2 0 . . .0 0 N1 0 0 N2 . . .

u1

v1

w1

u2...

w8

(2.6)

where 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, eachNi above has the form

Ni =(a±x)(b±y)(c±z)

8abc(2.7)

The strains are obtained from displacements by differentiation. Thus

ε = ∂u yields ε = Bd, where B = ∂N (2.8)

Relation between strains and displacements in the equationabove is given in two andthree dimension respectively by

εx

εy

γxy

=

∂∂x 00 ∂

∂y∂∂y

∂∂x

{

uv

}

and

εx

εy

εz

γxy

γyz

γzx

=

∂∂x 0 00 ∂

∂y 0

0 0 ∂∂z

∂∂y

∂∂x 0

0 ∂∂z

∂∂y

∂∂z 0 ∂

∂x

uvw

(2.9)

8

Substitution of (2.3) and (2.8) into (2.1) yields

Πp =12

numel

∑n=1

dTnkndn−

numel

∑n=1

dTnren−DTP (2.10)

where summation symbols indicate that we include contributions from allnumelelements ofthe structure. Element stiffness matrixk and element load vectorre are derived, respectively,from

k =∫

Ve

BTEB dV (2.11)

re =

∫

Ve

BTEε0dV−

∫

Ve

BTσ0dV +

∫

Ve

NTF dV +

∫

Se

NTΦdS (2.12)

whereVe denotes the volume of an element andSe denotes its surface. In the surface integral,N is evaluated onSe.

Every d.o.f. in an element vectord also appears in the vector of global d.o.f.D. Thus,whenk and re of every element are expanded to structure size,D can replaced in (2.10).Equation (2.10) becomes

Πp =12

DTKD−DTR (2.13)

where

K =numel

∑n=1

kn and R= P+numel

∑n=1

ren (2.14)

Summations indicate assembly of element matrices by addition of overlapping terms.MakingΠp in (2.13) stationary with respect to small changes in theDi we obtains

{

∂Πp

∂D

}

= 0 (2.15)

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 elastic

problems 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 thenodesD 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 matrixK is singular by its nature. It cannot be invertednor can a unique set of nodal displacementsD 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 thestrainvector by the corresponding material property matricesE presented earlier. For nonlinearproblems in elastoplasticity, Equation (2.16) becomesK (D) D = R(D) and displacementsare incrementally solved in an iterative manner.

9

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 tomultiple 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 thatcan 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 computingtechnology 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 lessexpensive 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

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, atechnique in distributed computingfrom computer science is necessary. The next chapter presents an overview of developmentsin distributed computing.

11

12

CHAPTER 3DISTRIBUTED COMPUTING

3.1 Distributed Computing Concepts

Distributed computing is an area in computer science that deals with the spreading ofa computational task across several programs, processes orprocessors (Brown, 1994). Thereare many forms of distributed computing with many differentreasons 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 useexisting general-purpose programs to handle some of these steps, and so reduce theamount of new code we have to write. We may often be able to avoid writing any newcode altogether. This benefit is referred to astool building.

2. By using several processors concurrently, we can solve the problem more quickly thanif we used a single processor. This benefit is referred to asconcurrency.

3. If the problem itself is sometimes of the form “Do A, B and C in parallel”, the mostnatural 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 isunnatural and makes it harder to understand. This benefit is referred to asparallelism.

4. Sometimes, the resources needed to solve the problem are themselves spread aroundamong several computers on a network. In distribute computing context, we can viewthe network as a whole as a collection of shared resources. This benefit is referred toasresource sharing.

3.2 Methods of Problem Decomposition

To benefit from distributed computing techniques, a problemhas 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 asdatadistribution 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 ofdata that can sensibly be pro-cessed on each processor. The limits are related to orderingand 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

Processor A Processor B Processor C

Figure 3.1: Problem Decomposition: Data Distribution

to categorize problems based on their synchronization requirements.Loosely coupledprob-lems are problems that do not require frequent synchronization of activity and the exchangeof data among processors whiletightly coupledproblems 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 isalgorithmic distributionorfunctional 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 thatits 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

Process A Process B Process C

Figure 3.2: Problem Decomposition: Algorithmic Distribution

Process A2 Process B Process C

Process A3

Process A1

Figure 3.3: Problem Decomposition: Hybrid Distribution Method 1

15

Process B1 Process C1Process A1

Process B2 Process C2Process A2

Figure 3.4: Problem Decomposition: Hybrid Distribution Method 2

3.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 hasan 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 aprocessor farmand 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 suchanalyses involve discrete mod-els that depend on sizes of the problems and desired accuracyof the solutions, rather thanin closed forms usually found in the past. In some applications, as sizes of the problems

16

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 projectfor 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 approachwhich 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-purposesupercomputers 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 rangebut does a more thoroughsearch in that range.

The computational strategy of SETI@home can be described asfollows. At the cen-tral server complex, the radio signal data is divided intowork unitsof 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 whoseInternet connections are behindfirewalls. The client program, downloadable from SETI@homeweb 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 periodicallywrites 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 databasemanagement 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 andJuly 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

3.3.2 Grid Computing

Grid computing is a recent field in distributed computing. The termgrid 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 asa 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 thecoordinated resource sharing andproblem solving in dynamic, multi-institutional virtual organizationsand that the sharing isnot primarily in file exchange but rather is the direct accessto computers, software, data,and other resources, as required by a range of collaborativeproblem-solving and resource-brokering strategies.

Many distributed computing technologies have emerged overthe 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 mustintegrate and coordinate resources and users that live in different control domains, e.g.different administrative units of the same company, different companies, or differentcountries.

2. Uses of standard, open, general-purpose protocols and interfaces: A grid must be builtfrom multi-purpose protocols and interfaces that address fundamental issues such asauthentication, authorization, resource discovery and resource access. It is importantthat these protocols and interfaces be standard and open to prevent application-specificsystems.

3. Delivery of nontrivial qualities of service: A grid must allow its constituent resourcesto be used in a coordinated fashion to deliver various qualities of service, relatingfor example to response time, throughput, availability, and security, including co-allocation of multiple resource types to meet complex user demands and result in thesynergy 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 isa 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

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 thede factostandard 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 least12 companies. The grid com-

19

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

CHAPTER 4WEB SERVICES

4.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 standardssuch 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-Leeet 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 illustratedin Figure 4.1. Threeroles, namely, service provider, service consumer and service registry, and three operations,namely, publishing, finding and binding, are involved in theWeb 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 potentialof a Web Service, theservice provider needs to do two tasks. First, it needs todescribethe Web Servicein a standard format understandable by all organizations that will be using that WebService. Next, it needs topublishthe details about its Web Service in a central registrythat is publicly available to everyone.

Service Consumer– A service consumer is any organization that uses the Web Serviceprovided by a service provider. The service consumer can know the functionality of aWeb Service from the description made available by the service provider. To retrievethese details, the service consumer makes a search in the registry where the serviceprovider had published its Web Service description. The service consumer is able toget from the service description the description of the mechanism tobind to the serviceprovider’s Web Service and in turn to invoke that Web Service.

Service Registry – A service registry is a central location where the service provider canlist its Web Services, and where a service consumer can search for Web Services.Service providers usually publish their Web Service capabilities in the service registryfor service consumers to find and then bind to their Web Service. Information such asorganization details, the Web Services that it provides, and the brief details about eachWeb 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

Service Registry

Service Consumer

Service Provider

Web ServiceDescription

Find Publish

Bind

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 theWeb Service, the input/output parameters for each of the methods, the data types, thenetwork transport protocol used and URL of the end point at which the Web Servicewill 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 serviceproviders to publish details about their organization and the Web Services that theyprovide to a central registry. It also provides a standard for service consumers to findservice 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 ObjectAccess Protocol (SOAP) (W3C, 2000) is a lightweight2 XML mechanism used toexchange 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 inthe 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

2with small amount of overhead instructions

22

Service Publication/Discovery

Service Description

XML Messaging

Transport Network

UDDI

WSDL

SOAP

HTTP, SMTP, FTP or HTTPS

TCP/IP

Figure 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 Publicationand Discovery layer acts like a Yellow Pages

TMwhere service providers publish the links to

their WSDL documents describing the Web Services they provide and the instructions tomake use of them. Service consumers, on the contrary, use these Yellow Pages

TMto search

for Web Services suitable for their needs and make use of themaccording 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 ofthe 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 applyingmessage 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 mostsignificant 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 toFoster and Gannon (2003),

23

SOAP and WSDL, two important components of Web Services, areadopted 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 WebServices technology.

24

CHAPTER 5THE SEMANTIC WEB

5.1 General

The World Wide Web has turned into a hyper-library where accesses to the very largecollection of information are ubiquitous, in both academicand 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 inventionin 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 tagsthat are used to specifyhow a document is to be displayed on web browsers. Examples ofHTML 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 asshown 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 apattern matchingtechnique to

get the character string (not a number) that lies between thesecond pair of<td>, </td> tags located inside the pair of<tr>, </tr> tags whose firstpair of <td>, </td> tags contains the stringaluminum.

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 “mechanicalproperties” on Google

TMreturns hundreds thousands of web pages, with a potential that the

HTML 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 thenext generation of theWorld Wide Web, is the Web in which information presented areuseful not only for humans

1the relationship between words or symbols and their intended meanings (Microsoft, 1997)

25

<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 Young's 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

<rdf:RDFxmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax- ns#"><rdf:Description about="http://www.computings.org">

<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 targetedat computers and by adding documents solely for computers, we would be able to transformthe Web into the Semantic Web where computers find the meaningof semantic data on aweb page by following hyperlinks to definitions of key terms and rules for reasoning aboutthem logically. Computers will be able tounderstandpieces of information on web pagesrather than merely presenting them to users, and will be ableto manipulate such informationon their own. Explicit representation of the semantics underlying data, programs, pages, andother web resources, will enable a knowledge-based web thatprovides a qualitatively newlevel of service. Automated services will improve in their capacity to assist us in achievingour goals by understanding more of the content on the Web and thus provide more accuratefiltering, 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 scatteredon the Internet in a more efficient and less tedious way.

According to (Berners-Lee et al., 2001), for the Semantic Web to function, computersmust have access to structured collections of information and sets of inference rules that theycan use to conduct automated reasoning. In artificial intelligence, such collections are calledknowledge representation systems. Enabling such systems on the Web involves syntactic andsemantic descriptions of data.

Syntactic description is achieved by making use of the eXtensible Markup Langauge(XML) which allows users to add arbitrary structure to theirdocuments by using tags, thehidden labels such as<youngs modulus> or <yield stress> that annotate web pages orsections of text on a page. Computer programs can make use of these tags in many ways butprogrammers would also have to know in advance the intended meaning of each tag, whichis created, adopted, or used by document writers, as XML doesnot say anything about thesemeanings.

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 insets of triples in a gram-matical form like the subject, verb and object of an elementary sentence. The triples can bewritten using XML tags. For example, in RDF, a document makesassertions that a particularthing (such as a person) has properties (such as “is the author of”) with certain values (suchas 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 languagesas well as the mechanisms to make inferences on ontologies will be presented.

27

5.2 Resource Description Framework (RDF)

5.2.1 Introduction

The Resource Description Framework (RDF) is anXML 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 aWeb resource, RDF can also be used to representinformation about things that can beidentifiedon the Web, even if they cannot be directlyretrievedon 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 thatidentifies the thing the statementis about is called thesubject. The part that identifies the property of charateristic of thesubject that the statement specifies is called thepredicate. The part that identifies the valueof that property is called theobject. 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 versionof RDF representationand is the machine-processable way to represent an RDF statement. The English statementcorresponding to the figure is “http://www.computings.org has aCreator whose valueis Glenn Smith .” The subject for this statement ishttp://www.computings.org . Thepredicate isCreator and the object isGlenn 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 usesURI references(URIref), whichis a URI with an optional fragment identifier separated by thesymbol#. For example, theURI referencehttp://www.computings.org/peoples.html#85740 consists of the URIhttp://www.computings.org/peoples.html , which is a web page that contains informa-tion about many people, and the fragment identifier85740 , which specifically identifies theinformation about people whose identification number is 85740. RDF defines aresourceasanything that is identifiable by a URI reference. According to the specification (Berners-Leeet al., 1998) URIs andURIrefs can be used to identify things that can be accessed onlineas well as the ones that cannot. Thus, usingURIrefs 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

2A markup language defined by XML. XML is a meta-markup language or the language that is used todefine markup languages (Harold, 2001).

28

http://www.computings.org/staffid/85740

http://www.computings.org/index.html

http://purl.org/dc/elements/1.1/creator

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. Figure5.5 shows a groupof RDF statements that modify the statement in Figure 5.4 with the following statements:

http://www.computings.org/index.html has acreation-date whose valueis August 16, 1999 .

http://www.computings.org/index.html has alanguage whose value isEnglish .

The name of the staff specified byhttp://www.computings.org/staffid/85740 is Glenn Smith . He is27 years old.

Objects in RDF statements may be eitherURIrefs 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 areURIrefs 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 thepredicatecreator is to be strictly interpreted by the definition inhttp://purl.org/dc/elements/1.1/creator , and the object is strictly the staff ofComputings.org whose iden-tification number is 85740. UsingURIrefs 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 usingRDF 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

August 16, 1999

English

http://www.computings.org/index.html

http://www.computings.org/staffid/85740

Glenn Smith27

http://www.computings.org/terms/creation-date

http://www.computings.org/terms/language

http://purl.org/dc/elements/1.1/creator

http://www.computings.org/terms/name

http://www.computings.org/terms/age

Figure 5.5: Several RDF Statements about Resources (adapted from W3C, 2003b)

Classes

RDF Schema usesclassesto refer to the kinds of things to be described. A class inRDF Schema corresponds to the generic concept of atypeor 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 resourcesrdfs:Class and rdfs:Resource, and thepropertiesrdf:type andrdfs: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 classrdf:Property, and the RDF Schema propertiesrdfs:-domain, rdfs:range, andrdfs:subPropertyOf to specifically describepropertiesthat character-ize classes of things. All properties in RDF are described asinstances of classrdf: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 propertiesrdfs: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. Therdfs:domain prop-erty is used to indicate that a particular property applies to a specified class. Data typesof literals specified inrdfs: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 theirURIrefs. Statements withrdfs: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 providesa way to make specializa-tion on properties. The specialization relationship between two properties is described by

30

http://example.org/schemas/vehicles#MiniVan

http://www.w3.org/2000/01/rdf-schema#Class

http://example.org/schemas/vehicles#PassengerVehicle

http://example.org/schemas/vehicles#Van

http://example.org/schemas/vehicles#Truck

http://example.org/schemas/vehicles#MotorVehicle

http://www.w3.org/2000/01/rdf-schema#subClassOf

http://www.w3.org/2000/01/rdf-schema#subClassOf

http://www.w3.org/2000/01/rdf-schema#subClassOf

http://www.w3.org/2000/01/rdf-schema#subClassOf

http://www.w3.org/2000/01/rdf-schema#subClassOf

http://www.w3.org/1999/02/22/22-rdf-syntax-ns#type

http://www.w3.org/1999/02/22/22-rdf-syntax-ns#type

http://www.w3.org/1999/02/22/22-rdf-syntax-ns#type

http://www.w3.org/1999/02/22/22-rdf-syntax-ns#type

http://www.w3.org/1999/02/22/22-rdf-syntax-ns#type

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 ofa 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 WebConsortium(W3C), which is the organization that controls standards onthe 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, itwas 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 ontologicalmodeling 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

<?xml version="1.0"?><! DOCTYPE rdf:RDF [<! ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]><rdf:RDF

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax- ns#"5 xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"

xml:base="http://example.org/schemas/vehicles">

<rdf:Description rdf:ID="MotorVehicle"><rdf:type rdf:resource="http://www.w3.org/2000/01/rd f-schema#Class"/>

10 </rdf:Description>

<rdf:Description rdf:ID="PassengerVehicle"><rdf:type rdf:resource="http://www.w3.org/2000/01/rd f-schema#Class"/><rdfs:subClassOf rdf:resource="#MotorVehicle"/>

15 </rdf:Description>

<rdf:Description rdf:ID="Truck"><rdf:type rdf:resource="http://www.w3.org/2000/01/rd f-schema#Class"/><rdfs:subClassOf rdf:resource="#MotorVehicle"/>

20 </rdf:Description>

<rdf:Description rdf:ID="Van"><rdf:type rdf:resource="http://www.w3.org/2000/01/rd f-schema#Class"/><rdfs:subClassOf rdf:resource="#MotorVehicle"/>

25 </rdf:Description>

<rdf:Description rdf:ID="MiniVan"><rdf:type rdf:resource="http://www.w3.org/2000/01/rd f-schema#Class"/><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="http://www.w3.org/1999/02/22-rdf-syntax- ns#"xmlns:ex="http://example.org/schemas/vehicles#"

5 xml:base="http://example.org/things">

<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

<?xml version="1.0"?><! DOCTYPE rdf:RDF [<! ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]><rdf:RDF

xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax- ns#"5 xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"

xml:base="http://example.org/schemas/vehicles">

<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

<?xml version="1.0"?><! DOCTYPE rdf:RDF [<! ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]><rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf -syntax-ns#"

xmlns:ex="http://example.org/schemas/vehicles#"5 xml:base="http://example.org/things">

<ex:PassengerVehicle rdf:ID="johnSmithsCar"><ex:registeredTo

rdf:resource="http://www.example.org/staffid/85740" />10 <ex:rearSeatLegRoom

rdf:datatype="&xsd;integer">127</ex:rearSeatLegRoom ><ex:primaryDriver

rdf:resource="http://www.example.org/staffid/85740" /></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 YesCardinality Constraints YesClass Expressions YesData Types Yes YesDefined Classes YesEnumerations YesEquivalence YesExtensibility Yes YesFormal Semanticsb Yes YesInheritance Yes YesInference YesLocal Restrictions YesQualified Constraints YesReification Yes Yesa RDF and RDF Schemab Formal semanticsis the study of language meaning using

mathematical and logical formalisms (ILLC, 2003). Formalism isthe mathematical or logical structure of a scientific argument asdistinguished from its subject matter (Collins, 2000).

34

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,anddaml:maxCardinality,

which allow one to specify the number of occurences of properties in a certain class.It also provides the data typedaml:UniqueProperty which allows one to specify that aproperty be unique, meaning that there can only be one value of the property for eachinstance (Ouellet and Ogbuji, 2002). DAML+OIL also provides the constructs thatallow qualified restrictions such as “at most 3 of the children of X are of typeDoctor”by using the

daml:hasClassQ, daml:cardinalityQ,daml:minCardinalityQ, anddaml:maxCardinalityQ

constructs.

Class ExpressionsDAML+OIL provides the constructs

daml:unionOf, daml:disjointUnionOf,daml:intersectionOf, anddaml:complementOf,

which allow one to express the relationship between classes. For example, given agroup of classesA andB, it is possible to state that classC is the

daml:disjointUnionOf A andB.

As a result, if bothA andB are defined as the subsets ofC, it is asserted that neitherAnorB has any properties in common.

Defined ClassDAML+OIL allows new classes to be defined based on property values orother restrictions of an existing class or class expressions. For example, a classChildcan be defined based on the properties of the classPersonwith a restriction thatage< 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. Itrestricts the value space of a property to a certain set of values. For example, thegenderof a personcan only be eitherMale or Female. In DAML+OIL, enumerationof property types is possible with thedaml:oneOf construct (Gil and Ratnakar, 2002).

Equivalence To support reasoning across ontologies and knowledge bases, DAML+OILallows definition ofnecessary and suffient conditionsfor class membership. The con-ditions specify a class definition that can be used to recognize whether an instancebelongs to a class, or to classify whether a class is a subclass of another class (Gil andRatnakar, 2002). In DAML+OIL, equivalence of classes and instances is expressed bythedaml:equivalentTo anddaml:sameClassAs constructs.

Inference In addition toequivalence, DAML+OIL also provides constructs to provide ad-ditional information for reasoning engines such as

daml:TransitiveProperty, daml:inverseOf,anddaml:UnambigousProperty.

35

<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 ofdaml:Restriction Construct

daml:TransitiveProperty is used to specify that a property is transitive on its class hier-archy. If p is a property of classA, B is a subclass ofA, andC is a subclass ofB, thenC also has the propertyp. daml:inverseOf allows the specifications of inverse relation-ships between properties. For example, ifA is the father ofB, thenB is a child ofA.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 propertythat identifies a resource.

Local Restriction RDF associatesrdfs:domain and rdfs:range constraints with a property,whereas DAML+OIL allowsdaml:Restriction constraints to be associated with a Class–property pair. In DAML+OIL, bydaml:Restriction classes can be a subclass of anony-mous classes. Consider an example in Figure 5.11, by property restriction, classA isdefined as the subclass of an unidentified class whose property p has the valuev1. Ineffect, classA becomes a subclass of all resources that have at least one property pwhose value value isv1.

DAML+OIL has been widely accepted by researchers on the Semantic Web as thelanguage to model ontologies. In scientific computing, a suite of DAML+OIL ontologieshave been developed to describe Web Services and data in computational biology3 (Wroeet al., 2003). A revised version of DAML+OIL is now adopted byW3C in an effort tocreate Web Ontology Language (OWL) (W3C, 2003a), the standard language for ontologicalrepresentation. Currently being in its final draft revisions, OWL will be recommended byW3C 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 anydomain and the instantiation of these ontologies in the description of specific Web sites(DAML-S, 2003b). With such a markup language, it is possibleto provide unambiguousdescription of contents and resources on the Web. Among the resources, Web Services areone of the most important resources on the Web since they not only provide information tousers, but also enable them to effect changes in the world (Ankolenkar et al., 2002) such asthe 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

3a.k.a. bioinformatics

36

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. Thesedescriptions 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 thatthey invoke only asingle Web Service that does not reply on another Web Serviceand 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 andprovide information condi-tionally. DAML-S are designed to enable tasks such as:

1. Automatic Web Service Discovery With DAML-S, the information necessary forWeb Service discovery could be specified as computer-interpretable semantic markupat the service Web sites. To enable discoveries, a service registry or an ontology-enabled search engine could be used to automatically locatethe services from theirWeb sites, or the servers hosting the services could proactively advertise themselvesin DAML-S with a service registry known as the middle agent, so that requesters canfind it when they query the registry. DAML-S provides declarative advertisements ofservice properties and capabilities that can be used for automatic service discovery.

2. Automatic Web Service Invocation Automatic Web Service invocation involves theautomatic 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 offunction calls. DAML-S provides a declarative, computer-interpretable Application Program Interface (API)for executing these function calls. Upon interpreting the markup, a software agentwould 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 theautomatic selection, composition, and interoperation of Web Services to perform sometask, given a high-level description of an objective. With DAML-S, the informationnecessary to select and compose services will be encoded at the service Web sites.DAML-S provides declarative specifications of the prerequisites and consequences ofindividual service use. Software agent can thus manipulatethese 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

4DAML-S verion 0.9 (DAML-S, 2003b)

37

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 serviceworks, and 3) How to use theservice.

The classServiceprovides the reference point for declaring Web Services. One in-stance ofServicewill exist for each distinct published service. The classServicepossessesthree properties, namely,presents, describedBy, andsupports. The classesServiceProfile,ServiceModel, andServiceGrounding, are the respective ranges of these properties.

The ServiceProfiletells “what the service does”. It gives the types of informationneeded by an agent seeking for a service to determine whethera 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, anda 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 ServiceModeltells “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 analysiswhether 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 ServiceGroundingspecifies the details of how an agent can access a service byspecifying a communication protocol, message formats, theport5 number, as well as thetechnique to encode the data to be exchanged. A grounding canbe thought of as amappingfrom anabstractto aconcretespecification of the service description elements requiredforinteracting 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 aServicecan be described by at most oneServiceModeland another is that aServiceModelmust be accompanied by at least one supportingServiceGrounding. The cardinality for thepropertiespresentsanddescribedByis 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 tagsandXMLnamespaces6 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 as5An entrance to or exit for a data network (AHD, 1992)6see definition in Figure 5.14

38

ServiceModel

Service

describedBy

ServiceGrounding

supports

ServiceProfile

presents

Resource provides

What theservice does

How it works

How to access it

Figure 5.12: Upper Levels of DAML-S Ontology (DAML-S, 2003b)

<dc:TITLE>Glenn Smith</dc:TITLE> ,

in which theURIref dc is defined by

xmlns:dc="http://purl.org/DC" .

The Unicodecharacter 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 respectiveURIs. Semanticdescription of the XML tags are provided by theRDF Model and Syntax (RDF M&S), RDFSchema, and ontology representation languages such as DAML+OIL, as discussed earlier.Ontologiescan be viewed as knowledge bases on the Web. They can be usefulonly if theyare consulted during decision processes. Thus, a key requirement for the Semantic Webarchitecture overall is to be able to layerruleson 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 respectivelogic frameworks. Information obtained from reasoning processes areproofs, which, once encrypted and accompanied by electronicsignaturesof 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.

7A self-evident principle or one that is accepted as true without proof as the basis for argument (AHD,1992)

8such as ontologies encoded in DAML+OIL language

39

Figure 5.13: Semantic Web Stack Diagram (W3C, 2002)

XML Namespace

An 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 therdf namespace whoseURIref ishttp://www.w3.org/1999/02/22-rdf-syntax-ns# . 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

CHAPTER 6XML DECLARATIVE DESCRIPTION

In this chapter, XML Declarative Description (XDD) (Wuwongse et al., 2001), an XML-based knowledge representation founded on the DeclarativeDescription (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 theoryinspired 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 atemplate for developingdeclarative semantics for declarative descriptions in many specific data domains. Descriptionof DD theory, as presented in Wuwongse et al. (2000), is givenbelow.

6.1.1 Specialization Systems

First, the concept of specialization system is introduced.

Definition 6.1 Let A , G , andS be respectively the sets ofobjects, ground objects1, special-izations, and µ be a mapping fromS 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). ThesetG is called theinterpretation domain.

The conditions (1) to (3) intuitively mean that:

1. For all specializationss1 and s2, there exists a specializations such that the corre-sponding partial mapping ofs is the composition of the two mappings that correspondto s1 ands2,

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 asaθ. Ifthere existsb such thataθ = b, θ is said to be applicable toa, anda is specialized tob by θ.Fora∈ A , let rep(a) denote the set of all ground objects which can be specializedfrom a:

rep(a) = {aθ | θ ∈ S ,aθ ∈ G} . (6.1)

1ground objects are objects that do not contain variables

41

6.1.2 Declarative Descriptions

A declarative description onΓ and other related concepts are defined by the follow-ing:

Let a setK be comprised of the constraint predicates. AconstraintonΓ is a formulaq(a1, . . . ,an), whereq is a constraint predicate inK andai is an object inA . Given a groundconstraintq(g1, . . . ,gn), gi ∈G , its truth and falsity are assumed to be predetermined. Denotethe set of all true ground constraints byTcon. A specializationθ is applicable to a constraintq(a1, . . . ,an) if θ is applicable toa1, . . . ,an. The result ofq(a1, . . . ,an)θ is the constraintq(a1θ, . . . ,anθ); andq(a1, . . . ,an) is said to be specialized toq(a1θ, . . . ,anθ) by θ. The notionof constraints introduced here is useful for defining restrictions on objects inA .

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 inA and Bi is an object inA or a constraint onΓ. H is calledthe head and (B1,B2, . . . ,Bn) is called thebody of the clause. Adeclarative description orsimply adescription onΓ is a (possibly infinite) set of clauses onΓ.

Let C be a clause(H ← B1,B2, . . . ,Bn). If n = 0, C is called aunit clause. If n > 0,C is called anon-unit clause. The head ofC is denoted byhead(C). The sets of all objectsand constraints in the body ofC are respectively denoted byob ject(C) andcon(C). Letbody(C) = ob ject(C)∪con(C). A clauseC′ is aninstanceof C iff 2 there is a specializationθ ∈ S such thatθ is applicable toH,B1,B2, . . . ,Bn andC′ =Cθ = (Hθ←B1θ,B2θ, . . . ,Bnθ).A clauseC is a ground clause iff Cis comprised only of ground objects and ground con-straints.

6.1.3 Semantics of Declarative Descriptions

Let P be a declarative description onΓ. The mappingTP on the power-set 2G , whichmaps a subset ofG into another subset ofG , 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,

ob ject(Cθ)⊂ X, con(Cθ)⊂ Tcon}

.(6.3)

Based onTP, the meaning ofP is defined as follows:

Definition 6.4 Let P be a declarative description onΓ. The meaning of P, denoted byM (P),is defined by

M (P) =∞⋃

n=1

[TP]n(∅) (6.4)

where∅ is the empty set.[TP]1(∅) = TP(∅) and[TP]n(∅) = TP(

[TP]n−1(∅))

.

2if and only if

42

6.1.4 Equivalent Transformations

Equivalent Transformation (ET) is a computational paradigm that is based on thesemantics preserving transformations (orequivalent transformations) of declarative descrip-tions by employing the definition:

Transformability of Declarative Descriptions

Definition 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 ofequivalent 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: aprogram specificationand aprogram. A program specification, simplycalled aspecification, is a pair〈D,Q 〉, whereD is a declarative description, called adefinitionpart, andQ is a set of declarative descriptions, each of which is calleda query part. Thedefinition partD provides general knowledge about a problem domain and describes somespecific problem instances. A query part inQ specifies a question with regard to the contentof the definition partD. For each query partQ in Q , the pair〈D,Q〉 is regarded as aproblemdescriptioncovered by the specification〈D,Q 〉, and a declarative meaning is associatedwith each problem description. On the contrary, aprogram, 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 querypart from which the answers tothe specified query are readily obtained. In other words, letP1 be the declarative descriptionof a given query part andM (P1) be its associated meaning. The paradigm applies ET rulesin order to successively transform

P1ET rules−−−−−→ P2

ET rules−−−−−→ P3

ET rules−−−−−→ . . .

ET rules−−−−−→ Pn

while maintaining the conditions

M (P1) = M (P2) = M (P3) = . . . = Pn

until the descriptionPn, 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;

→{Es2},Bs2;

· · ·

→ {Esn},Bsn.

in which〈rulename〉 is the name of a rule; H is an object called thehead; Cs is a (possiblyempty) sequence of executable objects called theapplicability condition part; each Esi are

43

(possibly empty) sequences of executable objects called anexecution part; each pair of Esiand Bsi are (possibly empty) sequences of objects called abody of the rule. The〈rulename〉,the applicability condition part, and the execution parts are optional.

Assume that we are given an objectb in the body of a definite clauseC. An ET ruleis applicable to the objectb iff the headH matches the objectb by a specializationθ, i.e.Hθ = b, andCsθ is true3. When the rule is applied to a clauseC at an objectb, C producesless than or equal ton clauses. Each new clause is obtained afterEsiθ is executed successfullywith an answer specializationσ by replacingbσ in Cσ with Bsiθσ. 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 areground, 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>

wheren,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), andei is an XML element.

Let ΣX be theXML expression alphabetcomprised 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 arenon-ground XML expressions and those without

3recall the shortened form of the specialization operatorµ(θ)(a)≡ aθ introduced on page 41

44

Table 6.1: Definition of the XML Expression Alphabet (Wuwongse et al., 2000)

Symbols Set Elements Conditions Specialization Objects

C Characters ’$’6∈C N/A

N Namesa All names not beginningwith “$N:”

N/A

VN Name variables(N-variables)

Names beginning with“$N:”

Element types or attributenames inN

VS String variables(S-variables)

Names beginning with“$S:”

Strings inC∗b

VP Attribute-value-pairvariables (P-variables)

Names beginning with“$P:”

Sequences ofattribute-value pairs

VE XML-expressionvariables (E-variables)

Names beginning with“$E:”

Sequences of XMLexpressions

VI Intermediate-expressionvariables (I -variables)

Names beginning with“$I:”

Parts of XML expressions

a Names can be either element types or attribute namesb C∗ is the set of character strings.

variables areground XML expressions or XML elements. An expression of the2nd, 3rd, and4th form is a t-expression, whereas that of the5th form is an ivar-expression. A groundt-expression is at-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 respectivelystarttags, end tags and empty-element tags, and are collectively referred to astags. ai is anattribute name when ai ∈ N, and is anattribute-name variable when ai ∈VN.

6.2.2 Formulation of XML Declarative Description

Variable Instantiation

A variable instantiation is defined bybasic specializations, each of which has theform (v,w) wherev specifies the name of the variable to be specialized, andw specifies thespecializing value.

45

XML Specializing Generation System

Definition 6.8 Let∆X = 〈AX,GX,CX,µX〉 be anXML 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, thebasic specialization mappingoperator νX : CX→ partial map(AX) is defined in Table 6.2, and the elements ofCX are callbasic specializations.

XML Specialization System

Definition 6.9 Based on∆X, let ΓX = 〈AX,GX,SX,µX〉 be anXML specialization system,whereSX = C ∗X, i.e. the set of all sequences onCX. 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 thespecialization operator, and µX(s)(a) is defined for each a∈AX

and 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, whichis the XML versionof the specialization systems presented in Section 6.1.1. After such a specialization systemis defined, definitions ofXML clauses, XML declarative descriptions, and thesemantics ofan XML declarative descriptionare 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). XETwas 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, alsounifiesdocument processing and transformation, program execution, andquery 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 programis comprised of a set ofXET rulesand 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 exceptthat 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 thexet namespace, is presentedin Figure 6.1.

46

Table 6.2: Definition of the Basic Specialization Mapping OperatorνX (Wuwongse et al.,2000)

Types Basic Specializationsc in CX Methods by whichνX(c)(a)is obtained froma

ApplicabilityConditions

1. Variable Renaming c = (v,u) ∈(VN×VN)∪(VS×VS)∪(VP×VP)∪ (VE×VE)∪ (VI ×VI)

Replacement of alloccurrences ofv in a by u

2. Variable Expansion

2.1P-variable c = (v1,(nvar,svar,v2))∈VP× (VN×VS×VP)

Simultaneous replacement ofall occurrences ofv in a bythe sequence of the pairnvar= svarand theP-variablev′.

For every tagin acontainingv,that tag doesnot containnvar as anattributename

2.2E-variable c =(

v1,(v1,v2))

∈VE× (VE×VE)Simultaneous replacement ofeach occurrence ofv in a bythe sequencev1 v2.

3. Variable Removal

3.1P- or E-variable c = (v,ε) ∈ (VP∪VE)×{ε} Removal of each occurrenceof v in a.

3.2 I -variable c = (v,ε) ∈VI ×{ε} Removal of each occurrenceof <v> and each occurrenceof </ v> in a.

4. Variable Instantiation

4.1N-variable c = (v,b) ∈VN×N Simultaneous replacement ofeach occurrence ofvin a by b.

For every tagin acontainingvas anattribute-namevariable, thattag does notcontainb asan attributename

4.2S- or E-variable c = (v,b)∈ (VS×Σ∗)∪ (VE×AX)

Simultaneous replacement ofeach occurrence ofvin a by b

4.3 I -variable c =(

v,(nvar, pvar,evar1,evar2,v′)

)

∈VI × (VN×VP×VE×VE×VI)

Simultaneous replacement ofeach occurrence of thev-expression<v>e1 . . .en</ v>in a by thenvar-expression<nvar pvar> evar1 <v′>e1 . . .en </ v′> evar2</ nvar> .

47

<xet:Program xmlns:xet="http://kr.cs.ait.ac.th/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

xet:Fact is used to specify application data and is comprised of ground XML expres-sions. Anxet:Rule is used to specify an XET rule and is comprised of the following compo-nents defined inxet 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 aHeadElement , 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 ofCondElements , 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 moreBodyElements , eachof which is either an XML element to be matched with the head ofthe 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, anS-variable nameduri is represented bySvar-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 6.5.

6.3 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 classPerson in Fig-ure 6.2. Ontology instances of the class are given in Figure 6.3. An XDD descriptionof the ontology axiomdaml: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 asrdfs:subPropertyOf anddaml:TransitiveProperty, are also avail-able in the proposal. In XDD, Figures 6.2 and 6.3 are regardedas 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

<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 ClassPerson(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

<$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 Axiomdaml:inverseOf (Suwanapong,2001)

51

<xet:Program xmlns:xet="http://kr.cs.ait.ac.th/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

<! -- 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

<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

CHAPTER 7METHODOLOGY

7.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 logicor application logic, anddatabase. Layersmay have one or more components. For example, there can be oneor 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 andbe 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, aclient, anapplication Web Service, aknowledge base server, and an optionaldatabase server.

Client A client, the user-interface tier in the architecture, is the component where end-usersinteract with application Web Services in the framework. Itis used to initiate a re-quest for an operation to be performed by application Web Services and to presentresults of the operation to the users. The client can be a web browser or other end-userapplication, 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 clientsor other Web Services. Ser-vices are provided by employing computing modules, knowledge bases and databasesaccessible locally, or by delegating tasks to the others. Anapplication Web Serviceis called anagent if the services provided are accomplished mainly by making useof other Web Services. It is called aspecial-purpose Web Service, or simply aWebService, if the services provided are accomplished mainly by makinguse of local fa-cilities. Application Web Services identify and make use ofthe others by consultingtheir localservices ontologies, possibly encoded in DAML-S language, or by assis-tance of aservice registry broker, which is a special-purpose Web Service that helpother Web Services advertise themselves, as well as helpingeach of them identify andmake use of the others. Communications between applicationWeb Services are bymeans of SOAP messages transported over HTTP protocol.

Knowledge Base ServerA knowledge base server, a component of the database tier in thearchitecture, is the component where ontologies,URIrefs to ontolgies, rules, and aninference 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

Database ServerA database server, another component of the database tier inthe architec-ture, is the optional component where raw or unprocessed data relevant to the operationof an application Web Service are stored. A database server is accessible locally to anapplication Web Service and provides support for queries against such data during theoperation of the Web Service.

Referred to Figure 7.1 and the paradigm discussed in Section1.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 toconnect to a structural analysisagent, which may be recommended by a colleague or discoveredfrom an advertisement onsearch enginessuch as Google

TMor Yahoo.

TMFour stages of operations are involved from the

moment an agent is identified by a user until the moment the agent presents the user therequested results, namely, adata inputstage, aservice planningstage, aservice executionand monitoringstage, and aresult presentationstage. Operations at each stage are describedas follows:

Data Input Stage Through user interfaces provided by the agent, the user supply the datathat model the real world structure being considered as wellas the desired results. Theformer include the shape and dimensions of the structure, the type of material of whichit is built, the boundary conditions, and the external forces to which it is subjected. Thelatter are specifications such as stresses at particular points, contour plots of particularstress components, or evaluation whether the structure cansafely withstand the givenloading conditions. The user may explicitly specify directions and magnitudes of theexternal forces or ask the agent to use the forces specified bya design code that governsthe area where the structure is located. He or she needs not explicitly provide all thedata and may omit some of them if they can be implied from otherinput data.

Service Planning StageWhen the user finishes providing the input data, the agent analyzesthe user requests and consults the local knowledge base server, where process ontolo-gies reside, to identify local computing modules that produce the results requested bythe user.

If it is found that a particular request cannot be handled locally, a service registrybroker is consulted to identify Web Services or other agentsthat can handle such arequest. A service registry broker may inform the agent of such Web Services andagents by means of SOAP messages containingURIrefs to their DAML-S ontologyinstances. If the service registry broker returns a list of more than one Web Services oragents that can handle a request, the agent would consult itsknowledge base server toselect the most appropriate one based on descriptions in theDAML-S ServiceProfilesuch 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 thecomputing modules and application Web Services. The formatof the required inputdata, as well as that of the output data, are specified in WSDL documents publishedon the Internet.

Mismatched input data items are arbitrated by consulting the agent’s local knowledgebase server or by making requests for information from knowledge bases of otheragents or Web Services. For example, if the user specifies dimensions of the structurein SI units but the computing modules of the agent are developed for Imperial units,

56

the agent would consult its knowledge base and look for ontology instances of SI unitsand convert the dimensions specified by the user into the onesin Imperial units sothat they can be handled by local computing modules. Differences between keywordsrecognized by agents, Web Services, and users, such asmodulus of elasticityversusYoung’s modulus, are arbitrated by ontology mapping facilities available on knowledgebase servers.

General data items are also made more specific and precise by consulting the agent’slocal knowledge base server or by making requests for information from knowledgebases of other agents or Web Services. For example, if the user requests that externalforces to be applied to the structure conform to those specified in the latest revisionof UBC Building Code and the agent’s local knowledge base does not contain such abuilding code, it would consult a service registry broker and be directed to respectiveWeb Service of a government agency that provides loading information from UBCBuilding Codes. Such information is provided by Web Serviceof the governmentagency through queries against ontology instances on its local knowledge base server.

By consulting process ontologies stored on knowledge base servers, the agent thencreate aservice execution plan, which is a list of computing modules, agents, and WebServices to be executed, sequentially or in parallel, to deliver end results requested bythe user.

Service Execution and Monitoring StageThe service execution plan created in the ser-vice planning stage containsServiceGrounding information extracted from DAML-Sontology instances of respective computing modules and application Web Services.As discussed in Section 5.4, aServiceGrounding description specifies the details ofhow services can be accessed by an agent. Such details include message formats andURIs, the explicit specifications of communication protocol, network address, and portnumber 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, andaccordingly invoke them by the methods specified in theirServiceGrounding descrip-tions. Preparation of input data is performed by means of adaptations and conversionsof the output from preceding service executions, with the assistance of ontologies, on-tology instances, and ontology mapping facilities. Monitoring of services that requiresubstantial time for data processing is expected to be achieved by monitoring compo-nents of DAML-SServiceModel constructs expected to be included in the final versionof DAML-S markup language.

Result Presentation StageIn the last stage of operations, the agent presents the results tothe user in the requested formats. The results obtained fromthe service execution andmonitoring stage are in XML format that conforms to an XML schema provided andadopted by the agent. If the user-interface client is an end-user application, the resultsin XML format are directly downloaded to the application, and are further formattedand displayed to the user by computing modules and application logics embedded inthe client. If the user-interface client is a web browser, the agent renders the resultsinto HTML format and present them on the client web browser. The HTML codepresenting the results may also containURIrefs to graphical plots, pictures, or videoclips which are generated in the previous stage by visualization Web Services usingraw data obtained from the results themselves.

57

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 thatknowledges relevant to general operations of the frameworkcomponents are cap-tured,

(b) Construction of ontology mapping facilities to be utilized by local knowledgebase servers of application Web Services,

(c) Construction of service enactment facilities to enablesemantic service advertise-ment, discovery, composition, execution, and monitoring among application WebServices.

2. Application Web Services Development

For each application Web Service,

(a) Design of XML Schemas for input, intermediate, and output data, as well asdefinition of DAML+OIL ontologies to describe the meaning ofdata items,

(b) Construction DAML-S ontology instances to support and control operations ofthe application Web Service,

(c) Implementation and deployment of application Web Services using particulartools 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 Table7.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 intothe 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 relationshipswill be produced using RDF(S) and

58

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 includeMaterial, 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 anend-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, AgentA 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” isdefined. In other words,Agent A needs to supply Agent B aURIref that points to the ontology adopted by itself. Uponarrival of the message, Agent B needs to verify, by investigating the ontology accessible atthe specifiedURIref, 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 ofModulusOfElasticity which re-lates TensileStress to TensileStrain by anEquation namedHooke’s Law specified athttp://def.physics.org/hookes . According to the ontology adopted by Agent A,TensileMod-ulusOfElasticity hasUnit of GPa (109N/m2), which is a subclass of theforcePerUnitArea unit,a subclass of theDerivedUnit rooted fromUnitOfMeasurement.

Upon investigating at theURIref specified by Agent A, Agent B discovers thatYoungs-Modulus used by Agent A is aPhysicalQuantity that relates TensileStress to TensileStrainby theEquation namedHooke’s Law specified athttp://def.physics.org/hookes andhasUnit of ksi (kips per square inch), which is a subclass of theforcePerUnitArea unit, asubclass of theDerivedUnit rooted fromUnitOfMeasurement.

SinceTensileModulusOfElasticity andYoungsModulus (1) are both subclasses ofPhys-icalQuantity, (2) bothrelate TensileStress to TensileStrain by theEquation namedHooke’sLaw specified athttp://def.physics.org/hookes , and (3) are both subclasses of thefor-cePerUnitArea unit, a subclass of theDerivedUnit rooted fromUnitOfMeasurement, 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

Table 7.1: Examples of Mathematical and Physical Ontologies Related to KeyOperations in Computational Mechanics

Ontology Names Examples of Subclasses

1. Quantities mathematical quantities, physicalquantities

2. Mathematical quantities scalar, vector, matrix, tensor

3. Geometrical entities one-dimensional entities, two-dimensionalentities, three-dimensional entities

3.1 One-dimensional entities point3.2 Two-dimensional entities line, triangle, rectangle, square, circle,

ellipse3.3 Three-dimensional entities box, cube, sphere, tetrahedral, cone,

paraboloid, surfaces

4. Physical quantities base physical quantities, derived physicalquantities

4.1 Base physical quantities length, mass, time, electric current,thermodynamic temperature, amount ofsubstance, 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 hardeningparameter, kinematic strain hardeningparameter

60

Table 7.2: Examples of Conceptual Ontologies Related to KeyOperations inComputational Mechanics

Ontology Names Examples of Subclasses

1. Mathematical concepts coordinate system, Cartesiancoordinate, polar coordinate, space,reference point, coordinatetransformation, mapping,approximation, interpolation

2. Computational mechanics concepts discretization, element, load,stiffness, boundary conditions,response, displacement

Table 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

“Young’s modulus” from Agent A as its “tensile modulus of elasticity” value and proceedon the analysis request. Agent B may also add the termYoungsModulus to its local ontologyspecifying that this term specified by theURIref employed by Agent A is thesameClassAsthe termTensileModulusOfElasticity 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 theURIref 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 involvesthe 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 sparsematrix involved in its opera-tions. Upon consulting a service registry broker for “matrix inversion services”, supposethat four application Web Services, namely the ones byScience.net, NumMethods.org, Opti-mize.com, andNumericalRecipe.net, are identified and theURIrefs to their DAML-S ontol-ogy instances are reported by the service registry broker. After following theURIrefs, 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 byScience.net because

1. it takes general matrices as the input which means that it is not optimized forsparse matrices, and

2. direct matrix inversion method generally gives exact solutions at the expense oflonger computation time, which, in this case, is not necessary since the resultswill be governed by numerical procedures being employed by the agent.

• The agent would also not choose the service byOptimize.com because, although theservice is based on an iterative method, which is suitable for the agent, it takes densematrices as the input which means that advantages of sparse matrices are not taken intoaccount. Thus, this service is not suitable for the agent.

• The agent prefers the service byNumMethods.org to the one byNumericalRecipe.netbecause, although both offer services optimized for sparsematrices, the service by

62

Table 7.4: Summary of Matrix Inversion Service Profiles in Figures 7.7 to 7.10

Service Provider Solution Method Input Type Quality Rating

Science.net Direct method General matrix ANumMethods.org Iterative method Sparse matrix AOptimize.com Iterative method Dense matrix ANumericalRecipe.net Iterative method Sparse matrix B

NumMethods.org is more reliable because it receives higher quality rating fromComp-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 byNumMethods.org. To make use of the ap-plication Web Service, the agent would follow theServiceGrounding description of the ser-vice. Specifically, in Figure 7.8, the agent would investigate theNumMethOrgMatInvWOR,which is the service grounding description that maps the conceptual matrix inversion pro-cess ofNumMethods.org to its correspondinggetInverse operation defined in WSDL doc-umenthttp://nummethods.org/matInv.wsdl , the content of which is presented in Fig-ures 7.11 and 7.12. By inspecting thegetInverse operation in the WSDL document, the agentwould be informed accordingly that it can request for a matrix inverse operation by sending aSOAP message tohttp://ws.nummethods.org:8080/axis/services/MatrixW S usingthe message defined between lines 29–34 of Figure 7.11.

Composition of application Web Services may be performed ina 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 aURIref to the DAML+OIL ontology that describes sucha status. Construction of the service enactment facilitiesis 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 basescomprised 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 thatdrive and support the operation is

63

Table 7.5: Preliminary List of Application Web Services to be Developed

Service Name Description Profile Classa Interfaces

CompMechRegistry service registry broker forthe prototype system

ServiceRegistryBroker SOAP requests

AgentAWebService front-end structuralanalysis agent

StructuralAnalysisService Web browserinterface forend-users,SOAP requests

AgentBFemService specializes in finiteelement methods forproblems in elasticity andelastoplasticity

FiniteElement-AnalysisService

SOAP requests

LSESolver specializes in solvinglinear systems of equations

LinearSystemOf-EquationsSolver

SOAP requests

NLSESolver specializes in solvingnon-linear systems ofequations

NonlinearSystemOf-EquationsSolver

SOAP requests

SIMeasureService provides information on SIunits

MeasurementInfoService SOAP requests

USMeasureService provides information onUS customary units

MeasurementInfoService SOAP requests

ASTMMaterialService provides information onASTM material standards

MaterialInfoService SOAP requests

UBCInfoService provides information onthe Uniform BuildingCode

DesignStandard-InfoService

SOAP requests

ACIInfoService provides information onthe ACI building coderequirements

DesignStandard-InfoService

SOAP requests

AISCInfoService provides information onthe AISC designspecifications

DesignStandard-InfoService

SOAP requests

a See definitions in Figure 7.5

64

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 outputdata are important tointeroperations among application Web Services and clients, as well as local operations ofthe application Web Services themselves. Schemas can be regarded asstructure definitionsinthe C programming language, orclass definitionsin 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 beanother 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 keycomponent 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 definesSOAPMatrix 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. ThekeywordsyoungsModulus, poissonRatio, anddensity used in the figures are as defined bythe DAML+OIL material ontology presented in Figure 7.3, with youngsModulus being aninstance ofYoungsModulus, poissonsRatio being an instance ofPoissonsRatio, anddensitybeing an instance ofDensity, 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 andhow 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 theParameterDescription instancesavailable in service profiles to determine whether the input, output, precondition, and effectof the services match their requirements. Once a decision ismade 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

is received, can be further investigated from the instancesof DAML-S ServiceGroundingsupported by that service.

During the operation of an application Web Service, its instances of DAML-SSer-viceModel, particularly those ofAtomicProcess, SimpleProcess, CompositeProcess, Pro-cessComponent, andControlConstruct, are also used to control how process components (orthe computing modules in Figure 7.2) interact to accomplishservices that it offers.

For each process defined in the service model, an applicationWeb Service can de-termine whether it can handle the process by itself by verifying whether a correspondingatomic process grounding exists in itsServiceGrounding 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 WSDLblueprintsfrom 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 operatingsystem.

Application Web Services based on Java Servlet technology will be implementedin the Java programming language using open-source XML SOAPmessaging toolkits suchas Apache Axis (Apache, 2003) by the Apache software foundation. Those based on Mi-crosoft .NET technology will be implemented in proprietarylanguages by Microsoft, suchas Visual Basic .NET or C#. Software libraries necessary forscientific 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 linearelasticity 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 comparisonwith 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)2typical personal computers configured to perform a server role in the distributed computing paradigm3(see Microsoft, 2003)

66

VisualizationService

KB

Visualization Process Ontologies

KB

Process Ontologies

Special-purposeService

Equation SolverService

KB

Matrix Ontology

Solution Techniques

Process Ontologies

Service RegistryBroker

KB

Service Profile Ontologies

Quality Rating Ontologies

User & Web Browser

Real WorldProblems

Structural AnalysisAgent “B”

KB

Analysis Process Ontologies

Analysis Types: static, dynamic, fracture, etc.

Analysis Rules

etc.

SensorsScalar

VectorsMatricesTensors

Operations

General Knowledge in Scientific Computing

Structural AnalysisAgent “A”

Knowledge Bases(KB)

FEM Input/Output

Schemas

Boundary Conditions

ACI Design & Construction

Manuals

AISC Design & Construction

Manuals Institutions

Material Properties

JIS Material Specifications

ASTM Material Specifications

Institutions

Pictures

Movies

Metric System of Measurement

US Customary System of

Measurement

SI Measurement

Domain Ontology

Domain Ontology

Building Code

British Building Code

NBC Building Code

UBC Building Code

GovernmentAgencies

Figure 7.1: An Overview of the Proposed Semantic Web Services for Computational Mechanics Framework

67

ApplicationWeb Service 1

LocalKnowledge Base

Server

LocalDatabase

Server

Que

ry

Ans

wer

ApplicationWeb Service 2

LocalKnowledge Base

Server

LocalDatabase

Server

ApplicationWeb Service n

LocalKnowledge Base

Server

LocalDatabase

Server

Client

Client

Client

Que

ry

Ans

wer

Request

Response

DB DB DB

KB KB KB

Knowledge Base Components

Ontologies

Rules

Infe

renc

e E

ngin

e

Application LogicComponents

Com

putin

g M

odul

e A

Com

putin

g M

odul

e B

Com

putin

g M

odul

e n

. . .

Database Components

Dat

a

Que

ry

Pro

cess

ingText-based

Application

GUI-based Application

Web Browser

Figure 7.2: The Multi-tier System Architecture adopted in the SWSCM Framework(adapted from Cyran, 2002)

68

daml:Thing

Material

sc

PropertyQuantity

Response

UnitOfMeasurement

sc

Legendrel : http://ont.swscm.org/

terms.daml#relatessc : daml:subClassOfsca : daml:sameClassAs

: dummy node

sc

sc

sc

BrittleMaterial

sc

DuctileMaterial

sc

ElasticMaterial

sc

LinearElasticMaterial

sc

NonlinearElasticMaterial

sc

InelasticMaterial

sc

MaterialProperty

Density

FractureToughness

ModulusOfElasticity

Shear-ModulusOfElasticity

Tensile-ModulusOfElasticity

YoungsModulus

PlasticModulus

Isotropic-PlasticModulus

sc

sc

scsc

scsc

sca

Kinematic-PlasticModulus

PoissonsRatiosc

sc

sc

sc

ProportionalLimit

Shear-ProportionalLimit

Tensile-ProportionalLimit

YieldStrength

sc

sc

sc

sca

UltimateStrength

Compressive-Strength

ShearStrength

TensileStrength

sc

sc

sc

sc

MathQuantity

sc

Scalar

Vector

Matrix

sc

scsc

PhysicalQuantity

representedBy

sc

Base-PhysicalQuantity

Derived-PhysicalQuantity

sc

BaseUnit

DerivedUnit

sc

sc

hasUnithasUnit

hasUnit

Stress Strain

sc

sc

AxialStress

ShearStress

TensileStress

CompressiveStress

AxialStrain

ShearStrain

TensileStrain

CompressiveStrain

sc

sc

sc sc

sc

sc

sc

sc

Length

Mass

Time

sc

sc

sc Area

Volume Pressure

sc

sc

sc

scsc

scsc

rel

rel daml:collection

rdf:parseType

rdf:_1

rdf:_2

HookesLaw

hasEquation

Equation

sc

sc

“Hooke’s Law” http://ont.swscm.org/terms.daml#hasName http://def.physics.org/hookes

http://ont.swscm.org/terms.daml#definedByNoteDefault namespace: http://ont.swscm.org/ materials.daml#

Foreign termmapped into

local ontology

forcePerUnitArea

sc

hasUnit

sc

hasUnit

GPa

ksi

sc

sc

sc

hasProperty

Figure 7.3: Example of a Material Ontology

69

participant

sc

sc

sc

value

ServiceModel

Service ServiceGroundingsupports

ServiceProfile

presents

Resource providedBy

Profile

daml:subClassOf

xsd:string

serviceNamexsd:string

textDescription

Actor

contactInformation

ProcessPowerSet

has_process

ServiceCategory

serviceCategory

ServiceParameter

serviceParameter

QualityRating

qualityRating

ParameterDescription

parameter(input/output/

precondition/effect)

xsd:string

parameterName

ParameterPowerSet

refersTo

xsd:string

categoryName

xsd:string

taxonomy

xsd:string

xsd:string

code

xsd:string

daml:Thing

xsd:string

ratingName

daml:Thing

rating

daml:Thing

sc

xsd:string name

xsd:string

title

xsd:string

phone

xsd:string

fax

xsd:string

emailxsd:string

physicalAddress

xsd:string

webURL

NAICS UNSPSC

AverageResponseTime

Duration

sParameter

sc

MaxResponseTime

Duration

sParameter

sc

sParameterserviceParameterName

GeographicRadius

Country

sParameter

DAndBRating

Dun and BradstreetRating

ratingName

sc

categoryNameNAICS

taxonomy

www.naics.com categoryName UNSPSC

ProcessModel

ProcessPowerSet

hasProcess

ProcessControlModel

hasControlModel

Process

sca

daml:Restriction

rdf:type

daml:subClassOf

daml:onProperty

daml:hasValue

SimpleProcess

sc

AtomicProcess

daml:disjointUnionOf

realizedBy

daml:Thinginput

ConditionalOutput

output

daml:Thingrdf:_1

CompositeProcess

Condition

precondition

ConditionalEffect

rdf:parseType

daml:collection

effect

realizes

sc

Literal

name

expandsTo

collapsesTo

rdf:_2

rdf:_3

describedBy

daml:intersectionOf

rdf:parseType

daml:collection

rdf:_1

daml:Restriction

rdf:type composedOf

daml:onPropertyrdf:_2

1

daml:cardinality

ControlConstruct

composedOf

xsd:boolean

invocable

daml:Thing

computedInput

computedOutput computedEffect

computedPrecondition

ProcessComponent

daml:unionOf

rdf:parseType

daml:collection

rdf:_2

rdf:_1

currentProcessComponent

nextProcessComponent

ProcessComponent-List

ProcessComponent-Bag

daml:List

daml:Restriction

daml:item

rdf:typedaml:toClass

sc

sc

scsc

daml:onProperty

Sequence

sc

components

Split

sc

components

Split-Join

components

sc

Unordered

components

Choice components

scsc

chooseFrom

TestCondition

sc

TestValue

conditionValue

True, False

If-Then-Else

components

sc

ProcessComponent

ConditionifConditionthenelse

Iterate components

sc

Repeat-While

untilCondition

whileProcess

sc

Repeat-Until

whileCondition

untilProcess

currentStatus

daml:oneOfrdf:parseType

daml:collection

ProcessControlStatus

Ready

Ongoing Suspended

Aborted

Canceled

Completed

rdf:_1

rdf:_2rdf:_3

rdf:_4

rdf:_5

rdf:_6

time:Instant

time:Interval

startTime

endTime

duringtimeout

WsdlGrounding

WsdlAtomicProcess-Grounding

hasAtomicProcessGrounding

daml:subClassOf

AtomicProcess-PowerSet

damlsProcess

WsdlOperationRef

wsdlOperation

xsd:anyURI

wsdlOutputMessage

WsdlOutputMessage-MapList

wsdlOutputs

xsd:anyURI

wsdlInputMessage

WsdlInputMessage-MapList

wsdlInputs

wsdlVersion

wsdlDocument

xsd:anyURIportType

operation

WsdlMessageMap

ParameterPowerSet

damlsParameter

wsdlMessagePart

xsltTransformationURI

xsltTransformationString

xsd:string

WsdlOutputMessage-Map

WsdlInputMessage-Map

sc sc

daml:Listsc

sc

daml:Restriction

daml:first

rdf:type

daml:toClass

daml:rest

rdf:type

daml:toClass

daml:onProperty

sc

sc

daml:onProperty

daml:Restrictiondaml:first

daml:toClass

daml:rest

daml:toClass

daml:onPropertysc

daml:onProperty

rdf:typerdf:type

sc

parameter

daml:subClassOf

Legendsc : daml:subClassOfsca : daml:sameClassAs

: dummy node

Figure 7.4: The DAML-S Ontology

70

damls:Profile

sc

ComputationService InformationService

MathematicalServiceStructuralAnalysis-

Service

ClosedForm-AnalysisService

FiniteElement-AnalysisService

MeasurementInfo-Service

DesignStandardInfo-Service

MatrixService

MatrixInversion-Service

DirectMatrix-InversionService

IterativeMatrix-InversionService

sc

sc sc sc sc

IntegralService

MatrixDeterminant-Service

sc

sc

sc

sc

sc

scsc

sc

MaterialInfoService

sc

VisualizationService

sc

ServiceRegistryBroker

sc

EquationSolver

sc

PolynomialEquation-Solver SystemOfEquations-

Solver

LinearSystemOf-EquationsSolver

NonlinearSystemOf-EquationsSolver

sc

sc

sc sc

Figure 7.5: A Service Profile Hierarchy for Computational Mechanics Application WebServices

SparseMatrix

daml:Thing

Quantity

sc

MathQuantity

sc

Scalar

Vector

Matrix

sc

scsc

DenseMatrix BandedMatrix

sc

sc sc

Figure 7.6: A Hierarchy of Matrices Involved in Computational Mechanics

71

ScienceNetMatInv

sc

damls:Service

ScienceNetMatInv-Profile

DirectMatrix-InversionService

sc

presents

ScienceNetMatInv-WsdlGrounding

supports

ScienceNetMatInv-WAPG

damls:WsdlGrounding

damls:WsdlAtomic-ProcessGrounding

sc

sc

ScienceNetMatInv-ProcessModel

ScienceNetMatInv-Process

hasProcess

describedBy

damls:ProcessModel

sc

damls:AtomicProcesssc

Matrix

input

damlsProcess

hasAtomicProcessGrounding

ScienceNetMatInv-WOR

damls:WsdlOperationRef

sc

wsdlOperation

http://science.net/matinv.wsdl#matInv

operation

CompMechRating Class A

qualityRating

rating

QualityRating

sc

Figure 7.7: DAML-S Ontology Instance DescribingScience.net Matrix Inversion Service

NumMethOrgMatInv

sc

damls:Service

NumMethOrgMatInv-Profile

IterativeMatrix-InversionService

sc

presents

NumMethOrgMatInv-WsdlGrounding

supports

NumMethOrgMatInv-WAPG

damls:WsdlGrounding

damls:WsdlAtomic-ProcessGrounding

sc

sc

NumMethOrgMatInv-ProcessModel

NumMethOrgMatInv-Process

hasProcess

describedBy

damls:ProcessModel

sc

damls:AtomicProcesssc

SparseMatrix

input

damlsProcess

hasAtomicProcessGrounding

NumMethOrgMatInv-WOR

damls:WsdlOperationRef

sc

wsdlOperation

http://nummethods.org/matInv.wsdl#getInverse

operation

CompMechRating Class A

qualityRating

rating

QualityRating

sc

Figure 7.8: DAML-S Ontology Instance DescribingNumMethods.org Matrix InversionService

72

OptimizeComMatInv

sc

damls:Service

OptimizeComMatInv-Profile

IterativeMatrix-InversionService

sc

presents

OptimizeComMatInv-WsdlGrounding

supports

OptimizeComMatInv-WAPG

damls:WsdlGrounding

damls:WsdlAtomic-ProcessGrounding

sc

sc

OptimizeComMatInv-ProcessModel

OptimizeComMatInv-Process

hasProcess

describedBy

damls:ProcessModel

sc

damls:AtomicProcesssc

DenseMatrix

input

damlsProcess

hasAtomicProcessGrounding

OptimizeComMatInv-WOR

damls:WsdlOperationRef

sc

wsdlOperation

http://optimize.com/matinverse.wsdl#opInverse

operation

CompMechRating Class A

qualityRating

rating

QualityRating

sc

Figure 7.9: DAML-S Ontology Instance DescribingOptimize.com Matrix Inversion Service

NumRecpNetMatInv

sc

damls:Service

NumRecpNetMatInv-Profile

IterativeMatrix-InversionService

sc

presents

NumRecpNetMatInv-WsdlGrounding

supports

NumRecpNetMatInv-WAPG

damls:WsdlGrounding

damls:WsdlAtomic-ProcessGrounding

sc

sc

NumRecpNetMatInv-ProcessModel

NumRecpNetMatInv-Process

hasProcess

describedBy

damls:ProcessModel

sc

damls:AtomicProcesssc

SparseMatrix

input

damlsProcess

hasAtomicProcessGrounding

NumRecpNetMatInv-WOR

damls:WsdlOperationRef

sc

wsdlOperation

http://numericalrecipe.net/matrixInverse.wsdl#doInverse

operation

CompMechRating Class B

qualityRating

rating

QualityRating

sc

Figure 7.10: DAML-S Ontology Instance DescribingNumericalRecipe.net Matrix InversionService

73

<wsdl:definitions xmlns="http://schemas.xmlsoap.org/wsdl/"xmlns:xs="http://www.w3.org/2001/XMLSchema"xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"

5 xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"xmlns:soapenc="http://schemas.xmlsoap.org/soap/enco ding/"xmlns:nmeth="http://std.nummethods.org"targetNamespace="http://std.nummethods.org">

10 <wsdl:types><xs:schema xmlns="http://www.w3.org/2001/XMLSchema"

targetNamespace="http://std.nummethods.org"><import namespace="http://schemas.xmlsoap.org/soap/e ncoding/"/><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 NumMethods.org(adapted from Sintopchai et al., 2003) (Part 1 of 2)

74

<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:MatrixSe rvice">

<soap:binding style="rpc"transport="http://schemas.xmlsoap.org/soap/http"/>

10 <operation name="getInverse"><soap:operation/><input>

<soap:body use="encoded"encodingStyle="http://schemas.xmlsoap.org/soap/enco ding/"

15 namespace="http://std.nummethods.org"/></input><output>

<soap:body use="encoded"encodingStyle="http://schemas.xmlsoap.org/soap/enco ding/"

20 namespace="http://std.nummethods.org"/></output>

</ operation></ binding><service name="MatrixService">

25 <port name="MatrixWS" binding="nmeth:MatrixServiceSoapBinding"><soap:address

location="http://ws.nummethods.org:8080/axis/servic es/MatrixWS"/></ port>

</ service>30 </ wsdl:definitions>

Figure 7.12: WSDL Description of a Matrix Inversion Web Service by NumMethods.org(adapted from Sintopchai et al., 2003) (Part 2 of 2)

75

X

Y

Z

10.0 kN

1.00 in

5.00 in

6.00 in3.00 in

1.00 in

Figure 7.13: Model of a Structure to be Analyzed by a Structural Analysis Agent

76

<?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

<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

AgentBFemService

sc

damls:Service

AgentBFemService-Profile

FiniteElement-AnalysisService

scpresents

AgentBFemService-WsdlGrounding

supports

AgentBFemService-SolutionWAPG

damls:WsdlGrounding

sc

AgentBFemService-ProcessModel

Solution-AtomicProcess

hasProcess

describedBy

damls:ProcessModel sc

damlsProcess

hasAtomicProcessGrounding

wsdlOperation

CompMechRating Class A

qualityRating

rating

QualityRating

sc

AgentBFemService-GForceWAPG

AgentBFemService-GStiffnessWAPG

AgentBFemService-BoundaryWAPG

AgentBFemService-DiscretizeWAPG

AgentBFemService-SolutionWOR

http://192.168.0.2/processes.wsdl#getSolution

operation

hasAPG

hasAPG

hasAPG

hasAPG

Discretization-AtomicProcess

GForceAtomicProcess

GStiffness-AtomicProcess

Boundary-AtomicProcess

hasProcess

hasProcess

hasProcesshasProcess

MainFemProcessdamls:Composite-

Processsc

sc daml:Restriction

damls:composedOf

rdf:type

daml:onProperty

daml:toClass

daml:intersectionOf

rdf:parseTypedaml:collectiondamls:Sequence

rdf:_1

rdf:_2daml:Restriction

rdf:type

damls:components

daml:onProperty

daml:toClassdamls:listOfInstancesOf

rdf:parseType

daml:collection

rdf:_1rdf:_2

rdf:_3 rdf:_4rdf:_5

damls:WsdlAtomic-ProcessGrounding

damls:WsdlOperationRef

sc

sc

Figure 7.16: DAML-S Ontology Instance Describing Finite Element Service by StructuralAnalysis Agent B

79

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 ofCompMechRegistry

6. Development ofAgentAWebService

7. Development ofAgentBFemService

Second progress report to examination committee 2nd Progress Report

8. Development ofLSESolver and NLSESolver

9. Development ofSIMeasureService

10. Development ofUSMeasureService

11. Development ofASTMMaterialService

Third progress report to examination committee 3rd Progress Report

12. Development ofUBCInfoService

13. Development ofACIInfoService

14. Development ofAISCInfoService

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

Task Description

2003 2004 20054th 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. Aug.Apr. May June July

Figure 7.17: Preliminary Schedule for the Proposed Research Tasks

80

Table 7.6: Expenditure Estimates for the Proposed Research

Item Cost (Baht)

Laboratory equipment 10,000Textbooks and article reprints 10,000Photocopies 5,000Transportation and communications 3,000Thesis binding 2,000

Total 30,000

81

82

REFERENCES

Adeli, 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 MifflinCompany, third edition, 1992.

Akama, K. (1993). Declarative semantics of logic programs on parameterized representationsystems.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 programsynthesis by Equivalent Transformation. InPerspectives of System Informatics, vol-ume 2244 ofLecture Notes in Computer Science, pages 131–139. Springer Verlag,Heidelberg, 2001. Available online:http://assam.cims.hokudai.ac.jp/akama/j/papers/paper1.pdf . [Downloaded: October 8, 2003].

Akama, K., Nantajeewarawat, E., and Koike, H. (2002). Program synthesis based on theEquivalent Transformation computation model. InProceedings of the 12th InternationalWorkshop on Logic Based Program Development and Transformation (LOPSTR 2002),pages 285–304, Madrid, Spain, 2002. Available online:http://assam.cims.hokudai.ac.jp/akama/j/papers/paper5.pdf . [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. InProceedings of the First InternationalSemantic Web Conference (ISWC), Sardinia, Italy, June 2002.

Anutariya, C., Wuwongse, V., Akama, K., and Wattanapailin,V. (2001). Semantic Webmodeling and programming with XDD. InProceedings of the First Semantic Web Work-ing Symposium (SWWS’01), pages 161–180, California, USA, July 2001. Available on-line: http://kr.cs.ait.ac.th/Publications/swws01.pdf . [Downloaded: October9, 2003].

Anutariya, C., Wuwongse, V., and Wattanapailin, V. (2002).An Equivalent-Transformation-based XML Rule Language. InProceedings of the International Workshop on RuleMarkup Languages for Business Rules in the Semantic Web, Sardinia, Italy, June 2002.Available online:http://kr.cs.ait.ac.th/Publications/XETruleml.pdf . [Down-loaded: July 21, 2003].

Apache (2003).Apache Axis 1.1 Release Candidate 1. Apache Software Foundation, 2003.Available online: http://jakarta.apache.org/tomcat/index.html .

83

Baker, M. and Buyya, R. (1999). Cluster computing: the commodity supercomputer.Software–Practice and Experience, 29(6):551–576, 1999. Available online:http://citeseer.nj.nec.com/article/baker99cluster.html .

Barnard, 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 dynamicson the Information Power Grid using Globus. InProceedings of Frontiers ’99, 1999.Available online: http://www.globus.org/documentation/incoming/paper1 .pdf .[Downloaded: June 6, 2003].

Barry, W. and Vacharasintopchai, T. (2001a). A queue serverapproach to parallelizing theElement-Free Galerkin Method. InProceedings 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-FreeGalerkin Method. InProceedings of the Eight East Asia-Pacific Conference on StructuralEngineering 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. ISBN1-861003-75-7.

Belytschko, T., Lu, Y. Y., and Gu, L. (1994). Element-free galerkin methods.InternationalJournal 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:http://www.ietf.org/rfc/rfc2396.txt . [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. Availableonline: http://www.ietf.org/rfc/rfc1738.txt . [Downloaded: August 29, 2003].

Berners-Lee, T., Cailliau, R., Groff, J.-F., and Pollermann, B. (1992). World-Wide Web: Theinformation universe.Electronic Networking: Research, Applications and Policy, 1(2):74–82, 1992. Available online:http://www.w3.org/History/1992/ENRAP/Article_9202.ps . [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 WebConsortium (W3C), May 2001. Available online: http://www.w3.org/TR/xmlschema-2 . [Downloaded: June 23, 2003].

Bray, T., Paoli, J., Sperberg-McQueen, C. M., and Maler, E. (2000). Extensible MarkupLanguage XML 1.0 (Second Edition). World Wide Web Consortium (W3C), October 2000.Available online: http://www.w3.org/TR/REC-xml . [Downloaded: June 23, 2003].

84

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.ComputerNetworks, 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: http://www.teragrid.org/about/TeraGrid-Primer-Sept- 02.pdf . [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. InProceedings ofInternational 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 SOAPperformance for scientific computing. InProceedings of 11th IEEE International Sym-posium on High Performance Distributed Computing (HPDC-11), Edinburgh, Scot-land, July 2002. Available online:http://www.extreme.indiana.edu/xgws/papers/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 FiniteElement Analysis. John Wiley & Sons, New York, 1989. ISBN 0-471-84788-7.

Cyran, M. (2002). Oracle9i Database Concepts, Release 2 (9.2), chapter 6: ApplicationArchitecture. Oracle Corporation, 2002.

DAML (2001). DAML+OIL Language Specification. The Defense Advanced ResearchProjects Agency Agent Markup Language (DAML) Program, March 2001. Available on-line: http://www.daml.org/2001/03/daml+oil . [Downloaded: September 19, 2003].

DAML (2002). Language feature comparison, The Defense Advanced Research ProjectsAgency Agent Markup Language (DAML) Program, August 2002. Available on-line: http://www.daml.org/language/features.html . [Downloaded: September 29,2003].

DAML (2003). The DAML homepage, The Defense Advanced Research Projects AgencyAgent Markup Language (DAML) Program, June 2003. Availableonline: http://www.daml.org . [Downloaded: September 29, 2003].

DAML-S (2003a). DAML-S DAML Services homepage, The DAML Services Coalition,September 2003. Available online:http://www.daml.org/services/index.html .[Downloaded: October 1, 2003].

DAML-S (2003b). DAML-S: Semantic markup for Web Services. Technical report,The DAML Services Coalition, June 2003. Available online:http://www.daml.org/services/daml-s/0.9/daml-s.pdf . [Downloaded: July 10, 2003].

85

Ding, Y., Fensel, D., Klein, M. C. A., and Omelayenko, B. (2002). The Semantic Web: Yetanother hip?Data and Knowledge Engineering, 41(2–3):205–227, June 2002. Availableonline: http://www.cs.vu.nl/˜ying/download/dke2001.pdf .

Fallside, D. C. (2001).XML Schema Part 0: Primer. World Wide Web Consortium (W3C),May 2001. Available online:http://www.w3.org/TR/xmlschema-0 . [Downloaded:June 23, 2003].

Fensel, D. and Bussler, C. (2002). The Web Service Modeling Framework WSMF. Technicalreport, Vrije Universiteit Amsterdam, 2002. Available online: http://gunther.smeal.psu.edu/article/fensel02web.html . [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 TaskForce (IETF), June 1999. Available online:http://www.ietf.org/rfc/rfc2616.txt .[Downloaded: August 29, 2003].

Foster, I. and Gannon, D. (2003).The Open Grid Services Architecture Platform. TheGlobal Grid Forum, 2003. Available online:http://www.gridforum.org/Meetings/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:http://www.globus.org/research/papers/anatomy.pdf .[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:http://www-unix.mcs.anl.gov/dbpp .

Foster, I. (2002a). The Grid: A new infrastructure for 21st century science.Physics Today, 55(2), February 2002. Available online:http://www.aip.org/pt/vol-55/iss-2/p42.html . [Downloaded: June 10, 2003].

Foster, I. (2002b). What is the Grid? A three point checklist. July2002. Available online: http://www-fp.mcs.anl.gov/˜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 scienceand engineering, 2003. Available online:http://www-fp.mcs.anl.gov/˜foster/grid-projects . [Downloaded: April 29, 2003].

GGF (2003). The Global Grid Forum website, The Global Grid Forum, 2003. Availableonline: http://www.gridforum.org . [Downloaded: June 13, 2003].

Gil, Y. and Ratnakar, V. (2002). A comparison of (semantic) markup languages. InProceed-ings of the Fifteenth International Florida Artificial Intelligence Research Society Con-ference, pages 413–418, Pensacola Beach, Florida, USA, May 2002. AAAI Press. ISBN1-57735-141-X. Available online:http://trellis.semanticweb.org/expect/web/semanticweb/flairs02_comparison.pdf . [Downloaded: September 30, 2003].

86

Globus (2003a). The Globus Project website, The Globus Project, 2003. Available online:http://www.globus.org . [Downloaded: June 13, 2003].

Globus (2003b). The Globus Toolkit website, The Globus Project, 2003. Available online:http://www-unix.globus.org/toolkit . [Downloaded: June 16, 2003].

Gropp, W. D., Kaushik, D. K., Keyes, D. E., and Smith, B. F. (2001). High-performanceparallel implicit CFD. Parallel Computing, 27(4):337–362, 2001. Available online:http://www-fp.mcs.anl.gov/petsc-fun3d/Papers/manke. pdf . [Downloaded: July29, 2003].

Grosof, B. N. and Horrocks, I. (2003). Description Logic Programs: Combining logicprograms with Description Logic. Working paper, Center foreBusiness, MIT SloanSchool of Management, Cambridge, MA, USA, June 2003. Available online: http://www.daml.org/rules/dlp-wp-v19.pdf . [Downloaded: October 3, 2003].

Grosof, B. N., Horrocks, I., Volz, R., and Decker, S. (2003).Description LogicPrograms: Combining logic programs with Description Logic. In Proceedigns ofthe 12th International World Wide Web Conference (WWW2003), Budapest, Hungary,May 2003. Available online:http://ebusiness.mit.edu/research/papers/192_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). FractureMechanics on the Intel Itanium Architecture. Technical report, Intel Corporation, 2001.Available online: http://cedar.intel.com/media/pdf/scs/cptconitanium. pdf .[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:http://www.lolali.net . [Downloaded: September 29, 2003].

IPG (2003). What is the IPG? Information Power Grid Project, NASA, October 2003.Available online: http://www.ipg.nasa.gov/aboutipg/what.html . [Downloaded:June 11, 2003].

Klensin, J. (2001).RFC2821 Simple Mail Transfer Protocol (SMTP). The Internet Engi-neering Task Force (IETF), April 2001. Available online:http://www.ietf.org/rfc/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:http://ksl-web.stanford.edu/people/sam/ieee01.pdf . [Down-loaded: June 17, 2003].

87

Microsoft (1997). Microsoft Press Computer Dictionary. Microsoft Press, third edition,1997.

Microsoft (2003). Microsoft .NET, Microsoft Corporation,2003. Available online:http://www.microsoft.com/net . [Downloaded: November 5, 2003].

MPI (1995). MPI: A Message-Passing Interface Standard. Message Passing Interface Fo-rum, June 1995. Available online:http://www.mpi-forum.org/docs/mpi-11-html/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:http://www.oasis-open.org/committees/uddi-spec/tcspecs.shtml#uddiv2 .

Ouellet, R. and Ogbuji, U. (2002). Introduction to DAML: Part 1, January 2002.Available online: http://www.xml.com/pub/a/2002/01/30/daml1.html . [Down-loaded: September 25, 2003].

PVM (2002). PVM: Parallel Virtual Machine. The PVM Project, Oak Ridge NationalLaboratory, November 2002. Available online:http://www.csm.ornl.gov/pvm/pvm_home.html . [Downloaded: July 28, 2003].

Sintopchai, T. V., Barry, W., and Wuwongse, V. (2003). XML Web Services for scientificcomputing applications. Technical report, Asian Institute of Technology, 2003. Availableonline: http://stweb.ait.ac.th/˜st029284/papers/matrix-ws-p aper.pdf .

Sun (2003). Java Servlet Technology. Sun Microsystems, Inc., 2003. Available online:http://java.sun.com/products/servlet .

Suwanapong, S. (2001). Intelligent Web Services. Master’sthesis, Computer Science andInformation Management Program, School of Advanced Technologies, Asian Institute ofTechnology, Thailand, December 2001.

Thompson, H. S., Beech, D., Maloney, M., and Mendelsohn, N. (2001). XML SchemaPart 1: Structures. World Wide Web Consortium (W3C), May 2001. Available online:http://www.w3.org/TR/xmlschema-1 . [Downloaded: June 23, 2003].

Tidwell, D. (2000). Web Services: the Web’s Next Revolution. IBM Corporation,November 2000. Available online:http://www-106.ibm.com/developerworks/edu/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.npaci.edu/ahm2003/slides/ungaro_par14.pdf . [Downloaded: June 4, 2003].

Unicode (2003). The Unicode Standard, Version 4.0.0. The Unicode Consortium, 2003.Available online:http://www.unicode.org/versions/Unicode4.0.0 . [Downloaded:October 6, 2003].

van Engelen, R. A. (2003). Pushing the SOAP envelope with WebServices for scientificcomputing. InProceedings 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

W3C (1999a).HyperText Markup Language (HTML) 4.01 Specification. World Wide WebConsortium (W3C), December 1999. Available online:http://www.w3.org/TR/html4 .

W3C (1999b).Namespaces in XML. World Wide Web Consortium (W3C), January 1999.Available online: http://www.w3.org/TR/REC-xml-names . [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.w3.org/TR/1999/REC-rdf-syntax-19990222 . [Downloaded: September 19, 2003].

W3C (2000). Simple Object Access Protocol (SOAP) 1.1. World Wide Web Consortium(W3C), 2000. Available online:http://www.w3.org/TR/SOAP .

W3C (2001).Web Service Definition Language (WSDL) 1.1. World Wide Web Consortium(W3C), 2001. Available online:http://www.w3.org/TR/wsdl .

W3C (2002). Semantic Web stack diagram, 2002. Available online: http://www.w3.org/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:http://www.w3.org/TR/2003/CR-owl-features-20030818 . [Downloaded: September 19, 2003]. W3C CandidateRecommendation.

W3C (2003b). RDF Primer. World Wide Web Consortium (W3C), September 2003.Available online: http://www.w3.org/TR/2003/WD-rdf-primer-20030905 . [Down-loaded: September 22, 2003]. W3C Working Draft.

W3C (2003c).RDF Vocabulary Description Language 1.0: RDF Schema. World Wide WebConsortium (W3C), September 2003. Available online:http://www.w3.org/TR/2003/WD-rdf-schema-20030905 . [Downloaded: September 24, 2003]. W3C Working Draft.

W3C (2003d). Web Services Architecture. World Wide Web Consortium (W3C), May2003. Available online: http://www.w3.org/TR/ws-arch . [Downloaded: July 30,2003]. W3C Working Draft.

Warfield, S. K., Talos, F., Tei, A., Nabavi, A., Ferrant, M., Black, P. M., Jolesz, F. A., andKikinis, R. (2002). Real-time registration of volumetic brain MRI by biomechanicalsimulation of deformation during Image Guided Neurosurgery. Computing and Visualiza-tion in Science, 5:3–11, 2002. Available online:http://splweb.bwh.harvard.edu:8000/pages/ppl/warfield/papers/2002/warfield-2002-c vs-appeared.pdf .[Downloaded: July 29, 2003].

Wroe, C., Stevens, R., Goble, C., Roberts, A., and Greenwood, M. (2003). A suite ofDAML+OIL ontologies to describe bioinformatics Web Services and data. Interna-tional Journal of Cooperative Information Systems, 12(2):197–224, 2003. Available on-line: http://www.semanticgrid.org/documents/mygrid_servic e_ontology_02.pdf . [Downloaded: July 22, 2003].

Wuwongse, V., Akama, K., Anutariya, C., and Nantajeewarawat, E. (2000). A foundation forXML databases: Data model. Technical Report CS-KR-00-01 (2000), Knowledge Rep-resentation Laboratory, Asian Institute of Technology, Thailand, 2000. Available online:

89

http://kr.cs.ait.ac.th/Publications/datamodel.pdf . [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:http://kr.cs.ait.ac.th/Publications/ieee-is.pdf . [Downloaded: July 21, 2003].

Yagawa, G., Soneda, N., and Yoshimura, S. (1991). A large scale finite element analysisusing domain decomposition method on a parallel computer.Computers and Structures,38(5/6):615–625, 1991.

90

INDEX

agent, 2, 55algorithmic distribution, 14applicability condition part, 43application logic, 55application Web Service, 55attribute name, 45attribute-name variable, 45

basic specialization mapping operator, 46basic specializations, 45, 46bind (Web Service), 21body, 42, 44bottleneck problem, 14boxes, 29business logic, 55

category, 30class definitions, 65classes, 30clause, 42client, 55collaboration, 2concurrency, 13constraint, 42

data, 46data distribution, 13data input, 56database, 55database server, 55declarative description, 42declarative programming language, 46definition part, 43degree of freedoms, 7describe (Web Service), 21description, 42document processing and transformation,

46documents, 46domain decomposition, 13

ellipses, 29empty element, 44empty-element tags, 45end tags, 45equivalent transformation rules, 43equivalent transformations, 43execution part, 44

Formal semantics, 34functional decomposition, 14

ground, 44ground clause, 42ground objects, 41ground XML expressions, 45

head, 42, 43HTTP, 21

identity specialization, 41instance, 42intelligent, 2interpretation domain, 41isotropic materials, 7ivar-expression, 45

knowledge base server, 55knowledge representation systems, 27

literals, 29load balancing, 16logic frameworks, 39Loosely coupled, 14

multi-tier, 55

nested element, 44non-ground XML expressions, 44non-unit clause, 42

object, 28objects, 41Ontologies, 39ontologies, 2ontology mapping facilities, 57

parallelism, 13pattern matching, 25PC-based servers, 66predicate, 28problem description, 43process ontology, 3processor farm, 16program, 43program execution, 46program specification, 43programs, 46proofs, 39

91

properties, 30publish (Web Service), 21

query part, 43query processing, 46

RDF Model and Syntax (RDF M&S), 39RDF Schema, 39reasoning, 2Remote Procedure Calls (RPC), 21resource, 28resource sharing, 13result presentation, 56rules, 39

search engines, 56Semantic Web Services, 37semantics of an XML declarative descrip-

tion, 46service consumer, 21service execution and monitoring, 56service execution plan, 57service planning, 56service provider, 21service registry, 3, 21service 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, 28

t-element, 45t-expression, 45tags, 45tier, 55tightly coupled, 14tool building, 13type, 30

UDDI, 22understand, 27

Unicode, 39unit clause, 42URI references, 28URIs, 39user interface, 55

Web resource, 28Web Service, 55Web Services, architecture of, 21WSDL, 22

XET program, 46XET rules, 46XML, 21XML application, 28XML clauses, 46XML declarative descriptions, 46XML elements, 44XML expression, 44XML expression alphabet, 44XML expressions, 44XML namespaces, 38XML specialization generation system, 46XML specialization system, 46XML tags, 38

92