in order to look for software solutions supporting
their CRM activities, are not technical experts and
thus they can be in trouble even in filling in large
on-line forms, possibly requiring technical skills in
order to be completed. Thus, we are studying the
possibility of implementing different types of UI for
these users: a Natural Language (NL) UI, in which
the SME users can freely express their requirements,
and a UI based on a graphical representation of
business processes (BP), based on the idea that
business processes could be the form in which
companies think about their business and
management activities.
These two alternative UIs are a work in progress.
The form-based UI, instead, can be suited for ICT
company users, which are probably skilled enough
about the functional and technological aspects of
their software products or services. Moreover, such
users are probably also more used to web-based
interaction, often consisting in a sequence of on-line
forms. Finally, such users are probably also more
motivated to complete a possibly boring task, since
they are describing the software solutions they offer,
and this can be viewed as an effective promotion of
their products and services.
Thus, in the following, we will concentrate on
the form-based UI devoted to the acquisition of
descriptions of software solutions by ICT
companies.
4.3 Managing User Interaction
We claim that the design of the user interaction
enabling ICT company users to provide a description
of their software solutions could only be based on an
analysis of the way in which users talk about CRM.
For this reason, in the domain analysis phase,
besides Ontology requirements, we also identified
dialog topics, representing the key concepts of the
descriptions of software solution supporting CRM
activities (see Section 3).
In order to clarify how dialog topics are
exploited in the system, let’s look at an example.
One of the templates representing dialog topics we
extracted from our analysis corresponds to the
concept of “(dynamic) acquisition of data from
(another) enterprise application”, which means that
the described CRM software application can acquire
data by directly communicating with another
application (within the system, templates do not
have a linguistic form, but only a formal, OWL, one.
For the sake of readability, here we provide also a
rough linguistic “translation”). Such a general
concept is instantiated in different
documents/interviews with more specific concepts
by heterogeneous linguistic expressions: specific
instances of this template include more specific
concepts in place of “data” and in place of
“enterprise application”; for example “real time
acquisition of customers info from Ms Outlook”, or
“(management of) product records acquired from
ERP software”.
We decided to represent templates as ontological
concepts belonging to an Application Ontology
(Guarino, 1997), specific for ARNEIS, and linked to
the upper CRM Ontology.
A template represents a structured concept in
which there are some variables (slots). By default,
such variables are filled in by generic concepts (e.g.
“data”), that can be replaced by more specific
concepts (e.g. “product data”).
Figure 2 shows the OWL logical representation
(generated by Protégé) of the class representing the
template corresponding to the concept of “(dynamic)
acquisition of data from (another) enterprise
application”.
In order to identify slots within a template, we
needed a way lo “label” them, possibly without
compromising the correctness of the OWL syntax.
Thus, we decided to indicate them by adding, to
each concept that represents a default slot filler, the
expression and S
i
, where S
i
is a unique identifier
(automatically generated) for that slot. Thus, for
example, in Figure 2 the expression (CRM_element
and S
1
) identifies a slot (labeled S
1
) filled in, by
default, by the CRM_element class (intuitively
speaking, CRM_element represents all the items that
are typically involved in CRM: customers, products,
orders, sales, and so on). If we aim at expressing the
acquisition of data about customers (e.g., “customers
info”), in the template instantiation, the class
CRM_element will be replaced by a more specific
one, i.e. Customer (subclass of CRM_element) and
the expression and S
1
will be deleted; if we aim at
expressing the acquisition of data about products
(e.g., “product records”), CRM_element will be
replaced by Product_or_service (subclass of
CRM_element). Analogously, the class
(Application_software and S
2
) can be replaced by
the class Ms_Outlook, or ERP.
At a first glance, this labeling solution may seem
to bring to odd meanings. In fact, from a semantic
point of view, by writing Information_object ...
refers_to some (CRM_element and S
1
), we are
actually saying that an Information_object refers to
something that is, at the same time, a CRM_element
and a S
1
(see Figure 2), which is not the meaning we
would like to express. Thus, it is important to stress
WEBIST 2011 - 7th International Conference on Web Information Systems and Technologies
198