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

SEMANTIC WEB SERVICES FOR COMPUTATIONAL MECHANICS

by

Thiti Vacharasintopchai

A dissertation proposal submitted in partial fulﬁllment of the requirements for the
degree of Doctor of Engineering

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

Nationality: Thai
Previous Degrees: B. Eng. (Civil Engineering)
Chulalongkorn University
Bangkok, Thailand
M. Eng. (Structural Engineering)
Asian Institute of Technology
Bangkok, Thailand

Scholarship Donor: Royal Thai Government Followship

Asian Institute of Technology
School of Civil Engineering
Thailand
November 2003

i

TABLE OF CONTENTS

Chapter Title Page

Title Page i
Table of Contents iii
List of Figures v
List of Tables vii

1 Introduction 1
1.1 Background 1
1.2 Problem Statement 4
1.3 Objectives 4
1.4 Scope 5
1.5 Research Approach 5
1.6 Contributions 5

2 FEM and the Need towards Distributed Computing 7
2.1 Formulation of the Finite Element Method 7
2.2 Parallel Computing and Applications in Computational
Mechanics 10
2.3 Towards an Application of Distributed Computing Technique 10

3 Distributed Computing 13
3.1 Distributed Computing Concepts 13
3.2 Methods of Problem Decomposition 13
3.2.1 Data Distribution 13
3.2.2 Algorithmic Distribution 14
3.2.3 Load Balancing 16
3.3 Applications in Scientific Computing 16
3.3.1 SETI@home Project 17
3.3.2 Grid Computing 18

4 Web Services 21
4.1 The Web Services Architecture 21
4.2 Applications of Web Services in Scientific Computing 23

5 The Semantic Web 25
5.1 General 25
5.2 Resource Description Framework (RDF) 28
5.2.1 Introduction 28
5.2.2 An RDF Statement 28
5.2.3 Identification of Resources 28
5.2.4 The RDF Model 28
5.2.5 Defining RDF Vocabularies 29
5.3 DAML+OIL 31
5.4 DAML-S: Semantic Markup for Web Services 36
5.5 Inferences – Making Use of Resources and Ontologies 38

6 XML Declarative Description 41
6.1 Declarative Description Theory 41

iii

6.1.1 Specialization Systems 41
6.1.2 Declarative Descriptions 42
6.1.3 Semantics of Declarative Descriptions 42
6.1.4 Equivalent Transformations 43
6.2 XML Declarative Description 44
6.2.1 XML Elements and XML Expressions 44
6.2.2 Formulation of XML Declarative Description 45
6.2.3 XML Equivalent Transformation 46
6.3 Ontology Modeling and Inference with XDD 49

7 Methodology 55
7.1 A Semantic Web Services Framework for Computational
Mechanics 55
7.2 An Overview of the Research Tasks 58
7.3 Infrastructure Design and Development 58
7.3.1 Construction of Domain Ontologies 58
7.3.2 Construction of Ontology Mapping Facilities 59
7.3.3 Construction of Service Enactment Facilities 62
7.4 Application Web Services Development 63
7.4.1 Design of XML Schemas and Ontologies 65
7.4.2 Construction of DAML-S Ontology Instances and
WSDL Documents 65
7.4.3 Implementation and Deployment of Application
Web Services 66
7.5 Illustrative Applications of the Framework 66

References 83

Index 91

iv

LIST OF FIGURES

Figure Title Page

3.1 Problem Decomposition: Data Distribution 14
3.2 Problem Decomposition: Algorithmic Distribution 15
3.3 Problem Decomposition: Hybrid Distribution Method 1 15
3.4 Problem Decomposition: Hybrid Distribution Method 2 16
3.5 Model of the NASA X-38 Crew Return Vehicle (Barnard et al.,
1999) 19
3.6 Mach Contours for the X-38 Crew Return Vehicle (Barnard
et al., 1999) 19

4.1 Conceptual Web Services Model (Basha et al., 2002) 22
4.2 Roles of SOAP, WSDL and UDDI in Web Services Architec-
ture (Basha et al., 2002) 23

5.1 Example of an HTML Document 26
5.2 HTML Document in Figure 5.1 as Rendered on a Web Browser 26
5.3 Example of an RDF Description 27
5.4 A Simple RDF Statement (adapted from W3C, 2003b) 29
5.5 Several RDF Statements about Resources (adapted from W3C,
2003b) 30
5.6 A Vehicle Class Hierarchy (adapted from W3C, 2003b) 31
5.7 An RDF/XML Encoding that Corresponds to Figure 5.6 (W3C,
2003b) 32
5.8 An Instance of a Class Defined in Figures 5.6 and 5.7 (W3C, 2003b) 32
5.9 Definition of Properties Corresponding to Classes in Figures 5.6
and 5.7 (adapted from W3C, 2003b) 33
5.10 An Instance of a Class using Properties Defined in Figure 5.9
(W3C, 2003b) 34
5.11 An Example of daml:Restriction Construct 36
5.12 Upper Levels of DAML-S Ontology (DAML-S, 2003b) 39
5.13 Semantic Web Stack Diagram (W3C, 2002) 40
5.14 Definition of XML Namespace 40

6.1 Typical Structure and Syntax of an XET Program (Anutariya
et al., 2002) 48
6.2 XDD Description Modeling the Ontology Definitions of Class
Person (Suwanapong, 2001) 50
6.3 XDD Description Modeling the Ontology Instances of Class
Person (Suwanapong, 2001) 50
6.4 XDD Description Modeling the Ontology Axiom daml:inverseOf
(Suwanapong, 2001) 51
6.5 An XET Program Corresponding to the XDD Descriptions in
Figures 6.2 to 6.4 (Part 1 of 2) 52
6.6 An XET Program Corresponding to the XDD Descriptions in
Figures 6.2 to 6.4 (Part 2 of 2) 53
6.7 Information Derived from the XDD Descriptions in Figures 6.2 to 6.4
(Suwanapong, 2001) 54

v

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 SWSCM
Framework (adapted from Cyran, 2002) 68
7.3 Example of a Material Ontology 69
7.4 The DAML-S Ontology 70
7.5 A Service Proﬁle Hierarchy for Computational Mechanics Ap-
plication Web Services 71
7.6 A Hierarchy of Matrices Involved in Computational Mechanics 71
7.7 DAML-S Ontology Instance Describing Science.net Matrix
Inversion Service 72
7.8 DAML-S Ontology Instance Describing NumMethods.org Ma-
trix Inversion Service 72
7.9 DAML-S Ontology Instance Describing Optimize.com Matrix
Inversion Service 73
7.10 DAML-S Ontology Instance Describing NumericalRecipe.net
Matrix Inversion Service 73
7.11 WSDL Description of a Matrix Inversion Web Service by Num-
Methods.org (adapted from Sintopchai et al., 2003) (Part 1 of 2) 74
7.12 WSDL Description of a Matrix Inversion Web Service by Num-
Methods.org (adapted from Sintopchai et al., 2003) (Part 2 of 2) 75
7.13 Model of a Structure to be Analyzed by a Structural Analysis Agent 76
7.14 Example of an Input Data that Represents the Model in Fig-
ure 7.13 (Part 1 of 2) 77
7.15 Example of an Input Data that Represents the Model in Fig-
ure 7.13 (Part 2 of 2) 78
7.16 DAML-S Ontology Instance Describing Finite Element Ser-
vice by Structural Analysis Agent B 79
7.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 Related
to Key Operations in Computational Mechanics 60
7.2 Examples of Conceptual Ontologies Related to Key Opera-
tions in Computational Mechanics 61
7.3 Examples of Axioms Related to Key Operations in Computa-
tional Mechanics 61
7.4 Summary of Matrix Inversion Service Profiles in Figures 7.7 to 7.10 63
7.5 Preliminary List of Application Web Services to be Developed 64
7.6 Expenditure Estimates for the Proposed Research 81

vii

CHAPTER 1
INTRODUCTION

1.1 Background
In performing the analysis of structures using numerical methods, computers must
be closely guided by human users. For example, consider the case of finite element anal-
yses, at first we have to examine a real world problem and model it as a problem domain
and boundary conditions subjected to applied forces. We may have to consult many design
codes or experimental results to obtain the forces for the analysis. Next, we have to discretize
the 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 the
boundary conditions and solve for nodal solutions. We also have to use our experience and
judgment to select the element types and the constitutive models for the material and problem
being considered, examine the accuracy of the analysis results and, if necessary, repeat the
entire process to obtain accurate results. Moreover, for large and complex analyses, running
an entire process may take hours or days and special visualization techniques such as ani-
mating graphics or virtual reality may be needed to effectively interpret the analysis results.
This situation may be more complicated in the case that there exist incompatibilities between
input and output data format of software components employed, and may be tedious, take a
lot of time, and lead to inaccurate analyses if performed by inexperienced users.
Solutions are available to improve the performance and user-friendliness of structural
analysis software. One could be modifying or inventing a new formulation of the analysis
method. Another could be using computer technologies to improve computing performance
and 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) (Belytschko
et al., 1994) which is an analysis procedure that avoids the need for meshing by employing
a moving least-squares technique (Lancaster and Salkauskas, 1981) in approximating the
field quantities of interest. An example of the latter is the application of parallel computing
techniques into the finite element analysis procedure, cf. Adeli and Kamal (1993) and Ya-
gawa et al. (1991), so that complex analyses are performed in shorter time. Improvement
of user-friendliness in structural analysis software may come at the cost of an increase in
computational requirement, thus in some cases combination of the two solutions is also con-
sidered. For example, a parallel computing technique was employed to make analyses using
EFGM analyses more practical to users (Barry and Vacharasintopchai, 2001b).
Distributed computing technologies, in particular, Web Services (W3C, 2003d) and
the Semantic Web (Berners-Lee et al., 2001), are available in computer science to help unify
and 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. With
Web Services and the Semantic Web, we wil not have to be actively involved in the analyses
by feeding the computers all the data and elaborate instructions, but instead be involved in a
less 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 the
maturity of researches in artificial intelligence, the Internet is not just a hyper-library for us
to search for information nor a communication tool for us to send emails or messages. We
could use the Internet as a very large platform for scientific computations with the help of
intelligent software agents that collaborate to accomplish a given task.
Web Services and the Semantic Web, two technologies built on top 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 breed
of Web application that enables collaboration on the Web. They are self-contained, self-
describing, modular applications that can be published, located, and invoked across the Web.
Web services perform functions, which can be anything from simple requests to complicated
processes. Once a Web service is deployed, other applications (and other Web services) can
discover and invoke the deployed service (Tidwell, 2000). The Semantic Web, on the other
hand, is a technology that enables computers accessing data on the Web to be intelligent. Up
to now, the World Wide Web has developed rapidly as a medium of documents for people
rather 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 for
computers, the Web will be transformed into the Semantic Web where computers can find the
meaning of semantic data by following hyperlinks to definitions of key terms and rules for
reasoning about them logically (Berners-Lee et al., 2001). The combination of Web Services
and Semantic Web technologies, termed Semantic Web Services (McIlraith et al., 2001), will
enable automated discovery, execution, composition, and interoperation of web services to
accomplish any tasks requested by human users. Automation is not achieved by humans
hard-coding programs into software agents but rather by the agents themselves through rea-
soning processes that lead to understanding. Such reasoning and automated operation are
based on ontologies, which are the formal, explicit specifications of shared conceptualiza-
tions of the world (Broekstra et al., 2002) and, like web pages, can be individually published
and linked to other ontologies across the Internet.
In terms of numerical analysis of structures, Semantic Web Services may be applied
to assist human users in the analysis and design of structures as in, but not limited to, the
following scenario:

• At first one examines a real world problem, defines the problem domain for the analy-
sis, and inputs the data as well as important analysis keywords into a structural analysis
software agent, which is a web service that performs analysis of structures on behalf
of human users or other agents. The keywords may be related to material types such
as mild steel, aluminum, reinforced concrete or ASTM1 A36 steel, material charac-
teristics such as linear elastic, elastoplastic, viscoelastic, or viscoplastic, modes of
analysis such as static, dynamic, buckling, or fracture, or boundary conditions such as
cantilever, simply-supported, three-edge fixed supported, building codes such as the
Uniform Building Code (UBC) and the National Building Code (NBC), and design
specifications such as the American Institute of Steel Construction (AISC) specifica-
tions, the American Concrete Institute (ACI) specifications, and the British Standards
(BS) specifications.

• Next, the agent consults its ontology to understand the user’s request and construct a
set of problem parameters to perform an analysis. For example, if the user instructs
the agent to

find the maximum service stresses of an ASTM A36 steel plate with dimen-
sions of 1.00 m wide by 200 cm long with a quarter inch thickness simply
supported on all edges and subjected to the residential floor live load spec-
ified in the latest version of UBC code,
1 American Society for Testing and Materials

2

the agent would consult its ontology to identify the parameters required for a typical
stress analysis, which are the nodal coordinates, modulus of elasticity, Poisson’s ratio,
vector of applied forces, and boundary conditions, and then prepare the parameters
to perform the analysis accordingly. Specifications of the boundary conditions, i.e.
simply-supported, are available in the boundary condition ontology. Specifications
of the design live load, i.e. UBC residential live load on floors, are available in the
building code ontologies accessible to the agent. In the same manner, modulus of
elasticity, yield stress, and ultimate strength of the ASTM A36 steel are also specified
in the ASTM standard material ontology. If the keywords used in the building code
ontologies or material ontologies are different from the ones that the agent knows, the
agent can infer from the ontologies that define those keywords and identify the one that
specifies the parameter needed. Differences among units of measurements, i.e. meters,
centimeters and inches, will also be arbitrated since the agent can identify meters,
centimeters, and inches as units of lengths and consult the measurement ontology.

• The agent would consult its process ontology and understand that maximum stresses in
typical analyses can be derived from nodal displacement solutions obtained by a finite
element analysis. Inferences on the process ontology also suggests the agent that, to
perform a finite element analysis, it needs to discretize the problem domain, which, in
this case, is the geometry of the plate given by the user, into a mesh consisting of a
number of nodes and their connectivities. After discretization, it needs a global stiff-
ness matrix, which is constructed by assembling the element stiffness matrices derived
from nodal coordinates and material properties, and a global force vector, which is
constructed by assembling the element force vectors derived from nodal coordinates
and specifications of forces, including the live load it obtained from the building code
ontology.

• The agent would consult the process ontology further that once it obtains the global
stiffness matrix and the global force vector, it needs to set up a linear system of equa-
tions, apply the boundary conditions obtained from the boundary condition ontology,
and solve the system of equations to obtain the vector of nodal displacements. It then
needs to find the derivatives of the nodal displacements to obtain stresses in the plate
and search for the maximum values of stresses as requested by the human user.

• During the analysis, the agent is aware that it cannot solve the linear system of equa-
tions nor search for the maximum values of stresses efficiently because the agent was
originally designed to solve some other types of problems. Therefore, it seeks the help
of other agents. It starts by making a request to a service registry for a list of available
software agents that offer solutions to linear system of equations and the ones that can
identify maximum values from a list of given floating point numbers. The service reg-
istry would return to the agent the requested list which includes the estimated time to
get results from the agents, the characteristics of the input, e.g. dense matrices, sparse
matrices, banded matrices, and the formats of input and output data. The agent would
consult the list, reason and select the best third-party agent for each operation, prepare
the suitable input data for each agent, request them to perform the computations on its
behalf, convert the results back to its own format, and utilize the results in its struc-
tural analysis procedure in the same manner as it would do with the results from its
own subroutines.

3

1.2 Problem Statement
Semantic Web Services, which is the combination of Web Services and the Semantic
Web technologies, can be used to improve the performance and user-friendliness of structural
analysis software as well as the collaboration among them by enabling intelligent agent-
based analyses of structures in a parallel and distributed manner. The realization of such a
paradigm with an example described at the end of Section 1.1 involves issues in the following
areas:

1. Representation of knowledge in scientific computing and structural engineering

2. Modeling of structural analysis processes such as the processes in the finite element
methods or meshless methods

3. Description of software agents for automatic discovery and delegation of analysis tasks

4. Design of languages and mechanisms for communications among software agents

5. Design of the services registry broker to support automatic discovery and collaboration
of software agents.

Knowledge and tools in structural engineering and computer science, and in par-
ticular, computational mechanics and artificial intelligence, are required in this study. The
former are required to construct ontologies in scientific computing and structural engineering
as well as to model structural analysis processes. The latter are required to properly design
and 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 a
user-friendly intelligent structural analysis paradigm that enables collaboration of structural
analysis software agents on sequential and parallel computers by means of the Semantic Web
Services technology. To fulfill the primary objective, the following secondary objectives are
to be achieved:

1. To capture and construct the domain ontologies in scientific computing and structural
engineering, which include

(a) the ontology on quantities such as scalars, vectors, matrices, tensors and the op-
erations on them
(b) the ontology on measurements such as lengths, forces, masses and the conver-
sions between different units such as SI units and US customary units
(c) the ontology on material properties such as strength properties and elastoplastic
or viscoplastic properties
(d) the ontology on geometric properties such as those of points, lines, triangles,
rectangles, boxes, and tetrahedra.
(e) the ontology in computational mechanics domain such as nodes, displacements,
stresses, strains, and boundary conditions.

4

2. To capture and construct the process ontologies in computational mechanics such as
discretization, formulation of shape functions, formulations of element stiffness ma-
trices and their assembly, applications of the boundary conditions, solutions of the
system of equations, and calculations of stresses and strains

3. To examine and apply available techniques in computer science, which include de-
scriptions of software agents, agent communication languages, and services registry
brokering, to create a mechanism that enables automatic discovery and collaboration
among the structural analysis software agents.

4. To demonstrate and evaluate the usability of the framework by implementing the pro-
posed components and applying them to selected classes of analysis problems.

1.4 Scope
The goal of this study is to propose a framework for Semantic Web Services in com-
putational mechanics and to provide an implementation to demonstrate its usability. The
study will involve semantic collaboration of structural analysis software agents located on
sequential and parallel computer clusters on the Internet to solve problems in linear elasticity
and elastoplasticity. The SI and the US customary units of measurements, loadings from the
UBC building code, load factors from ACI and AISC structural design manuals, and material
properties specified in ASTM standards will be supported in the implementation by means of
ontologies. In the computer science aspect, networking security issues will not be taken into
account. Implementation of the software components will utilize efficient and appropriate
algorithms. However, exhaustive searches and uses of the most optimal ones will be of less
concern.

1.5 Research Approach
Semantic Web Services is an area in the Extensible Markup Language (XML) (Bray
et 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 and
the services registry broker will be based on state-of-the-art XML technologies and will be
implemented 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 software
components on parallel computer clusters. Modeling of processes, representation of knowl-
edge, and inference capabilities of the software agents will be by means of XML Declarative
Description (Wuwongse et al., 2001) and XML Equivalent Transformation (XET) (Anutariya
et al., 2002), which are a unified modeling language for the Semantic Web and the associated
computation 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 intelligence
technologies. The result of this study will be a framework that turns the Internet into a
large platform for numerical analysis of structures where distributed software agents or web
services 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 conceptualizations
defined by ontologies. This framework would improve knowledge sharing and collaboration
among researchers and implementors in structural engineering field. It may be further linked
with 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 2
FEM 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 structures
and continua. Usually the problems addressed are too complicated to be solved satisfactorily
by classical analytical methods. The finite element procedure produces many simultaneous
algebraic equations, which are generated and solved on computers ranging from personal
computers to mainframe and super computers (Cook et al., 1989).
The formulation of typical displacement-based finite element methods from Cook
et al. (1989) is presented in this section. In the displacement-based finite element method,
displacements are taken as the dependent variables with the total potential energy of a body
Π p as the associated functional. An admissible displacement field is defined in a piecewise
fashion such that displacements within any elements are interpolated from nodal degree of
freedoms (d.o.f.) of that element. The total potential energy functional is then evaluated in
terms of nodal d.o.f. Using the principle of stationary potential energy, we write dΠ p = 0 and
obtain a simultaneous system of algebraic equations to be solved for nodal d.o.f. Detailed
derivation of the displacement-based finite element method is as follows:
The total potential energy in a linearly elastic body is described as:

1 T
Πp = ε E ε − εT E ε0 + εT σ0 dV − uT F dV − uT Φ dS − DT P (2.1)
V 2 V S

in which u = u v w T , the displacement field
ε = εx εy εz γxy γyz γzx T , the strain field
E = the material property matrix
ε0 , σ0 = initial strains and initial stresses
F = Fx Fy Fz T , body forces
Φ = Φx Φy Φz T , surface tractions
D = nodal d.o.f. of the structure
P = loads applied to d.o.f. by external agencies
S,V = surface area and volume of the structure

The material property matrices E for isotropic materials are given as

(1 − ν)c νc νc
 
0 0 0
 νc (1 − ν)c νc 0 0 0
 νc νc (1 − ν)c 0 0 0 
 
E =  (in three dimensions) (2.2a)
 0 0 0 G 0 0 
 0 0 0 0 G 0
0 0 0 0 0 G
E E
where c = and G = ,
(1 + ν)(1 − 2ν) 2(1 + ν)

1−ν ν
 
0
E  ν
E= 1−ν 0  (for plane strain conditions), (2.2b)
(1 + ν)(1 − 2ν) 1−2ν
0 0 2

7

1 ν
 
0
E 
E= ν 1 0  (for plane stress conditions). (2.2c)
1 − ν2 1−ν
0 0 2

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)

where N is the shape function matrix.
For 4-noded plane rectangular bilinear element (2.3) is specialized as
 
u1 
 
v1 
 
 
u N1 0 N2 0 N3 0 N4 0
 
= u2 (2.4)
v 0 N1 0 N2 0 N3 0 N4  .  .
.
 
 
v 
4

where subscripts 1 . . . 4 respectively denote the ﬁrst node to the fourth node of the plane
element. For an element of 2a wide by 2b long, each Lagrange’s shape function Ni above
has the form
(a ± x)(b ± y)
Ni = (2.5)
4ab
For 8-noded solid rectangular trilinear element (2.3) is specialized as
 
 u1 
 
  v1 
 
    
u N1 0 0 N2 0 0 . . . w 
 
 1
v =  0 N1 0 0 N2 0 . . . u (2.6)
 2
w 0 0 N1 0 0 N2 . . .  . 
   . 
 . 
 
 
 
w 
8

where subscripts 1 . . . 8 respectively denote the ﬁrst node to the eight node of the brick ele-
ment. For an element of 2a wide by 2b long by 2c thick, each Ni above has the form
(a ± x)(b ± y)(c ± z)
Ni = (2.7)
8abc
The strains are obtained from displacements by differentiation. Thus

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

Relation between strains and displacements in the equation above is given in two and
three dimension respectively by
∂ 
0 0
 εx   ∂x ∂
 
  0
 εy 
  0  
  ∂ ∂y

 εx  0

∂x    0 0 ∂ u
  
εz
 
∂ u
εy =  0 ∂y  =  ∂ ∂ ∂z  v

and (2.9)

v γxy   ∂y ∂x 0   
γxy ∂ ∂

   w
γyz 
 
∂y ∂x   0 ∂ ∂ 
  
∂z ∂y 
γzx
 
 
∂ ∂
∂z 0 ∂x
8

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

1 numel T numel
Πp = ∑
2 n=1
d n kn d n − ∑ d n ren − DT P
T
(2.10)
n=1

where summation symbols indicate that we include contributions from all numel elements of
the structure. Element stiffness matrix k and element load vector re are derived, respectively,
from
k= B T EB dV (2.11)
Ve

re = B T E ε0 dV − B T σ0 dV + N T F dV + N T Φ dS (2.12)
Ve Ve Ve Se
where Ve denotes the volume of an element and Se denotes its surface. In the surface integral,
N is evaluated on Se .
Every d.o.f. in an element vector d also appears in the vector of global d.o.f. D. Thus,
when k and re of every element are expanded to structure size, D can replace d in (2.10).
Equation (2.10) becomes
1
Π p = DT K D − DT R (2.13)
2
where
numel numel
K= ∑ kn and R = P+ ∑ re n (2.14)
n=1 n=1
Summations indicate assembly of element matrices by addition of overlapping terms.
Making Π p in (2.13) stationary with respect to small changes in the Di we obtains
∂Π p
=0 (2.15)
∂D
KD = R (2.16)

Matrix equation (2.16) is a set of simultaneous algebraic equations to be solved for d.o.f. D.
From the formulation presented above, the finite element procedure for linear elastic
problems is summarized. Given a description of the problem which consists of a problem
domain, a specification of body forces, surface tractions, initial stresses, initial strains, and
prescribed boundary conditions, the problem domain is divided into a finite number of parts
or elements identified by nodes and their connectivities. The goal of the displacement-based
finite element procedure is to obtain the displacement at the nodes D by solving the simulta-
neous system of equations (2.16). The global stiffness matrix K and the global load vector in
this equation are assembled from their element counterparts, which are the element stiffness
matrices and the element load vectors obtained by evaluating Equations (2.11) and (2.12),
respectively. The global stiffness matrix K is singular by its nature. It cannot be inverted
nor can a unique set of nodal displacements D be obtained by solving the equations. The
physical reason for this is that rigid-body motion is still possible. Without supports, the
structure 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 to
make them solvable. Once the nodal displacements are obtained, strains within an element
are derived from ε = Bd in Equation (2.8). Stresses are obtained by multiplying the strain
vector by the corresponding material property matrices E presented earlier. For nonlinear
problems in elastoplasticity, Equation (2.16) becomes K (D) D = R(D) and displacements
are incrementally solved in an iterative manner.

9

Accuracy of the finite element methods depends on many factors such as the basis
of shape functions used for interpolation, the fineness of discretization of the problem do-
main, and constitutive models of the materials. More accurate constitutive models gives
more accurate responses of a structure to given applied loads whereas finer discretizations
and higher order of bases make responses of the structure closer to the ones that would be
obtained if it was a continuum. For large and complex analysis problems such as nonlinear
analyses of three dimensional bodies, the increased accuracy may come at the expense of a
significantly increase in analysis time, which could be hours or days. Thus, techniques from
computer science such as parallel and distributed computing are often applied to improve the
performance of computer-aided structural analyses. The next sections present an overview
of parallel computing technique and a discussion which leads to the need for an application
of 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 accomplish
a task faster by dividing it into a set of subtasks assigned to multiple workers (Kumar et al.,
1994). It differs but is closely related to distributed computing which is the field that deals
with techniques to spread a computational task across several programs, processes or pro-
cessors (Brown, 1994). Distributed computing is mainly concerned with problems such as
reliability, security, and heterogeneity which are generally regarded lightly in parallel com-
puting, however, the basic task of developing programs that can run on many computers at
the same time is a parallel computing problem (Foster, 1995).
Parallel software needs a parallel computing platform to run. In the past, the platform
is 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 access
to. Beginning in 1990s the development of cluster computing technology which enables per-
sonal computers connected to a high-speed local area network to form a virtual parallel com-
puter has made it possible for the public to have access to parallel computing environments.
Toolkits such as the Parallel Virtual Machine (PVM) library (PVM, 2002) and the Message
Passing Interface (MPI) library (MPI, 1995) enable the communication and coordination of
processors 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 processors
comprising a virtual parallel computer (Baker and Buyya, 1999). A parallel computer based
on the message-passing cluster technology is classified as the Multiple Instruction stream,
Multiple Data stream (MIMD) type in parallel computing taxonomy (Kumar et al., 1994;
Foster, 1995). Cluster-type parallel computer is now a less expensive alternative platform
for 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, new
applications 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 approximate
solutions while in 2001 analysis of large structures with minor details taken into account are
preferred. 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 may
not deliver enough power for real-time simulation of natural phenomena with increasingly
complex problem formulation. More computational power from many computers may be
needed 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. In
some 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 such
that the ever-increasing application demand is satisﬁed, a technique in distributed computing
from computer science is necessary. The next chapter presents an overview of developments
in distributed computing.

11

CHAPTER 3
DISTRIBUTED COMPUTING

3.1 Distributed Computing Concepts
Distributed computing is an area in computer science that deals with the spreading of
a computational task across several programs, processes or processors (Brown, 1994). There
are many forms of distributed computing with many different reasons for each and a wide
range of research activity in the area. The forms of distributed computing can be classified
by the benefits that they offer. Based on Brown (1994), the benefits are listed as follows:

1. By splitting the solution to a specific problem into a number of steps, we can use
existing general-purpose programs to handle some of these steps, and so reduce the
amount of new code we have to write. We may often be able to avoid writing any new
code altogether. This benefit is referred to as tool building.

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

3. If the problem itself is sometimes of the form “Do A, B and C in parallel”, the most
natural solution may be to use separate parallel processes to perform A, B and C.
Forcing the solution into a strictly sequential form for execution by a single process is
unnatural and makes it harder to understand. This benefit is referred to as parallelism.

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

3.2 Methods of Problem Decomposition
To benefit from distributed computing techniques, a problem has to be decomposed
into pieces so that the solution may be distributed. In the following, various methods to
decompose a problem, as described in (Brown, 1994), will be presented.

3.2.1 Data Distribution
The first way of distributing an application is to divide the input data set into pieces,
and hand each piece to a separate process, as shown in Figure 3.1. This is known as data
distribution or domain decomposition. Data distribution divides the input data set among
several 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 the
nature of the problem, there will be an upper limit on the number of processors which can be
usefully employed and a lower limit on the smallest amount of data that can sensibly be pro-
cessed on each processor. The limits are related to ordering and synchronization of the tasks
distributed to each processor. Consider a number of tasks with many processors processing
data on each task. Some data may need to be processed by other tasks and we cannot have
all of these tasks performed simultaneously. Information from other processors performing
the same task may be necessary to process a set of data on a given processor, and thus a
processor may have to wait for other processors in processing a set of data. The former is
an 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 coupled prob-
lems are problems that do not require frequent synchronization of activity and the exchange
of data among processors while tightly coupled problems are the opposite. The coupling
degree is very important for problems that involve a large number of processors because it
determines the extent to which one can achieve a speed-up which is linearly related to the
number of processors.

3.2.2 Algorithmic Distribution
The second way for distributing a problem solution is algorithmic distribution or
functional 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 lines
in manufacturing factories. The key characteristic of algorithmic distribution is that each
processor 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 the
input data set increases. Loose synchronization is inherited with algorithmic distribution.
In Figure 3.2, when Process A receives so much input data that its production rate cannot
match the input capacity of Process B, Process B will have to wait for Process A. This causes
a bottleneck problem and data distribution techniques may be employed in the process or the
whole 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 A1
Process A2 Process B Process C
Process A3

Figure 3.3: Problem Decomposition: Hybrid Distribution Method 1

15

Process A1 Process B1 Process C1

Process A2 Process B2 Process C2

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 has an equal amount of work to
do. If some processors are given less work than the others, they will finish sooner and be
idle until the others are done. In some applications using data distribution, load balancing is
easily achieved by giving each processor an equal amount of input data. This would work if
each data item is equally expensive to process and each process has the same performance or
production rate but it is not generally true for all applications and environments. For many
applications each data item does not take equal time to process and the performance of each
processor on a network is typically not equal. Thus, a load balancing strategy needs to be
employed to maximize the performance of the whole distributed computing system. One
approach for load balancing on data distribution is to divide the data into many more pieces
than the number of processors, and allow the processors to get themselves a new piece of data
when they are ready. This approach is sometimes called a processor farm and was, for exam-
ple, implemented in Barry and Vacharasintopchai (2001a). Load balancing for a pipelined,
algorithmic decomposition of a problem is more difficult than its data decomposition coun-
terpart because we cannot usually fine tune the workload of each processor by adjusting the
boundaries between the tasks that they perform. In this case, the hybrid methods discussed
earlier 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 relied
heavily on the use of digital computers. Procedures for such analyses involve discrete mod-
els that depend on sizes of the problems and desired accuracy of the solutions, rather than
in 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. Researchers
and practitioners have then turned to distributed computing as a means to solve the problems
in 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 important
achievements in this area, namely, the SETI@home project and grid computing, will be
summarized.

3.3.1 SETI@home Project
SETI@home Project (Anderson et al., 2002), a famous project for its application of
public-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 the
Earth. SETI@home project is based on the radio SETI approach which uses radio telescopes
to listen for narrow-bandwidth radio signals from space. The signals are not known to occur
naturrally, so a detection would provide evidence of extraterrestrial technology. In contrast
to radio SETI projects in the past that used special-purpose supercomputers located at the
telescope to perform data analysis, the project uses a virtual supercomputer composed of a
large 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 enough
to capture a significant sign of intelligence. It was reported that, compared to other radio
SETI projects, SETI@home covers a narrower frequency range but does a more thorough
search in that range.
The computational strategy of SETI@home can be described as follows. At the cen-
tral server complex, the radio signal data is divided into work units of the same sizes. These
work units are distributed by a multithreaded data/result server to a client program running
on the participants’ computers via the Internet using a HTTP-based protocol. The reason
for a HTTP-based protocol is to facilitate the clients whose Internet connections are behind
firewalls. The client program, downloadable from SETI@home web site, computes a result,
which is a set of candidate signals, returns it to the server for post-processing, and gets an-
other work unit. All clients work on their own without any communication among them and
need Internet connections only while downloading the source data from the server or vice
versa. The client program can be configured to compute only when the host is idle or to com-
pute constantly at a low priority. The program periodically writes its state to a disk file and
reads the file on startup so that progress is made even if the host is frequently turned off. The
project 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 a
canonical result for a particular work unit, results from faulty processors and from malicious
users can be identified and discarded. A relational database management system is employed
to manage information about source data, work units, results, users, and other aspect of the
project.
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 had
grown to over 3.8 millions by July 2002. Between July 2001 and July 2002 SETI@home
participants processed 221 million work units in 12 months and the average throughput was
27.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 term grid was intro-
duced in the 1990s to denote a proposed distributed computing infrastructure for advanced
science 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 and
high-performance mechanisms for discovering and negotiating access to remote comput-
ing resources (Foster, 2002a). Through resource sharing among geographically distributed
groups, it is possible for scientific communities to collaborate on a very large scale. Foster
(2002b) gave a definition of the grid as a hardware and software infrastructure that provides
dependable, consistent, pervasive, and inexpensive access to high-end computational capa-
bilities. In Foster et al. (2001), the definition was refined to address social and policy issues.
It was stated that grid computing is concerned with the coordinated resource sharing and
problem solving in dynamic, multi-institutional virtual organizations and that the sharing is
not primarily in file exchange but rather is the direct access to computers, software, data,
and other resources, as required by a range of collaborative problem-solving and resource-
brokering strategies.
Many distributed computing technologies have emerged over the past decade as a
result of the prosperity of the Internet. Currently these technologies are of great interests
to 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 an
identification checklist and explained that a grid computing technology must possess the
following properties:

1. Coordination of resources that are not subjected to centralized control: A grid must
integrate and coordinate resources and users that live in different control domains, e.g.
different administrative units of the same company, different companies, or different
countries.

2. Uses of standard, open, general-purpose protocols and interfaces: A grid must be built
from multi-purpose protocols and interfaces that address fundamental issues such as
authentication, authorization, resource discovery and resource access. It is important
that these protocols and interfaces be standard and open to prevent application-specific
systems.

3. Delivery of nontrivial qualities of service: A grid must allow its constituent resources
to be used in a coordinated fashion to deliver various qualities of service, relating
for example to response time, throughput, availability, and security, including co-
allocation of multiple resource types to meet complex user demands and result in the
synergy of the combined system.

A list of major projects in grid computing can be found in Foster (2003a) and Foster
(2003b). Two large-scale grid deployments that are worth-mentioning and are being under-
taken within the scientific community are NASA’s Information Power Grid (IPG, 2003) and
the TeraGrid (Catlett, 2002). The Information Power Grid is a project funded by the Com-
puting, Information, and Communications Technology (CICT) program at NASA Ames Re-
search Center to link the resources between NASA Ames Research Center, NASA Glenn
Research 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 project
being constructed to link major academic sites in the U.S. which include California Institute
of Technology (Caltech) for data collection analysis facilities, Argonne National Labora-
tory (ANL) for visualization facilities, San Diego Supercomputing Center (SDSC) for data
storage facilities, National Center for Supercomputing Applications (NCSA) and Pittsburg
Supercomputing Center (PSC) for computational facilities. The work described in Barnard
et al. (1999) is an example of computational fluid dynamics (CFD) experiments performed
on 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-complex
three-dimensional body shown in Figures 3.5 and 3.6. Problems of this nature challenge the
capabilities of the most advanced single-processor platforms available. Large-scale multi-
processor computer systems offer a powerful tool to solve large and complex problems; but
they 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 Globus
Toolkit has now become the de facto standard for grid computing (Globus, 2003a). Spon-
sored by the U.S. Department of Defense, Department of Energy, National Science Foun-
dation, NASA, IBM, Microsoft and Cisco Systems Corporation (Globus, 2003b; Ungaro,
2003), the project has been announced for support by at least 12 companies. The grid com-

19

munity has also formed their own organization called the Global Grid Forum. Currently
with more than 5,000 members world-wide, the Global Grid Forum is a signiﬁcant body for
setting standards and development in the ﬁeld (GGF, 2003).

20

CHAPTER 4
WEB SERVICES

4.1 The Web Services Architecture
Web Services (W3C, 2003d) is a new distributed computing architecture that uses the
Internet as the medium for communication. The fundamental concept of Web Services is to
build 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 computing
technologies in the use of platform-independent standards such as the Hypertext Transfer
Protocol (HTTP) (Fielding et al., 1999) and the eXtensible Markup Language (XML) (Bray
et al., 2000; Fallside, 2001; Thompson et al., 2001; Biron and Malhotra, 2001) which allow
service providers to completely hide the implementation details from the clients. The clients
need to know the Unified Resource Locator (URL) (Berners-Lee et al., 1994) of the service
and the data types used for the method1 calls but does not need to know how the service is
implemented in order to make use of it (Basha et al., 2002). The architecture of Web Services
as described in (Basha et al., 2002) is presented as follows. Web Services architecture make
extensive use of the XML language. The readers are referred to standard textbooks on XML
such as Harold (2001) for detailed information.
A typical model of Web Services architecture is illustrated in Figure 4.1. Three
roles, namely, service provider, service consumer and service registry, and three operations,
namely, publishing, finding and binding, are involved in the Web Services model. Descrip-
tions of the roles are as follows:

Service Provider – A service provider is an entity that creates the Web Service. Typically,
the service provider exposes certain functionality in their organization as a Web Ser-
vice for any organization to invoke. To reach full potential of a Web Service, the
service provider needs to do two tasks. First, it needs to describe the Web Service
in a standard format understandable by all organizations that will be using that Web
Service. Next, it needs to publish the details about its Web Service in a central registry
that is publicly available to everyone.

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

Service Registry – A service registry is a central location where the service provider can
list its Web Services, and where a service consumer can search for Web Services.
Service providers usually publish their Web Service capabilities in the service registry
for service consumers to find and then bind to their Web Service. Information such as
organization details, the Web Services that it provides, and the brief details about each
Web Service including technical details is typically stored in the service registry.

As mentioned above, three operations fundamental to Web Services architecture are
“finding”, “binding”, and “publishing”. The architecture aims to achieve inter-application
1A subroutine in object-oriented programming paradigm

21

Find Service Registry Publish

Service Bind Service Provider
Consumer
Web Service
Description

Figure 4.1: Conceptual Web Services Model (Basha et al., 2002)

communication irrespective of the programming language the application is written in, the
platform the application is running on, etc. To make this happen, the standards for each
of these three operations and a standard way for a service provider to describe their Web
Service irrespective of the programming languge used are needed. These standards are listed
as follows:

• A standard way to describe Web Services – The Web Service Description Language
(WSDL) (W3C, 2001) is a standard that uses XML format to describe Web Services.
The WSDL document for a Web Service defines the methods that are present in the
Web Service, the input/output parameters for each of the methods, the data types, the
network transport protocol used and URL of the end point at which the Web Service
will be hosted.

• A standard protocol to publish or find Web Services – The Universal Description,
Discovery, and Integration (UDDI) standard (OASIS, 2002) provides a way for service
providers to publish details about their organization and the Web Services that they
provide to a central registry. It also provides a standard for service consumers to find
service providers and details about their Web Services. Publication of the details is the
“description” part of the UDDI and finding of such details is the “discovery” part of it.
• A standard protocol for applications to bind to Web Services – The Simple Object
Access Protocol (SOAP) (W3C, 2000) is a lightweight2 XML mechanism used to
exchange information between applications regardless of the operating systems, pro-
gramming languages, or object models employed in developments of the applications.

The roles of SOAP, WSDL and UDDI within the context of Web Services architec-
ture is presented in Figure 4.2. Each of the layered blocks in the figure builds upon the block
beneath it. The labels shown on the left identify the concepts in the architecture and those
on the right identify actual technologies being used in the implementations. The Transport
Network layer is responsible for making Web Services accessible by using any of the trans-
port protocols available such as the Hypertext Transfer Protocol (HTTP) and the Simple Mail
2 with small amount of overhead instructions

22

Service Publication/Discovery UDDI

Service Description WSDL

XML Messaging SOAP

HTTP, SMTP, FTP or HTTPS
Transport Network
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 message
format that is used for application communication, with SOAP as the standard commonly
used by Web Services. The Service Description layer provides a mechanism for a service
provider to describe the functionality that a Web Service provides. The Service Publication
TM
and Discovery layer acts like a Yellow Pages where service providers publish the links to
their WSDL documents describing the Web Services they provide and the instructions to
TM
make use of them. Service consumers, on the contrary, use these Yellow Pages to search
for Web Services suitable for their needs and make use of them according to the instructions
given by service providers.

4.2 Applications of Web Services in Scientific Computing
Web Services has been involved in many area of scientific computing ranging from
computational infrastructure developments (Chiu et al., 2002; van Engelen, 2003) to finite
element analysis a coupled fluid, thermal, and mechanical fracture problem (Chew et al.,
2003). Chiu et al. (2002) investigated the limitations of SOAP for high-performance scien-
tific computing and presented an improved implementation of the SOAP specification more
suitable to applications in this area. van Engelen (2003) investigated the usability, interoper-
ability, and performance issues of SOAP/XML-based Web Services for scientific computing
and addressed key issues important for deployment of high-performance and mission-critical
services. 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 through
defining optimized XML data representations and by applying message chunking, compres-
sion, routing, and streaming techniques in the communication between services. In Chew
et al. (2003), crack propagation of a rocket engine segment subjected to high Reynolds num-
ber, chemically reacting gas flow was studied. One of the most significant efforts in this area
is the standardization attempt by the Global Grid Forum to create the Open Grid Service
Architecture specification (OGSA) (Foster and Gannon, 2003), which is the global standard
for interoperations among the grid community. According to Foster and Gannon (2003),

23

SOAP and WSDL, two important components of Web Services, are adopted in this standard.
Since there are already a significant number of scientific computing projects that rely on
grid computing infrastructures, with NASA’s Information Power Grid and the TeraGrid as
key projects in the area, imposition of such a standard implies a significant increase in the
number of scientific computing applications that rely on Web Services technology.

24

CHAPTER 5
THE SEMANTIC WEB

5.1 General
The World Wide Web has turned into a hyper-library where accesses to the very large
collection of information are ubiquitous, in both academic and non-academic worlds. The
success of the Web may be reflected by the ever-increasing electronic versions of documents
such as books, magazines, and journals. Since its invention in 1992 (Berners-Lee et al.,
1992), HyperText Markup Language (HTML) (W3C, 1999a) has been the standard for pub-
lication of documents on the Web. HTML is a collection of tags that are used to specify
how a document is to be displayed on web browsers. Examples of HTML tags are those
presented 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 of
rows and columns, respectively. One drawback of using HTML as the sole representation of
documents is that, from the point of view of computers, no semantics1 can be extracted from
such 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 provide
much information other than a stream of characters with extra specifications on how they are
to be rendered on web browsers. The HTML code in Figure 5.1 would be rendered as a table
of mechanical properties for steel, aluminum, and copper as shown in Figure 5.2. Humans
would have no trouble understanding that the modulus of elasticity of steel, aluminum, and
copper, 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 specific
properties 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 specify
how information from a particular HTML code of a particular web site can be extracted and
used. In the example in Figure 5.1, to extract the modulus of elasticity of aluminum from the
table, the computer may be programmed to use a pattern matching technique to

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

The example above is for the case that involves only one document on the Web. In
the real world, searching for information on the Web often involves multiple documents and
data sources. This means that, in a non-automated way, humans would have to read and
examine 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 if
they involve ten to twenty documents from restricted searches on web sites and are next
to impossible on unrestricted searches over the Internet, where a search for “mechanical
TM
properties” on Google returns hundreds thousands of web pages, with a potential that the
HTML code of each one is constantly being changed due to the decentralized architecture of
the Web.
The Semantic Web (Berners-Lee et al., 2001), a vision for the next generation of the
World Wide Web, is the Web in which information presented are useful not only for humans
1 the relationship between words or symbols and their intended meanings (Microsoft, 1997)

25

<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:RDF
xmlns: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 targeted
at computers and by adding documents solely for computers, we would be able to transform
the Web into the Semantic Web where computers find the meaning of semantic data on a
web page by following hyperlinks to definitions of key terms and rules for reasoning about
them logically. Computers will be able to understand pieces of information on web pages
rather than merely presenting them to users, and will be able to manipulate such information
on their own. Explicit representation of the semantics underlying data, programs, pages, and
other web resources, will enable a knowledge-based web that provides a qualitatively new
level of service. Automated services will improve in their capacity to assist us in achieving
our goals by understanding more of the content on the Web and thus provide more accurate
filtering, categorization, and search of information sources (Ding et al., 2002). Eventually,
computers could then be able to help us make better use the enormous information scattered
on the Internet in a more efficient and less tedious way.
According to (Berners-Lee et al., 2001), for the Semantic Web to function, computers
must have access to structured collections of information and sets of inference rules that they
can use to conduct automated reasoning. In artificial intelligence, such collections are called
knowledge representation systems. Enabling such systems on the Web involves syntactic and
semantic descriptions of data.
Syntactic description is achieved by making use of the eXtensible Markup Langauge
(XML) which allows users to add arbitrary structure to their documents by using tags, the
hidden labels such as <youngs modulus> or <yield stress> that annotate web pages or
sections of text on a page. Computer programs can make use of these tags in many ways but
programmers would also have to know in advance the intended meaning of each tag, which
is created, adopted, or used by document writers, as XML does not say anything about these
meanings.
Semantic description, the meaning description of an XML tag, is expressed by on-
tology representation languages such as the Resource Description Framework (RDF) (W3C,
1999c) and DAML+OIL (DAML, 2001). Ontologies are encoded in sets of triples in a gram-
matical form like the subject, verb and object of an elementary sentence. The triples can be
written using XML tags. For example, in RDF, a document makes assertions that a particular
thing (such as a person) has properties (such as “is the author of”) with certain values (such
as a Web page). An example of RDF descriptions using XML tags is shown in Figure 5.3.
In the following sections, RDF and DAML+OIL ontology representation languages
as well as the mechanisms to make inferences on ontologies will be presented.

27

5.2 Resource Description Framework (RDF)
5.2.1 Introduction
The Resource Description Framework (RDF) is an XML application2 for representing
information 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 Web
page, but, by generalizing the concept of a Web resource, RDF can also be used to represent
information about things that can be identified on the Web, even if they cannot be directly
retrieved on the Web. Intended for situations in which information needs to be processed by
applications rather than being displayed to people, RDF provides a common framework for
expressing the information such that it can be exchanged without loss of meaning. In the
following, 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 have
values, and that resources can be described by making statements that specify those prop-
erties and values. For a particular statement, the part that identifies the thing the statement
is about is called the subject. The part that identifies the property of charateristic of the
subject that the statement specifies is called the predicate. The part that identifies the value
of that property is called the object. RDF statements may be represented in both graphical
and non-graphical ways. Figure 5.3 presented earlier is an RDF statement about the au-
thor of a Web site encoded in RDF/XML, which is the XML version of RDF representation
and is the machine-processable way to represent an RDF statement. The English statement
corresponding to the figure is “http://www.computings.org has a Creator whose value
is Glenn Smith.” The subject for this statement is http://www.computings.org. The
predicate is Creator and the object is Glenn Smith.

5.2.3 Identification of Resources
RDF uses Uniform Resource Identifiers (URIs) (Berners-Lee et al., 1998), the gen-
eralization of the Uniform Resource Locators (URLs) (Berners-Lee et al., 1994) commonly
used on web browsers, as the basis of its mechanism to uniquely identify subjects, predi-
cates, and objects in statements. To be precise, RDF uses URI references (URIref), which
is a URI with an optional fragment identifier separated by the symbol #. For example, the
URI reference http://www.computings.org/peoples.html#85740 consists of the URI
http://www.computings.org/peoples.html, which is a web page that contains informa-
tion about many people, and the fragment identifier 85740, which specifically identifies the
information about people whose identification number is 85740. RDF defines a resource as
anything that is identifiable by a URI reference. According to the specification (Berners-Lee
et al., 1998) URIs and URIrefs can be used to identify things that can be accessed online
as well as the ones that cannot. Thus, using URIrefs allows RDF to describe practically
anything, 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 in
a graph. An RDF statement is represented by (1) a node for the subject, (2) a node for the
2
A markup language defined by XML. XML is a meta-markup language or the language that is used to
define markup languages (Harold, 2001).

28

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

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

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

Figure 5.4: A Simple RDF Statement (adapted from W3C, 2003b)

object, and (3) an arc for the predicate, directed from the subject node to the object node.
Groups of statements are represented by corresponding groups of nodes and arcs.
Figure 5.4 shows an example of a simple RDF statement. Figure 5.5 shows a group
of RDF statements that modify the statement in Figure 5.4 with the following statements:

http://www.computings.org/index.html has a creation-date whose value
is August 16, 1999.
http://www.computings.org/index.html has a language whose value is
English.
The name of the staff specified by http://www.computings.org/staffid/
85740 is Glenn Smith. He is 27 years old.

Objects in RDF statements may be either URIrefs or literals, which are constant val-
ues of character strings to represent property values. Literals may not be used as subjects or
predicates in RDF statements. In RDF graphs, nodes that are URIrefs are shown as ellipses
whereas nodes that are literals are shown as boxes.
URIrefs are used in Figures 5.4 and 5.5 to explicitly specify, for example, that the
predicate creator is to be strictly interpreted by the definition in http://purl.org/dc/
elements/1.1/creator, and the object is strictly the staff of Computings.org whose iden-
tification number is 85740. Using URIrefs as subjects, predicates, and objects in RDF state-
ments supports the development and use of a shared vocabulary on the Web, since people
can discover and begin using vocabularies already used by others to describe things, thus
reflecting a shared understanding of concepts.

5.2.5 Defining RDF Vocabularies
RDF provides a way to express statements about resources using named properties
and values. However, it lacks the capability to define terms or vocabularies to describe
specific classes of resources nor the properties to be used specifically on them. Such classes
and properties can be described as an RDF vocabulary by using RDF Schema (RDFS) (W3C,
2003c). RDF Schema provides the facilities needed to describe classes and properties, and
to indicate which classes and properties are expected to be used together. It provides a type
system for RDF, which is similar in some aspects to the type systems in object-oriented
programming languages. RDF Schema allows resources to be defined as instances of one or
more classes and allows classes to be organized in a hierarchical fashion.

29

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

http://purl.org/dc/elements/1.1/creator
http://www.computings.org/terms/creation-date

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

August 16, 1999 http://www.computings.org/staffid/85740

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

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

Glenn Smith
27

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

Classes
RDF Schema uses classes to refer to the kinds of things to be described. A class in
RDF Schema corresponds to the generic concept of a type or category, or a class in object-
oriented programming languages. RDF classes can be used to represent any category of
things, ranging from people, Web pages, document types, to abstract concepts. Classes
are described by using the RDF Schema resources rdfs:Class and rdfs:Resource, and the
properties rdf:type and rdfs:subClassOf. The resources that belong to a class are called the
instances to that class. As an illustration, a hierarchy of classes in RDF Schema in graph
notation 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 also
shown in Figure 5.8.
Properties
RDF Schema uses the RDF class rdf:Property, and the RDF Schema properties rdfs:-
domain, rdfs:range, and rdfs:subPropertyOf to specifically describe properties that character-
ize classes of things. All properties in RDF are described as instances of class rdf:Property.
RDF Schema also provides vocabulary for describing how properties and classes are in-
tended to be used together in RDF data, with the RDF Schema properties rdfs:range and
rdfs: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 are
instances of a specified class or given by a specific type of literals. The rdfs:domain prop-
erty is used to indicate that a particular property applies to a specified class. Data types
of literals specified in rdfs:range are defined externally to RDF and RDF Schema. Data
types may be defined by XML Schema data typing mechanisms (Biron and Malhotra, 2001)
and are referred to in RDF statements by their URIrefs. Statements with rdfs:range serve
to document the existence of data types and to indicate explicitly that they are to be used
in the schemas. Similar to classes, RDF Schema also provides a way to make specializa-
tion on properties. The specialization relationship between two properties is described by

30

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

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


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

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

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

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

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


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

Figure 5.6: A Vehicle Class Hierarchy (adapted from W3C, 2003b)

the rdfs:subPropertyOf. As an illustration, definition of properties that corresponds to the
classes defined in Figures 5.6 and 5.7 as well as an instance of a class that makes use of such
properties are presented in Figures 5.9 and 5.10, respectively.

5.3 DAML+OIL
RDF was developed at about the same as XML by the World Wide Web Consortium
(W3C), which is the organization that controls standards on the Internet. RDF was used
to complement XML as a language for modeling semi-structured metadata and enabling
knowledge-management applications (Ouellet and Ogbuji, 2002), and was adopted as an en-
abling technology for the Semantic Web when it was first introduced (Berners-Lee et al.,
2001). However, as researches on the Semantic Web went on, it was found that RDF and
its RDF Schema extension could be used as the bases for development of ontologies, but
they alone do not provide enough facilities such that practical artificial intelligent systems
may be implemented. In particular, RDF Schema can be used as the basic tool to define vo-
cabulary, structure and constraints for expressing metadata about Web resources. However,
its expressivity is not sufficient for complete ontological modeling and reasoning (Broekstra
et 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 Defense
Advanced Research Projects Agency (DARPA) Agent Markup Language Program (DAML,
2003) and the Ontology Inference Layer (OIL) Project (Broekstra et al., 2002) to provide a
language for expressing “far more sophisticated classifications and properties of resources”
than RDFS (Ouellet and Ogbuji, 2002). A comparison between the features provided by
RDF 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/rdf-schema#Class"/>

<rdf:Description rdf:ID="PassengerVehicle">
<rdfs:subClassOf rdf:resource="#MotorVehicle"/>

<rdf:Description rdf:ID="Truck">

<rdf:Description rdf:ID="Van">

<rdf:Description rdf:ID="MiniVan">
<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)

<rdf:RDF
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 Deﬁned in Figures 5.6 and 5.7 (W3C, 2003b)

32

<rdf:RDF
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: Deﬁnition of Properties Corresponding to Classes in Figures 5.6 and 5.7
(adapted from W3C, 2003b)

33

<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 Yes
Cardinality Constraints Yes
Class Expressions Yes
Data Types Yes Yes
Defined Classes Yes
Enumerations Yes
Equivalence Yes
Extensibility Yes Yes
Formal Semanticsb Yes Yes
Inheritance Yes Yes
Inference Yes
Local Restrictions Yes
Qualified Constraints Yes
Reification Yes Yes
a RDF and RDF Schema
b Formal semantics is the study of language meaning using
mathematical and logical formalisms (ILLC, 2003). Formalism is
the mathematical or logical structure of a scientific argument as
distinguished from its subject matter (Collins, 2000).

34

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 provides
is presented as follows:

Cardinality Constraints and Qualified Constraints DAML+OIL provides the constructs
daml:cardinality, daml:minCardinality,
and daml:maxCardinality,
which allow one to specify the number of occurences of properties in a certain class.
It also provides the data type daml:UniqueProperty which allows one to specify that a
property be unique, meaning that there can only be one value of the property for each
instance (Ouellet and Ogbuji, 2002). DAML+OIL also provides the constructs that
allow qualified restrictions such as “at most 3 of the children of X are of type Doctor”
by using the
daml:hasClassQ, daml:cardinalityQ,
daml:minCardinalityQ, and daml:maxCardinalityQ
constructs.
Class Expressions DAML+OIL provides the constructs
daml:unionOf, daml:disjointUnionOf,
daml:intersectionOf, and daml:complementOf,
which allow one to express the relationship between classes. For example, given a
group of classes A and B, it is possible to state that class C is the
daml:disjointUnionOf A and B.
As a result, if both A and B are defined as the subsets of C, it is asserted that neither A
nor B has any properties in common.
Defined Class DAML+OIL allows new classes to be defined based on property values or
other restrictions of an existing class or class expressions. For example, a class Child
can be defined based on the properties of the class Person with a restriction that age
< 18.
Enumeration DAML+OIL provides built-in support for enumerations (Ouellet and Ogbuji,
2002). An enumeration defines a class by giving an explicit list of its member. It
restricts the value space of a property to a certain set of values. For example, the
gender of a person can only be either Male or Female. In DAML+OIL, enumeration
of property types is possible with the daml:oneOf construct (Gil and Ratnakar, 2002).
Equivalence To support reasoning across ontologies and knowledge bases, DAML+OIL
allows definition of necessary and suffient conditions for class membership. The con-
ditions specify a class definition that can be used to recognize whether an instance
belongs to a class, or to classify whether a class is a subclass of another class (Gil and
Ratnakar, 2002). In DAML+OIL, equivalence of classes and instances is expressed by
the daml:equivalentTo and daml:sameClassAs constructs.
Inference In addition to equivalence, DAML+OIL also provides constructs to provide ad-
ditional information for reasoning engines such as
daml:TransitiveProperty, daml:inverseOf,
and daml:UnambigousProperty.

35

<daml:Class rdf:ID="A">
<rdfs:subClassOf>
<daml:Restriction>
<daml:onProperty rdf:resource="#p"/>
5 <daml:hasValue rdf:resource="#v1"/>
</daml:Restriction>
</rdfs:subClassOf>
</daml:Class>

Figure 5.11: An Example of daml:Restriction Construct

daml:TransitiveProperty is used to specify that a property is transitive on its class hier-
archy. If p is a property of class A, B is a subclass of A, and C is a subclass of B, then
C also has the property p. daml:inverseOf allows the specifications of inverse relation-
ships between properties. For example, if A is the father of B, then B is a child of A.
Thus, when an assertion is made on a property, another assertion can be implicitly in-
ferred on the inverse. daml:UnambigousProperty allows the specification of a property
that identifies a resource.

Local Restriction RDF associates rdfs:domain and rdfs:range constraints with a property,
whereas DAML+OIL allows daml:Restriction constraints to be associated with a Class–
property pair. In DAML+OIL, by daml:Restriction classes can be a subclass of anony-
mous classes. Consider an example in Figure 5.11, by property restriction, class A is
defined as the subclass of an unidentified class whose property p has the value v1 . In
effect, class A becomes a subclass of all resources that have at least one property p
whose value value is v1 .

DAML+OIL has been widely accepted by researchers on the Semantic Web as the
language to model ontologies. In scientific computing, a suite of DAML+OIL ontologies
have been developed to describe Web Services and data in computational biology3 (Wroe
et al., 2003). A revised version of DAML+OIL is now adopted by W3C in an effort to
create Web Ontology Language (OWL) (W3C, 2003a), the standard language for ontological
representation. Currently being in its final draft revisions, OWL will be recommended by
W3C as the language to represent ontologies on the Semantic Web in the near future.

5.4 DAML-S: Semantic Markup for Web Services
DAML+OIL is the markup language that enable the creation of ontologies for any
domain and the instantiation of these ontologies in the description of specific Web sites
(DAML-S, 2003b). With such a markup language, it is possible to provide unambiguous
description of contents and resources on the Web. Among the resources, Web Services are
one of the most important resources on the Web since they not only provide information to
users, but also enable them to effect changes in the world (Ankolenkar et al., 2002) such as
the sale of a product of the control of a physical device (DAML-S, 2003b).
Based on Berners-Lee et al. (2001), with the assistance of a software agent, the Se-
mantic Web should enable users to locate, select, employ, compose, and monitor Web Ser-
vices automatically. The integration of the Semantic Web and Web Services results in a
3 a.k.a. bioinformatics

36

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 of
purposes, including discovery and search, evaluation, selection, composition, execution, and
monitoring (Grosof et al., 2003). For a software agent to make use of Web Services and
in turn offer services to its users, it needs a computer-interpretable descriptions of the ser-
vices and the means by which the services are accessed. These descriptions can be achieved
by employing a set of basic classes and properties for declaring and describing services on
Web sites. DAML+OIL provides the ontology modeling facilities to make such descriptions
possible (DAML-S, 2003b). The DAML Services (DAML-S) language is an effort by the
DAML Services Coalition (DAML-S, 2003a) to use DAML+OIL in defining such an ontol-
ogy. Description of DAML-S as given in DAML-S (2003b) is presented as follows:
In DAML-S, services can be simple or primitive, meaning that they invoke only a
single Web Service that does not reply on another Web Service and the only interaction be-
tween the user and the service is only a simple response. Services can be complex, meaning
that they are composed of multiple primitive services and often require interactions between
the user and the services so that the user can make choices and provide information condi-
tionally. DAML-S are designed to enable tasks such as:

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

2. Automatic Web Service Invocation Automatic Web Service invocation involves the
automatic execution of an identified Web Service by a computer program or an agent.
Execution of a Web Service can be thought of as a collection of function calls. DAML-
S provides a declarative, computer-interpretable Application Program Interface (API)
for executing these function calls. Upon interpreting the markup, a software agent
would be able to understand what input is necessary to the service call, what informa-
tion will be returned, and how to execute the service automatically.

3. Automatic Web Service Composition and Interoperation This task involves the
automatic selection, composition, and interoperation of Web Services to perform some
task, given a high-level description of an objective. With DAML-S, the information
necessary to select and compose services will be encoded at the service Web sites.
DAML-S provides declarative specifications of the prerequisites and consequences of
individual service use. Software agent can thus manipulate these specifications, to-
gether with a specification of the objectives of the task, to achieve the task automati-
cally.

In addition to the three tasks above, the DAML Service Coalition also envisions an-
other task called Automatic Web Service Execution Monitoring but has not yet provided it
in the current version of DAML-S4 . This task involves the provision of descriptors for the
execution of services and will be useful in the situation when services take some time to
4 DAML-S verion 0.9 (DAML-S, 2003b)

37

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 process
the request is and whether any unanticipated problems have appeared.
The upper levels of DAML-S ontology are presented in Figure 5.12. The structure
of ontology is motivated by the need to provide three essential types of knowledge about a
service, namely, 1) What the service does, 2) How the service works, and 3) How to use the
service.
The class Service provides the reference point for declaring Web Services. One in-
stance of Service will exist for each distinct published service. The class Service possesses
three properties, namely, presents, describedBy, and supports. The classes ServiceProfile,
ServiceModel, and ServiceGrounding, are the respective ranges of these properties.
The ServiceProfile tells “what the service does”. It gives the types of information
needed by an agent seeking for a service to determine whether a service meets its need.
The information is of three basic types, namely, the identification of the organization that
provides the service, the description of the function that the service computes, such as the
inputs, outputs, preconditions, and expected results, and a host of properties to describe fea-
tures of the service, such as the classification of the service, the quality rating, and other
information which includes the estimate of maximum response time and the geographic ra-
dius of a service.
The ServiceModel tells “how the service works”. It describes what happens when
the service is carried out. This description may be used in four different ways by an agent
seeking for a service: 1) to perform a more in-depth analysis whether the service meets its
need, 2) to compose service descriptions from multiple services to perform a specific task,
3) to coordinate the activities of different participant during the course of service enactment,
and 4) to monitor the execution of the service.
A ServiceGrounding specifies the details of how an agent can access a service by
specifying a communication protocol, message formats, the port5 number, as well as the
technique to encode the data to be exchanged. A grounding can be thought of as a mapping
from an abstract to a concrete specification of the service description elements required for
interacting with the service. The DAML-S concept of grounding is consistent with WSDL
concept of binding presented earlier in Section 4.1.
The upper ontology for services specifies two cardinality constraints. One is that a
Service can be described by at most one ServiceModel and another is that a ServiceModel
must be accompanied by at least one supporting ServiceGrounding. The cardinality for the
properties presents and describedBy is not specified as it may be useful for some services
to provide partial charaterization and some services to offer multiple profiles or multiple
groundings.

5.5 Inferences – Making Use of Resources and Ontologies
Figure 5.13 illustrates the layered architecture of the Semantic Web from the point
of view of the World Wide Web Consortium. According to the figure, XML tags and XML
namespaces6 are used to encode information to be published on the Web. Using XML, these
information are represented in the format
<uri ref:tagname>textual information</uri ref:tagname>,
such as
5 An entrance to or exit for a data network (AHD, 1992)
6 see definition in Figure 5.14

38

Resource provides Service

supports
presents

describedBy
ServiceProfile ServiceGrounding

What the How to access it
service does

ServiceModel

How it works

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

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

in which the URIref dc is defined by

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

The Unicode character set (Unicode, 2003), the standard for encoding multi-language text
in documents, is used to encode these information. Once stored on the Web, the information
are termed resources and are referred to and accessed by their respective URIs. Semantic
description of the XML tags are provided by the RDF Model and Syntax (RDF M&S), RDF
Schema, and ontology representation languages such as DAML+OIL, as discussed earlier.
Ontologies can be viewed as knowledge bases on the Web. They can be useful only if they
are consulted during decision processes. Thus, a key requirement for the Semantic Web
architecture overall is to be able to layer rules on top of ontologies by creating and reasoning
with rule-bases that mention vocabulary specified by ontological knowledge bases (Grosof
and Horrocks, 2003). Reasoning processes are performed by software reasoning engines
and their respective logic frameworks. Information obtained from reasoning processes are
proofs, which, once encrypted and accompanied by electronic signatures of the information
providers, are considered authentic and trustful, and hence can be used with confidence by
other users on the Semantic Web. In the next chapter, XML Declarative Description (XDD)
(Wuwongse et al., 2001), an XML-based knowledge representation capable of modeling
axioms7 and rules and as well as reasoning on XML-encoded ontologies8 will be discussed.

7
A self-evident principle or one that is accepted as true without proof as the basis for argument (AHD,
1992)
8 such as ontologies encoded in DAML+OIL language

39

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

XML Namespace
An XML namespace is a collection of tag names identified by
a URI reference (W3C, 1999b) in the form <uri ref:tagname>,
such as <rdf:Description> in Figure 5.3. <rdf:Description>
is a tag name defined in the rdf namespace whose URIref is
http://www.w3.org/1999/02/22-rdf-syntax-ns#. Uses of XML
namespaces prevent collision and ambiguity of tag names when the names
defined by many sources are used together inside an XML document.

Figure 5.14: Definition of XML Namespace

40

CHAPTER 6
XML DECLARATIVE DESCRIPTION

In this chapter, XML Declarative Description (XDD) (Wuwongse et al., 2001), an XML-
based knowledge representation founded on the Declarative Description (DD) theory (Akama,
1993), which can be used to model axioms and rules, as well as to make inferences on on-
tologies, will be discussed. First, Declarative Description (DD) theory, the logical theory on
which 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 associated
programming language, will be introduced.

6.1 Declarative Description Theory
Declarative Description (DD) theory is an axiomatic theory inspired by the concept
of conventional logic programs with an attempt to cover a wider variety of data domains.
According to Wuwongse et al. (2000), DD theory may be used as a template for developing
declarative semantics for declarative descriptions in many speciﬁc data domains. Description
of DD theory, as presented in Wuwongse et al. (2000), is given below.

6.1.1 Specialization Systems
First, the concept of specialization system is introduced.
Deﬁnition 6.1 Let A , G , and S be respectively the sets of objects, ground objects1, special-
izations, and µ be a mapping from S to partial map(A ) (i.e., the set of all partial mappings
on 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 ). The
set G is called the interpretation domain.
The conditions (1) to (3) intuitively mean that:
1. For all specializations s1 and s2 , there exists a specialization s such that the corre-
sponding partial mapping of s is the composition of the two mappings that correspond
to s1 and s2 ,
2. There exists a specialization which does not change any objects (identity specializa-
tion), and
3. Ground objects are objects.
Let Γ = A , G , S , µ be a specialization system. When µ is clear from the context,
i.e. when there is no danger of confusion, for θ ∈ S , µ(θ)(a) will be written simply as aθ. If
there exists b such that aθ = b, θ is said to be applicable to a, and a is specialized to b by θ.
For a ∈ A , let rep(a) denote the set of all ground objects which can be specialized from a:
rep(a) = {aθ | θ ∈ S , aθ ∈ G } . (6.1)
1 ground objects are objects that do not contain variables

41

6.1.2 Declarative Descriptions
A declarative description on Γ and other related concepts are defined by the follow-
ing:
Let a set K be comprised of the constraint predicates. A constraint on Γ is a formula
q(a1 , . . . , an ), where q is a constraint predicate in K and ai is an object in A . Given a ground
constraint q(g1 , . . . , gn ), gi ∈ G , its truth and falsity are assumed to be predetermined. Denote
the set of all true ground constraints by Tcon . A specialization θ is applicable to a constraint
q(a1 , . . . , an ) if θ is applicable to a1 , . . . , an . The result of q(a1 , . . ., an )θ is the constraint
q(a1 θ, . . . , an θ); and q(a1 , . . . , an ) is said to be specialized to q(a1 θ, . . . , an θ) by θ. The notion
of constraints introduced here is useful for defining restrictions on objects in A .

Definition 6.2 A clause on Γ is a formula of the form

H ← B1 , B2 , . . . , Bn (6.2)

where n ≥ 0. H is an object in A and Bi is an object in A or a constraint on Γ. H is called
the head and (B1 , B2 , . . . , Bn ) is called the body of the clause. A declarative description or
simply a description on Γ is a (possibly infinite) set of clauses on Γ.

Let C be a clause (H ← B1 , B2 , . . . , Bn ). If n = 0, C is called a unit clause. If n > 0,
C is called a non-unit clause. The head of C is denoted by head(C). The sets of all objects
and constraints in the body of C are respectively denoted by ob ject(C) and con(C). Let
body(C) = ob ject(C) ∪ con(C). A clause C is an instance of C iff 2 there is a specialization
θ ∈ S such that θ is applicable to H, B1 , B2 , . . . , Bn and C = Cθ = (Hθ ← B1 θ, B2 θ, . . ., Bn θ).
A clause C is a ground clause iff C is comprised only of ground objects and ground con-
straints.

6.1.3 Semantics of Declarative Descriptions
Let P be a declarative description on Γ. The mapping TP on the power-set 2G , which
maps a subset of G into another subset of G , is defined by:

Definition 6.3 For each X ⊂ G a ground object g is contained in TP (X ) iff there exist a
clause C ∈ P and a specialization θ ∈ S such that Cθ is a ground clause the head of which is
g and all the objects and constraints in the body of which belong respectively to X and Tcon ,
i.e.
TP (X ) = head(Cθ) | C ∈ P, θ ∈ S, Cθ is a ground clause,
(6.3)
ob ject(Cθ) ⊂ X , con(Cθ) ⊂ Tcon .

Based on TP , the meaning of P is defined as follows:

Definition 6.4 Let P be a declarative description on Γ. The meaning of P, denoted by M (P),
is defined by
∞
M (P) = [TP ]n (∅) (6.4)
n=1

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

42

6.1.4 Equivalent Transformations
Equivalent Transformation (ET) is a computational paradigm that is based on the
semantics preserving transformations (or equivalent 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 a
declarative description P2 if they have exactly the same meaning, i.e., M (P1 ) = M (P2 ).

Computations in ET paradigm are defined by means of equivalent transformation
rules (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 involve
two components: a program specification and a program. A program specification, simply
called a specification, is a pair D, Q , where D is a declarative description, called a definition
part, and Q is a set of declarative descriptions, each of which is called a query part. The
definition part D provides general knowledge about a problem domain and describes some
specific problem instances. A query part in Q specifies a question with regard to the content
of the definition part D. For each query part Q in Q , the pair D, Q is regarded as a problem
description covered by the specification D, Q , and a declarative meaning is associated
with each problem description. On the contrary, a program, is a set of procedural rewriting
rules (or ET rules), each of which defines a transformation operation on a set of declarative
descriptions. Computations are performed by successive transformations of a given query
part by application of ET rules so as to derive a simpler query part from which the answers to
the specified query are readily obtained. In other words, let P1 be the declarative description
of a given query part and M (P1 ) be its associated meaning. The paradigm applies ET rules
in order to successively transform
ET rules ET rules ET rules ET rules
P1 − − − P2 − − − P3 − − − . . . − − − Pn
− −→ − −→ − −→ − −→

while maintaining the conditions

M (P1 ) = M (P2 ) = M (P3 ) = . . . = Pn
until the description Pn , the meaning of which contains the desired statements or solutions,
is obtained (Anutariya et al., 2002).
General Form of ET Rules
The general form of an ET rule is defined as follows:

Definition 6.6 (Akama et al., 2001) The general ET rule is of the form (n ≥ 0):

rulename :
H, {Cs} → {Es1 }, Bs1 ;
→ {Es 2 }, Bs 2 ;
···
→ {Esn }, Bsn .

in which rulename is the name of a rule; H is an object called the head; Cs is a (possibly
empty) sequence of executable objects called the applicability condition part; each Es i are

43

(possibly empty) sequences of executable objects called an execution part; each pair of Esi
and Bsi are (possibly empty) sequences of objects called a body of the rule. The rulename ,
the applicability condition part, and the execution parts are optional.

Assume that we are given an object b in the body of a definite clause C. An ET rule
is applicable to the object b iff the head H matches the object b by a specialization θ, i.e.
Hθ = b, and Cs θ is true3 . When the rule is applied to a clause C at an object b, C produces
less than or equal to n clauses. Each new clause is obtained after Es i θ is executed successfully
with an answer specialization σ by replacing bσ in Cσ with Bs i θσ. The theoretical foundation
that verifies the validity and correctness of the ET transformations is presented in Akama
et al. (2001).

6.2 XML Declarative Description
XML Declarative Description (XDD) was developed by extending the format and
structure of conventional XML elements with variables, resulted in a new structure called
XML expressions, and place them in the context of DD theory. In this section, XML expres-
sions and the formulation of XDD, as given in Wuwongse et al. (2000), will be presented.

6.2.1 XML Elements and XML Expressions
Conventional XML elements are ground, i.e. they do not contain variable, and have
the forms:

1. empty element: <t a1 = v1 . . . am = vm />

2. simple element: <t a1 = v1 . . . am = vm > vm+1 </t>

3. nested element: <t a1 = v1 . . . am = vm >e1 . . . en </t>

where n, m ≥ 0, t is an element type (or tag name), ai is a distinct attribute name, vi is a string
of characters (or simply a string), and ei is an XML element.
Let ΣX be the XML expression alphabet comprised of the sets defined in Table 6.1.
XML expressions are defined by the following definition:

Definition 6.7 An XML expression on ΣX takes one of the following forms:

1. evar

2. <t a1 = v1 . . . am = vm pvar1 . . . pvark />

3. <t a1 = v1 . . . am = vm pvar1 . . . pvark > vm+1 </t>

4. <t a1 = v1 . . . am = vm pvar1 . . . pvark > e1 . . . en </t>

5. <ivar> e1 . . . en </ivar>

where evar ∈ VE , k, m, n ≥ 0, t, ai ∈ (N ∪VN ), pvari ∈ VP , vi ∈ (C∗ ∪VS ), ivar ∈ VI , and ei are
XML expressions on ΣX .
The order of the attribute-value pairs a1 = v1 . . . am = vm and the order of the P-
variables pvar1 . . . pvark are immaterial whereas the order of the expressions e1 . . . en is im-
portant. XML expressions with variables are non-ground XML expressions and those without
3 recall the shortened form of the specialization operator µ(θ)(a) ≡ aθ introduced on page 41

44

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

Symbols Set Elements Conditions Specialization Objects
C Characters ’$’ ∈ C N/A
N Namesa All names not beginning N/A
with “$N:”
VN Name variables Names beginning with Element types or attribute
(N-variables) “$N:” names in N
VS String variables Names beginning with Strings in C∗b
(S-variables) “$S:”
VP Attribute-value-pair Names beginning with Sequences of
variables (P-variables) “$P:” attribute-value pairs
VE XML-expression Names beginning with Sequences of XML
variables (E-variables) “$E:” expressions
VI Intermediate-expression Names beginning with Parts of XML expressions
variables (I-variables) “$I:”
a Names can be either element types or attribute names
b C∗ is the set of character strings.

variables are ground XML expressions or XML elements. An expression of the 2nd , 3rd , and
4th form is a t-expression, whereas that of the 5th form is an ivar-expression. A ground
t-expression is a t-element.
When n = 0, an expression <t a1 = v1 . . . am = vm pvar1 . . . pvark > </t> of the fourth
form is considered identical to the expression <t a1 = v1 . . . am = vm pvar1 . . . pvark /> of the
second form. The parts enclosed by < and >, </ and >, or < and /> are respectively start
tags, end tags and empty-element tags, and are collectively referred to as tags. ai is an
attribute name when ai ∈ N, and is an attribute-name variable when ai ∈ VN .

6.2.2 Formulation of XML Declarative Description
Variable Instantiation
A variable instantiation is defined by basic specializations, each of which has the
form (v, w) where v specifies the name of the variable to be specialized, and w specifies the
specializing value.

45

XML Specializing Generation System
Definition 6.8 Let ∆X = AX , GX , CX , µX be an XML specialization generation system, where
AX is the set of all XML expressions on ΣX , GX is the set of all ground XML expressions on
ΣX , CX is the union of the sets:
1. (VN ×VN ) ∪ (VS ×VS ) ∪ (VP ×VP ) ∪ (VE ×VE ) ∪ (VI ×VI ),
2. VP × (VN ×VS ×VP ) ∪ VE × (VE ×VE ) ,
3. (VP ∪VE ) × ε ∪ (VI × {ε}), and
4. (VN × N) ∪ (VS × Σ∗ ) ∪ (VE × AX ) ∪ VI × (VN ×VP ×VE ×VE ×VI ) ,
where {ε} denotes the null symbol. Let a ∈ AX and c ∈ CX , the basic specialization mapping
operator νX : CX → partial map(AX ) is defined in Table 6.2, and the elements of CX are call
basic specializations.

XML Specialization System
Definition 6.9 Based on ∆X , let ΓX = AX , GX , SX , µX be an XML specialization system,
∗
where SX = CX , i.e. the set of all sequences on CX . For each a ∈ AX , µX : SX → partial map(AX )
is defined by
1. µX (λ)(a) = a, where λ denotes the null sequence, and
2. µX (c · s)(a) = µX (s) νX (c)(a) , where c ∈ CX and s ∈ SX .
The mapping µX is called the specialization operator, and µX (s)(a) is defined for each a ∈ 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, which is the XML version
of the specialization systems presented in Section 6.1.1. After such a specialization system
is defined, definitions of XML clauses, XML declarative descriptions, and the semantics of
an XML declarative description are obtained by direct application of the DD theory using
Definitions 6.2, 6.3, and 6.4, respectively.

6.2.3 XML Equivalent Transformation
XML Equivalent Transformation (XET) is a declarative programming language found-
ed on XDD theory which can directly and succinctly manipulate XML data without a neces-
sity for data conversion (Anutariya et al., 2001, 2002). XET was developed by integration
of the XDD language, the ET computational paradigm, and XML syntax. It naturally uni-
fies documents, programs, data, and, with its computational and reasoning services, also
unifies document processing and transformation, program execution, and query processing,
the three functions of which are important for manipulations of information on the Semantic
Web. In the followings, description of XET as presented in Anutariya et al. (2002) will be
given.
An XET program is comprised of a set of XET rules and XML elements or documents,
which are regarded as the data of facts associated with the program. Each XET rule has a
similar structure to an ET rule given in Definition 6.6 except that every component of an
XET rule can be an arbitrary XML expression. The typical structure and syntax of an XET
program, the tags and attribute names of which are defined in the xet namespace, is presented
in Figure 6.1.

46

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

Types Basic Specializations c in CX Methods by which νX (c)(a) Applicability
is obtained from a Conditions
1. Variable Renaming c = (v, u) ∈ Replacement of all
(VN ×VN ) ∪ (VS ×VS ) ∪ (VP × occurrences of v in a by u
VP ) ∪ (VE × VE ) ∪ (VI × VI )
2. Variable Expansion
2.1 P-variable c = (v1 , (nvar, svar, v2 )) Simultaneous replacement of For every tag
∈ VP × (VN × VS × VP) all occurrences of v in a by in a
the sequence of the pair containing v,
nvar = svar and the that tag does
P-variable v . not contain
nvar as an
attribute
name
2.2 E-variable c = v1 , (v1 , v2 ) Simultaneous replacement of
∈ VE × (VE × VE ) each occurrence of v in a by
the sequence v1 v2 .
3. Variable Removal
3.1 P- or E-variable c = (v, ε) ∈ (VP ∪VE ) × {ε} Removal of each occurrence
of v in a.
3.2 I-variable c = (v, ε) ∈ VI × {ε} Removal of each occurrence
of <v> and each occurrence
of </v> in a.
4. Variable Instantiation
4.1 N-variable c = (v, b) ∈ VN × N Simultaneous replacement of For every tag
each occurrence of v in a
in a by b. containing v
as an
attribute-
name
variable, that
tag does not
contain b as
an attribute
name
4.2 S- or E-variable c = (v, b) Simultaneous replacement of
∈ (VS × Σ∗ ) ∪ (VE × AX ) each occurrence of v
in a by b
4.3 I-variable c = v, (nvar, pvar, evar1, Simultaneous replacement of
evar2 , v ) ∈ each occurrence of the
VI × (VN ×VP ×VE ×VE ×VI ) v-expression
<v>e1 . . . en </v>
in a by the nvar-expression
<nvar pvar> evar1 <v >
e1 . . . en </v > evar2
</nvar> .

47

<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_1
35 ...
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. An xet:Rule is used to specify an XET rule and is comprised of the following compo-
nents defined in xet namespace: name specifies the name of the rule. priority specifies the pri-
ority of the rule in case that many conflicting rules are to be applied simultaneously. xet:Head
contains a HeadElement, which either specifies an XML expression pattern to be matched
and transformed or defines an event to be monitored for execution of the rule. The optional
xet:Condition contains a list of CondElements, which are the applicability conditions that
must be satisfied for execution of the rule. CondElements may either be the predicates built
into XET or the ones defined by the users. Body contains zero or more BodyElements, each
of which is either an XML element to be matched with the head of the other rules in the
program, a query about XML elements in the program, or an XET built-in or user-defined
function. All variables in XET rules are prefixed with their variable-type specification, for
example, an S-variable named uri is represented by Svar-uri in XET programs.
Given an XDD description for a particular problem, a set of XET rules for imple-
mentation of such a problem can directly be derived. Therefore, an XDD description can
also be regarded as an XET program specification. Computation and execution of an XET
program follow those in the ET paradigm. A given problem is executed by successively
applying semantics-preserving transformation rules (or XET rules) to an XDD description
that 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 Semantic
Web can be modeled and manipulated under the framework of XDD. Ontologies definitions
and ontology instances, represented in languages such as RDF(S) and DAML+OIL, can be
modeled 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 XML
non-clauses in the form (H ← B1 , B2 , . . . , Bn ). Specific rules, constraints, and restrictions
on the information can also be represented and imposed by a corresponding set of XML
non-unit clauses. Declarative Description theory, the theory which underlies XDD, can be
regarded as the logical framework in Figure 5.13. Thus, XDD and the XET programming
language can be readily used to implement the Semantic Web.
An example of inferences on RDF(S) and DAML+OIL ontologies using XDD is
presented as follows: consider the DAML+OIL ontology definition of class Person in Fig-
ure 6.2. Ontology instances of the class are given in Figure 6.3. An XDD description
of the ontology axiom daml:inverseOf, used in the definition of the class, as proposed by
Suwanapong (2001), is presented in Figure 6.4. Other axiomatic descriptions of ontology
modeling constructs, such as rdfs:subPropertyOf and daml:TransitiveProperty, are also avail-
able in the proposal. In XDD, Figures 6.2 and 6.3 are regarded as XML unit clauses whereas
Figure 6.4 is regarded as a non-unit clause. These XDD descriptions can respectively be
transformed into an XET program shown in Figures 6.5 and 6.6. Once, processed by an
XET processor, additional information implied by the semantics of the XDD descriptions
can 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"/>
</daml:ObjectProperty>

10 <daml:ObjectProperty rdf:ID="hasParent">
<daml:inverseOf rdf:resource="#hasChild"/>
15

<daml:UniqueProperty rdf:ID="age">
</daml:UniqueProperty>

Figure 6.2: XDD Description Modeling the Ontology Deﬁnitions of Class Person
(Suwanapong, 2001)

<Person rdf:ID="JACK">
<age>52</age>
<hasChild rdf:resource="#JOHN"/>
</Person>
5

<Person rdf:ID="JOHN">
<age>29</age>
<hasChild rdf:resource="#JILL"/>
</Person>
10

<Person rdf:about="JILL">
<age>7</age>
</Person>

Figure 6.3: XDD Description Modeling the Ontology Instances of Class Person
(Suwanapong, 2001)

50

<$N:classB rdf:about=$S:resourceY>
$E:resourceXElmt
<$S:propertyR rdf:resource=$S:resourceX/>
5 </$N:classB>

←−

<daml:ObjectProperty rdf:ID=$S:propertyR>
10 <daml:inverseOf rdf:resource=$S:propertyP/>
$E:inversePropertyElmt
</daml:ObjectProperty>,

<$N:classA rdf:ID=$S:resourceX>
15 <$S:propertyP rdf:resource=$S:resourceY/>
$E:resourceXElmt
</$N:classA>,

<$N:classB rdf:ID=$S:resourceY>
20 $E:resourceYElmt
</$N:classB>.

Figure 6.4: XDD Description Modeling the Ontology Axiom daml:inverseOf (Suwanapong,
2001)

51

<xet:Program xmlns:xet="http://kr.cs.ait.ac.th/XET">

<xet:RuleClassOrder>1 2 3 4</xet:RuleClassOrder>

5 <xet:Fact>


<daml:Class rdf:ID="Person">
<rdfs:label>person</rdfs:label>
10 </daml:Class>
<daml:ObjectProperty rdf:ID="hasChild">
15 <daml:ObjectProperty rdf:ID="hasParent">
<daml:inverseOf rdf:resource="#hasChild"/>
20 <daml:UniqueProperty rdf:ID="age">
</daml:UniqueProperty>


25 <Person rdf:ID="JACK">
<age>52</age>
<hasChild rdf:resource="#JOHN"/>
</Person>
<Person rdf:ID="JOHN">
30 <age>29</age>
</Person>
<age>7</age>
35 </Person>
</xet:Fact>



Figure 6.5: An XET Program Corresponding to the XDD Descriptions in Figures 6.2 to 6.4
(Part 1 of 2)

52

<xet:Rule name="inverseOf" priority="4">

5 
<xet:Head>
<Nvar-classB rdf:about=Svar-resourceY>
Evar-resourceXElmt
<Svar-propertyR rdf:resource=Svar-resourceX/>
10 </Nvar-classB>
</xet:Head>


<xet:Body>
15 <daml:ObjectProperty rdf:ID=Svar-propertyR>
<daml:inverseOf rdf:resource=Svar-propertyP/>
Evar-inversePropertyElmt
</xet:Body>
20


<xet:Body>
<Nvar-classA rdf:ID=Svar-resourceX>
<Svar-propertyP rdf:resource=Svar-resourceY/>
25 Evar-resourceXElmt
</Nvar-classA>
</xet:Body>


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>
<hasParent rdf:resource="#JACK"/>
5 <Person>

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

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 is
presented in Figure 7.2.
The multi-tier system architecture is a generalization of the three-tier client/server
system architecture, an architecture of which software systems are structured into three tiers
or layers, namely, user interface, business logic or application logic, and database. Layers
may have one or more components. For example, there can be one or more user interfaces
in the top tier, each user interface may communicate with more than one application in the
middle tier at the same time, and the applications in the middle tier may use more than one
database at a time. Components in a tier may run on a computer that is physically separate
from the other tiers, communicating with the other components over a computer network
(Microsoft, 1997). They may also run on the same computer and be logically separated
into processes, communicating with the others over messaging infrastructures built into an
operating system. In the multi-tier architecture, components in a tier may also communicate
with other components of the same tier. For example, application in the middle tier may
request other applications, which are also in the middle tier, to provide computations on its
behalf.
From the system architecture point of view, the framework comprises four compo-
nents, namely, a client, an application Web Service, a knowledge base server, and an optional
database server.

Client A client, the user-interface tier in the architecture, is the component where end-users
interact with application Web Services in the framework. It is used to initiate a re-
quest for an operation to be performed by application Web Services and to present
results of the operation to the users. The client can be a web browser or other end-user
application, with or without graphical user-interfaces.

Application Web Service An application Web Service, the application-logic tier in the frame-
work, is the component that provides services to the clients or other Web Services. Ser-
vices are provided by employing computing modules, knowledge bases and databases
accessible locally, or by delegating tasks to the others. An application Web Service
is called an agent if the services provided are accomplished mainly by making use
of other Web Services. It is called a special-purpose Web Service, or simply a Web
Service, if the services provided are accomplished mainly by making use of local fa-
cilities. Application Web Services identify and make use of the others by consulting
their local services ontologies, possibly encoded in DAML-S language, or by assis-
tance of a service registry broker, which is a special-purpose Web Service that help
other Web Services advertise themselves, as well as helping each of them identify and
make use of the others. Communications between application Web Services are by
means of SOAP messages transported over HTTP protocol.

Knowledge Base Server A knowledge base server, a component of the database tier in the
architecture, is the component where ontologies, URIrefs to ontolgies, rules, and an
inference engine are stored. A knowledge base server is accessbile locally to an appli-
cation Web Service and provides reasoning supports to the Web Service.

55

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

Referred to Figure 7.1 and the paradigm discussed in Section 1.1 on pages 2–3, when
an assistance is needed during a structural design process or an assessment of structural per-
formance, a user open a web browser or a client application to connect to a structural analysis
agent, which may be recommended by a colleague or discovered from an advertisement on
TM TM
search engines such as Google or Yahoo. Four stages of operations are involved from the
moment an agent is identified by a user until the moment the agent presents the user the
requested results, namely, a data input stage, a service planning stage, a service execution
and monitoring stage, and a result presentation stage. Operations at each stage are described
as follows:

Data Input Stage Through user interfaces provided by the agent, the user supply the data
that model the real world structure being considered as well as the desired results. The
former include the shape and dimensions of the structure, the type of material of which
it is built, the boundary conditions, and the external forces to which it is subjected. The
latter are specifications such as stresses at particular points, contour plots of particular
stress components, or evaluation whether the structure can safely withstand the given
loading conditions. The user may explicitly specify directions and magnitudes of the
external forces or ask the agent to use the forces specified by a design code that governs
the area where the structure is located. He or she needs not explicitly provide all the
data and may omit some of them if they can be implied from other input data.

Service Planning Stage When the user finishes providing the input data, the agent analyzes
the user requests and consults the local knowledge base server, where process ontolo-
gies reside, to identify local computing modules that produce the results requested by
the user.
If it is found that a particular request cannot be handled locally, a service registry
broker is consulted to identify Web Services or other agents that can handle such a
request. A service registry broker may inform the agent of such Web Services and
agents by means of SOAP messages containing URIrefs to their DAML-S ontology
instances. If the service registry broker returns a list of more than one Web Services or
agents that can handle a request, the agent would consult its knowledge base server to
select the most appropriate one based on descriptions in the DAML-S ServiceProfile
such as quality rating, maximum response time, and geographic radius of the service.
After all computing modules and third-party application Web Services are identified,
the agent compares the input data provided by the user against the those required by the
computing modules and application Web Services. The format of the required input
data, as well as that of the output data, are specified in WSDL documents published
on the Internet.
Mismatched input data items are arbitrated by consulting the agent’s local knowledge
base server or by making requests for information from knowledge bases of other
agents or Web Services. For example, if the user specifies dimensions of the structure
in SI units but the computing modules of the agent are developed for Imperial units,

56

the agent would consult its knowledge base and look for ontology instances of SI units
and convert the dimensions specified by the user into the ones in Imperial units so
that they can be handled by local computing modules. Differences between keywords
recognized by agents, Web Services, and users, such as modulus of elasticity versus
Young’s modulus, are arbitrated by ontology mapping facilities available on knowledge
base servers.
General data items are also made more specific and precise by consulting the agent’s
local knowledge base server or by making requests for information from knowledge
bases of other agents or Web Services. For example, if the user requests that external
forces to be applied to the structure conform to those specified in the latest revision
of UBC Building Code and the agent’s local knowledge base does not contain such a
building code, it would consult a service registry broker and be directed to respective
Web Service of a government agency that provides loading information from UBC
Building Codes. Such information is provided by Web Service of the government
agency through queries against ontology instances on its local knowledge base server.
By consulting process ontologies stored on knowledge base servers, the agent then
create a service execution plan, which is a list of computing modules, agents, and Web
Services to be executed, sequentially or in parallel, to deliver end results requested by
the user.

Service Execution and Monitoring Stage The service execution plan created in the ser-
vice planning stage contains ServiceGrounding information extracted from DAML-S
ontology instances of respective computing modules and application Web Services.
As discussed in Section 5.4, a ServiceGrounding description specifies the details of
how services can be accessed by an agent. Such details include message formats and
URIs, the explicit specifications of communication protocol, network address, and port
number to be contacted upon service requests. Thus, in this stage, the agent prepare in-
put data suitable for particular computing modules and application Web Services, and
accordingly invoke them by the methods specified in their ServiceGrounding descrip-
tions. Preparation of input data is performed by means of adaptations and conversions
of the output from preceding service executions, with the assistance of ontologies, on-
tology instances, and ontology mapping facilities. Monitoring of services that require
substantial time for data processing is expected to be achieved by monitoring compo-
nents of DAML-S ServiceModel constructs expected to be included in the final version
of DAML-S markup language.

Result Presentation Stage In the last stage of operations, the agent presents the results to
the user in the requested formats. The results obtained from the service execution and
monitoring stage are in XML format that conforms to an XML schema provided and
adopted by the agent. If the user-interface client is an end-user application, the results
in XML format are directly downloaded to the application, and are further formatted
and displayed to the user by computing modules and application logics embedded in
the client. If the user-interface client is a web browser, the agent renders the results
into HTML format and present them on the client web browser. The HTML code
presenting the results may also contain URIrefs to graphical plots, pictures, or video
clips which are generated in the previous stage by visualization Web Services using
raw data obtained from the results themselves.

57

7.2 An Overview of the Research Tasks
The tasks indentified from the objectives described in Chapter 1 and the framework
discussed previously are listed as follows:

1. Infrastructure Design and Development

(a) Construction of domain ontologies related to computational mechanics so that
knowledges relevant to general operations of the framework components are cap-
tured,
(b) Construction of ontology mapping facilities to be utilized by local knowledge
base servers of application Web Services,
(c) Construction of service enactment facilities to enable semantic service advertise-
ment, discovery, composition, execution, and monitoring among application Web
Services.

2. Application Web Services Development
For each application Web Service,

(a) Design of XML Schemas for input, intermediate, and output data, as well as
definition of DAML+OIL ontologies to describe the meaning of data items,
(b) Construction DAML-S ontology instances to support and control operations of
the application Web Service,
(c) Implementation and deployment of application Web Services using particular
tools and programming languages.

3. Illustrative Applications of the Framework

(a) Application of the application Web Services to solve illustrative problems in lin-
ear elasticity and elastoplasticity.

A preliminary schedule for the proposed research tasks and the estimates of expen-
ditures are respectively presented in Figure 7.17 and Table 7.6. Detailed description of each
task is presented in the following sections.

7.3 Infrastructure Design and Development
As discussed in Chapter 1, the XML Declarative Description (XDD) framework and
its XML Equivalent Transformation (XET) inference engine, the two of which are presented
in Chapter 6, will be employed to implement the proposed framework. Thus, contruction of
the infrastructure components will be such that they fit into the framework of XDD.

7.3.1 Construction of Domain Ontologies
Construction of domain ontologies involve the capture of basic knowledges related
to 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 as
axioms, will be designed and constructed. Examples of ontologies related to key operations
in computational mechanics are listed in Tables 7.1 and 7.2. Those of the axioms are listed
in Table 7.3. First, the definition of each entity and relationships among them will be inves-
tigated. Statements that define entities and relationships will be produced using RDF(S) and

58

DAML+OIL constructs. Next, class diagrams similar to the one in Figure 5.6 will be created
to 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+OIL
domain ontologies are regarded as ground XML expressions (or facts). Axioms such as the
ones 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 in
knowledge base servers to support the operations of application Web Services.

7.3.2 Construction of Ontology Mapping Facilities
A preliminary example of domain ontology described previously is presented in Fig-
ure 7.3. Specifically, the figure contains an ontology of terms related to engineering mate-
rials, which include Material, MaterialProperty, MathQuantity, PhysicalQuantity, UnitOfMea-
surement, Stress, Strain, and related subclasses and superclasses. To illustrate the situation
in which ontology mapping is needed, consider the case when structural analysis agents A
and B in Figure 7.1 are collaborating on a task requested by an end-user. Agent B adopts a
material-related ontology shown as solid lines in Figure 7.3 whereas Agent A adopts an on-
tology developed by someone else. Upon consulting process ontologies on the local knowl-
edge base, Agent B finds that a tensile modulus of elasticity is required to perform the re-
quested task. By consulting its local knowledge base, Agent A also knows in advance that
a Young’s modulus is required for the requested task. Therefore, together with the analysis
request, 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 “tensile
modulus 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 by
the 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 a
URIref to the Internet location where the term “Young’s modulus” is defined. In other words,
Agent A needs to supply Agent B a URIref that points to the ontology adopted by itself. Upon
arrival of the message, Agent B needs to verify, by investigating the ontology accessible at
the specified URIref, whether the term “Young’s modulus” used by Agent A and the term
“tensile modulus of elasticity” used by itself actually refer to the same concept or not.
From the ontology identified as solid lines in Figure 7.3, TensileModulusOfElas-
ticity that Agent B expects from Agent A is a subclass of ModulusOfElasticity which re-
lates TensileStress to TensileStrain by an Equation named Hooke’s Law specified at http:
//def.physics.org/hookes. According to the ontology adopted by Agent A, TensileMod-
ulusOfElasticity hasUnit of GPa (109 N/m2 ), which is a subclass of the forcePerUnitArea unit,
a subclass of the DerivedUnit rooted from UnitOfMeasurement.
Upon investigating at the URIref specified by Agent A, Agent B discovers that Youngs-
Modulus used by Agent A is a PhysicalQuantity that relates TensileStress to TensileStrain
by the Equation named Hooke’s Law specified at http://def.physics.org/hookes and
hasUnit of ksi (kips per square inch), which is a subclass of the forcePerUnitArea unit, a
subclass of the DerivedUnit rooted from UnitOfMeasurement.
Since TensileModulusOfElasticity and YoungsModulus (1) are both subclasses of Phys-
icalQuantity, (2) both relate TensileStress to TensileStrain by the Equation named Hooke’s
Law specified at http://def.physics.org/hookes, and (3) are both subclasses of the for-
cePerUnitArea unit, a subclass of the DerivedUnit rooted from UnitOfMeasurement, it can be
deduced 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 Key
Operations in Computational Mechanics

Ontology Names Examples of Subclasses
1. Quantities mathematical quantities, physical
quantities
2. Mathematical quantities scalar, vector, matrix, tensor
3. Geometrical entities one-dimensional entities, two-dimensional
entities, three-dimensional entities
3.1 One-dimensional entities point
3.2 Two-dimensional entities line, triangle, rectangle, square, circle,
ellipse
3.3 Three-dimensional entities box, cube, sphere, tetrahedral, cone,
paraboloid, surfaces
4. Physical quantities base physical quantities, derived physical
quantities
4.1 Base physical quantities length, mass, time, electric current,
thermodynamic temperature, amount of
substance, luminous intensity
4.2 Derived physical quantities area, volume, velocity, acceleration, force,
pressure, stress, strain
5. System of measurements International system of measurement (SI),
Imperial system of measurement
6. Unit of measurements base units, derived units
6.1 Base units meter, inch, foot, yard, kilogram, pound,
kips, second, minute, Farenhiet, Celcius,
Kelvin
6.2 Derived units square meter, cubic feet, meter per second,
mile per hour, Newton, pound (lbf),
Pascal, psi, ksi
7. Materials metallic material, non-metallic material
8. Material characteristics isotropic, anisotropic
9. Material properties ultimate stress, ultimate strain, yield stress,
yield strain, modulus of elasticity,
Poisson’s ratio, isotropic strain hardening
parameter, kinematic strain hardening
parameter

60

Table 7.2: Examples of Conceptual Ontologies Related to Key Operations in
Computational Mechanics

Ontology Names Examples of Subclasses
1. Mathematical concepts coordinate system, Cartesian
coordinate, polar coordinate, space,
reference point, coordinate
transformation, mapping,
approximation, interpolation
2. Computational mechanics concepts discretization, element, load,
stiffness, boundary conditions,
response, displacement

Table 7.3: Examples of Axioms Related to Key Operations in Computational
Mechanics

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 proceed
on the analysis request. Agent B may also add the term YoungsModulus to its local ontology
specifying that this term specified by the URIref employed by Agent A is the sameClassAs
the term TensileModulusOfElasticity employed by itself.
Specification of ontologies adopted by the involved agents is one part of a research
area 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, accessible
at local knowledge base server or downloadable from particular URIrefs. Thus, the task of
constructing facilities for ontology mapping becomes the task of investigating and creating
an agent communication language or a mechanism that allows an agent who initiates a com-
munication to inform its recipients of the URIref that points to the ontology adopted by itself,
and the task of creating an XET program comprising of non-ground XML expressions and
additional XET rules such that deduction on DAML+OIL ontologies in the fashion discussed
earlier is possible.

7.3.3 Construction of Service Enactment Facilities
Construction of the service enactment facilities involves the design and implemen-
tation of a mechanism to support semantic advertisement, discovery, composition, execu-
tion, and monitoring of application Web Services using the constructs in DAML-S ontology
whose definitions and relations are presented in Figure 7.4. As an illustration, consider
the situation in the service planning stage when a software agent needs assistance from an
application Web Service to determine the inverse of a sparse matrix involved in its opera-
tions. Upon consulting a service registry broker for “matrix inversion services”, suppose
that four application Web Services, namely the ones by Science.net, NumMethods.org, Opti-
mize.com, and NumericalRecipe.net, are identified and the URIrefs to their DAML-S ontol-
ogy instances are reported by the service registry broker. After following the URIrefs, the
agent finds that DAML-S descriptions of those application Web Services are as presented in
Figure 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 respectively
defined 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 following
decisions:

• The agent would not choose the service by Science.net because

1. it takes general matrices as the input which means that it is not optimized for
sparse matrices, and
2. direct matrix inversion method generally gives exact solutions at the expense of
longer computation time, which, in this case, is not necessary since the results
will be governed by numerical procedures being employed by the agent.

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

• The agent prefers the service by NumMethods.org to the one by NumericalRecipe.net
because, although both offer services optimized for sparse matrices, 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 A
NumMethods.org Iterative method Sparse matrix A
Optimize.com Iterative method Dense matrix A
NumericalRecipe.net Iterative method Sparse matrix B

NumMethods.org is more reliable because it receives higher quality rating from Comp-
MechRating, which is a service rating agency recognized by the agent.

From the decisions presented, the agent thus chooses to request for the inverse of
its matrix from the application Web Service by NumMethods.org. To make use of the ap-
plication Web Service, the agent would follow the ServiceGrounding description of the ser-
vice. Specifically, in Figure 7.8, the agent would investigate the NumMethOrgMatInvWOR,
which is the service grounding description that maps the conceptual matrix inversion pro-
cess of NumMethods.org to its corresponding getInverse operation defined in WSDL doc-
ument http://nummethods.org/matInv.wsdl, the content of which is presented in Fig-
ures 7.11 and 7.12. By inspecting the getInverse operation in the WSDL document, the agent
would be informed accordingly that it can request for a matrix inverse operation by sending a
SOAP message to http://ws.nummethods.org:8080/axis/services/MatrixWS using
the message defined between lines 29–34 of Figure 7.11.
Composition of application Web Services may be performed in a similar manner by
successively repeating the above procedure in the service planning stage. Monitoring of
service executions during the service execution and monitoring stage may be performed by
application Web Services assigning to the agents, for a particular request, a unique URL to
which they can send SOAP request messages and receive informative SOAP messages about
the status of the request, as well as a URIref to the DAML+OIL ontology that describes such
a status. Construction of the service enactment facilities is thus to devise a series of non-
ground XML expressions and XET rules that is capable of delivering the presented reasoning
functionalities.

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. A
preliminary list of application Web Services to be developed and the types of services that
they provide, which correspond to the service profile hierarchy in Figure 7.5, are presented
in Table 7.5, with a tentative schedule for the development of each presented in Figure 7.17.
An application Web Services can be regarded as a subroutine in the procedural pro-
gramming paradigm, driven and supported by knowledge bases comprised of ontologies and
rules. 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 detailed
implementaion in programming languages, are necessary. Being driven and supported by
knowledge bases, construction of ontologies and rules that drive 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 for ServiceRegistryBroker SOAP requests
the prototype system
AgentAWebService front-end structural StructuralAnalysisService Web browser
analysis agent interface for
end-users,
SOAP requests
AgentBFemService specializes in finite FiniteElement- SOAP requests
element methods for AnalysisService
problems in elasticity and
elastoplasticity
LSESolver specializes in solving LinearSystemOf- SOAP requests
linear systems of equations EquationsSolver

NLSESolver specializes in solving NonlinearSystemOf- SOAP requests
non-linear systems of EquationsSolver
equations
SIMeasureService provides information on SI MeasurementInfoService SOAP requests
units
USMeasureService provides information on MeasurementInfoService SOAP requests
US customary units
ASTMMaterialService provides information on MaterialInfoService SOAP requests
ASTM material standards
UBCInfoService provides information on DesignStandard- SOAP requests
the Uniform Building InfoService
Code
ACIInfoService provides information on DesignStandard- SOAP requests
the ACI building code InfoService
requirements
AISCInfoService provides information on DesignStandard- SOAP requests
the AISC design InfoService
specifications
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 output data are important to
interoperations among application Web Services and clients, as well as local operations of
the application Web Services themselves. Schemas can be regarded as structure definitions in
the C programming language, or class definitions in object-oriented programming languages,
such as C++ and Java. An application Web Service takes input data from its client, processes
it, and presents the output back to the client, which could be another application Web Service
or an end-user client, in a broader sense. It locally stores intermediate data and transforms it
so that it conforms to the input format specified by other application Web Services when it
needs any assistance from the others.
Exchanges of these data require shared understandings of each schema element among
the involved parties. In a simple case, shared understandings can be achieved when each of
the two parties adopts the same schema. In a more complex case, when each of the parties
adopts its own schema, terms and concepts in the schema need to be arbitrated and mapped
by using ontologies and rules, as discussed in Section 7.3.2.
As described in Section 7.1, application Web Services, a key component in the pro-
posed framework, will communicate via SOAP, an XML-based protocol. As such, the tasks
involved 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 provide
DAML+OIL ontological descriptions of the terms and concepts in the schema, to support
arbitration between parties adopting different set of schemas.
An example of XML Schema definition for input and output data is that between
lines 11–27 of Figure 7.11, which defines SOAPMatrix used in the SOAP input and output
messages defined between lines 29–34 of the same figure. As another example, an input data
that represents the structural model in Figure 7.13 is presented in Figures 7.14 and 7.15. The
keywords youngsModulus, poissonRatio, and density used in the figures are as defined by
the DAML+OIL material ontology presented in Figure 7.3, with youngsModulus being an
instance of YoungsModulus, poissonsRatio being an instance of PoissonsRatio, and density
being an instance of Density, respectively.

7.4.2 Construction of DAML-S Ontology Instances and WSDL Documents
DAML-S ontology instances and WSDL documents can be regarded as the blueprints
that control the operations of application Web Services and how they interact with the oth-
ers. A preliminary example of a DAML-S ontology instance that controls the operations
of AgentBFemService in Table 7.5, which is an application Web Service that specializes in
finite element methods, is presented in Figure 7.16. An example of WSDL document that
specifies the schemas of input and output data as well as how a Web Service can be accessed
is 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 subclasses
advertised on and made accessible by service registry brokers. Application Web Services
interested in other application Web Services may inspect the ParameterDescription instances
available in service profiles to determine whether the input, output, precondition, and effect
of the services match their requirements. Once a decision is made to select a particular
service, detailed descriptions, such as the schemas of input and output data, the URI to which
a SOAP request message is submitted, and the URI from which the SOAP response message

65

is received, can be further investigated from the instances of DAML-S ServiceGrounding
supported by that service.
During the operation of an application Web Service, its instances of DAML-S Ser-
viceModel, particularly those of AtomicProcess, SimpleProcess, CompositeProcess, Pro-
cessComponent, and ControlConstruct, are also used to control how process components (or
the computing modules in Figure 7.2) interact to accomplish services that it offers.
For each process defined in the service model, an application Web Service can de-
termine whether it can handle the process by itself by verifying whether a corresponding
atomic process grounding exists in its ServiceGrounding instances. If such an atomic pro-
cess grounding does not exist, the application Web Service, through the assistance of a
service registry broker, can create one that maps to the URI of a service provided by the
others. Hence this also explains how semantic composition of application Web Services is
performed.

7.4.3 Implementation and Deployment of Application Web Services
To provide a heterogeneous prototype environment, application Web Services listed
in Table 7.5 will be developed and deployed, per their respective DAML-S and WSDL
blueprints from the previous section, on various platforms and environments that support
XML SOAP messaging. These include the platforms and environments such as:

1. Java Servlets1 on PC-based servers2 running Windows XP operating system,

2. Java Servlets on PC-based servers running Linux operating system,

3. Java Servlets on parallel computer clusters running Linux operating system, and

4. Microsoft .NET3 Web Services on PC-based servers running Windows XP operating
system.

Application Web Services based on Java Servlet technology will be implemented
in the Java programming language using open-source XML SOAP messaging toolkits such
as Apache Axis (Apache, 2003) by the Apache software foundation. Those based on Mi-
crosoft .NET technology will be implemented in proprietary languages by Microsoft, such
as Visual Basic .NET or C#. Software libraries necessary for scientific computations, such as
operations on matrices and solution to linear systems of equations, will be non-commercial
ones from the public domain.

7.5 Illustrative Applications of the Framework
The prototype system, with infrastructure components developed and application
Web Services deployed, will be applied to problems in linear elasticity and elastoplasticity. It
will be applied to problems for which closed form solutions are available in the literature to
verify the validity of the framework and itself, and will be applied to general problems, with
or without closed-form solutions, as a demonstration. Accuracy of the results for problems
with closed-form solutions can be determined by comparison with closed-form solutions.
Accuracy of the ones without closed-form solutions can be determined by comparing against
the results from well-accepted finite element analysis software.
1 (see Sun, 2003)
2 typicalpersonal computers configured to perform a server role in the distributed computing paradigm
3 (see Microsoft, 2003)

66

Domain Ontology ACI Design &
Metric System of Construction
Measurement Manuals
Domain Ontology AISC Design &
US Customary
Construction
System of
Measurement Manuals
Institutions
Sensors
Scalar SI Measurement
Vectors Building Code Service Profile
Matrices Ontologies
Tensors
Operations British Building Code Quality Rating
Material Properties Ontologies
General Knowledge in
NBC Building Code JIS Material
Scientific Computing Government
Agencies
Specifications Institutions
KB
UBC Building Code ASTM Material
Specifications

FEM
Input/Output
Schemas
Analysis Process Service Registry
Boundary Ontologies
Conditions Knowledge Broker
Bases Analysis Types: Matrix Ontology
67

(KB) static, dynamic,
fracture, etc. Solution
Techniques
Analysis Rules
KB Process
etc. Ontologies

Structural Analysis
Agent “A” KB

Structural Analysis
Pictu

Agent “B”
Movie

User & Web Browser
res
s

Equation Solver
Service

Visualization
Real World Process Process
Problems Ontologies Ontologies
KB
KB

Visualization
Service Special-purpose
Service

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

Database
Components

Processing
Text-based

Query

Data
Application

DB DB DB

Local Local Local
Database Database Database
Server Server Server
Client
Query
Answer

Application Logic
Components

Web Browser

Computing

Computing

Computing
Module A

Module B

Module n
Request

...
Response

Application Application Application
Client Web Service 1 Web Service 2 Web Service n
Query

Answer

Knowledge Base
GUI-based Components
Application
Inference Engine

Ontologies

Rules
KB KB KB

Local Local Local
Client
Knowledge Base Knowledge Base Knowledge Base
Server Server Server

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

68

sc
sc
sc
sc BaseUnit
forcePerUnitArea sc sc
UnitOfMeasurement
Equation daml:Thing
ksi sc DerivedUnit
sc sc
sc sc
sc Scalar
Response
GPa sc sc
sc
UltimateStrength Quantity sc
Material Property sc Vector
sc Stress Strain ShearStrain
PoissonsRatio sc
sc sc sc sc
hasProperty sc Compressive- sc representedBy
sc MathQuantity
BrittleMaterial Strength Matrix
sc MaterialProperty sc
sc hasUnit AxialStrain
PlasticModulus sc hasUnit sc
sc hasUnit
sc
ShearStrength
PhysicalQuantity sc
DuctileMaterial sc sc sc sc sc
Density ShearStress TensileStrain
Isotropic- sc
sc PlasticModulus sc
sc sc sc
sc
TensileStrength Base-
PhysicalQuantity AxialStress CompressiveStrain
ElasticMaterial FractureToughness Kinematic- sc Derived-
PlasticModulus PhysicalQuantity
sc Length sc sc TensileStress
sc sc
sc
InelasticMaterial
Mass sc CompressiveStress
69

ModulusOfElasticity ProportionalLimit sc
sc Area sc
LinearElasticMaterial sc
hasUnit sc sc
hasUnit sc
Shear- sc
Shear- Time
ProportionalLimit Volume Pressure
ModulusOfElasticity
rdf:_2
NonlinearElasticMaterial rdf:_1
Tensile-
Tensile- ProportionalLimit
ModulusOfElasticity Legend
sca
rel : http://ont.swscm.org/
sc
sca YieldStrength terms.daml#relates
hasEquation sc : daml:subClassOf
rel
rdf:parseType
sca : daml:sameClassAs
YoungsModulus
rel
: dummy node
Foreign term HookesLaw daml:collection
mapped into
local ontology Note
http://ont.swscm.org/terms.daml#definedBy
Default namespace:
http://ont.swscm.org/
“Hooke’s Law” http://ont.swscm.org/terms.daml#hasName http://def.physics.org/hookes materials.daml#

Figure 7.3: Example of a Material Ontology

daml:toClass
rdf:type rdf:type rdf:type
rdf:type
xsd:string
Resource providedBy daml:first daml:Restriction
Service supports daml:Restriction
ServiceGrounding daml:onProperty
daml:onProperty daml:onProperty

daml:toClass daml:toClass
presents xsltTransformationString sc
daml:first daml:rest sc sc daml:onProperty
describedBy WsdlInputMessage-
sc daml:toClass
Map sc daml:List
Legend ServiceModel
ServiceProfile sc sc WsdlOutputMessage- sc daml:rest
sc : daml:subClassOf WsdlOutputMessage-
Map MapList
sca : daml:sameClassAs wsdlVersion
: dummy node WsdlMessageMap wsdlMessagePart wsdlDocument xsd:anyURI WsdlInputMessage-
wsdlOutputs
MapList
operation wsdlOutputMessage
xsd:anyURI WsdlOperationRef
xsltTransformationURI portType wsdlInputs xsd:anyURI
ProcessPowerSet
daml:subClassOf WsdlAtomicProcess-
Grounding
wsdlOperation wsdlInputMessage
WsdlGrounding
damlsParameter hasAtomicProcessGrounding damlsProcess
xsd:string
has_process
daml:subClassOf AtomicProcess-
xsd:string
xsd:string serviceName PowerSet ProcessControlModel
ParameterPowerSet
daml:Thing
daml:Thing textDescription hasControlModel
ratingName True, False
qualityRating
xsd:string daml:subClassOf TestValue hasProcess
Profile rating ProcessModel
contactInformation daml:collection
sc
QualityRating conditionValue
rdf:parseType
webURL
rdf:_2 time:Interval ProcessPowerSet
daml:subClassOf
xsd:string name physicalAddress
serviceParameter TestCondition
sc
daml:onProperty
sca
title Actor
DAndBRating ControlConstruct rdf:type
during
70

ServiceParameter rdf:_1
xsd:string timeout
phone xsd:string sc Literal
email sParameter nextProcessComponent
ratingName Dun and Bradstreet sc time:Instant daml:Restriction
serviceParameterName daml:hasValue
fax sc currentProcessComponent daml:unionOf
Rating sc
sc startTime name
sc
sc parameter
xsd:string sc sc sc endTime
xsd:string serviceCategory xsd:string sc daml:Thing
sc input
daml:collection Process
AverageResponseTime ProcessComponent composedOf output
parameter Sequence currentStatus
participant
xsd:string (input/output/
daml:disjointUnionOf
daml:Thing daml:toClass rdf:type ConditionalOutput
precondition/effect) sParameter rdf:parseType
MaxResponseTime sc
daml:List
sParameter
Split sc daml:Restriction rdf:_1 daml:Thing
ParameterDescription Duration daml:onProperty
sc
components sc
Duration precondition
AtomicProcess
parameterName sc
refersTo ServiceCategory ProcessComponent- sc daml:item effect
Condition
Split-Join List rdf:_2 rdf:_1
code GeographicRadius realizes realizedBy
xsd:string components daml:collection
sParameter rdf:_3
value categoryName
ParameterPowerSet ProcessControlStatus SimpleProcess
components
taxonomy Unordered ProcessComponent-
xsd:string Country ConditionalEffect
Bag rdf:parseType Completed daml:collection
components rdf:_6 expandsTo
xsd:string daml:oneOf
sc rdf:_1 collapsesTo
rdf:_5 1
Choice components Canceled
rdf:_2
rdf:_4 CompositeProcess rdf:parseType
sc chooseFrom daml:cardinality
xsd:string Ready rdf:_3 rdf:_2
xsd:string Aborted daml:onProperty
invocable daml:intersectionOf
components
Iterate
Ongoing Suspended computedInput computedPrecondition
categoryName components
NAICS rdf:type
UNSPSC computedOutput computedEffect composedOf
NAICS
If-Then-Else
xsd:boolean
taxonomy else then ifCondition
Condition daml:Restriction
www.naics.com categoryName UNSPSC whileProcess
daml:Thing
ProcessComponent
Repeat-While
whileCondition
untilProcess untilCondition
Repeat-Until

Figure 7.4: The DAML-S Ontology

damls:Profile

sc sc sc

ComputationService ServiceRegistryBroker InformationService

sc sc sc sc sc

sc

StructuralAnalysis- MeasurementInfo- DesignStandardInfo-
VisualizationService MathematicalService
Service Service Service

sc sc
sc MaterialInfoService

EquationSolver FiniteElement-
sc
IntegralService AnalysisService
sc
sc
sc
PolynomialEquation-
Solver ClosedForm-
SystemOfEquations- AnalysisService
Solver
sc sc

LinearSystemOf- NonlinearSystemOf- MatrixService
EquationsSolver EquationsSolver

sc sc

MatrixDeterminant- MatrixInversion-
Service Service

sc
sc

DirectMatrix- IterativeMatrix-
InversionService InversionService

Figure 7.5: A Service Proﬁle Hierarchy for Computational Mechanics Application Web
Services

daml:Thing

sc Scalar

Quantity Vector
sc

sc
sc sc
MathQuantity
Matrix

sc
sc sc

SparseMatrix DenseMatrix BandedMatrix

Figure 7.6: A Hierarchy of Matrices Involved in Computational Mechanics

71

DirectMatrix-
InversionService
damls:Service
QualityRating damls:WsdlGrounding
sc
presents
sc
ScienceNetMatInv- damls:WsdlAtomic-
sc
sc Profile ProcessGrounding
qualityRating supports
rating ScienceNetMatInv
ScienceNetMatInv-
WsdlGrounding
CompMechRating Class A
describedBy sc
hasAtomicProcessGrounding

ScienceNetMatInv-
ScienceNetMatInv- WAPG
damls:WsdlOperationRef
sc ProcessModel
damls:ProcessModel hasProcess
wsdlOperation

damlsProcess sc
ScienceNetMatInv-
sc ScienceNetMatInv-
damls:AtomicProcess Process
WOR
input
operation

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

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

IterativeMatrix-
InversionService
damls:Service
sc
presents
sc
NumMethOrgMatInv- damls:WsdlAtomic-
Profile sc
sc ProcessGrounding
rating NumMethOrgMatInv
NumMethOrgMatInv-
WsdlGrounding
describedBy sc

NumMethOrgMatInv-
NumMethOrgMatInv- WAPG
sc ProcessModel
wsdlOperation

damlsProcess sc
NumMethOrgMatInv-
sc Process NumMethOrgMatInv-
damls:AtomicProcess WOR
input
operation

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

Figure 7.8: DAML-S Ontology Instance Describing NumMethods.org Matrix Inversion
Service

72

IterativeMatrix-
InversionService
damls:Service
sc
presents
sc
OptimizeComMatInv- damls:WsdlAtomic-
Profile sc
sc ProcessGrounding
rating OptimizeComMatInv
OptimizeComMatInv-
WsdlGrounding
describedBy sc

OptimizeComMatInv-
OptimizeComMatInv- WAPG
sc ProcessModel
wsdlOperation

damlsProcess sc
OptimizeComMatInv-
sc Process OptimizeComMatInv-
input
operation

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

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

IterativeMatrix-
InversionService
damls:Service
sc
presents
sc
NumRecpNetMatInv- damls:WsdlAtomic-
Profile sc
sc ProcessGrounding
rating NumRecpNetMatInv
NumRecpNetMatInv-
WsdlGrounding
CompMechRating Class B
describedBy sc

NumRecpNetMatInv-
NumRecpNetMatInv- WAPG
sc ProcessModel
wsdlOperation

damlsProcess sc
NumRecpNetMatInv-
sc Process NumRecpNetMatInv-
input
operation

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

Figure 7.10: DAML-S Ontology Instance Describing NumericalRecipe.net Matrix Inversion
Service

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/encoding/"
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/encoding/"/>
<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:MatrixService">
<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/encoding/"
15 namespace="http://std.nummethods.org"/>
</input>
<output>
<soap:body use="encoded"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
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/services/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

Y

in 6.00 in
3 .00

5.00 in

Z 1.00 in
X

10.0 kN in
1 .0 0

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>
</endPoint>
<numCells x1="12" x2="10" x3="6"/>
</geometry>
25 <boundaryConds>
<forces>
<nodalForce id="fn01">
<direction coordType="cartesian">X</direction>
30 <magnitude unit="kN">10.0</magnitude>
</nodalForce>
</nodalForce>
</nodalForce>
</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">
<dispVal unit="cm">0.00</dispVal>
5 </displ>
<displ id="dn02">
<direction coordType="cartesian">Y</direction>
10 </displ>
<displ id="dn03">
<direction coordType="cartesian">Z</direction>
15 </displ>
<displ id="dn04">
20 </displ>
<displ id="dn05">
<direction coordType="cartesian">Y</direction>
25 </displ>
<displ id="dn06">
<direction coordType="cartesian">Z</direction>
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"/>
</dispLoc>
40 <stressLoc>
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

FiniteElement-
AnalysisService
damls:Service AgentBFemService-
damls:WsdlGrounding DiscretizeWAPG
QualityRating
sc
presents
sc
AgentBFemService- hasAPG AgentBFemService-
sc GForceWAPG
sc Profile
supports
qualityRating hasAPG
rating AgentBFemService hasAPG
AgentBFemService-
WsdlGrounding AgentBFemService-
GStiffnessWAPG
describedBy hasAtomicProcessGrounding hasAPG

AgentBFemService-
BoundaryWAPG
sc AgentBFemService-
damls:ProcessModel AgentBFemService- SolutionWAPG
hasProcess ProcessModel sc

damls:WsdlAtomic-
hasProcess wsdlOperation ProcessGrounding
hasProcess
Discretization-
AtomicProcess hasProcess sc
hasProcess damlsProcess

Solution- AgentBFemService- damls:WsdlOperationRef
AtomicProcess SolutionWOR
GForceAtomicProcess
operation
Boundary-
AtomicProcess
GStiffness- http://192.168.0.2/
AtomicProcess processes.wsdl#getSolution

rdf:_1 rdf:_5
rdf:_2 damls:Composite-
rdf:_3 rdf:_4 MainFemProcess sc
Process

daml:toClass daml:toClass
damls:listOfInstancesOf sc daml:Restriction
rdf:type
rdf:type
daml:intersectionOf
daml:onProperty
rdf:parseType daml:Restriction rdf:_2
daml:onProperty
rdf:_1
daml:collection damls:composedOf
rdf:parseType
damls:components damls:Sequence daml:collection

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

79

2003 2004 2005
Task Description 4th Term 5th Term 6th Term 7th Term 8th Term 9th Term
Dec. Jan. Feb. Mar. Apr. May June July Aug. Sept. Oct. Nov. Dec. Jan. Feb. Mar. Apr. May June July Aug.

Infrastructure Design and Development Research Begins
1. Construction of domain ontologies
2. Construction of ontology mapping facilities
3. Construction of service enactment facilities
4. Deployment of the infrastructure and test cases
First progress report to examination committee 1st Progress Report
Application Web Services Development
4. Design of master plan for application Web Services
5. Development of CompMechRegistry
6. Development of AgentAWebService
7. Development of AgentBFemService
Second progress report to examination committee 2nd Progress Report
80

8. Development of LSESolver and NLSESolver
9. Development of SIMeasureService
10. Development of USMeasureService
11. Development of ASTMMaterialService
Third progress report to examination committee 3rd Progress Report
12. Development of UBCInfoService
13. Development of ACIInfoService
14. Development of AISCInfoService
15. Deployment of the prototype system and test cases
Fourth progress report to examination committee 4th Progress Report
Documentation Tasks
16. Preparation of the thesis and mandatory web site
Final thesis defense
Final Defense

Figure 7.17: Preliminary Schedule for the Proposed Research Tasks

Table 7.6: Expenditure Estimates for the Proposed Research

Item Cost (Baht)
Laboratory equipment 10,000
Textbooks and article reprints 10,000
Photocopies 5,000
Transportation and communications 3,000
Thesis binding 2,000
Total 30,000

81

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 Mifﬂin
Company, third edition, 1992.

Akama, K. (1993). Declarative semantics of logic programs on parameterized representation
systems. Advances in Software Science and Technology, 5:45–63, 1993.

Akama, K., Shimitsu, T., and Miyamoto, E. (1998). Solving problems by Equivalent Trans-
formation of Declarative Programs. Journal of the Japanese Society of Artiﬁcial Intelli-
gence, 13(6):944–952, 1998. In Japanese.

Akama, K., Koike, H., and Mabuchi, H. (2001). A theoretical foundation of program
synthesis by Equivalent Transformation. In Perspectives of System Informatics, vol-
ume 2244 of Lecture Notes in Computer Science, pages 131–139. Springer Verlag,
Heidelberg, 2001. Available online: 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 the
Equivalent Transformation computation model. In Proceedings of the 12th International
Workshop on Logic Based Program Development and Transformation (LOPSTR 2002),
pages 285–304, Madrid, Spain, 2002. Available online: http://assam.cims.hokudai.
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. In Proceedings of the First International
Semantic Web Conference (ISWC), Sardinia, Italy, June 2002.

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

Anutariya, C., Wuwongse, V., and Wattanapailin, V. (2002). An Equivalent-Transformation-
based XML Rule Language. In Proceedings of the International Workshop on Rule
Markup Languages for Business Rules in the Semantic Web, Sardinia, Italy, June 2002.
Available online: 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 dynamics
on the Information Power Grid using Globus. In Proceedings 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 server approach to parallelizing the
Element-Free Galerkin Method. In Proceedings of the Fifth Annual National Sympo-
sium on Computational Science and Engineering, Bangkok, Thailand, June 2001. Na-
tional Electronics and Computer Technology Center of Thailand. ISBN 974-229-024-5.

Barry, W. and Vacharasintopchai, T. (2001b). A parallel implementation of the Element-Free
Galerkin Method. In Proceedings of the Eight East Asia-Pacific Conference on Structural
Engineering and Construction (EASEC-8), Singapore, December 2001. Nanyang Techno-
logical University.

Basha, S., Cable, S., Galbraith, B., Hendricks, M., Irani, R., Milbery, J., Modi, T., Tost, A.,
and Toussaint, A. (2002). Professional Java Web Services. Wrox Press, Ltd., 2002. ISBN
1-861003-75-7.

Belytschko, T., Lu, Y. Y., and Gu, L. (1994). Element-free galerkin methods. International
Journal for Numerical Methods in Engineering, 37:229–256, 1994.

Berners-Lee, T., Fielding, R., and Masinter, L. (1998). RFC2396 Uniform Resource Identi-
fiers (URI): Generic Syntax. The Internet Engineering Task Force (IETF), August 1998.
Available online: 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. Available
online: 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: The
information 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 Web
Consortium (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 Markup
Language 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. Computer
Networks, 39(5):609–634, 2002.

Brown, C. (1994). UNIX Distributed Programming. Prentice Hall, 1994. ISBN 0-13-
075896-5.

Catlett, C. (2002). TeraGrid Primer. The TeraGrid Project, September 2002. Available on-
line: 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. In Proceedings of
International Conference on Computational Science 2003, St. Petersburg, Russian Feder-
ation and Melbourne, Australia, June 2003. Available online: http://www.cs.cornell.
edu/stodghil/papers/iccs03.pdf. [Downloaded: September 3, 2003].

Chiu, K., Govindaraju, M., and Bramley, R. (2002). Investigating the limits of SOAP
performance for scientiﬁc computing. In Proceedings 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 Finite
Element Analysis. John Wiley & Sons, New York, 1989. ISBN 0-471-84788-7.

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

DAML (2001). DAML+OIL Language Speciﬁcation. The Defense Advanced Research
Projects 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 Projects
Agency 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 Agency
Agent Markup Language (DAML) Program, June 2003. Available online: 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: Yet
another hip? Data and Knowledge Engineering, 41(2–3):205–227, June 2002. Available
online: 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. Technical
report, 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 Task
Force (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. The
Global 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. July
2002. Available online: http://www-fp.mcs.anl.gov/˜foster/Articles/
WhatIsTheGrid.pdf. [Downloaded: April 29, 2003].
Foster, I. (2003a). The Grid: Computing without bounds. Scientiﬁc American, 288(4):78–85,
April 2003.
Foster, I. (2003b). Selected major Grid application and deployment projects in science
and 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. Available
online: http://www.gridforum.org. [Downloaded: June 13, 2003].
Gil, Y. and Ratnakar, V. (2002). A comparison of (semantic) markup languages. In Proceed-
ings of the Fifteenth International Florida Artiﬁcial Intelligence Research Society Con-
ference, pages 413–418, Pensacola Beach, Florida, USA, May 2002. AAAI Press. ISBN
1-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-performance
parallel implicit CFD. Parallel Computing, 27(4):337–362, 2001. Available online:
http://www-fp.mcs.anl.gov/petsc-fun3d/Papers/manke.pdf. [Downloaded: July
29, 2003].
Grosof, B. N. and Horrocks, I. (2003). Description Logic Programs: Combining logic
programs with Description Logic. Working paper, Center for eBusiness, MIT Sloan
School of Management, Cambridge, MA, USA, June 2003. Available online: http:
//www.daml.org/rules/dlp-wp-v19.pdf. [Downloaded: October 3, 2003].
Grosof, B. N., Horrocks, I., Volz, R., and Decker, S. (2003). Description Logic
Programs: Combining logic programs with Description Logic. In Proceedigns of
the 12th International World Wide Web Conference (WWW2003), Budapest, Hungary,
May 2003. Available online: 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). Fracture
Mechanics 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 National
Laboratory, 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 scientific
computing applications. Technical report, Asian Institute of Technology, 2003. Available
online: http://stweb.ait.ac.th/˜st029284/papers/matrix-ws-paper.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’s thesis, Computer Science and
Information Management Program, School of Advanced Technologies, Asian Institute of
Technology, Thailand, December 2001.
Thompson, H. S., Beech, D., Maloney, M., and Mendelsohn, N. (2001). XML Schema
Part 1: Structures. World Wide Web Consortium (W3C), May 2001. Available online:
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 Web Services for scientific
computing. In Proceedings of the International Conference on Web Services (ICWS)
2003, Las Vegas, Nevada, USA, June 2003. Available online: http://www.cs.fsu.
edu/˜engelen/icws03.pdf. [Downloaded: September 3, 2003].

88

W3C (1999a). HyperText Markup Language (HTML) 4.01 Specification. World Wide Web
Consortium (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 Candidate
Recommendation.
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 Web
Consortium (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), May
2003. 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., and
Kikinis, R. (2002). Real-time registration of volumetic brain MRI by biomechanical
simulation of deformation during Image Guided Neurosurgery. Computing and Visualiza-
tion in Science, 5:3–11, 2002. Available online: http://splweb.bwh.harvard.edu:
8000/pages/ppl/warfield/papers/2002/warfield-2002-cvs-appeared.pdf.
[Downloaded: July 29, 2003].
Wroe, C., Stevens, R., Goble, C., Roberts, A., and Greenwood, M. (2003). A suite of
DAML+OIL ontologies to describe bioinformatics Web Services and data. Interna-
tional Journal of Cooperative Information Systems, 12(2):197–224, 2003. Available on-
line: http://www.semanticgrid.org/documents/mygrid_service_ontology_02.
pdf. [Downloaded: July 22, 2003].
Wuwongse, V., Akama, K., Anutariya, C., and Nantajeewarawat, E. (2000). A foundation for
XML databases: Data model. Technical Report CS-KR-00-01 (2000), Knowledge Rep-
resentation Laboratory, Asian Institute of Technology, Thailand, 2000. Available online:

89

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 ﬁnite element analysis
using domain decomposition method on a parallel computer. Computers and Structures,
38(5/6):615–625, 1991.

90

INDEX

agent, 2, 55 Formal semantics, 34
algorithmic distribution, 14 functional decomposition, 14
applicability condition part, 43
application logic, 55 ground, 44
application Web Service, 55 ground clause, 42
attribute name, 45 ground objects, 41
attribute-name variable, 45 ground XML expressions, 45

basic specialization mapping operator, 46 head, 42, 43
HTTP, 21
basic specializations, 45, 46
bind (Web Service), 21 identity specialization, 41
body, 42, 44 instance, 42
bottleneck problem, 14 intelligent, 2
boxes, 29 interpretation domain, 41
business logic, 55 isotropic materials, 7
ivar-expression, 45
category, 30
class definitions, 65 knowledge base server, 55
classes, 30 knowledge representation systems, 27
clause, 42
client, 55 literals, 29
collaboration, 2 load balancing, 16
concurrency, 13 logic frameworks, 39
constraint, 42 Loosely coupled, 14

data, 46 multi-tier, 55
data distribution, 13
nested element, 44
data input, 56
non-ground XML expressions, 44
database, 55
non-unit clause, 42
database server, 55
declarative description, 42 object, 28
declarative programming language, 46 objects, 41
definition part, 43 Ontologies, 39
degree of freedoms, 7 ontologies, 2
describe (Web Service), 21 ontology mapping facilities, 57
description, 42
document processing and transformation, parallelism, 13
46 pattern matching, 25
documents, 46 PC-based servers, 66
domain decomposition, 13 predicate, 28
problem description, 43
ellipses, 29 process ontology, 3
empty element, 44 processor farm, 16
empty-element tags, 45 program, 43
end tags, 45 program execution, 46
equivalent transformation rules, 43 program specification, 43
equivalent transformations, 43 programs, 46
execution part, 44 proofs, 39

91

properties, 30 Unicode, 39
publish (Web Service), 21 unit clause, 42
URI references, 28
query part, 43 URIs, 39
query processing, 46 user interface, 55
RDF Model and Syntax (RDF M&S), 39 Web resource, 28
RDF Schema, 39 Web Service, 55
reasoning, 2 Web Services, architecture of, 21
Remote Procedure Calls (RPC), 21 WSDL, 22
resource, 28
resource sharing, 13 XET program, 46
result presentation, 56 XET rules, 46
rules, 39 XML, 21
XML application, 28
search engines, 56 XML clauses, 46
Semantic Web Services, 37 XML declarative descriptions, 46
semantics of an XML declarative descrip- XML elements, 44
tion, 46 XML expression, 44
service consumer, 21 XML expression alphabet, 44
service execution and monitoring, 56 XML expressions, 44
service execution plan, 57 XML namespaces, 38
service planning, 56 XML specialization generation system, 46
service provider, 21 XML specialization system, 46
service registry, 3, 21 XML tags, 38
service registry broker, 55
services ontologies, 55
signatures, 39
simple element, 44
SOAP, 22
special-purpose Web Service, 55
specialization operator, 46
specializations, 41
speciﬁcation, 43
speed-up, 14
start tags, 45
stationary potential energy, principle of, 7
structure deﬁnitions, 65
subject, 28

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

UDDI, 22
understand, 27

92

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

More Related Content

Viewers also liked (6)

Similar to Semantic Web Services for Computational Mechanics : A Literature Survey and Research Proposal (20)

More from Dr. Thiti Vacharasintopchai, ATSI-DX, CISA (17)

Recently uploaded (20)

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