Thesis full text (PDF) - Politecnico di Milano

POLITECNICO DI MILANO
V Facoltà di Ingegneria
Corso di Laurea Specialistica in Ingegneria Informatica
Dipartimento di Elettronica e Informazione
Applying Ontology and Reasoning to the Semantic Web for
Recommendation
Supervisor: Prof. Marco Brambilla
Master’s Thesis of
Junayeed, Mohammad Abdullah
Matr: 722892
Anno Accademico 2009/2010

Abstract
The thesis aims at implementing a web based social networking application using an existing
model-driven knowledge-intensive web application framework. The application is mainly based
on ontology and semantic web application with recommendation features. The increasing needs
for information integration and exploitation expect an approach which solves impuissance that
the traditional web applications are suffering. The architecture of the framework is based on
model driven approach which also use reasoning technique to deduct some new information and
relation which allows us to explore recommendation. In the framework we have extended some
components and patterns which is also important to verify the consistency and incompleteness of
the design of the application. We also have implemented a real world application. Lastly we have
made a comparative analysis on the different techniques.
2

Table of Contents
Abstract .......................................................................................................................................... 2
1. Introduction .............................................................................................................................. 5
1.1 Motivation ........................................................................................................................... 5
1.2 Overview of the Approach ................................................................................................ 6
2. Background ............................................................................................................................. 10
2.1 Model Driven Architecture (MDA) ................................................................................ 10
2.1.1 Review of MDA .......................................................................................................... 10
2.1.2 Basic concepts ............................................................................................................. 10
2.1.3 MDA in our Approach .............................................................................................. 12
2.2 Web Modeling Language (WebML) .............................................................................. 13
2.3 WebRatio ............................................................................................................................ 15
2.4 Semantic Web .................................................................................................................... 17
2.4.1 A First Look at the Semantic Web ........................................................................... 17
2.4.2 RDF ............................................................................................................................... 19
2.4.3 OWL ............................................................................................................................. 20
2.5 Ontology ............................................................................................................................ 20
2.6 Approaches to Knowledge Representation .................................................................. 22
2.7 Usage of UML ................................................................................................................... 22
2.8 UML Primitives for Data Semantics Representation ................................................... 23
2.9 Reasoning Capabilities for UML Models ...................................................................... 24
2.9.1 Representation Formalisms ...................................................................................... 24
2.9.2 Reasoning Engines ..................................................................................................... 24
3. Semantics Web based Recommendation System .............................................................. 27
3.1 Components for Knowledge Representation ............................................................... 27
3.1.1 Class Component ....................................................................................................... 27
3.1.2 Datatype Component ................................................................................................. 30
3.1.3 Property Component ................................................................................................. 30
3.1.4 Hierarchy Components ............................................................................................. 31
3.1.5 Instance Component .................................................................................................. 32
3.1.6 Property Value Component ...................................................................................... 33
3.1.7 Explanation Component ........................................................................................... 34
3.1.8 Add Components ....................................................................................................... 35
3.1.9 Add Class Component .............................................................................................. 36
3.1.10 Add Datatype component ....................................................................................... 37
3.1.11 Add Property component ....................................................................................... 38
3.1.12 Add Property Value component ............................................................................ 39
3.1.13 Add Instance component ........................................................................................ 39
3

3.1.14 Remove Components ............................................................................................... 40
3.1.15 Remove Class component ....................................................................................... 42
3.1.16 Remove Datatype component ................................................................................ 42
3.1.17 Remove Property component ................................................................................. 43
3.1.18 Remove Property Value component ..................................................................... 44
3.1.19 Remove Instance component .................................................................................. 45
3.2 Knowledge‐base Management Components ................................................................ 45
3.2.1 Create‐KB component ................................................................................................ 45
3.2.2 Release‐KB component .............................................................................................. 46
3.2.3 Import‐XMI‐to‐KB component ................................................................................. 46
3.2.4 Export‐XMI‐from‐KB component ............................................................................ 47
3.3 Patterns for Knowledge Exploration and Management ............................................. 47
3.3.1 Knowledge Exploration ............................................................................................. 47
3.3.2 Knowledge Management .......................................................................................... 53
3.4 Social Network Application ............................................................................................ 55
3.4.1 Use Cases of the Application .................................................................................... 55
3.4.2 Application Specification .......................................................................................... 57
3.4.3 Application Design .................................................................................................... 61
3.4.4 Uses of Components and Patterns in the Recommendation Application .......... 63
4. Implementation Experience .................................................................................................. 66
4.1 WebML and WebRatio background .............................................................................. 66
4.2 Runtime Architecture of the Framework ...................................................................... 69
4.3 Implementation of Components..................................................................................... 70
4.3.1 Content publishing units ........................................................................................... 70
4.3.2 Content management operations ............................................................................. 71
4.3.3 Implementation .......................................................................................................... 73
4.4 Implementation of Patterns ............................................................................................. 74
4.5 Application Implementation ........................................................................................... 76
5. Related Work .......................................................................................................................... 86
6. Comparison ............................................................................................................................. 88
7. Conclusion .............................................................................................................................. 92
References ................................................................................................................................... 94
4

1. Introduction
At present the Web applications involve more in terms of explicitly declared semantics of
published and managed data, because of increasing demands for information integration and
exploitation. Typically, the context, and the content of the Web applications assembled from
several heterogeneous sources, on which no assumption of common terminology can be done.
Recent evolutions of Web applications involve abstruse demands in the explicitly declared
meaning of managed data in terms of real-world entities. Data and its non-ambiguous
interpretation must be shared between involved parties. In this setting, applications do need to
know the meaning of the shared data that we reference in the rest of the article as data semantics.
Once such knowledge is formalized and explicitly integrated into the system, it may be
interpreted and managed with application-dependent means for delivering the system services
and products.
The aforementioned limitations can be overcome by representing Web data semantics using the
UML class diagrams. We are using an existing framework [1] to serve this purpose which can
check the consistency of a knowledge base represented by a UML class diagram, and can make
inferences upon the UML objects derive new associations between Web data. We have
developed a model-driven knowledge-intensive web application with recommendation feature.
1.1 Motivation
Traditional Web applications aim at offering information to users in terms of contents that can be
browsed, searched, and modified through navigational links. But unfortunately, the
implementation techniques that are currently used for Web applications suffer of several
impuissances:
• Semantics of data and navigation is conveyed only within design documents that are not
usually available along with the Web data at runtime, thus making it impossible to grasp
the meaning of the implemented data structures.
• Traditional Web applications are not rich enough to cover commonly required aspects of
data semantics representation, like generalization hierarchies with overlapping
5

classifications, recommendation, transitivity of relations, and static and multi-valued
attributes.
• The available data retrieval mechanisms usually require design-time specification of the
content structure, thus failing to deliver objects when the relations among them are not
known a priori.
These drawbacks become more and more critical in several Web information systems that
require awareness of both system data and its semantics specially in the social network web
applications where reasoning on the user profile as well as other information which could help to
identify common interests among users.
In summary, the application must be integrated with the data semantics and inference mechanism
by which can deduct some interesting information in applications that involve content
personalization, adaptively, recommendation and machine-to-machine sharing. All these
information systems need to make decisions upon knowledge that is derived mainly from their
data and its semantics.
To fulfill such requirements, traditional modeling approaches for Web applications must be
extended from a purely database oriented or object oriented perspective, to a full-fledged
semantics based and ontology based perspective. This involves dramatic changes from static and
syntax-based models to dynamic and semantics-based knowledge.
1.2 Overview of the Approach
To overcome the impuissance of Web applications, new effective and efficient tools are needed
so that application designers move to knowledge-intensive application development, without
losing development productivity and results quality.
We are using a framework [1] for designing and implementing a Web application with
recommendation lineament that leverage data semantics for achieving the abovementioned
results. More precisely, we address three main objectives:
6

• Definition of the formal representation of Web data semantics. We offer a representation
method (based on the UML notation) of the knowledge we want to get from Web data,
considering the usability, expressivity, inference and derivation of new information
possibilities.
• Specification of a set of components for managing Web data semantics and producing
knowledge. We define a framework of reusable programming primitives that interact
with the reasoning engines and apply queries for delivering contents to the user.
• Specification of a set of patterns that exploit the abovementioned components and to
develop the recommendation applications.
The framework explores the UML as knowledge representation language. The main motivation
of this choice was the wide adoption and acceptance of the UML notation in software
engineering and its immediate applicability to design and development of desktop and web
applications. In the framework, Pellet [53] has been used as the reasoning engine enabling
inferences upon UML models. Given the UML representation of knowledge is fit in Pellet [53],
an inference engine that exposes its capabilities by means of Java interfaces. The main reason of
using a reasoner is to deduct some information from the knowledge base based on the user
profile and to use these information recommendation purposes.
UML class diagrams are already proved and widely used to be a valid representation language
for data semantics. We represent Web data semantics with UML class diagrams and we are using
a framework for data querying and reasoning able to: (i) check the consistency of a knowledge
base represented as a UML class diagram; (ii) make inferences upon the UML objects deriving
new data associations; and (iii) deliver and update knowledge.
Figure:1.1 depicts the phase by phase development process of a knowledge-intensive Web
recommendation application and the initialization of its knowledge repository, according to the
proposed method. As a first step, the data semantics is modeled in UML using a CASE tool of
choice.
7

Upon the previous UML model, the designer visually specifies the design of both the Web
application functionalities, and the knowledge repository (holding the semantics during the
application execution) using the framework components.
Once the application model has been created, the CASE tool supporting the framework provides
automatic generation of the application code (on the J2EE platform). At runtime the knowledge
developer inserts the knowledge (specified as XMI representation of the UML models) in the
repository, and eventually the final user will be able to browse the application hypertexts.
Modeling Actions
Runtime Actions
Manual
Manual
Automatic
Automatic
UML
modeling
AND
Visual design:
ontology
query &
management
XMI
representation
XMI
translation
to
ontology
Manual
Automatic
Automatic
Visual design:
knowledge
repository
management
AND
Generation
of
running
application
Interaction with
knowledgeintensive
application
CASE tool
i.e IBM
Rational
Framework
tool
user
interfaces tool
i.e Browser
Figure 1.1: Development phases of knowledge-intensive Web applications
This framework [1] is implemented within WebML [3], a DSL for Web applications design that
features visual modeling, CASE tool support, and automatic code generation. The
implementation experience comprises:
• the specification and implementation of the WebML primitives corresponding to the
framework components
• the specification of the patterns in WebML
• the code generation with the WebRatio CASE tool [55] integrated with the Pellet
reasoner.
8

This approach overcomes the developers’ resistance to the new knowledge-oriented and
semantics-oriented paradigm thanks to the adoption of the widely accepted UML notation and to
its immediate applicability to design and development of applications. Using this framework, we
have developed a web application.
9

2. Background
2.1 Model Driven Architecture (MDA)
2.1.1 Review of MDA
The MDA defines an approach to IT system specification that separates the specification of
system functionality from the specification of the implementation of that functionality on a
specific technology platform. To this end, the MDA defines an architecture for models that
provides a set of guidelines for structuring specifications expressed as models.
The MDA is a new way of writing specifications, based on a platform-independent model. A
complete MDA specification consists of a definitive platform-independent base UML model,
plus one or more platform-specific models and interface definition sets, each describing how the
base model is implemented on a different middleware platform.
The MDA approach and the standards that support it allow the same model specifying system
functionality to be realized on multiple platforms through auxiliary mapping standards, or
through point mappings to specific platforms, and allow different applications to be integrated by
explicitly relating their models, enabling integration and interoperability and supporting system
evolution as platform technologies come and go.
2.1.2 Basic concepts
Systems notions
Two different system notions exist: the teleological and the ontological system notion [4]. The
teleological system notion is about the function and the (external) behavior of a system. This
notion can be visualized with a black-box model. The teleological system notion is adequate for
the purpose of using or controlling a system. The ontological system notion, on the other side,
can be used for building or changing a system. It is about the construction and operation of a
system and can be modeled with a white-box model.
10

Both the teleological and the ontological system notion are relevant for designing a system [4].
In other words: both the functional and the constructional perspective of a system are relevant. In
software, the terms functional design and technical design are often used to refer to these
perspectives.
Model
A model of a system is a description or specification of that system and its environment for some
certain purpose. A model is often presented as a combination of drawings and text. The text may
be in a modeling language or in a natural language [5].
Viewpoint
A viewpoint on a system is a technique for abstraction using a selected set of architectural
concepts and structuring rules, in order to focus on particular concerns within that system. Here
‘abstraction' is used to mean the process of suppressing selected detail to establish a simplified
model [5].
Platform
A platform is a set of subsystems and technologies that provide a coherent set of functionality
through interfaces and specified usage patterns, which any application supported by that platform
can use without concern for the details of how the functionality provided by the platform is
implemented [5]. In principle a platform is a place to launch software on. Examples of platforms
are operation systems, the Java Virtual Machine, runtime libraries of programming languages,
etc.
Platform Independence
Platform independence is a quality, which a model may exhibit. This is the quality that the model
is independent of the features of a platform of any particular type. Like most qualities, platform
independence is a matter of degree. So, one model might only assume availability of features of a
very general type of platform, such as remote invocation, while another model might assume the
availability a particular set of tools for the CORBA platform. Likewise, one model might assume
11

the availability of one feature of a particular type of platform, while another model might be
fully committed to that type of platform [5].
Pervasive Services
Pervasive services are services available in a wide range of platforms [5]. In the MDA pervasive
services are modeled as platform independent. Examples are Directory services, Event handling,
Persistence, Transactions, and Security [6].
Application
The term application is used to refer to computer software delivering certain functionality.
Implementation
An implementation is a specification, which provides all the information needed to construct a
system and to put it into operation [5].
Model Transformation
Model transformation is the process of converting one model to another model of the same
system [5].
2.1.3 MDA in our Approach
The development of Web sites with a model-driven approach has been specifically addressed by
two important research projects, namely Araneus [7] and Strudel [8]. The first generation of
conceptual models for the Web [9][10][11][12][13][14][15] essentially considered Web
applications as a variant of traditional hypermedia applications, with the particularity that the
published contents are extracted from a database, and user interaction with the application takes
place via the medium of the Internet. Therefore, these modeling approaches have focused on
capturing the structure of the application contents, e.g., as a set of object classes or entities
connected by associations or relationships, and the navigation primitives, represented by such
concepts as pages, content nodes, and links. One such model is WebML, described in [15].
WebML allows specifying a Web site on top of existing data sources. A conceptual model
12

consists of a data schema, describing application data, and of one or more hypertexts (called site
views), expressing the Web interface used to publish and manipulate such data.
The specification of a WebML application consists of a set of models: the application data model
(an extended Entity-Relationship or UML Class Diagram), one or more hypertext models (i.e.,
different site views for different types of users), describing the Web application structure; the
presentation model, describing the visual aspects. The hypertext main concept is the site view,
which is a graph of pages; pages are composed by units, representing publishing of atomic pieces
of information, and operations for modifying data or performing arbitrary business actions. Units
are connected by links, to allow navigation, parameter passing, and computation of the hypertext.
We do not exploit MDA entirely but we inspired and do some transformation from WebML
where WebML assures MDA.
2.2 Web Modeling Language (WebML)
Web Modeling Language (WebML) is a methodology for specifying complex web application
design at the conceptual level. WebML guarantees a model driven architecture (MDA) approach
for developing web application. This is a key factor for defining a novel generation of CASE tool
for the construction of complex sites and for supporting advanced features like personalization,
evolution and multi device access. It enables the high level description of a web application
under distinct orthogonal dimensions – structural model (the data content), composition model
(the pages that compose it), navigation model (links between the model), presentation model (the
layout and graphic requirements for page rendering), and personalization model (customized
features of the contents). WebML consists a set of visual graphic notation to represent all the
components for defining the conceptual schemas and to represent the hypertext interface. The
WebML primitives are also provided with an XML-based (XMI format) textual representation
for specifying the data underlying the application. WebML exploits the ER (Entity Relationship)
model which consists of entities defined as containers of data elements and relationships defined
as semantic connections between entities.
The specification of a site in WebML consists mainly four orthogonal perspectives:
13

• Structural Model: The structural model expresses the data content of the site. The content
is expressed in terms of relevant entities and relationships (Figure 2.1.a). WebML is
compatible with classical notations like Entity Relationship (E-R) model [16], the ODMG
object-oriented model [17] and UML class diagram [18].
• Hypertext Model: The hypertext model can be published in the site. Different hypertext
defines different site view (Figure 2.1.b). The site view consist two sub models:
o Composition Model: It specifies which page composes the hypertext and which
content units make up a page. There are six different types of units available to
build up a page. The units are following: data, multi-data, index, filter, scroller
and direct units. Composition units are defined on the top of the structure schema
of the site. The developer/designer indicates the underlying entity or relationship
on which the content of each unit is based. For example in figure 2.1.b, the “Book
Data”, “Author Data” data unit are showing the information of a book, refer the
“Book” and “Author” entity is specified in the schema of figure 2.1.a.
o Navigation Model: Navigation model describes how the pages and the content of
the units are connected or linked to form the hypertext. There are two kinds of
links – non-contextual and contextual. Non-contextual links are used when they
connect semantically independent pages. For example, the page of a book to the
home page of the site. On the other hand, the contextual links are used when the
content of the destination unit of the link depends on the content unit of the source
unit. For instance, the page showing a book’s data in linked by a contextual link
of the page showing the index of edition of books of that book. Contextual links
are based on the structure schema because they connect content units whose
underlying entities are associated by the relationships in the schema.
• Presentation Model: Presentation model expresses the layout of the pages and graphic
content of each page. Presentation specifications are either page-specific or generic.
• Personalization Model: Users and user groups are explicitly modeled in the structure
schema in the form of predefined entities namely – User and Group. The features of these
entities can be used for storing group-based or individual content like shopping
suggestion, list of favorites etc. This personalized information can be used both in the
composition of units or in the definition of presentation specifications. On the other hand,
14

high-level business rules, written using simple SML syntax can be defined for reacting to
site-related events like hit counter, content update etc.
Figure 2.1: (a) Example of structural schema (b) correspondent site view
2.3 WebRatio
WebRatio supports the WebML design process. With respect to the WebML development
workflow, WebRatio covers the phases of data design and hypertext design, and supports
implementation by automating the production of the relational database and of the application
page templates. More precisely, WebRatio focuses on five main aspects:
• Data design: supports the design of Entity-Relationship data schemas, with a graphical
user interface for drawing and specifying the properties of entities, relationships,
attributes, and generalization hierarchies.
• Hypertext design: assists the design of site views, providing functions for drawing and
specifying the properties of areas, pages, units, and links.
• Data Mapping: permits declaring the set of data sources to which the conceptual data
schema has to be mapped, and automatically translates Entity-Relationship diagrams and
OCL expressions into relational databases and views.
15

• Presentation design: offers functionality for defining the presentation style of the
application, allowing the designer to create XSL style sheets and associate them with
pages, and organize page layout, by arranging the relative position of content units in the
page.
• Code generation: automatically translates site views into running Web applications built
on top of the Java2EE, Struts, and .NET platforms.
The diagram of figure: 2.2 summarize the design flow of WebRatio, highlighting the design
phases, together with their inputs and outputs. The different design steps will be described in
more detail in the next sections.
Figure 2.2: Design flow diagram of WebRatio
16

Thanks to the automatic generation of code, the tool can be used for fast prototyping, thus
shortening the requirements validation cycle. Unlike traditional prototyping tools, which
generate application mock-ups, the WebRatio code generator produces application modules
running on state-of-the-art architectures, and can be used for implementation, maintenance, and
evolution. Code generation starts from the outputs of conceptual design and therefore
implementation and maintenance benefit from the presence of a conceptual specification of the
application.
The internal software architecture of the applications created by WebRatio exploits the design
principles and techniques. In particular, applications are built using the Model-View-Controller
pattern, generic components in the business tier, and CSS and XSL presentation rules for
factoring out the look and feel from the page templates.
WebRatio internally uses XML and XSL as the formats for encoding both the specifications and
the code generators: XML is used for describing data and hypertext schemas, whereas XSL is
used for generating the graphic properties and layout of the page templates, for validity checking,
and for automatic project documentation. The extensive use of XML and XSL facilitates custom
extensions, which apply both to the WebML language, which can be extended with user-defined
units and operations, and to the tool functions, which can be enriched with custom consistency
checkers, documentation and code generators, and presentation rules.
2.4 Semantic Web
2.4.1 A First Look at the Semantic Web
The Semantic Web is an extension of the current Web. It is constructed by linking current Web
pages to a structured data set that indicates the semantics of this linked page. A smart agent, who
is able to understand this structure data set, will then be able to conduct intelligent actions and
make educated decisions on a global scale.
“The Semantic Web is an extension of the current Web in which information is given welldefined
meaning, better enabling computers and people to work in cooperation. A web of data
17

that can be processed directly and indirectly by machines.” — Tim Berners-Lee, James Hendler,
Ora Lassila [19].
Summarization of the Semantic Web is:
• The current Web is made up of many Web documents (pages).
• Any given Web document, in its current form (HTML tags and natural text), only gives
the machine instructions about how to present information in a browser for human eyes.
• Therefore, machines have no idea about the meaning of the document they are
presenting; in fact, every single document on the Web looks exactly the same to
machines.
• Machines have no way to understand the documents and cannot make any intelligent
decisions about these documents.
• Developers cannot process the documents on a global scale (and search engines will
never deliver satisfactory performance).
• One possible solution is to modify the Web documents, and one such modification is to
add some extra data to these documents; the purpose of this extra information is to enable
the computers to understand the meaning of these documents.
• Assuming that this modification is feasible, we can then construct tools and an agent
running on this new Web to process the document on a global scale; and this new Web is
now called the Semantic Web.
Figure 2.3: A Web page in the Semantic Web Environment
18

2.4.2 RDF
Resource Description Framework is the basic building block for supporting the Semantic Web.
RDF is to the Semantic Web what HTML has been to the Web. RDF is an XML-based language
for describing information contained in a Web resource. A Web resource can be a Web page, an
entire Web site, or any item on the Web that contains information in some form.
RDF is a language recommended by W3C [20], and it is all about metadata. It is capable of
describing any fact (resource) independent of any domain. It provides a basis for coding,
exchanging, and reusing structured metadata. RDF is structured; i.e., it is machineunderstandable.
Machines can do useful operations with the knowledge expressed in RDF. RDF
allows interoperability among applications exchanging machine understandable information on
the Web.
RDF can be used to describe resources in a structured way that machines can process; it can also
be used to assert relations between these resources so that machines can be empowered with
some basic reasoning capabilities. However, it does not define the vocabulary used; that is, RDF
does not say anything about the classes, subclasses and the relations that may exist between these
classes
RDFS stands for RDF Schema. RDFS is used to create such a vocabulary. It can be viewed as an
RDF vocabulary description language. RDFS in conjunction with RDF statements will push the
Internet one step further toward machine-readability, and this additional step cannot be
accomplished by RDF alone. RDFS is a language one can use to create a vocabulary for
describing classes, subclasses, and properties of RDF resources; it is a recommendation from
W3C [18]. The RDFS language also associates the properties with the classes it defines. RDFS
can add semantics to RDF predicates and resources: it defines the meaning of a given term by
specifying its properties and what kinds of objects can be the values of these properties.
19

2.4.3 OWL
OWL (Web Ontology Language) is the latest recommendation of W3C [21], and is probably the
most popular language for creating ontologies today. It is also the last technical component. The
good news is that it is built on RDF schema; as you have already established a solid
understanding of RDF schema, much of the material here is going to look familiar to you.
OWL = RDF schema + new constructs for expressiveness
Therefore, all the classes and properties provided by RDF schema can be used when creating an
OWL document. OWL and RDF schema have the same purpose: to define classes, properties,
and their relationships. However, compared to RDF schema, OWL gives us the capability to
express much more complex and richer relationships. The final result is that can construct agents
or tools with greatly enhanced reasoning ability. Therefore, OWL often used for the purpose of
ontology development.
RDF schema is still a valid choice, but it’s obvious limitations compared to OWL will always
make it a second choice. Compared to RDFS, OWL has much more powerful expressiveness.
2.5 Ontology
There are several aspects of this definition that need to be clarified. First, this definition states
that ontology is used to describe and represent an area of knowledge. In other words, ontology is
domain specific; it is not there to represent all knowledge, but an area of knowledge. A domain is
simply a specific subject area or sphere of knowledge, such as photography, medicine, real
estate, education, etc.
Second, ontology contains terms and the relationships among these terms. Terms are often called
classes, or concepts; these words are interchangeable. The relationships between these classes
can be expressed by using a hierarchical structure: super classes represent higher-level concepts
and subclasses represent finer concepts, and the finer concepts have all the attributes and features
that the higher concepts have.
20

Third, besides the aforementioned relationships among the classes, there is another level of
relationship expressed by using a special group of terms: properties. These property terms
describe various features and attributes of the concepts, and they can also be used to associate
different classes together. Therefore, the relationships among classes are not only super class or
subclass relationships, but also relationships expressed in terms of properties. To summarize,
ontology has the following properties:
• It is domain specific.
• It defines a group of terms in the given domain and the relationships among them.
By clearly defining terms and the relationships among them, ontology encodes the knowledge of
the domain in such a way that it can be understood by a computer. This is the basic purpose of
ontology.
We can summarize the benefits of ontology as follows (and you should be able to come up with
most of these benefits yourself):
• It provides a common and shared understanding/definition about certain key concepts in
the domain.
• It provides a way to reuse domain knowledge.
• It makes the domain assumptions explicit.
• Together with ontology description languages (such as RDF schema), it provides a way
to encode knowledge and semantics such that machines can understand.
• It makes automatic large-scale machine processing possible.
Among all these benefits, we in fact pay more attention to the fourth one in the preceding list.
21

2.6 Approaches to Knowledge Representation
Some approaches use UML class and object diagrams [22] for knowledge modeling. Their main
motivation stands on the expanding community of UML users and on the variety of associated
CASE tools. Indeed, designers do not need to learn a new formalism; they can take advantage of
a well established notation in software engineering of a plethora of documentation and user
experiences. Classification of these approaches according to the role UML semantics plays in the
modeled knowledge:
• UML is the knowledge representation language and its models are mapped to formal
logical structures [23] [24] [25] [26].
• Knowledge is represented with a markup, text-based syntax language and UML is only
the visual syntax of this language [27] [28] [29] [30] [31].
2.7 Usage of UML
Data semantics representation combines UML class diagrams, DL for formalizing UML models,
and the Pellet reasoner [32] for generating conclusions upon the models. This combination fully
satisfies the requirements for a representation language for data semantics:
• It has a formal semantics, with unambiguous interpretations from different applications.
• It has the necessary modeling constructs for expressing the data semantics required by
Web applications, enabling analysis, exploration, and inference of patterns.
• These constructs are easily recognizable by applications, thus enabling efficient
incorporation of data semantics into the application logic.
• It allows the application to carry out inferences upon its models, through sound and
complete deduction mechanisms. If the computational cost is too high, it is possible to
reduce the expressiveness of the language in order to increase efficiency.
• It allows the application to carry out incremental updates upon its models, thus granting
continuous evolution of data semantics.
• It allows a standard serialization of its models, thus facilitating the semantics exchange
among applications.
22

The XMI serialization of UML [33] enables the models to be exchanged on the Web. Mapping
mechanisms have already been studied for transforming UML models to application objects,
enabling the easy integration of UML elements into application code. Further, the UML
graphical notation facilitates the task of modeling with a plethora of open source graphical tools
that minimize the modeling time, effort, and cost.
Alternative approaches defined upon markup languages [34] [35] [36] [37] [38] can cope only
partially with the listed requirements. They explore the semantics of applications data in the
effort of addressing Tim Berners-Lee’s vision [39] of shared knowledge among business
partners: (i) their linear syntax makes them appropriate for sharing knowledge on the Web; (ii) a
variety of graphical editors have been implemented to support them; (iii) the formal meaning and
the optimized inference methods allow machines to efficiently interpret knowledge. Their main
drawback is the difficulty of inserting the represented knowledge within real developed
applications, since additional efforts are required for integrating knowledge specified as markup
within the application code.
2.8 UML Primitives for Data Semantics Representation
Initially, UML did not support automatic implementation of systems, since it was meant for
documenting and communicating the system’s development phases, and its constructs are only
explained in natural language. Transformations (e.g., encompassing reification for n-ary
associations and association classes) must be applied to the initial model to get a normalized
representation, and still not all the UML constructs are significant for deducting knowledge. The
main UML primitives for interpreting knowledge are:
• Package: It is the container for other UML components providing name-based access
mechanism to elements. Similar is the Ontology in DAML+OIL and OWL.
• Class: It describes domain objects with common structural features.
• Datatype: It describes (possibly structured) objects identifiable only by their value.
• Property: It can be either an attribute or an association role. Roles can be inverse,
aggregations, or compositions (the latter two are transitive). The concept of property has
different semantics in logic markup languages: it expresses first-class citizens; it does not
need to have defined endpoints. In DAML+OIL and OWL, the DatatypeProperty models
23

elements that correspond to UML attributes of datatypes. The rest of the UML properties
are defined with property restrictions added apart allowing for the same property to have
multiple domains and ranges.
• Generalizations: They organize classes and associations hierarchically with additional
restrictions of disjointness and completeness. The subClassOf and subPropertyOf
constructs in DAML+OIL and OWL have similar meaning.
• Instances: Instances appear in class diagrams as values for enumeration types and static
attributes. Similar is the use of hasValue and oneOf in OWL for individuals.
2.9 Reasoning Capabilities for UML Models
2.9.1 Representation Formalisms
Although the formalization of UML class diagrams has been already addressed in First Order
Logic [40] [41] [42], theorem proves do not guarantee complete automatic reasoning because of
the FOL undecidability.
DL languages have been widely used to formalize UML components [43], because their
computational complexity and decidability are well studied. Interpretations have been given with
DLRifd [44], ALCQI [45], and sROIQ [46]. We adopt sROIQ because it overcomes the
limitations of ALCQI by supporting nominal’s, role inclusion axioms and transitivity, and
inference systems are highly optimized.
2.9.2 Reasoning Engines
For reasoning upon the description logic languages used to formalize UML class and object
diagrams, three widely used tableau-based provers: Pellet, Fact++, and RacerPro. All of them
provide sound and complete reasoning based upon the tableau method. The features they
support, and evaluate:
• their expressivity in terms of the inferences they provide upon Tboxes and Aboxes,
• the advanced features they support for ontologies development,
• their access mechanisms for clients.
24

2.9.2.1 Pellet
Pellet 1 [47] is an open-source, description logic reasoning engine for sROIQ(D) models. sROIQ
supports qualifying number restrictions, role hierarchies, disjoint, inverse, reflexive and
irreflexive roles, and nominals. sROIQ(D) provides restrictions on integer and string datatypes,
and supports user-defined datatypes. The worst case complexity of the KB satisfiability
reasoning task in sROIQ has been proven to be NExpTime-hard [48].
All the reasoning services offered by Pellet are reduced to consistency checking which is
determined with tableau algorithms. The standard reasoning tasks are:
• Concept Satisfiability: it determines if a concept may be instantiated. Unsatisfiable
concepts result from modeling errors at the knowledge base, and therefore, detecting
them is the first step for the correction of these errors.
• Consistency Checking: it determines if the knowledge base contains any contradictory
definitions. Contradictions may occur because (i) an unsatisfiable concept has been
instantiated, (ii) an individual does not respect the number restrictions defined upon its
participating roles, or (iii) there are contradictions in the definition of concepts resulting
from the presence of nominal’s. Detecting the consistency of the knowledge base may
reveal modeling errors and illegal role assertions for individuals.
• Classification: it creates the hierarchy of concepts. The hierarchy is further used in other
retrieval mechanisms, like in getting all the concepts of an individual.
• Realization: it retrieves the direct concepts instantiated by an individual. It also supports
retrieval of individuals that satisfy certain criteria like participation in certain roles and
instantiation of indirect concepts.
Besides the above standard reasoning tasks, Pellet offers features that are not found often in other
reasoning engines. It allows the incremental update of the instances base (Abox). It keeps tracks
of the changes by indicating the dependencies between individuals and by updating them during
1
http://pellet.owldl.com
25

additions and deletions. Its technique presented in [49] is implemented upon the tableau decision
procedure for consistency checking in DL languages. It offers debugging of a knowledge base
providing explanations for the cause of unsatisfiable concepts [50]. It has new optimization
techniques for DL reasoning in presence of nominals [51], and supports reasoning both with
XML Schema data types and user defined ones.
It is implemented in Java and it provides a variety of communication interfaces: command-line
access, implementation of DIG 1.1 interface, bindings for OWL API and Jena interfaces, its own
Java API, and a Web-based access. Examples of its usage in tools for ontology editing and
querying are found in Protegè 4.0 and SWOOP.
Besides the above standard reasoning tasks, Pellet offers (i) incremental update of the instance
base [52], (ii) debugging through assertions [53], (iii) optimization reasoning techniques in
presence of nominal [54], and (iv) reasoning both with XML Schema and user defined data
types. Test cases in [55] show that RacerPro generally performs better. However, frequent
updates in the assertions increase the Pellet overall performance with respect to the RacerPro
system, since RacerPro builds the concepts hierarchy from scratch.
26

3. Semantics Web based Recommendation System
Semantic web based recommendation system in our work is the automatic processing of the
inference procedures provided by Pellet upon the formal representation of Web data semantics
with sROIQ(D) formulas, and the ease integration of such processing into the Web applications
execution without adding significant complexity in the designer’s tasks. For addressing the
usability requirement, we specify a set of components that are configurable upon the visual
specification of Web data semantics provided as UML class diagrams.
According to software engineering best practices, to simplify the design task of applications we
propose a set of reusable patterns for knowledge exploration and management that can be very
much useful for the recommendation. These patterns properly combine the components with the
aim of directly addressing the demands of real applications.
For the component and pattern we have got the core idea from the paper [1].
3.1 Components for Knowledge Representation
A component is a reusable software artifact that deals with one knowledge concept and allows us
to easily access and manipulate it. The knowledge concepts refer to a meta-conceptualization as
defined by the UML metamodel. Every component is defined upon one of the UML primitives of
Class, Datatype, Property, Generalization and Instance. Therefore, the configuration for a
component corresponds to a pattern upon a UML structure and its execution results to the
extraction or modification of the knowledge concept from the knowledge base in terms of UML
elements depicted in the UML model representing the Web data semantics. In case of a complex
pattern that manipulates UML elements described with different UML primitives, we combine
the corresponding components to properly propagate their values.
3.1.1 Class Component
The Class Component defines a set of extraction rules for retrieving UML classes. Concretely, it
explores the axioms in the knowledge base and deducts classes with selection conditions based
27

upon these axioms. If no selection condition is applied, it extracts all the classes in the
knowledge base.
ClassWithNominal
- PValue [1..*]: String
- BooleanOperator : String
create(): void
destroy(): void
set(s:String[], b: String): void
getClasses(): String []
ClassIsUnsatisfiable
- IsUnsatisfiable : Boolean
create(): void
destroy(): void
set(s:String): void
getClasses(): String []
0..1
0..1
1
1
Class Component
- Description [0..*] : String
- conjunction(s: String [][]) : String []
+ query(s: String[][]) : String []
1 1
1
1
1
1
0..1
0..1
ClassDomainOfProperty
- Property [1..*] : String
- BooleanOperator : String
create(): void
destroy(): void
set(s:String[], b: String): void
getClasses(): String []
ClassTypeOfProperty
- Property [1..*] : String
- BooleanOperator : String
create(): void
destroy(): void
set(s:String[], b: String): void
getClasses(): String []
ClassOfName
- Name [1..*] : String
0..1
create(): void
destroy(): void
set(s:String []): void
getClasses(): String []
ClassDisjointOfClass
- Class [1..*] : String
- BooleanOperator : String
create(): void
destroy(): void
set(s:String[], b: String): void
getClasses(): String []
0..1 0..1 0..1
ClassOfInstance
- Instance [1..*] : String
- BooleanOperator : String
create(): void
destroy(): void
set(s:String[], b: String): void
getClasses(): String []
ClassOfDirectInstance
- Instance [1..*] : String
- BooleanOperator : String
create(): void
destroy(): void
set(s:String[], b: String): void
getClasses(): String []
Figure 3.1: Class Component
The Class Component is depicted in figure 3.1 as a UML class diagram. Each composition
indicates a selection condition to be applied for the extraction of classes: ClassOfName extracts
classes by name, ClassDisjointOfClass extract the classes being disjoint to some values,
ClassDomainOfProperty and ClassTypeOfProperty extract the definition for the given
properties, ClassOfInstance and ClassOfDirectInstance retrieve the classes being instantiated
(indirectly or directly) by these values, ClassWithNominal extracts the classes containing the
given nominals, and ClassIsUnsatisfiable retrieves the classes that cannot be instantiated.
The invocation of the component is made with the query method defined in the Class Component
class receiving the selection values if any. The Class Component object is responsible to create
the objects of the necessary selection conditions, initiate their value, get the classes, and destroy
28

them by invoking respectively the create, set, getClasses, and destroy methods. In case a
selection condition is multi-valued, another parameter value indicates if the condition for a
retrieved element should be satisfied for every input value or for at least one. Both conjunctive
and disjunctive expressions are allowed.
u:User
>
c:ClassComponent
query([["Jackie Brown"], ["Horror Parody"])
set("Jackie Brown")
:ClassOfInstance
c1 = getClasses()
destroy()
set("Horror Parody")
:ClassDisjointOfClass
c2 = getClasses()
destroy()
classes
classes = conjunction(c1, c2)
Figure 3.2: Invocation of the Class Component
To exemplify the behavior of the component, figure 3.2 shows the UML sequence diagram
describing the extraction of classes both defining the Jackie Brown object and being disjoint to
the Horror Parody class. The user inserts the values as parameters to the query method through
the user interface. The Class Component object creates a new ClassOfInstance object and
initializes the condition value invoking the set method with Jackie Brown as parameter value.
Then, it calls the getClasses method to get the classes defining Jackie Brown, and it destroys the
selection condition object. The Class Component object creates the ClassDisjointOfClass object,
sets the condition value to Horror Parody, and gets the classes being disjoint to it. Finally, the
object component returns to the user the conjunction of the two result sets.
29

3.1.2 Datatype Component
Similarly to the Class Component, the Datatype Component explores the axioms in the
knowledge base and deducts UML datatypes either by name, by being disjoint to other datatypes,
by their defined properties, or by being instantiated by the condition values.
Figure 3.3: Datatype Component
A combination of the previous conditions extracts the corresponding data types satisfying all the
conditions. The Datatype Component is depicted in figure 3.3 as a UML class diagram.
3.1.3 Property Component
The Property Component defines a set of extraction rules for retrieving UML properties
(attributes and roles) from the knowledge base. The selection conditions to be applied are:
PropertyOfName extracts properties by name, PropertyDisjointOfProperty extracts the
properties being disjoint to some values, PropertyInverseOfProperty extracts the properties
being inverse to some values, PropertyWithDomain and PropertyWithType extract properties by
their defining classes/datatypes, PropertyWithPropertyValue retrieves the properties by their
values, PropertyIsTransitive retrieves the properties being transitive, PropertyWithCardinality
30

etrieves the properties by their cardinality values, PropertyIsDatatypeProperty retrieves the
properties of data values, and PropertyIsObjectProperty retrieves the properties of objects.
Figure 3.4: Property Component
3.1.4 Hierarchy Components
The Hierarchy components explore the inclusion axioms in the knowledge base regarding
hierarchies of UML classes or properties, and to deduct the taxonomy defined upon them. If no
selection condition is specified, they extract the complete taxonomy. Otherwise, they retrieve the
elements in the knowledge base (classes or properties) satisfying the corresponding inclusion
assertions.
The selection conditions for the Classes Hierarchy Component are the following: the
DirectSuperClass and SuperClass for extraction of the direct superclass (father) or all the
superclasses (ancestors) of the given classes; the DirectSubClass and SubClass for extraction of
the direct subclass (child) or all subclasses (descendants) of the given classes; the
MostGenericClass and MostSpecificClass for retrieving the most generic or the most specific
classes in the hierarchy. A combination of the previous conditions extracts the hierarchy
31

Figure 3.5: Hierarchy Component
fragment satisfying all the defined conditions. Analogous is the definition of the UML classes
representing selection conditions for the extraction of the property taxonomies.
3.1.5 Instance Component
The Instance component explores the axioms in the knowledge base regarding both UML data
values and object instances. The selection conditions to be applied are: InstanceOfName extracts
instances and values by name, InstancesOfClass and InstancesOfDirectClass extract the
instances/values by their defining classes/datatypes, InstanceWithPropertyValue extracts the
instances by the values they assume possibly on some properties, and InstanceOfPropertyValue
extracts the object of the indicated property values.
32

Figure 3.6: Instance Component
3.1.6 Property Value Component
The Property Value component explores the axioms in the knowledge base regarding both UML
data values and object instances filling the values for properties on instances or in class
Figure 3.7: Prperty Value Component
33

definitions. The selection conditions to be applied are: PropertyValueOfName extracts instances
and data values corresponding to the indicated value, PropertyValueOfProperty extract the
values being assigned to the given property, PropertyValueOnInstance extracts the values being
assumed on the given instance, and PropertyValueIsNominal extracts nominals, that is the values
contained in class definitions.
3.1.7 Explanation Component
The Explanation component explores the axioms in the knowledge base regarding either the
consistency of the knowledge base or the satisfiability for a given class, and gives explanations
in terms of assertions in case these entailments do not hold. Alternatively, it may be used for
giving explanations of axioms. If the axioms are asserted, no further explanations are provided.
Otherwise, if the axioms are inferred, the component invocation returns the asserted axioms
being responsible for the inferred ones.
3.8: Explanation Component
34

3.1.8 Add Components
The Add components create new axioms in the knowledge base regarding UML elements. Every
component is defined upon one of the UML primitives of Class, Datatype, Property,
Generalization, Slot, and Instance, and it is invoked for exactly one UML element instantiating
the UML primitive upon which the component is defined. It updates the knowledge base either
by inserting the UML element as new in case it does not already exist, by correlating the UML
element with other existing elements, or by a combination of both.
Figure 3.9: Add Component
The generic graphical depiction of an Add component is shown in figure 3.9. The component is
defined by the central Add Name Component UML class (main class), representing the main
UML primitive upon which the component is defined, and by a set of UML compositions
representing the relations of the main UML primitive with other UML primitives that may be
explored for the insertion of knowledge. There is one mandatory UML composition modeling the
(main) element instantiating the main UML primitive. In some cases, elements of the main UML
primitive are not first-class citizens in UML but are identified within the element that contains
them. In these cases, we have more than one parameter for the condition in the mandatory UML
35

composition. We depict the rest of UML compositions modeling the relations of the main
element with other UML elements.
Whenever an Add component is used, it is properly configured: the mandatory UML
composition is always present, only the optional compositions necessary for the use of the
component in the specific context are being added. We call these configured compositions
necessary parts for the specific component.
Whenever a configured Add component is invoked, a new object of the Add Name Component
UML class is created. The invocation of the component functionalities for the created object is
made with the execute(s: String[][]) method defined in the main class. Upon the method’s
invocation, the object communicates with the defined parts in order to update the knowledge
base. In particular, the object of the Add Name Component UML class is responsible for the
objects of the necessary parts: (i) their creation, (ii) the initialization of their condition values,
(iii) the creation of their axioms in the knowledge base, and (iv) their destruction, by invoking
respectively the create, set, execute, and destroy methods defined in the UML classes defining
the parts.
In the rest of this section, we graphically depict the add components only with the UML
compositions modeling insertion conditions. For having more readable figures, the operations are
not shown since they are the ones shown in figure 3.9.
3.1.9 Add Class Component
The Add Class Component creates new axioms in the knowledge base regarding UML classes. If
the insertion is about a new class, only its name is indicated as value to the component.
Otherwise, insertion conditions are also applied to the component to identify the elements in the
knowledge base upon which new axioms will be created.
The Add Class Component is depicted in figure 3.10 containing: the Add Class Component
UML class, a mandatory composing class modeling the name of the class for the component
(ClassOfName), and further optional composing classes modeling the insertion conditions. In
36

Add Class Component
ClassDisjointOfClass
1
0..1
- DisjointClass [1..*] : String
- Class : String
+ execute(s: String[]) : Boolean
1
1
1
0..1
create(): void
destroy(): void
set(s:String, c:String[]): void
execute(): Boolean
ClassOfName
- Name : String
1 0..1
create(): void
destroy(): void
set(s:String): void
execute(): Boolean
ClassSubOfClass
- SuperClass [1..*] : String
- Class : String
create(): void
destroy(): void
set(s:String, c:String[]): void
execute(): Boolean
ClassSuperOfClass
- SubClass [1..*] : String
- Class : String
create(): void
destroy(): void
set(s:String, c:String[]): void
execute(): Boolean
Figure: 3.10: Add Class Component
terms of UML classes, these are: ClassOfName (specifying the mandatory name of the
component class that should be inserted in the knowledge base), the ClassDisjointOfClass (for
inserting the class of the component as disjoint to the given values), ClassSubOfClass (for
inserting the class of the component as specific of the given values), and ClassSuperOfClass (for
inserting the class of the component as generic of the given values). A combination of the
previous conditions inserts all the corresponding axioms among the class of the component and
the elements identified by their values. The Add Class Component object is responsible for the
objects of the necessary parts, by invoking the create, set, execute, and destroy methods defined
in the UML classes.
3.1.10 Add Datatype component
Similarly to the Add Class Component, the Add Datatype Component inserts new axioms in the
knowledge base regarding UML datatypes. The insertion conditions are: DatatypeOfName
(specifying the mandatory name of the datatype that should be inserted in the knowledge base),
and DatatypeDisjointOfDatatype (for inserting the datatype of the component as disjoint to the
given values).
37

Figure 3.11: Add Datatype Compoment
3.1.11 Add Property component
The Add Property Component creates new axioms in the knowledge base regarding UML
properties (attributes and roles). UML properties are not first-class citizens but exist within the
defining object, therefore both the property and its defining class are parameter values for the
mandatory element for the component. The insertion conditions are: PropertyOfName
(specifying the mandatory name of the property that should be inserted in the knowledge base,
and the mandatory name of the class or datatype defining the property of the component),
Figure 3.12: Add Property Component
38

PropertyDisjointOfProperty (for inserting the property of the component as disjoint to the given
values), PropertyInverseOfProperty (for inserting the property of the component as inverse to
the given values).
3.1.12 Add Property Value component
The Add Property Value Component creates new axioms in the knowledge base regarding UML
slot values (both class objects and data values). UML slot values are not first-class citizens but
are defined for a given property, therefore the slot value, the class defining the property
assuming the value, and the property assuming the value are parameter values for the mandatory
element for the component. The insertion conditions are: PropertyValueOfValue (specifying: the
mandatory value of the property value, the mandatory name of the property that assumes the
property value, and the mandatory name of the class defining the previous property), and
PropertyValueOnInstance (for indicating the instance to be assigned with the property value of
the component). If a property value is added in the knowledge base without indicating the
instance to assume it, the value results to a nominal in a class definition.
Figure 3.13: Add Property Value Component
3.1.13 Add Instance component
The Add Instance Component creates new axioms in the knowledge base regarding UML
instances (class objects). The insertion conditions: InstanceOfName (specifying the mandatory
name of the instance that should be inserted in the knowledge base), and InstanceOfClass
(specifying the name of the classes instantiated by the instance of the component).
39

Figure 3.14: Add Instance Component
Similarly to the Add Class Component, the Add Datatype Component, Add Property Component,
Add Property Value Component, and Add Instance Component insert new axioms in the
knowledge base respectively regarding UML datatypes, properties, property values, and
instances. A mandatory insertion condition indicates the name of the datatype/ property/
propertyvalue/ instance to be inserted in the knowledge base. Further conditions may be applied
to specify related axioms that need to be inserted as well.
3.1.14 Remove Components
The Remove components remove existing axioms in the knowledge base regarding UML
elements. Similar to Add components, every component is defined upon one of the UML
primitives of Class, Datatype, Property, Generalization, Slot, and Instance, and it is invoked for
exactly one UML element instantiating the UML primitive upon which the component is
defined. It updates the knowledge base either by deleting the UML element and every axiom
defined upon it, or by disassociating the UML element from other existing elements.
The generic graphical depiction of a Remove component is shown in figure 3.15 and is
analogous to the one for Add components. The component is defined by the central Remove
Name Component UML class (main class), representing the main UML primitive upon which
the component is defined, and by a set of UML compositions representing the relations of the
main UML primitive with other UML primitives that may be explored for the insertion of
knowledge. There is one mandatory UML composition modeling the (main) element
instantiating the main UML primitive. In case the elements of the main UML primitive are not
40

first-class citizens, we have more than one parameter values for the condition in the mandatory
UML composition in order to identify the main element. We depict the rest of UML
compositions modeling the relations of the main element with other UML elements.
Figure 3.15: Remove Component
Whenever a Remove component is used, it is properly configured: the mandatory UML
composition is always present, only the optional compositions necessary for the use of the
component in the specific context are being added. We call these configured compositions
necessary parts for the specific component.
Whenever a configured Remove component is invoked, a new object of the Remove Name
Component UML class is created. The invocation of the component functionalities for the
created object is made with the execute(s: String[][]) method defined in the main class. Upon the
method’s invocation, the object communicates with the defined parts in order to update the
knowledge base. In particular, the object of the Remove Name Component UML class is
responsible for the objects of the necessary parts: (i) their creation, (ii) the initialization of their
condition values, (iii) the creation of their axioms in the knowledge base, and (iv) their
41

destruction, by invoking respectively the create, set, execute, and destroy methods defined in the
UML classes defining the parts.
Also in this case, we graphically depict the remove components only with the UML
compositions modeling deletion conditions.
3.1.15 Remove Class component
The Remove Class Component deletes axioms in the knowledge base regarding UML classes.
The deletion conditions: ClassOfName (specifying the mandatory name of the class of the class
that should be deleted in the knowledge base), ClassDisjointOfClass (for deleting the class of the
component as being disjoint to the given values), ClassSubOfClass (for deleting the class of the
component as specific of the given values), and ClassSuperOfClass (for deleting the class of the
component as generic of the given values).
Remove Class Component
+ execute(s: String[]) : Boolean
1
1
ClassOfName
- Name : String
create(): void
destroy(): void
set(s:String): void
execute(): Boolean
1
1
1
0..1
ClassSubOfClass
- SuperClass [1..*] : String
- Class : String
create(): void
destroy(): void
set(s:String, c:String[]): void
execute(): Boolean
0..1
0..1
ClassDisjointOfClass
- DisjointClass [1..*] : String
- Class : String
create(): void
destroy(): void
set(s:String, c:String[]): void
execute(): Boolean
ClassSuperOfClass
- SubClass [1..*] : String
- Class : String
create(): void
destroy(): void
set(s:String, c:String[]): void
execute(): Boolean
Figure 3.16: Remove Class Component
3.1.16 Remove Datatype component
The Remove Datatype Component deletes axioms in the knowledge base regarding UML
datatypes.
42

Figure 3.17: Remove Datatype Component
The deletion conditions: DatatypeOfName (specifying the mandatory name of the datatype that
should be deleted from the knowledge base), and DatatypeDisjointOfDatatype (for deleting the
datatype of the component as being disjoint to the given values).
3.1.17 Remove Property component
The Remove Property Component deletes axioms in the knowledge base regarding UML
properties (roles and attributes).
Figure 3.18: Remove Property Value Component
43

The deletion conditions are: PropertyOfName (specifying the mandatory name of the property,
and the mandatory name of the class or datatype defining the property of the component),
PropertyDisjointOfProperty (for deleting the property of the component as disjoint to the given
values), PropertyInverseOfProperty (for deleting the property of the component as inverse to the
given values), PropertyOfType (for deleting the property of the component as having type the
given values), PropertySubOfProperty (for deleting the property of the component as specific of
the given values), PropertySuperOfProperty (for deleting the property of the component as
generic of the given values), PropertyWithCardinality (for deleting the property of the
component with minimum and maximum cardinality the given values), and PropertyIsTransitive
(for deleting the property of the component as being transitive).
3.1.18 Remove Property Value component
The Remove Property value Component deletes axioms in the knowledge base regarding UML
property values. The deletion conditions: PropertyValueOfValue (specifying the mandatory The
Remove Property value Component deletes axioms in the knowledge base regarding UML
property values. The deletion conditions: PropertyValueOfValue (specifying the mandatory
name of the property value, the mandatory name of the property assuming the property value of
the component, and the mandatory name of the class defining the previous property),
PropertyValueOnInstance (for deleting the given instances as having value the property value of
the component).
Figure: 3.19: Remove Property Value Component
44

3.1.19 Remove Instance component
The Remove Instance Component deletes axioms in the knowledge base regarding UML
instances (class objects). The deletion conditions are: InstanceOfName (specifying the
mandatory name of the instance), and InstanceOfClass (for deleting the given classes as being
instantiated by the instance of the component).
Figure 3.20: Remove Instance Component
3.2 Knowledge-base Management Components
3.2.1 Create-KB component
Further components are defined for managing the knowledge base contents as a whole. The
Create-KB Component creates a new empty knowledge base instance that will be the container
for the data semantics. Yet, no schema is defined for the knowledge base. This component does
not accept any parameters. Upon successful invocation, the component returns the identifier of
the newly created knowledge base.
Figure 3.21: Create-KB Component
45

3.2.2 Release-KB component
The Release-KB Component releases an instantiated knowledge base, referred through its
identifier. Upon successful invocation, the component returns the identifier of the deleted
knowledge base. Subsequent attempts of interaction with the knowledge base will raise an
exceptional situation.
Figure 3.22: Release-KB Component
3.2.3 Import-XMI-to-KB component
The Import-XMI-to-KB Component creates both schema and instances for an existing knowledge
base in the Pellet repository. Schema and instances are extracted from an XMI file serializing a
UML model (class and object diagram). The component indirectly translates UML elements to
Description Logic formalisms. This operation works only if the mandatory parameters KB and
XMI are correctly set. Upon successful invocation, the component returns the identifiers of the
inserted objects in the knowledge base.
Figure 3.23: Import XMI to KB Component
46

3.2.4 Export-XMI-from-KB component
The Export-XMI-from-KB Component exports the knowledge base schema and instances to an
XMI file serializing a UML model. The KB and XMI parameters are mandatory indicating the
identifier of the knowledge base to be exported and the destination XMI file.
Figure 3.24: Export Xmi to KB Component
3.3 Patterns for Knowledge Exploration and Management
3.3.1 Knowledge Exploration
The patterns for knowledge exploration are built on top of the exploration components and
express simple but useful queries often found in the field of knowledge deduction.
• Class and its classification;
• Properties of a class;
• Instantiated classes;
• Instances of a class assuming known values on known properties;
• Instances of a class assuming any value on a known property;
• Instances of a class assuming known values on any property;
• Instances of a class assuming any value on any property;
• Instances of a class assuming values of known type on any property;
47

These patterns do not have side effects on the knowledge base. Whenever it is necessary, we
exploit the UML utility class Complex Query to transfer values from one component to another.
The role of this class is to orchestrate the invocation of the methods in the pattern. Its
configuration determines the methods invocation order (possibly including looping and
conditional execution), thus eliminating the burden of controlling the flow of components
execution.
3.3.1.1 Class and its classification pattern
This pattern checks the existence of a class in the knowledge base and deducts the hierarchy of
generalizing classes. It encompasses two exploration components (figure 3.25): (i) the Class
Component configured with a ClassOfName selection condition to retrieve the class
corresponding to the input, and (ii) the Classes Hierarchy Component configured with a
ClassOfSubClass condition to deduct the hierarchy above the previous class. The input received
by the user invoking the execute method is transferred to the Class Component; the deducted
class becomes the input for the Class Hierarchy Component, while both the class and the
retrieved hierarchy are returned to the user. The pattern is defined as the one extracting the
specializing class hierarchy for a given input.
This pattern may be used whenever the user needs to analyze a specific class and its generalized
classes.
Figure 3.25: Class and its classification
48

3.3.1.2 Properties of a class pattern
In this pattern, the user requests the properties defined in a given class and the respective type
restrictions. It encompasses (figure 3.26): (i) the Property Component configured with a
PropertyWithDomain selection condition for retrieving the properties of the class specified by
the user, and (ii) the Class Component configured with a ClassTypeOfProperty selection
condition to deduct the class type restrictions of one property. The Complex Query is configured
to repeatedly invoke the query method of the second component: the Class Component is
invoked once for each property found in the input class. Finally, the result set returned to the user
by the Complex Query contains for each property the retrieved typed classes.
Figure 3.26: Properties of a class pattern
3.3.1.3 Instantiated classes Pattern
This pattern checks the existence of classes in the knowledge base and deducts those that have at
least one instance. It encompasses two exploration components: (i) the Instance Component
configured with no selection conditions to retrieve all the instances in the knowledge base, and
(ii) the Class Component configured with a ClassOfInstance selection condition and the
BooleanOperator OR to retrieve the classes being instantiated by at least one of the previous
instances. The Complex Query class invokes the query component methods controlling the flow
of information: no input is transferred to the Instance Component, the deducted instances become
the input for the Class Component and the BooleanOperator is set to OR, and finally, the
deducted classes are returned to the user.
49

Figure 3.27: Instantiated classes Pattern
3.3.1.4 Instances of a class assuming known values on known properties Pattern
This pattern checks the existence of property values in the knowledge base, deducts those that
have known property values being assumed to known properties, and then extracts the instances
being assigned with these properties values. It encompasses two exploration components: (i) the
Property Value Component configured with a PropertyValueOfName and a
PropertyValueOfProperty selection conditions with BooleanOperators OR to retrieve the
property values of interest in the knowledge base, and (ii) the Instance Component configured
with a InstanceOfClass and a InstanceWithPropertyValue selection conditions and the
BooleanOperator OR to retrieve the instances having at least one of the previous property
values. The Complex Query class invokes the query component methods: the property and the
given value input is transferred to the Property Value Component, the class input and the
deducted property values become the input for the Instance Component, and finally, the deducted
instances are returned to the user.
Figure 3.28: Instances of a class assuming known values on known properties Pattern
50

3.3.1.5 Instances of a class assuming any value on a known property Pattern
This pattern checks the existence of property values in the knowledge base, deducts those that
have being assumed to known properties, and then extracts the instances being assigned with
these properties values. It encompasses two exploration components: (i) the Property Value
Component configured with a PropertyValueOfProperty selection condition with
BooleanOperator OR to retrieve the property values of specific properties in the knowledge base,
and (ii) the Instance Component configured with a InstanceOfClass and a
InstanceWithPropertyValue selection conditions and the BooleanOperator OR to retrieve the
instances having at least one of the previous property values. The Complex Query class invokes
the query component methods: the property input is transferred to the Property Value
Component, the class input and the deducted property values become the input for the Instance
Component, and finally, the deducted instances are returned to the user.
Figure 3.29: Instances of a class assuming any value on a known property Pattern
3.3.1.6 Instances of a class assuming known values on any property Pattern
This pattern checks the existence of property values in the knowledge base, deducts those with
known values not being restricted by the properties on which they are assigned, and then extracts
the instances being assigned with these properties values. It encompasses two exploration
components: (i) the Property Value Component configured with a PropertyValueOfName
selection condition (implicit BooleanOperator OR) to retrieve the property values of specific
value in the knowledge base, and (ii) the Instance Component configured with a InstanceOfClass
and a InstanceWithPropertyValue selection conditions and the BooleanOperator OR to retrieve
the instances having at least one of the previous property values. The Complex Query class
51

invokes the query component methods: the value input is transferred to the Property Value
Component, the class input and the deducted property values become the input for the Instance
Component, and finally, the deducted instances are returned to the user.
Figure 3.30: Instances of a class assuming known values on any property Pattern
3.3.1.7 Instances of a class assuming any value on any property Pattern
This pattern checks the existence of property values in the knowledge base and deducts the
instances to which they are being assigned. It encompasses two exploration components: (i) the
Property Value Component configured with no selection condition to retrieve all the property
values in the knowledge base, and (ii) the Instance Component configured with a
InstanceOfClass and a InstanceWithPropertyValue selection conditions and the
BooleanOperator OR to retrieve the instances having at least one of the previous property
values. The Complex Query class invokes the query component methods: no input is transferred
to the Property Value Component, the class input and the deducted property values become the
input for the Instance Component, and finally, the deducted instances are returned to the user.
Figure 3.31: Instances of a class assuming any value on any property Pattern
52

3.3.1.8 Instances of a class assuming values of known type on any property Pattern
This pattern checks the existence of property values in the knowledge base assumed by
properties of a known type. Then it deducts the instances to which they are being assigned. It
encompasses three exploration components: (i) the Property Component configured with a
PropertyWithType selection condition to retrieve the property with the given type in the
knowledge base, (ii) the Property Value Component configured with a PropertyValueOfProperty
selection condition to retrieve the property values being assumed by the previous properties, and
(iii) the Instance Component configured with a InstanceOfClass and a
InstanceWithPropertyValue selection conditions and the BooleanOperator OR to retrieve the
instances having at least one of the previous property values. The Complex Query class invokes
the query component methods: the type input is transferred to the Property Component, the
deducted properties are transferred to the Property Value Component, the class input and the
deducted property values become the input for the Instance Component, and finally, the deducted
instances are returned to the user.
Figure 3.32: Instances of a class assuming values of known type on any property Pattern
3.3.2 Knowledge Management
The patterns for knowledge management are built on top of the management components for
creating new UML elements or for removing existing ones under certain conditions. The
execution of these patterns has side effects on the knowledge base. Like in the case of
exploration patterns, values are transferred from one component to the other either with user
intervention or automatically. In the latter case, the methods invocation is done by the UML
53

class called Complex Operation. Its configuration may include programming language constructs
like loop and conditional execution for controlling the flow of components execution.
Typically, the invocation of a management pattern usually follows the execution of an
exploration pattern, because the user has to evaluate the status of the knowledge base before
wanting to apply changes.
3.3.2.1 Add a new instance as property value for another instance pattern
This pattern is used to insert a new instance in the knowledge base and to indicate it as the
property value for another instance. It may be used when it is necessary to make explicit the
correlation of two instances whenever such correlation does not derive from their definitions.
The pattern encompasses: (i) the Add Instance Component configured with a InstanceOfName
condition (to insert the first user input in the knowledge base as a new instance) and with a
InstanceOfClass condition (to define the class instantiated by the instance), and (ii) a second Add
Property Value Component configured with a PropertyValueOnInstance condition and with a
PropertyValueOfValue condition (to indicate that the previous instance is a value for the second
user input). In this case, a Complex Operation controls the flow of information: part of the input
sent by the user is transferred to the Add Instance Component; the created instance and the
remaining user input become the input for the Add Property Value Component. Finally, the
Complex Operation returns the outcome of the whole pattern.
Figure 3.33: Add a new instance as property value for another instance pattern
54

3.3.2.2 Remove property value for an instance
This pattern removes from the knowledge base the property value assigned to a class object. It
encompasses only the Remove Property Value management component, and therefore, there is
no need to involve the Complex Operation class since no automatic components interaction takes
place. The user submits the property value and the instance containing it and the component is
configured with: (i) a PropertyValueOfValue insertion condition to indicate the property value
specified by the first user input; and (ii) a PropertyValueOfInstance insertion condition to
remove the axiom indicating the previous property value assigned to the second user input.
3.4 Social Network Application
In our application we have proposed a social network application with recommendation feature
and also other features. In this application we have developed an automatic recommendation
system. This will recommend to the User about different interesting topics. If a User is a Group
Member he can get some recommendation from the system based on the other Group Members
interests. When a User browses interesting topics, he will get a recommendation about topics
based on his previous interests. We will see the details specification in the next section.
3.4.1 Use Cases of the Application
In this section, we have described the UML Use Case diagram for the social network application.
Here, a User or a Group Member is an Actor. Sometimes the system works as an Actor. A User
may be a Group member. But it is not necessary that every User has to be Group member.
55

Figure 3.34: Use Case diagram of the application
56

3.4.2 Application Specification
In this section we will specify each scenario according to the use case diagram of the application.
We divide the total use case into two main site views. User site view and Group site view. We
have shown each site view in several small scenarios such as View Personal Information, Send
Friend Invitation and so on. Here, ‘Object’ defines the classes and ‘Action’ defines the
functionalities.
3.4.2.1 User Site View
View Personal Information
Actor: User
Object: User/Friend/GroupMember, Interest, Recommendation
Action
• View: User can view his/her own personal information.
• Modify: User can modify his/her own personal information.
• Add New: User can add new personal interest in his/her profiles. Ex. add new movie,
novel etc.
• Delete: User can delete any information or interest from his/her profile.
Send Friend Invitation
Actor: User
Object: User, Invitation
Action
• Send Invitation: User can send Friend Invitation to other User. The invited User can
review this Invitation and can accept or deny the Invitation.
Review Friend Invitation
Actor: User
Object: User, Friend
57

Action
• Review: User will review the Invitations received from other Users. An User can accept
or deny the Friend Invitation. If the invited User accepts the Invitation they become
Friends.
Review Group Invitation
Actor: User
Object: User, Group, GroupMember
Action
• Review: User will review the Group Invitation send by the Group Member. User can
accept or ignore the Invitation. After accepting the Invitation the User will become the
Group Member of that Group.
Create Group
Actor: User
Object: User, Group, GroupMember
Action
• Create: User creates a new Group and the User becomes the Group Member of the
Group.
Create Interest
Actor: User
Object: User, Interest, InterestTopic
Action
• Create: User creates a new Interest in his/her profile.
View Notification
Actor: User
Object: GroupMember, Group, Notification
58

Action
• View Notification: Group Member will view the notification of the Group. The Members
will be notified when an Article is posted, when a new event is created or any message is
send to the Group Members (group message) by a Group Member.
Friend Recommendation
Actor: System
Object: Recommendation, RecommendedFriend, User
Action
• Recommended Friend: The system will recommend a user to another user based on
profile matching or interest matching between them. Ex. Live in same place, love same
types of music etc. For example, suppose there are two users in the system U1 and U2
and both of them have interest in same type of music. In this case the system will
recommend U1 to become friend of U2 and vice versa.
Group Recommendation
Actor: User
Object: Recommendation, Group Recommendation, User
Action
• Recommended Group: The system will recommend a Group to a User based on Interest
of the User which is similar to the activities (event, article etc) of a Group. For example,
there is a group called G1 which has several group members. Also there is a user called
U1 who is not a member of G1. U1 have Interest in “Rock” music. And G1 is a Group of
music lovers. In G1, there are some articles/events about “Rock” music. The system will
recommend the U1 to become a Group Member of G1.
Topic Recommendation
Actor: User
Object: Recommendation, Topic, User
59

Action
• Recommended Topic: The system will recommend a topic (an event or an article) to a
user based on interest of the user which is similar to the activities (event, article etc) of a
Group. For example, we have a group G1 and a user U1. U1 is not a member of G1. In
G1 there is an article/event published that there will be a “Jazz” concert in Milan. And
U1 lives in Milan. So, the system will Recommend the U1 for the concert as the U1 also
have Interest on “jazz” music.
3.4.2.2 Group Site View
Create New Event
Actor: Group Member
Object: GroupMember, Group, Event
Action
• Create New Event: Group Member will create a new event in the Group. All the other
Group Members will be notified about the new event.
Post New Article
Actor: Group Member
Object: GroupMember, Group, Article
Action
• Create New Article: Group member will post a new article in the group. And all the
group members will be notified about the new article.
Send Group Message
Actor: Group Member
Object: GroupMember, Group, GroupMessage
Action
• Send Group Message: Group Member will send message to all the Members of the
Group.
60

Send Group Invitation
Actor: Group Member
Object: GroupMember, Group, User, Invitation
Action
• Send Group Invitation: Group Member will send Group Invitation to a User. If the User
accepts the Invitation the User will become the Group Member of that Group.
3.4.3 Application Design
A User can create a Group. He can invite other Users to become Group Members. He may have
different activities in the Group. A User can have several interests which can be the
Recommended Topic for the other User of the same Group. A Group Member can Post a Group
Message or can create an Article or an Event. Other Group Member will get the notification
message. Interesting Article can be shown as a Topic Recommendation to the other user. Figure
3.35 is the details diagram of the network.
Using patterns and components we can build different types of recommendation. In this
application a User play the main role. A user may have several friends through the Friend class.
An User may have several friends. A user can become friends by accepting the Friend Invitation
which sent by the other User.
A User can create a Group. And he can invite other Users to become Group members. He may
have different activities in the Group. A User can have several interests which can be the
Recommended Topic for the other User of the same Group. A Group Member can Post a Group
Message or can create an Article or an Event. Other Group Member will get the notification
message. Interesting Article can be show as a Topic Recommendation to the other user.
61

Figure 3.35: Social Network Application
62

A user can recommend friend as Friend Recommendation to the other User. Comparing with the
common interest a Group can be recommended as a Group Recommendation. When a user will
browse interesting movie the system will recommend him certain genre of movie according to
his previous interest.
3.4.4 Uses of Components and Patterns in the Recommendation Application
An User can add a new interest. Using the “Instances of a class assuming any value on a known
property” we can identify his membership for a particular Group. Then we can recommend all
other members of the group about first user’s interest.
Figure 3.36: WebML hypertext for Recommendation
63

When a user browse movies, using the “Instances of a class assuming any value on a known
property” we can identify what kinds of movie he likes before, by checking his interest on
movie. And then Using the “Class and its classification” pattern we can recommend him some
movies which is the same genre of his previous interest.
In figure 3.36 shows the WebML hypertext view of the recommendation. Using the “Class and
its classification” pattern we are showing list of movies by genre and also novel by types. We are
using Class Hierarchy Unit and Class unit to build the pattern. If we click “Add as Interest” link
then the interest will be added in the User profile. From the ‘Get unit’ we will get the current
User instance. Using the “Instances of a class assuming any value on a known property” we
identify what kinds of movie he likes before, by checking his interest on movie and also about
the novel. Then the system will recommend him about the same genre movie or same types of
novel.
Figure 3.37: Movie and Novel Recommendation
64

In the figure 3.37, a User browsing interests to add his interest list. The system is recommending
him movies and novels according to his previously added interest. His interest list has a movie
called ‘La vita e bella’ which is an Italian movie. So after checking the genre the system
recommends him another Italian movie called ‘Malena’. In the same way the system recommend
him the novel called ‘The old man and the sea’ which belongs to the same writer of ‘For Whom
the Bell Tolls’ he already added in his interest list.
In the next section we will see the complete development of the application.
65

4. Implementation Experience
The concepts presented so far have been implemented in the context of the WebML 2 design
approach [3]. While other implementation approaches could have been followed, the one based
on WebML seemed to be the more convenient and productive. Indeed, other existing UML
C.A.S.E. tools would have been less effective, since they could have helped in producing the
Java code of the components by providing only a set of interfaces and / or stub classes, while all
the coding of the business logics and of the front end Web application would have been manual.
Vice versa, thanks to the WebML model and associated design tools, the components can be
quickly designed and integrated in the visual design of the Web application, whose code can then
be automatically generated. The conceptual components specified in Section 3 have been
implemented once and for all as WebML primitives, which can be reused in the design. A set of
WebML modeling and code generation facilities take care of the Web page implementation of
the method invocations, and of the parameters between components.
4.1 WebML and WebRatio background
This Subsection summarizes the basic concepts of WebML and WebRatio that are needed for
understanding the extensions that have been devised in this work. WebML is a Domain Specific
Model for Web application design and development. It allows specifying the conceptual
modeling of Web application hypertexts (site views) built on top of a content model of the
application data. A site view is a graph of pages. Pages consist of connected units, representing
at a conceptual level the publishing primitives that extract content from the database: a unit
displays instances of an entity, possibly restricted by a selector. Units are related to each other
through hypertextual links, representing navigational paths and carrying data from a unit to
another. WebML allows specifying also operations updating the underlying data or performing
other actions.
2 http://www.webml.com
66

Through the entry unit in figure 4.1 we can create new user on the social network. When the user
presses the submit button, chain of operations is triggered: a new user instance is created and add
a property value to the instance called ID.
Figure 4.1: Example of WebML hypertext specification
The example in figure 4.2 shows the WebML model of a page called Create New Group,
allowing the user to create a new group. Through the entry unit the user can create a group in the
social network. The get unit retrieves the data of the current user from the session. When the user
submits, a chain of operations is triggered: a new Group instance is created and also add its
property and is associated to the current user (relationship creator, member) and to the current
Group (relationship membership, creation).
The WebML language is extensible, allowing for the definition of customized operations and
units. The WebML models are provided with primitives for representing Web Services
interactions [56][57], workflows constraints [58], context-aware behavior [59], and Semantic
Web Services [60]. WebML has been implemented in the tool WebRatio 3 [61], a C.A.S.E.
3 http://www.webratio.com
67

environment for the visual design of Web applications and the automatic generation of code for
the J2EE platform.
Figure 4.2: Example of WebML hypertext specification
The tool supports the development phases:
• Data Design (E-R or UML models);
• Hypertext Design (WebML models);
• Presentation Design of the hypertext look-and-feel;
• Mapping of the data model to a relational database;
• Automatic Hypertexts Implementation and Documentation (queries, update statements,
Web Service calls, page templates).
The architecture of WebRatio features: the integrated development environment for the
application models design; the code generator for the translation of the models to application
code by means of XSL and Groovy transformations; and the runtime package encompassing the
application code and external libraries for the deployment of the Web application upon J2EE
platforms, according to the MVC 2 pattern. It also allows new components to be plugged in as
WebML custom units [62].
The following Subsections present the extensions of the runtime architecture and the new
WebML components that have been devised for implementing the framework.
68

Figure 4.2: Example of WebML hypertext specification
4.2 Runtime Architecture of the Framework
We have implemented the execution of the existing framework in the context of the WebRatio
runtime architecture, extended to include interactions with the knowledge base. Figure 4.3
depicts the new architecture, where white boxes show the WebRatio existing components, blue
components are provided by the reasoner, and the yellow ones represent the runtime elements of
the framework.
The resulting architecture still follows the MVC2 architectural pattern, and comprises: (i) the
Web-based interfaces delivering the knowledge exploration and management functionalities, (ii)
the framework logic implementing these functionalities, (iii) the user interactions with the
framework, and (iv) the business logic providing access to the knowledge base and the XMI files
of UML models. This differentiates from the traditional MVC2 architecture because of (i) the
knowledge layer incorporating the knowledge base managed by the Pellet reasoning engine; and
(ii) the data layer containing only XMI files serializing the UML data models used by the
framework.
Notice that the framework logic is decoupled from the knowledge access and the data access by
introducing business logic services that are responsible to interact with Pellet and with the UML
69

serializations. Such separation grants the independence from the specific reasoning engine and
from the UML serialization format.
Controller
(Servlet)
Actions
(Java classes)
Page Services
(Java classes)
Knowledge Base Interface
(Java)
Web
browser
WEB
Web
server
View
(JSP)
State Objects
(Java)
Knowledge
Exploration
Unit Services
(Java classes)
Tableau
Reasoner
Internalization
TBox
Absorption
Symbols
Components Interaction
HTTP/SOAP messages
Component
Servlet Container
Knowledge
Management
Operation Services
(Java classes)
Business Logic
Service
Species Validation &
Ontology Repair
Knowledge Layer - Pellet
XMI
Subcomponent
Application Server
Data Layer
Figure 4.3: Runtime architecture for the framework
4.3 Implementation of Components
As we have mentioned earlier, the framework components are specified as new WebML
primitives. For their implementation we exploit the WebRatio plug-in mechanism, which allows
to define new units and to seamlessly integrate them in the design and execution of the
applications. In the following we describe the list of new WebML units that have been defined as
implementations of the components discussed in Section 3.
4.3.1 Content publishing units
The Hierarchy, Class, Datatype, Property, Property Value, Instance, and Explanation
components are implemented as content units. The UML classes acting as selection conditions
for the corresponding UML component are defined for the respective content unit, with values
being parametric on the user choices. The units produce in output the names of the deducted
elements. Table 4.1 summarizes the Hierarchy components together with their symbol, the
expected inputs and delivered outputs. The remaining exploration components are summarized in
table 4.2.
70

Description
Classes
Hierarchy Unit
Properties
Hierarchy Unit
Input: optional class names to be used at the selection conditions
Output: structured set of class names
Input: optional property names to be used at the selection conditions
Output: structured set of property names
Table 4.1: WebML hierarchy components
Description
Class Unit
Datatype Unit
Property Unit
Instance Unit
Explanation
Unit
Property Value
Unit
Input: optional names for (disjoint) classes, typed instances, defined
properties
Output: set of class names
Input: optional names for datatypes, defined properties, and values
Output: set of datatype names
Input: optional names for (disjoint, inverse) properties, assigned instances,
defining classes and datatypes
Output: set of property names
Input: optional names for (assigned) instances, defining classes
Output: set of instance names
Input: optional names for classes, properties, instances
Output: set of assertions retrieved
Input: optionnal parameter for the evaluation of datatypes, defined
properties, values
Output: set of property values deducted
Table 4.2: WebML exploration components
4.3.2 Content management operations
The content management components are implemented as WebML operation units. The
implementation consists of pieces of code analogous to the publishing content units. A first set of
71

components (Table 4.3) is implemented for managing the whole knowledge base content
(Create-KB, Release-KB, Import-XMI-to-KB, Export-XMI-from-KB). Those for
adding/removing individual knowledge are implemented are summarized respectively in table
4.4 and table 4.5.
Create KB Unit
Output: OK-link transfers the identifier of the created knowledge
base instance. KO-link transfers the error code.
Release KB Unit Input: mandatory identifier of the knowledge base instance to be
deleted.
Output: OK-link: identifier of the deleted knowledge base instance.
KO-link: error code.
Import XMI to KB Unit Input: mandatory identifiers of the knowledge base instance and of
the XMI file to be imported.
Output: OK-link: set of imported axioms. KO-link: error code
Export KB to XMI Unit Input: mandatory identifier of the knowledge base instance to be
exported and mandatory XMI file.
Output: OK-link: set of exported axioms. KO-link: error code
Table 4.3: WebML manage knowledge base components
Description
Output: OK-link: set of added axioms. KO-link: error code
Add ClassAxiom
Add DatatypeAxiom
Add PropertyAxiom
Add InstanceAxiom
Input: mandatory name for class, optional names for disjoint classes,
defined instances and properties.
Input: mandatory name for datatype, optional names for defined
properties and values.
Input: mandatory name for property, optional names for disjoint and
inverse properties, assigned instances, defining classes and datatypes.
Input: mandatory name for instance, optional names for assigned
instances and defining classes.
72

Add
PropertyValueAxiom
Input: mandatory name for property value parameter, optional
parameters for the insertion of assuming instances, defined properties
Table 4.4: WebML add axiom components
Description
Output: OK-link: set of removed axioms. KO-link: error code
Remove ClassAxiom Input: mandatory name for class, optional names for disjoint classes,
defined instances and properties
Remove Input: mandatory name for datatype, optional names for defined
DatatypeAxiom properties and values
Remove Input: mandatory name for property, optional names for disjoint and
PropertyAxiom inverse properties, assigned instances, defining classes and datatypes
Remove Input: mandatory name for instance, optional names for assigned
InstanceAxiom instances, defining classes
Remove Input: mandatory name for property value parameter, optional
PropertyValueAxiom parameters for the deletion of assuming instances, defined properties
Table 4.5: WebML remove axiom components
4.3.3 Implementation
For each of the above units, the implementation within the WebRatio environment comprises the
development of the following elements:
• The design-time XML descriptor, defining the unit name, the selection conditions that
may be attached, and the acceptable links.
• The Groovy transformations for automatically generating the unit runtime XML
descriptor, which specifies the knowledge objects to be queried/updated.
• The XSL transformations for automatically generating the unit custom tags for formatting
the unit content in the JSP templates that contain it.
• The Java class implementing the functionality delivered by the operation. Its code calls
the appropriate Pellet API methods for knowledge inference and manipulation.
73

4.4 Implementation of Patterns
The WebRatio tool simplifies the implementation of the framework patterns. The designer can
combine the designed WebML components according to the pattern specification.
Figure 4.4: WebML class and its classification hypertext
Figure 4.4 depicts a WebML site view that implements the WebML modified of the
“Instantiated classes” pattern described in Section 3. The User Profile page displays the lists of
Friends and Interests of the WebML model, lists of Groups and Recommendation. By selecting
an Accept Recommendation from the Recommendation unit, the user can add Recommended
topics to his Interests page. By selecting a View Group Activities, the user navigates to the
Group page, where the Group Activities shown.
The whole application code is automatically generated (page templates and XML descriptors)
from the WebML model. Figure 4.5 depicts the implemented Recommendation page of figure
74

4.4. The top segment of the page is showing current user’s personal information, his/her interest
and recommendation based on user’s group activities. Below it is showing user’s friends list and
list of groups the user is member of.
Figure 4.5: User Profile Page with Recommendation
The knowledge management hypertext that enables the creation of the knowledge schema from a
UML class diagram and of knowledge instances from object instances is shown in figure 4.6.
Set KB
Home Page
Knowledge Base
Page
Load XMI
xmi
Create KB
kb, xmi
OK
OK
ImportXMI2KB
XMI
KB
KO
Error Page
KO
[KB=kb]
[XMI=xmi]
Figure 4.6: WebML hypertext for creating the KB
75

In the Knowledge Base page the user uploads the XMI description of the domain model through
a form. Upon submission, the Create-KB operation creates the knowledge base and the Import-
XMI2KB inserts the XMI specification of the UML model into the knowledge base. Its contents
are inserted as description logic axioms. Finally, the Set-KB unit stores the newly created
knowledge base identifier in the HTTP session.
4.5 Application Implementation
According to the specification and design we have implemented the application in WebRatio.
Knowledge schema creation in the WebRatio environment is shown in figure 4.7. Here the red
line indicates KO link, it will fire if any error occurs. The green line indicates OK link. In the
Entry page there is a KB Entry Unit, which will take the XMI description of the domain model.
And it will work in the same way that we have described in the previous section.
Figure 4.7: WebML hypertext for creating the KB in WebRatio
In figure 4.8 shows in the browser, the “Entry Page” for KB creation. In the text box (named
KB), we will insert the XMI description of the model and then press the ‘Create’ button and it
will create the Knowledge Schema. If the procedure work successfully then it will go to the next
76

page otherwise it will go to the error page. And when we press ‘SaveXMI’ button it will export
the XMI specification of the UML model into the knowledge base.
Figure 4.8: HTML view for creating the KB
After click on the link “View User” from the home page we can view the total list of available
User’s in the application. Figure 4.9 is showing the WebML view of such instance and figure
4.10 is showing the HTML view. We have used Instantiated class pattern here.
Figure 4.9: WebML in WebRatio for View User
77

Figure 4.10: HTML view for View User
After click in the link ‘User Profile’, in the figure 4.10, we can view full information of an User.
Figure 4.11 shows the WebML view and figure 4.12 shows the HTML view of the User
Information. We are performing some filtration to show specific information as a output.
Figure 4.11: WebML view for User Information
78

We are showing current user’s information as we stored the current user using the “Set Unit”.
We are using this information to load the instances of current user. We are using several property
value units to show Group membership, Address, Email, Friend list, Interest list and also the
Recommendation. When the User instance will load, in the same time all the property values will
be loaded. The property values will get instance by the transition link.
Figure 4.12 is showing user’s (in this case the user is ‘Roni’) personal information such as id,
email, address, city, country as well as the list of his interest that the user has added. Also the
user can view his available friends list and the list of the groups that he is member of. To view
the details activities of a specific group the user has to click on the ‘View Group Activities’ link
beside the group name.
Figure 4.12: HTML view for User Information
79

The user can add a new interest in his interest list by clicking on the “Add Interest” link on the
top right corner of the page. Also he can review the invitations sent from any group or sent by
another user by clicking on “View Invitation” link.
The user can also view the recommended information from the group. This information will be
available on the current user’s profile page when the current user is a member of a group and
another member from the same group added any interest to his profile. The system will
automatically recommend this information to the current user as “Recommendation from
Group”. The current user can accept this as his personal interest also by clicking on the “Accept”
link.
Figure 4.13 is showing the step by step procedure of sending a friend invitation to another user
in WebML perspective. After inserting the information corresponding to the entry form we will
create a new instance (in this case “CreateFriendInvitationIns” ) by the “Add Instance” unit and
then using the “Add Property Value” unit we will add the property value of the newly created
instance. Here, the “From User” field of the entry unit is preloaded with the current user value. If
we can create the instance and add the property value successfully we will return to “Invitation”
page otherwise if any error occurs we will go to the “Invitation Error Page”.
Figure 4.13: WebML view for an Invitation
Figure 4.14 is showing the “Invitation” page in the browser perspective i.e. it is the equivalent
representation of what we have implemented in the figure 4.13 using the components. Here, the
80

current user is sending a friend invitation to another user. In this case the current user is “Munir”
and he is sending invitation to another user named “Roni”. As we have stated earlier “Munir”
was preloaded in the “From User” field, as he is the current user. After filling up the required
information the user can send the invitation by clicking on the “Invite” button.
Figure 4.14: HTML view for an Invitation
Figure 4.16 is sowing the implementation of “Class and its Classification” pattern using the
knowledge base units in WebML. Using this pattern we can examine all the classes, all the
instances of those classes and all the property values of the instances.
The equivalent HTML representation of “Class and its Classification” pattern is shown in figure
4.16 that we have implemented in the figure 4.15. Here we can see all the available classes of the
schema and all the instances and the property values.
81

Figure 4.15: WebML view for showing all Instances
Figure 4.16: HTML view for showing all Instances
82

The information of a particular group is implemented in WebML in the figure 4.17. When the
instance of a group is loaded all the other property value of that instance is also loaded using the
transition link. For a group, we are showing the available group member of the group as well as
available articles, events and messages using the “Property Value Unit”.
Figure 4.17: WebML view for Showing Group information
The HTML representation of group information page is shown in the figure 4.18. Here the group
member can view the name of the group, the create date of the group. Also the group member
can view the other available members and available articles, events and messages of the group.
Figure 4.18: HTML view for Showing Group information
83

The group member can also post a new article, send group message and create a new event by
clicking on the “Post New Article”, “Send Group Message” and “Create New Event”,
respectively.
Figure 4.19 describes the step by step procedure of creating a new article for a group by the
group member. Here, also the name of the group is preloaded in the entry form. After that we are
creating a new instance using the name of the article. Then we add the property values of the
instance using the “Property Value Unit”. If all the steps are successfully done then we will
return to the group information page. Otherwise if any error occurs at any point of the procedure
then it will take to the error page called “Article Create Error Page”.
Figure 4.19: WebML view to Post a New Article
Figure 4.20 shows the HTML representation of Post New Article. Here we are creating a new
article called “Good Movie” with the subject “The movie was very good”. As we stated before
the “To Group” field is preloaded with the current group name. After inserting all the required
information the group member can post the article in the group by clicking the “Post” button. If
the article is posted successfully we will return to the group information page otherwise it will go
to the error page.
84

Figure 4.20: HTML view to Post New Article
85

5. Related Work
This section reviews existing design frameworks for ontology based semantic Web applications.
Hera [63] is a modeling language for enriching the contents of Web Information Systems with
knowledge resulting from different sources. Its design approach encloses the steps for modeling
the domain knowledge and the hypermedia structure and features, producing respectively the
Conceptual (CM), and the Application (AM) and Presentation Model. The representation syntax
of the application domain is RDF(S). The mapping between each data source schema and the
CM is also defined in RDF. The AM models the contents and navigational links of the
application interfaces in terms of classes and properties in the CM. The Hera approach defines
RQL data extraction mechanisms upon the structure of knowledge contained in the CM. It does
not provide any means for extracting the knowledge structure or for making inferences on it to
derive new relations.
Hera-S [64] covers some of the limitations of Hera, by enabling knowledge update through
hypertext interfaces. The domain is modeled with OWL, and the query language interpreted by
Sesame is SeRQL. Queries are not generated automatically by the system. The developer
expresses the appropriate SeRQL queries and parameters within the body of extraction
components.
These two approaches suffer of some common limitations:
• no automatic means are provided for manipulating the knowledge structure;
• the developer must be aware knowledgeable of OWL, RDF(S), and SeRQL, because no
abstraction on the implementation details of the queries is provided;
• the built architecture is rather monolithic and not open to extensibility.
The Semantic Hypermedia Design Method (SHDM) [65] is an extension of the OOHDM
approach for modeling semantic Web applications. It incorporates the conceptual modeling of
86

the application domain as extended UML class diagrams translated to OWL syntax. The
development process produces also the navigational class and context models, defining
respectively the objects that may be reached by the user and their access mechanisms, both of
them mapped to the ontology in the conceptual model with the use of RQL queries. The
knowledge structure is mapped to navigable application objects, which can be manipulated by
the application according to the OOHDM methodology. The main limitation is that the use of
RQL queries requires the developer to explicitly implement them at design time.
OntoWebber [66] is another model-driven ontology-based language for Web applications. It
generates sites from ontological descriptions of various aspects of the sites structure. Like in
Hera, the design process in OntoWebber concentrates on the integration of existing
heterogeneous data sources in a single RDF(S) domain ontology stored in a data repository
together with the site’s ontological models, which express predefined aspects like content,
navigation, presentation, personalization, maintenance, and integrity constraints requirements.
These aspects are translated to the domain ontology through TRIPLE queries.
With respect to the discussed approaches, our proposal presents several advantages: it allows the
designer to work at a graphical conceptual level for the application design; it exploits standard
UML representation of components; it provides a set of patterns that simplify the design task; it
benefits from an implementation experience that exploits the well known WebML DSL and
industrial CASE tool and code generation features.
87

6. Comparison
In this section, we make a comparison of the proposed framework and the development tools
implementing the existing design methodologies: Hera-S, SHDM, and OntoWebber. Table 6.1
summarizes the characteristics of the KB framework along with those for HPG [67],
SHDM2OWL [65] and Presentation Builder [68], and OntoWebber IDE [69]. The compared
characteristics are divided into: knowledge layer features, knowledge services supported by the
modeling approach, and software architecture properties.
Hera-S SHDM OntoWebber KB Framework
KNOWLEDGE LAYER
KR Language OWL UML-Style OWL RDF(S) UML Class and
object diagrams
Underlying KR formalism RDF(S) RDF(S) RDF(S) RDF(S)
Knowledge Sources Multiple Single Multiple Single
Interoperability
OWL/RDF(S)
models
OWL/RDF(S) models RDF(S) models XMI-based UML
models
Import Support
Non-automatic
Automatic
Non-automatic
Automatic
Integration
Integration
Export Support Automatic Automatic Automatic Automatic
Inference Engine
Sesame RFD(S)
Sesame
RFD(S)
TRIPLE
Pellet
reasoning
reasoning
Consistency Checking No No No Yes
Automatic Classification No No No Yes
Query Language SeRQL RQL TRIPLE Pellet API
Knowledge Storage
Memory/DBMS
Memory/DBMS/
Memory
Memory
/Files
Files
KNOWLEDGE-INTENSIVE WEB APPLICATION MODELING
Query Formulation Text-Based Text-Based RQL TRIPLE Syntax
Graphical
SeRQL syntax
Syntax
Components on
UML elements
Knowledge Schema
No No No Yes
Extraction
88

Knowledge Instances Yes Yes Yes Yes
Extraction
Knowledge-Based
Yes Yes Yes Yes
Navigation
Knowledge Update Partial Partial Partial Yes
SOFTWARE ARCHITECTURE
Extensibility No No No Plug-ins
Programming Language JAVA/XSLT JAVA JAVA JAVA
Methodological Support Yes Yes Yes Yes
Table 6.1: Comparison of knowledge-intensive Web applications modeling tools
Obviously, reasoning capabilities are closely related to the supported knowledge representation
language and inference engine. Hera-S, SHDM, and OntoWebber formalize the domain
knowledge with RDF schema statements. Hence, their inferences derive from RDF(S) reasoning
capabilities and include mainly type and subsumption queries upon RDF(S) ontologies. Since
Pellet is a description logic reasoner, it supports features like classification of concepts and
consistency checking that are particularly useful in execution platforms like the Web that often
require dynamic update of both data and its schema. Hera-S and SHDM store their knowledge in
the Sesame repository, a highly efficient system for ontologies storage and querying upon
DBMS, native files, and memory. Instead TRIPLE and Pellet API apply their inferences upon
data that resides in main memory, thus limiting the manageable knowledge size. The drawback
of integration of knowledge approach of Hera-S and OntoWebber is the high expertise needed
for mapping the various schemas to the domain knowledge schema. Instead, SHDM and the KB
framework automatically translate a data source into the knowledge layer.
The second table category summarizes the knowledge-based capabilities of built hypertexts. All
the approaches incorporate the deduction of instances and the user navigation upon them.
However, supported query notations influence the usability of the tools. Only the KB framework
uses graphical components defined upon the UML-based representation of knowledge, and
creates parameterized queries that are mapped to Pellet API methods in a transparent way for the
designer. The rest of the tools only recognize queries written directly in the supported query
language having a text-based syntax. Thus, the designer needs to be aware of logical formalisms,
89

the development complexity is increased, and the usability of the tools is reduced. Finally, only
the KB framework supports deduction and update of the knowledge with dedicated components
and design patterns.
The last table category summarizes the architectural aspects of the tools. All the tools have
methodological support, but except the KB framework, they are difficult to extend mainly
because they base on two-tier architecture. The KB framework is open to extensibility by means
of custom units. Extensions may occur either at the framework logic level providing a new
functionality upon the existing inference system, at the business logic level giving access to the
knowledge base, or at both.
In Table 6.2 a second comparison is made upon the expressive power of knowledge
representation languages (OWL and the language underlying the KB Framework). Both
languages are mapped to formalisms from the Description Logics family. Such comparison
focuses on the main features of each language in knowledge modeling in order to highlight their
differences and their limitations. All of them support the notion of class and class hierarchy;
although the KB Framework Language does not support exhaustive decomposition and
partitioning, due to implementation problems encountered using Pellet. In fact, UML considers
completeness upon generalization sets; therefore, we plan to resolve this limitation in future
releases. Similar is the support of property hierarchies in the languages. Derived support
indicates that the language does not provide a construct for the feature in question, but it supports
it through a combination of other constructs. Attributes that characterize the class are covered
through workarounds: both in OWL and in the KB Framework Language, class attributes are
defined once in the class definition for all the instances of the class. Finally, enumeration of
classes is not yet supported in KB Framework Language, although it is provided in UML. We
plan to extend the implementation to cover this aspect too.
90

OWL
DL
KB Framework
CLASS HIERARCHIES
subclass Yes Yes Yes
disjointness Yes Yes Yes
completeness Yes Yes No
partition Yes Yes No
PROPERTY HIERARCHIES
subproperty Yes Yes Yes
disjointness Yes Yes Yes
completeness Yes Yes No
partition Derived Yes No
OTHER FEATURES
instance attributes
class attributes
cardinality constraints
instance
enumeration of classes
Yes Yes Yes
Workaround Yes Workaround
Yes Yes Yes
Yes Yes Yes
Yes Yes No
Table 6.2: Comparison of knowledge-representation languages expressive power
91

7. Conclusion
In this work, we have implemented a social network web application with recommendation
features using the framework based on UML for designing knowledge intensive web application.
We have used a set of specific components and patterns for exploiting reasoning mechanisms to
be used for validating and exploring UML models of knowledge.
The framework bridges the gap between semi-formal modeling languages and semantic formal
representation languages, thus enabling the possibility of property verification and inference by
means of reasoning upon the model’s formalized representation.
The UML conceptual representation (or other equivalent design conceptual model, like WebML)
facilitates the adoption of semantic-based techniques by designers and developers, by hiding the
implementation details of the query evaluation. Indeed, the developer is not aware of the logical
formalisms supported by Pellet and of the mapping between UML and Pellet programmatic
elements, thus overcoming possible designer resistance to the new knowledge- and semanticsoriented
paradigm. The implementation with the WebML language (and associated tool
WebRatio) allows achieving good recommendation productivity in development.
The interaction with the underlying logical representation and the interaction with the reasoner
interface are completely hidden to the designer. Indeed, the specification and design activities
rely on high-level design primitives. The UML components used for the specification of the
knowledge base have been chosen carefully with respect to their expressive power and the
associated computational overhead for the reasoner, to avoid excessive computation loads.
We have designed and implemented a social network sharing information among its members
using the framework. Registered users are allowed to insert Create New Groups, post Article in
the Group, and invite another user to become Friends, add Interests, and send Group Invitation
and so on. The system automatically recommend to the group member about a particular interest
92

of a specific group members of the same group. When a user browses to select an interest, the
system recommends new interests according to his last selection.
Future works will include further implementation of real-world applications using the proposed
design paradigm. We aim at extending the implementation of the industrial application, and more
real world application by developing new functionalities that cannot be delivered in a dataintensive
application because of the limitations of query languages defined upon the relational
domain models. In the frame of such requirement, we expect to explore and provide new patterns
combining and configuring the framework components.
We also aim at (i) extend the components implementation in order to complete the missing
functionalities, and (ii) provide an extension of the WebML methodology towards the design of
knowledge-intensive Web applications.
93

References
[1] Marco Brambilla, Christina Tziviskou, A Framework for Model-driven Design and Development of Knowledge-intensive
Web Applications.
[2] SIRIN, E., PARSIA, B., GRAU, B. C., KALYANPUR, A., AND KATZ, Y. 2007. Pellet: A practical OWL-DL reasoner.
Journal of Web Semantics 5(2), 51-53.
[3] CERI, S., FRATERNALI, P., BONGIO, A., BRAMBILLA, M., COMAI, S., AND MATERA, M. 2002. Designing Data-
Intensive Web Applications. Morgan Kauffmann, San Francisco, CA.
[4] Dietz, J. L., & Hoogervorst, J. A. (2007). Enterprise Ontology and Enterprise Architecture - how to let them evolve into
effective complementary notions. GEAO Journal of Enterprise Architecture , Vol. 2 (Nr. 1).
[5] OMG. (2003, 06 12). MDA Guide Version 1.0.1. Retrieved from Object Management Group: http://www.omg.org/mda.
[6] Soley, R. (2000, 11 27). Model Driven Architecture. Retrieved from Object Management Group: http://www.omg.org/mda.
[7] P. Atzeni, G. Mecca, P. Merialdo. Design and Maintenance of Data-Intensive Web Sites. EDBT 1998, pp. 436–450.
[8] M.F. Fernandez, D. Florescu, J. Kang, A.Y. Levy, D. Suciu. Overview of Strudel—A Web-Site Management System.
Networking and Information Systems, 1(1), 1998, pp. 115–140.
[9] SCHWABE, D. AND ROSSI, G. 1998. An object oriented approach to Web-based applications design, TAPOS 4, 4.
[10] FERNANDEZ, M. F., FLORESCU, D., KANG, J., LEVY, A. Y., AND SUCIU, D. 1998. Catching the Boat withStrudel:
Experiences with a Web-Site Management System. In SIGMOD Conference. Seattle,414–425.
[11] MECCA, G., MERIALDO, P., ATZENI, P., AND CRESCENZI, V. 1999. The (Short) Araneus Guide to Web-Site
Development. In WebDB (Informal Proceedings). 13–18.
[12] CERI, S., FRATERNALI, P., AND PARABOSCHI, S. 1999. Data-driven, one-to-one Web site generation for data-intensive
applications. In Very Large Databases Conference, M. P. Atkinson,M. E. Orlowska,P. Valduriez, S. B. Zdonik, and M. L. Brodie,
Eds. Morgan Kaufmann, Edinburgh, UK, 615–626.
[13] CERI, S., FRATERNALI, P., AND BONGIO, A. 2000. Web modeling language (WebML): A modeling language for
designing Web sites. Computer Networks 33, 1–6, 137–157.
[14] CERI, S., FRATERNALI, P., BONGIO, A., BRAMBILLA, M., COMAI, S., AND MATERA, M. 2002. Designing Data-
Intensive Web Applications. Morgan-Kaufmann.
[15] G´OMEZ, J., CACHERO, C., AND PASTOR, O. 2001. Conceptual modeling of device-independent Web applications.
IEEE MultiMedia 8, 2, 26–39.
[16] P. P. Chen, The Entity-Relationship Model, Towards a Unified View of Data, ACM-Transactions on Database Systems, 1:1,
1976, pp. 9-36.
[17] R. G. G. Cattell, Douglas K. Barry, and Dirk Bartels (Eds.), The Object Database Standard : ODMG 2.0, Morgan-Kaufmann
Series in Data Management Systems, 1997.
[18] G. Booch, I. Jacobson, and J. Rumbaugh, The Unified Modeling Language User Guide, The Addison-Wesley Object
Technology Series, 1998.
[19] Berners-Lee, T., Hendler, J., and Lassila, O., 2001, The Semantic Web, Scientific American , 284: 34–43.
[20] W3C: Sparql query language for rdf (2007) http://www.w3.org/TR/rdf-sparql-query.
[21] Dean, M. and Schreiber, G., 2004, OWL Web Ontology Language Reference, W3C Recommendation,
http://www.w3.org/TR/2004/REC-owl-ref-20040210/.
94

[22] OMG UML (2007), Unified Modeling Language: Superstructure version 2.1.1. ptc/2007-02-03. OMG document
http://www.omg.org/cgi-bin/doc?formal/07-02-03
[23] CRANEFIELD, S., AND PURVIS, M. 1999. UML as an Ontology Modeling Language. In Proceedings of the Workshop on
Intelligent Information Integration in conjunction with the 16th International Joint Conference on Artificial Intelligence,
Stockholm, Sweden, July 1999.
[24] CRANEFIELD, S. 2001. UML and the Semantic Web. In Proceedings of the 1st International Semantic Web Working
Symposium, Stanford University, California, USA, July 2001, IOS Press.
[25] FALKOVYCH, K. 2002. Ontology Extraction from UML Diagrams. Master's thesis, Vrije Universiteit Amsterdam, 2002.
[26] FALKOVYCH, K., SABOU, M., AND STUCKENSCHMIDT, H. 2003. UML for the Semantic Web: Transformation-
Based Approaches. In the Knowledge Transformation for the Semantic Web, B. OMELAYENKO AND M. KLEIN, IOS Press,
92-106.
[27] BAC LAWSKI, K., KOKAR, M. K., KOGUT, P. A., HART, L., SMITH, J., HOLMES, W. S., LETKOWSKI, J., AND
ARONSON, M. L. 2001. Extending UML to Support Ontology Engineering for the Semantic Web. In Proceedings of the 4th
International Conference on UML, Toronto, Canada, October 2001, Springer, 342-360.
[28] BACLAWSKI, K., KOKAR, M. K., SMITH, J. E., WALLACE, E., LETKOWSKI, J., KOETHE, M. R., AND KOGUT, P.
2002. UOL: Unified Ontology Language. Assorted papers discussed at the DC Ontology SIG meeting, http://www.omg.org/cgibin/doc?ontology/2002-11-02,
2002.
[29] OMG ODM RFP (2006), Ontology Definition Metamodel Request for Proposal. OMG document http://www.omg.org/cgibin/doc?ad/06-05-01.pdf
[30] BROCKMANS, S., VOLZ, R., EBERHART, A., AND LOFFLER, P. 2004. Visual Modeling of OWL DL Ontologies Using
UML. In Proceedings of the 3rd International Semantic Web Conference, Hiroshima, Japan, November 2004, Springer, 198-213.
[31] BROCKMANS, S., HAASE P., HITZLER, P., AND STUDER, R. 2006. A Metamodel and UML Profile for Rule-extended
OWL DL Ontologies. In the Proceedings of the 3rd European Semantic Web Conference, Budva, Montenegro, June 2006,
Springer, 303-316.
[32] SIRIN, E., PARSIA, B., GRAU, B. C., KALYANPUR, A., AND KATZ, Y. 2007. Pellet: A practical OWL-DL reasoner.
Journal of Web Semantics 5(2), 51-53.
[33] OMG Meta Object Facility (MOF) (2005) 2.0 XMI Mapping Specification, v 2.1. OMG document http://www.omg.org/cgibin/apps/doc?formal/05-09-01.pdf
[34] BECHHOFER, S., VAN HARMELEN, F., HENDLER, J., HORROCKS, I., MCGUINNESS, D.L., PATEL-SCHNEIDER,
P.F., AND STEIN, L.A 2004. OWL Web Ontology Language Reference. Available at http://www.w3.org/TR/2004/REC-owlref-20040210/
[35] VAN HARMELEN, F., PATER-SCHNEIDER, P.F., AND HORROCKS, I. 2001. Reference description of the DAML+OIL
ontology markup language. Available at http://www.daml.org/2001/03/reference
[36] BRICKLEY, D., AND GUHA, R.V. 2000. RDF Vocabulary Description Language 1.0: RDF Schema. Available at
http://www.w3.org/TR/rdf-schema/
[37] KLYNE, G., CAROLL, J.J. 2004. Resource Description Framework (RDF): Concepts and Abstract Syntax. Available at
http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/
[38] HAYES, P. 2004. RDF Semantics. Available at http://www.w3.org/TR/2004/REC-rdf-mt-20040210/
[39] BERNERS-LEE, T., AND FISCHETTI, M. 1999. Weaving the Web-Chapter 12. Harper San Francisco, 1999.
95

[40] CLARK, T., EVANS, A., AND KENT, S. 2001. The Meta-Modeling Language Calculus: Foundation Semantics for UML.
In Proceedings of the 4th International Conference on Fundamental Approaches on Software Engineering (FASE), Genova, Italy,
April 2001, Springer, 17-31.
[41] EGEA, M. 2005. ITP/OCL: a Theorem Prover-Based Tool for UML+OCL Class Diagrams. Master’s thesis, Facultad de
Inform´atica, Universidad Complutense de Madrid, 2005.
[42] SHROFF, M., AND FRANCE, R. B. 1997. Towards a Formalization of UML Class Structures in Z. In Proceedings of 21st
International Computer Software and Applications Conference, Washington, DC, USA, August 1997, IEEE Computer Society,
646-651.
[43] BERARDI, D., CALVANESE, D., AND DE GIACOMO, G. 2005. Reasoning on UML class diagrams. Artificial
Intelligence, 168(1-2), 70-118.
[44] CALVANESE, D., GIACOMO, G., AND LENZERINI, M. 2001. Identification Constraints and Functional Dependencies in
Description Logics. In Proceedings of the 17th International Joint Conference on Artificial Intelligence, Seattle, Washington,
USA, August 2001, Morgan Kaufman, 155-160.
[45] BAADER, F., CALVANESE, D., MCGUINESS, D.L., NARDI, D., AND PATEL-SCHNEIDER, P.F. 2007. The
Description Logic Handbook: Theory, Implementation, and Applications. Cambridge University Press.
[46] HORROCKS, I., KUTZ, O., AND SATTLER, U. 2006. The Even More Irresistible SROIQ. In Proceedings of the 10th
International Conference on Principles of Knowledge Representation and Reasoning, Lake District, United Kingdom, June 2006,
AAAI Press, 57-67.
[47] Sirin, E., Parsia, B., Grau, B. C., Kalyanpur, A., and Katz, Y.: Pellet: A practical OWL-DL reasoner. Journal of Web
Semantics, 5(2): 51-53, 2007.
[48] Tobies, S.: Complexity results and practical algorithms for logics in Knowledge Representation. PhD Thesis, LuFG
Theoretical Computer Science, RWTH-Aachen, Germany, 2001.
[49] Halaschek-Wiener, C., Parsia, B., and Sirin, E.: Description Logic Reasoning with Syntactic Updates. In Proceedings of the
5th International Conference on Ontologies, Databases, and Applications of Semantics: 722–737, 2006.
[50] Parsia, B., Sirin, E., Kalyanpur, A.: Debugging OWL Ontologies. In the Proceedings of the 14th international conference on
World Wide Web (WWW-2005): 633-640, 2005.
[51] Sirin, E., Grau, B. C., and Parsia, B.: From Wine to Water: Optimizing Description Logic Reasoning for Nominals. In the
Proceedings of the International Conference on the Principles of Knowledge Representation and Reasoning (KR-2006): 90-99,
2006.
[52] HALASCHEK-WIENER, C., PARSIA, B., AND SIRIN, E. 2006. Description Logic Reasoning with Syntactic Updates. In
Proceedings of the 5th International Conference on Ontologies, Databases, and Applications of Semantics, Montpellier, France,
October 2006, Springer, 722–737.
[53] PARSIA, B., SIRIN, E., KALYANPUR, A. 2005. Debugging OWL Ontologies. In Proceedings of the 14th International
Conference on World Wide Web, Chiba, Japan, May 2005, ACM, 633-640.
[54] SIRIN, E., GRAU, B. C., AND PARSIA, B. 2006. From Wine to Water: Optimizing Description Logic Reasoning for
Nominals. In Proceedings of the 10th International Conference on the Principles of Knowledge Representation and Reasoning,
Lake District, United Kingdom, June 2006, AAAI Press, 90-99.
[55] LIEBIG, T. 2006. Reasoning with OWL - System Support and Insights. Technical report, number TR-2006-04, Ulm
University, Germany, 2006. Available at http://www.informatik.uni-ulm.de/ki/Liebig/papers/TR-U-Ulm-2006-04.pdf
96

[56] BRAMBILLA, M., CERI, S., FRATERNALI, P., ACERBIS, R., AND BONGIO, A. 2005. Model-driven Design of Serviceenabled
Web Applications. In Proceedings of the ACM SIGMOD International Conference on Management of Data, Baltimore,
Maryland, USA, June 2005, ACM, 851-856.
[57] MANOLESCU, I., BRAMBILLA, M., CERI, S., COMAI, S., AND FRATERNALI, P. 2005. Model-Driven Design and
Deployment of Service-Enabled Web Applications. ACM Transactions on Internet Technology (ACM TOIT) 5(3), 439-479.
[58] BRAMBILLA, M., CERI, S., FRATERNALI, P., AND MANOLESCU, I. 2006. Process Modeling in Web Applications.
ACM Transactions on Software Engineering and Methodology (TOSEM) 15(4), 360-409.
[59] CERI, S., DANIEL, F., MATERA, M., AND FACCA, F. 2007. Model-driven Development of Context-Aware Web
Applications. ACM Transactions on Internet Technology (ACM TOIT) 7(1).
[60] BRAMBILLA, M., CERI, S., FACCA, F., CELINO, I., CERIZZA, D., AND DELLA VALLE, E. 2007. Model-Driven
Design and Development of Semantic Web Service Applications. ACM Transactions on Internet Technologies (TOIT) 8(1), 3:1-
3:31.
[61] ACERBIS, R., BONGIO, A., BRAMBILLA, M., BUTTI, S., CERI, S., AND FRATERNALI, P. 2008. Web applications
design and development with WebML and WebRatio 5.0. In Proceedings of the 46th International Conference on Objects,
Components, Models and Patterns, TOOLS EUROPE, Zurich, Switzerland, July 2008, Springer, 392-411.
[62] WEBRATIO. WebRatio User Guide: Technical Report of Web Models s.r.l., 2007.
[63] VDOVJAK, R., FRASINCAR, F., HOUBEN, G. J., AND BARNA, P. 2003. Engineering semantic web information systems
in Hera. Journal of Web Engineering 2(1&2), 3-26.
[64] VAN DER SLUIJS, K., HOUBEN, G., BROEKSTRA, J., AND CASTELEYN, S. 2006. Hera-S: web design using sesame.
In Proceedings of the 6th International Conference on Web Engineering, Palo Alto, California, USA, 2006, ACM, 337-344.
[65] LIMA, F., AND SCHWABE, D. 2003. Application modeling for the Semantic Web. In Proceedings of the 1st Latin
American Web Congress, Washington, DC, USA, 2003, IEEE Computer Society, 93-102.
[66] JIN, Y., DECKER, S., AND WIEDERHOLD, G. 2001. OntoWebber: Model-Driven Ontology-Based Web Site
Management. In Proceedings of the 1st International Semantic Web Working Symposium, Stanford University, California, USA,
July 2001, 529-547.
[67] FRANSICAR, F., HOUBEN, G., AND BARNA, P. 2005. Hera presentation generator. In Special interest tracks and posters
of the 14th international conference on World Wide Web, New York, USA, 2005, ACM Press, 952-953.
[68] SCHWABE, D., SZUNDY, G., SILVA DE MOURA, S., AND LIMA., F. 2004. Design and Implementation of Semantic
Web Applications. WWW Workshop on Application Design, Development and Implementation Issues in the Semantic Web.
New York, USA, May 2004, CEUR-US.org.
[69] JIN, Y., XU, S., DECKER, S., AND WIEDERHOLD, G. 2002. Managing Web Sites with OntoWebber. In Proceedings of
the 8th International Conference on Extending Database Technology, Prague, Czech Republic, March 2002, Springer, 766-768.
97