Description Logics (DL) [9] are a well-known family of knowledge representation for-malisms which represent the knowledge of a domain. The essential elements of DLs are concepts (unary predicates, classes) and roles (binary relations). Complex concepts can
Figure 3.1: Architecture of a knowledge representation system based on Description Logics.
be defined by assembling atomic ones. With formal and logic-based semantics, reasoning is an important feature of Description Logics which allows inferring implicit knowledge from explicit knowledge stored in the knowledge base. In addition, the DL reasoner can check whether two concepts subsume each other(classify taxonomy). Figure 3.1 shows the architecture of a knowledge representation system based on Description Logics.
The knowledge representation system consists of a TBox and an ABox. In the TBox, it first defines the concepts in the application domain (the terminology used in the world) and then utilizes these concepts to define roles (binary relationship between concepts).
Along with concepts and roles, TBox contains a set of axioms that are used for asserting relationship among concepts and roles. A concept can be viewed as a set of objects, which are instances of a certain object class. Therefore, in the ABox, we can assert that a certain instance (denoted as individual) belongs to the given concept or two individ-ual have realized the relationship of a certain role. TBox supports reasoning service for checking subsumption and satisfiability among concepts, while ABox support reasoning services, such as consistency and instance checking. Both of them are described in De-scription Language, such as AL ,or the other extensive language. Another feature of the
Description Logics knowledge representation system is the emphasis on reasoning as its core services. Application programs and rules can interact with the systems in various way. Other applications can interact with the system by querying the Knowledge Base ,and by modifying it by adding and retracting concepts, roles, and assertions. Rules, which are extensional formalisms that enrich the knowledge base, are another way to access the DLs knowledge architecture. In the following sections, we list Description Logics notations, such as concept definitions and roles to represent ontology definitions.
Detailed theoretical explanation can be referred in [9].
3.1.1 Description Logics Syntax and Semantics
Description Logics Syntax Atomic concepts, which are sets of unary predicate sym-bols that are used to denote, and atomic roles, which are sets of binary predicate symsym-bols that are used to denote, are basic description elements of Description Logics. Complex descriptions can be built from them inductively with concept constructors and role con-structors. In the following abstract notations, the capital letter A stands for an atomic concept, the capital letter R stands for atomic roles, and the capital letter C and D rep-resent concept descriptions. The language AL is a minimal and fundamental language that contains smallest set of concept constructors. Concept description in AL are defined using the following syntax rules [9]:
C,D −→ A | (atomic concept)
We present an example to illustrate the expressive of AL: suppose that Person and Female are atomic concepts, then we can define Person u Female to represent Woman, which means a person who is female. Then Person u ¬Female represents Man, which means a person who is not a female. In addition, if hasChild is an atomic role, we can say
that Person u ∃hasChild.> express a person who has at least a child. Another example Person u ∃hasChild.(Person u Female) expresses a person whose children are all female.
However, in practical applications and business domains, the AL languages are not enough for describing cardinality constraints on roles, concrete domains, transitive roles, inverse roles, role hierarchies and so on. The extended language, such as ALC which supports full concept negation(C), based on AL with more expressive power is proposed.
A language that supports number restriction(N ) is named ALCN while all member of the AL-family include AL as a sublanguage. Therefore, we use constructors, SHIQ(D), to describe our application domain. These added constructors include:
=n ≥n ≤n (concrete domain exactly min max restriction)
= n R > n R 6 n R (unqualified cardinality exact atleast atmost restriction)
= n R.C > n R.C 6 n R.C (qualified cardinality exact atleast atmost restriction)
¬C (arbitrary concept negation)
To follow up the example presented before, we show some examples of the constructors.
If Woman ≡ Person u Female, we can define Mother concept by Woman u ∃hasChild.Person.
Here we can see that Woman and Person are arbitrary concept name. ¬Woman means a set of individuals that are not women. Moreover, we can use Motheru ≥ 2hasChild and Motheru ≥ 2hasChild.Female to represent “a mother has 2 children” and “a mother has 2 daughters”.
Description Logics Semantics Here we summarize the Description Logics syntax and its semantics in the Table 3.1. The language description for each constructor is listed in column Symbol.
Table 3.1: Description Logics Concept Constructors
Name Syntax Semantic Symbol
Top > ∆I AL
Bottom ⊥ ∅ AL
Intersection C u D CI∩ DI AL
Union C t D CI∪ DI U
Name Syntax Semantic Symbol
Description Logics Terminologies Terminologies are statements describing the re-lationship between concepts and concepts or between roles and roles. The terminological axioms are represented in the following two forms of
• Inclusion Axioms C v D (R v S)
• Equality Axioms C ≡ D (R ≡ S)
where C, D are concept names (and R, S are role names). The first axiom is called inclusion, while the second one is called equalities.The relative semantics to inclusion and equalities are defined as follows: an interpretation I satisfies C v D if CI ⊆ DI, and it satisfies C ≡ D if CI ≡ DI. All the terminological (TBox) and assertional (ABox) axioms are listed in Table 3.2.
Table 3.2: Terminological and Assertional Axioms
Name Syntax Semantics
3.2 OWL
The Web Ontology Language(OWL) [18, 42] is a semantic markup language which is defined to describe and construct web ontologies. OWL supports greater machine inter-pretability of Web content. It is derived from the DAML+OIL Ontology language and is the recommended and standard ontology language in W3C. For the implementation of Semantic Web, OWL is based on XML and RDF and has ability to represent machine interpretable and understandable content on Web by providing additional vocabulary along with a formal semantics. It is written in XML document and defines it own syntax as a vocabulary extension of RDF. An OWL ontology includes descriptions of class, prop-erties, and their individuals. Based on the logic-based semantics theory, OWL supports ontology reasoning.
The OWL currently provides three kinds of sublanguages: OWL-Lite, OWL-DL, and OWL-Full. OWL-Lite supports those users primarily needing a classification hierarchy and simple constraints. OWL-DL supports those users who want the maximum expres-siveness while retaining computational completeness, which means all conclusions are guaranteed to be computable, and decidability, which means all computations will finish in finite time. OWL-DL includes all OWL language constructs but they can be used only under certain restrictions. OWL-DL is based on Description Logics to form the formal foundation of OWL. OWL-Full is defined for users who want maximum expressiveness and the syntactic freedom of RDF with no computational guarantees. Since OWL-Full retain the most expressiveness and freedom on represent OWL, there are no reasoning software supporting complete reasoning for all features of OWL-Full.
These sublanguages are an extension of its particular simpler predecessor, both in what can be legally expressed and in what can be validly concluded. Such relationships between subsets are in the following sets which are not reversibly:
• Every legal OWL Lite ontology is a legal OWL DL ontology.
• Every legal OWL DL ontology is a legal OWL Full ontology.
• Every valid OWL Lite conclusion is a valid OWL DL conclusion.
• Every valid OWL DL conclusion is a valid OWL Full conclusion.
Ontology developers consider which OWL subset they adopt depending on their needs.
The choice between OWL-Lite and OWL-DL is decided by the extent to which users require the more-expressive constructs provided by OWL-DL, while the choice between OWL-DL and OWL-Full depends on the extent to which users require the meta-modeling facilities of RDF Schema. Reasoning support is less predictable when using OWL-Full since complete OWL-Full implementations do not currently exist.
3.3 Semantic Web Rule Language: SWRL
Semantic Web Rule Language (SWRL) [26] is a rule language, which combines OWL and RuleML. It extends OWL axioms to support Horn-like rules. Rules are of the form of an implication between an antecedent (body) and consequent (head), which means whenever the conditions specified in antecedent holds, the conditions in consequent must also hold. Besides, an empty antecedent is treated as trivially true, while an empty consequent is treated as trivially false. For example, we can define a rule which asserts that the composition of two roles hasParent and hasBrother is hasUncle. This rule can be represented as the following human readable form:
parent(?x,?y) ∧ brother(?y,?z)−→ uncle(?x,?z)
where ?x,?y,and ?z stand for variables corresponding to individuals in ABox. The overall abstract syntax of SWRL are listed in Table 3.3
3.3.1 SWRL Editor
To integrate rules with ontologies, a SWRL rule editor called SWRLTab has been embed-ded into Prot´eg´e, which is the most popular OWL-ontology editor. SWRLTab works as a plug-in of Prot´eg´e. It provides a friendly graphical user interface to edit SWRL rules.
Figure 3.2 shows the editing environment of the SWRL editor in Prot´eg´e.
The SWRLTab should be visible for all OWL knowledge bases that import the SWRL ontology 1. The rules are stored as concepts within the same ontology where classes and properties are defined. Therefore, classes and properties defined in an ontology can be used directly by SWRL rules. Figure 3.3 shows the relationship between SWRL rules and
1http://www.daml.org/rules/proposal/swrl.owl
Table 3.3: Abstract Syntax of SWRL
ontologies. Rules can be divided into two parts: head and body. Each part consists of zero or multiple atoms, which can be ClassAtom, IndividualPropertyAtom or others. Multiple atoms are treated as a conjunction. ClassAtom can be viewed as an unary predicate and the predicate name refer to a class name in an ontology; whereas IndividualPropertyAtom can be viewed as a binary predicate and the predicate name refer to an property name in the same ontology.
3.4 Quantitative Relations
In the previous section, we’ve introduce the Web Ontology Language (OWL) and Se-mantic Web Rule Language (SWRL). Although, OWL has been a standardize language to express ontology in the Semantic Web, it still have some drawbacks considering the support of concrete domain. Pan et al. [47] pointed out some limitations of current version OWL.
• It does not support user-defined XML Schema datatypes:e.g., >15
• It does not support negated datatypes:e.g., ¬ >15
• Enumerated datatypes are the only user-defined datatypes supported by OWL.
Figure 3.2: The SWRL Editor in Prot´eg´e
• We cannot name the enumerated datatypes in OWL.
• There is no n-ary datatype predicates:e.g., +.
• There is no user-defined datatype predicates:e.g., sumNoLargerThan15
From the above, we can see that the current version of OWL lacks support for the modeling for quantitative relations. For example, it is difficult for us to express the range of the trip budget in the form of concept expression. Lu [39] proposed an approach for modeling quantitative relations. The main idea is to transfer a linear inequality problem into concept subsumption checking. He proposed two methods to deal with such kind of problem.
In the first method, concrete values and intervals are modeled with four kinds of concepts. Each concept represents a range with an upper/lower bound and relations among these ranges can be defined with concept subsumptions. The semantics of these four kinds of concepts are defined by the following table.
Figure 3.3: Relationship between SWRL and Ontology
Table 3.4: Semantics of Quantitative Concepts Concept Semantics
leqX (−∞, X ]
lessT hanX (−∞, X )
geqX [X , ∞)
greaterT hanX (X , ∞)
Therefore, given a concrete value X , we have the following four types of concepts:
leqX represents ” X and all concrete values less than X ” lessT hanX represents ” all concrete values less than X ”
geqX represents ” X and all concrete values greater than X ” greaterT hanX represents ” all concrete values greater than X ”
Given two concrete values X and Y where X < Y, we can define relations among these four kind of concepts as follows:
lessT hanY v leqY greaterT hanY v geqY leqX v lessT hanY lessT hanX v leqY geqY v greaterT hanX greaterT hanY v geqX
Based on these concepts and subsumption relationships, we can express all concrete values between X and Y with ”lessT hanX u greaterT hanY”. A single point of concrete value is a special case of interval whose upper bound and lower bound are the same. A concrete value X can be represented with “leqX u geqX ”. Such a method models concrete values and intervals well, but it cannot define ordinal relations between intervals. Therefore, Lu proposed a second method.
The second method is used for modeling temporal ordinal relations. Given a rational number line, we can divide it into equal length ranges called primitive intervals. Temporal relations between primitive intervals are defined as
t1 < t2 means t1 is before t2
t1 ≤ t2 means t1 is before or the same as t2 t1 > t2 means t1 is after t2
t1 ≥ t2 means t2 is after or the same as t2
Complex intervals consist of primitive intervals. A complex interval T is an interval that stars form one primitive interval (written as begin(T )) and ends at another primitive interval (written as end(T )). Temporal relations between two arbitrary intervals T1 and T2 can be defined as
T1 < T2 means end(T1) < begin(T2) T1 > T2 means begin(T1) > end(T2)
T1 ≤ T2 means (end(T1) ≤ end(T2)) and (begin(T1) ≤ end(T2)) T1 ≥ T2 means (begin(T1) ≥ begin(T2)) and (begin(T1) ≥ end(T2))
In this method, an interval T are modeled as a concept (written as C(T )) in TBox. If T2 is a sub-interval of T2, it means that C(T2) is a sub-concept of C(T1). Then, he defines two transitive object property ends before and begins after to express the above temporal ordinal relations. Their semantics are shown in the following table.
Note that, in the concept hierarchy, if we say an interval C(T1) ends before C(T2) (represented as C(T1) v ends before.C(T2))and does not overlap C(T2) (represented as C(T1) u C(T2) v ⊥), C(T1) also ends before all sub-concept of C(T2). Temporal ordinal relations between two intervals can be checked by the following rules.
Table 3.5: Semantics of Quantitative Relations
Lu’s approach models quantitative relations using concepts and object properties. It has several flaws. For example, in the first method, for every concrete value, it will create four concepts:leq, lessT han, geq, and greaterT han. Second, it does not allow the user to specify intervals that are smaller than primitive intervals. For example, if the primitive interval is set to be one day, then it is impossible for user to describe schedule using hours.
On the other hand, SWRL supports build-ins for dealing with quantitative relations. We can use the less(X, Y ) function provided by SWRL build-in to compare the numeric value or time interval. Such a numeric value or time interval must be XML Schema datatypes.
However, SWRL rules can be only applied to individuals and cannot be used in the level of TBox. In our system, we models service descriptions as concept expressions. Therefore, we adopt Lu’s approach to model value partition and time ontology.
3.5 Web Service Description Language(WSDL)
The WSDL [3] is an XML based document for describing network services in abstract terms about operating on messages containing concrete data formats and network
proto-col. As communication protocols and message formats are standardized in W3C (World Wide Web Consortium), it becomes increasingly possible and important to be able to describe the communications in structured way. WSDL defines an XML grammar for describing services’ specification in order to achieve its needs. Such network connection used to communicate is standardized with SOAP 1.1, HTTP GET/POST, and MIME.
A WSDL document simply specifies:
• What the Web Services consists of - (types, message, operation)
• How the Web Services is bound to a set of concrete protocol - (binding, port type)
• Where the Web Services are implemented - (port)
Above-mentioned specification is defined with some main elements for automating the details involved in application communications applied in distributed systems and services. Details description about these elements is in the following section:
• Types: A Type is a container for data type definitions using some type system, such as XSD.
• Message: Message is an abstract, typed definition of the data being communicated.
• Operation: Operation defines an abstract description of an action supported by the service.
• Port Type: Port Type is an abstract set of operations supported by one or more endpoints.
• Binding: Binding defines a concrete protocol and data format specification for a particular port type.
• Port: A Port means a single endpoint defined as a combination of a binding and a network address.
• Service: A Service represents a collection of related endpoints.
However, since WSDL recognizes the need for rich type systems for describing message formats and supports the XML Schemas specification (XSD), it does not support semantic description of services.
3.6 Web Services Business Process Execution Language(WS-BPEL)
The Web Services - Business Process Execution Language (WS-BPEL) [7], which is de-veloped from Business Process Execution Language for Web Services (BPEL4WS) [30, 8]
is a language for describing business processes in Web Services. It is based on WSFL and XLANG, provided by IBM and Microsoft respectively. Based on Web Service Description Language (WSDL) 1.1, BPEL-WS is also compatible with other Web Services standards of XML module definitions, XPath, and WS-Addressing. The goals of the BPEL4WS specification are as follows [36]:
• Define business processes that interact with external entities through Web Services operations.
• Define business processes using XML as the basic language.
• Define a set of Web Services orchestration concepts to be used by both external (abstract) and internal (executable) views of a business process.
• Provide both hierarchical and graph-like control strategies.
• Provide functions for the simple manipulation of data needed to define process relevant data and control flow.
• Support an identification mechanism for process instances.
• Support the implicit creation and termination of process instances as the basic lifecycle mechanism.
• Define a long-running transaction model.
• Use Web Services as the model for process decomposition and assembly.
• Build on compatible Web Services standards as much as possible in a composable and modular manner.
WS-BPEL refers to high-level state transition interaction of processes with an Ab-stract Process, which represents a set of publicly observable behaviors, including informa-tion like when to wait for messages, when to send messages, when to compensate for failed transactions, and so on. It also deals with short-lived programmatic behaviors, which are often executed as a single transaction and invoke access to local logic and resources, such as files and databases.
Business Process Execution Language for Web Services (BPEL4WS) is still the most adopted standards for Web Services composition. Essentially, it is comprised of Part-ner Links, PartPart-ner Link Types, Variables, Activities, Correlation Sets, Compensation Handlers, and Fault Handlers for describing business processes. Partner Links are Web Services interfaces that facilitate interaction between a business process and partner Web Services. Partner Link Types define the roles played by the services using the processes’
WSDL. Variables define messages sent and received by partners. Activities can be divided into two types: Primitive Activities,namely assign, invoke, receive, reply, throw, and wait;
and Structure Activities, including sequence, while, switch, flow and pick. Correlation Sets are sets of business data fields that capture the state of an interaction. Compensation Handlers are invoked to perform compensation activities. Fault Handlers are defined to catch exceptions.
BPEL4WS enables automated Web Services execution and is broadly used for Web Services composition. However, some shortcomings of BPEL4WS that limit its ability to provide flexible interoperability are reported in [40, 59]. BPEL4WS is a process-based language, so that process participants (partners’ Web Services) must be defined and bound to the process flow during the design stage. The BPEL standard does not support Semantic Web Services; therefore, partner discovery and binding at run time are not possible. In [13, 32], the authors discuss some solutions for dynamical composition of Web Services execution.
3.7 Web 2.0 Technology
The Web 2.0 technology, as outlined in [46], allows for an easier distributed collaboration.
The Web 2.0 technology, as outlined in [46], allows for an easier distributed collaboration.