CS 566
Web Semantics
E-Commerce and Semantic Web
Antonis Misargopoulos
[email protected]
Athina Tziaki
[email protected]
Antoniou Grigoris
June 2003
The growth of a wide range of e-commerce services is contributing
to the increasing international trading of products and services
The ability to find, interrogate and exchange knowledge is
fundamental for Business-to-Business (B2B) and Business-toCustomer (B2C) e-commerce
Semantic Web brings structure to the content of Web pages
Semantic Web is extension of the current Web, in which information
is given a well-defined meaning
It will be able to support automated electronic services using
semantics-based descriptions
Ontologies and metadata are becoming increasingly prevalent and
important in a wide range of e-commerce applications
RDF is the technical foundation of the Semantic Web which provides
a generic core data model
When Semantic Web Approaches E-Commerce
Semantic Web will enable automated agents to describe and carry
out more intelligent tasks on behalf of the user
Tim Berners-Lee, the inventor of the WWW, has conceived a fivelayer architecture for Semantic Web:
 The syntax layer – XML allows to markup arbitrary content by
means of nested, attributed elements
 The data layer – RDF allows the encoding, exchange and
reuse of structured metadata. Contrary to XML, RDF allows
assigning global identifiers to resources and allows referring
and extending statements made in other documents
 The ontology layer describe structurally heterogeneous and
distributed information sources of interest
 The logic layer consists of rules that enable inferences
 The proof layer allows the explanation of given answers
generated by automated agents. This will require the translation
of agents internal reasoning mechanisms into some unifying
proof representation language.
While e-service approaches to e-commerce is to become
widespread, standarisation of ontologies, message
content and message protocols will be necessary
Because of the great XML-like modelling languages
release, the challenge is to create small standards for
communities to describe information with meaning
Ontologies can be seen as metadata that explicitly
represent semantics of data in machine-processable way
Ontology-based reasoning services help people and
computers to access the information they need, and
effectively communicate with each other
Semantic E-Commerce Lifecycle (1/10)
Lifecycle Stages:
Matchmaking: A trader locates other traders that it could
potentially do business with.
Negotiation: The trader enters into negotiation with one or more
of these potential business partners, to see if they can agree
mutually acceptable terms of business.
This is done by some traders placing advertisements, and others
making queries over these advertisements
This is done through an interchange of negotiation proposals
describing constraints on an acceptable deal. The outcome of this is
an agreement.
Contract Formation: The agreement is transformed into a legally
binding contract
Contract Fulfilment: The parties carry out the agreed
transaction, within the parameters specified in the contract
Semantic E-Commerce Lifecycle (2/10)
Matchmaking is the process whereby potential trading partners
become aware of each other’s existence
Provides an associated partially specified service description that
defines the set of possible services the provider can offer which are
of the interest to the buyers
Despite different architectures and communication protocols:
we can identify clear roles which are common to all of them.
we have a repository of information about services or service
requirements, which is maintained by the repository host.
 agents adopting advertiser role are willing to advertise descriptions of
services in the repository. They may be buyers, advertising a service
request, or may be marketplaces offering environments where such
services can be traded.
 agents adopting the seeker role similarly wish to locate appropriate
advertisers. Seekers can query a repository, via the repository host,
and may be able to browse the repository.
Semantic E-Commerce Lifecycle (3/10)
Negotiation stage of the e-commerce interaction lifecycle refines
the abstract service specification from the matchmaking phase to a
concrete agreement between two parties
Negotiation can be one-to-one, one-to-many or many-to-many
Negotiation protocols determine the interchange of messages which
take place during the negotiation, and the roles by which the
negotiation must abide
In each case there are at least two negotiation participants trying to
make a deal with each other
There is at least one (possible more) negotiation host, responsible
for enforcing the rules of the negotiation and ensuring it goes
Semantic E-Commerce Lifecycle (4/10)
Before negotiation can begin, the parties have already agreed
roughly what the negotiation is about. So, this places a restriction on
the parameters and values to be negotiated, which is called
negotiation template
The negotiation template refers to a common ontology accepted by
all participants in the negotiation.
It defines a schema for valid negotiation proposals that participants
submit to each other
The result of the negotiation process is an agreement
Semantic E-Commerce Lifecycle (5/10)
Standardization take place at 3 levels:
Standards for business-specific ontologies which
describe goods, services and contracts being traded
Standards for specifying the format of advertisements,
proposals, contracts and other constructs which are
used during B2B interactions
Standards that specify the protocols which traders use to
interact with each other during different phases of the
B2B lifecycle
Semantic E-Commerce Lifecycle (6/10)
Description Language for B2B E-Commerce Lifecycle
Description should offer a high degree of flexibility and
Descriptions need to share a common semantics
Descriptions should easily lend themselves to performing
the operations described in the negotiation and
matchmaking sections
Descriptions should express restrictions and constraints
Semantic E-Commerce Lifecycle (7/10)
Description Language for B2B E-Commerce Lifecycle
Why DAML+OIL is a good candidate?
DAML+OIL offers support for types, which greatly
enhances the expressiveness and modularity of the
DAML+OIL offers support for ontologies. It is almost
integrated with tools such as OilEd and Protégé which
make the generation of new ontologies for service
descriptions much easier
All the operations can be expressed in terms of the
subsumption operation. DAML+OIL descriptions lend
themselves very well
DAML+OIL offers some support for expressing constraints
Semantic E-Commerce Lifecycle (8/10)
Description Language for B2B E-Commerce Lifecycle
Description Ontology:
Description class is a common
superclass for Advertisement, Query,
Template and Proposal
PC Ontology:
PC class is a subclass of Product
and must have at most one
Processor and one amount of
Semantic E-Commerce Lifecycle (9/10)
Description Language for B2B E-Commerce Lifecycle
Service Ontology:
Two services are defined in this
ontology: Sales and Delivery
Participant Ontology:
Public information about prospective
advertisers and negotiators.
Built from information that
individuals or companies are
requested to provide at registration
Such information is then used at
matchmaking and negotiation time
to verify compatibility of
advertisements and proposals.
Semantic E-Commerce Lifecycle (10/10)
Description Language for B2B E-Commerce Lifecycle
Agreement Instance Example
E-commerce issues (1/2)
Many consumers do not trust the Internet to provide
robust security for online transactions, and many
businesses neither trust e-commerce systems nor
believe they will be able to evaluate or control their
business risk when using them
Lack of automation – human intervention is required for
browsing, selecting, ordering and paying for products
Current e-commerce sites do not include semantic
representations of data, services, processes, or business
models that are readable by software programs (agents)
E-commerce issues (2/2)
Three technologies will bring e-commerce to the
next generation by increasing efficiency,
compatibility, autonomy, and security:
Mobile Agents: Automate Electronic Transactions
Security and Trust: Build a Web of Trust
XML: Create a Semantic Web
Mobile Agents:
Automate Electronic Transactions
 Mobile software agents are programs that act on behalf of a user
or another program and, for a specified mission, are able to migrate
from host to host on a network
 Numerous applications could benefit from mobile agent technology,
such as Internet information retrieval and network management
 However, the greatest potential for mobile agents has been e-
commerce applications in which the agents automate and facilitate
the phases of
Brokering of a transaction
 Negotiation of a transaction
 Payment of a transaction
 Delivery of a transaction
Security and Trust: Build a Web of Trust
 Most of the security issues, such as confidentiality, authentication,
integrity, and non - repudiation, are addressed by well-known
cryptographic algorithms and protocols
 However, even if we have a secure channel connecting us to a party
whose identity can be verified, we still have no way to confirm the
trustworthiness of that party
 To meet this challenge, we need a trust management mechanism
to manage the histories and reputation of parties involved in the
business to create a web of trust
 While the mobile agent automates the electronic transactions, it also
introduces new security threats
XML: Create a Semantic Web
 Today’s Web is a vast unstructured mass of information
 HTML was designed to provide a usable interface for humans,
rather than to communicate with other machines. While HTML
reflects the structure and limited presentation of a Web page, it
conveys nothing about the meaning of the marked document
 Search engines and software programs have difficulty using
information that is not semantically encoded
 Today, several industry-focused initiatives have been formed to work
on standards based on XML for interoperable frameworks for ecommerce application domains
 Rules range from how to offer items for sale, to making payment
choices, delivering products, generating receipts, and resolving
Integration Problems of XML-Based
Catalogs for B2B Electronic Commerce
 Electronic marketplaces for Business-to-Business (B2B)
electronic commerce bring together many online suppliers
and buyers
 Each individual participant can potentially use his own
format to represent the products in his product catalog
 A B2B mediator has to integrate both suppliers’ and buyers’
formats to allow them to do contracting with one another
 Given the dominance of XML, e-commerce integration
technology must be based on the XML low-level integration
architecture provided by the W3C consortium with XSLT
and XPath languages
Product Description Standards (1/2)
 xCBL 3.0 developed by Commerce One2, Inc
Provides a comprehensive set of standardized XML
document formats, allowing buyers, suppliers and service
providers to integrate their existing systems quickly and
efficiently in the electronic marketplaces
 Internet Open Trading Protocol (IOTP) was developed
within the Internet Engineering Task Force (IETF3)
Provides the data structures and communication protocols
for payment transactions: purchase, refund, authentication,
deposit, and other protocols that occur in electronic
Product Description Standards (2/2)
 Open Applications Group Integration Specification
 Provides data structures, messaging formats and protocols for
business integration. OAGIS defines a vocabulary of business
terms and more than 90 different types of business documents
can be exchanged
 Real Estate Data Interchange Standard (RETS)
 Defines a protocol for implementing transactions, and
incorporates an XML specification for general-purpose
interchange. It also provides a compressed data interchange
format and specification to allow the interchange of machineinterpretable property information
Catalog Integration (1/3)
 If a marketplace mediates between n suppliers and m
buyers, then it must be able to map each of the n
suppliers’ catalogs into m buyers’ formats performing
nxm mappings
 The numbers n and m may be high enough to make
the problem of creating and maintaining these catalog
integration rules nontrivial
Catalog Integration (2/3)
Unified Catalog (the UC), only
requires the marketplace to
perform mapping between
each supplier or buyer catalog
and the UC, and therefore
requires only n+m mappings
There are two opposing strategies for selecting the elements for
inclusion in the UC:
a) The unified catalog stores the minimum
core number of attributes for each product
b) The unified catalog stores the maximum
possible number of attributes
Catalog Integration (3/3)
In both strategies the UC can change if we add a new
 In strategy (a)
The addition of a more detailed catalog will not change the UC
The addition of a less detailed catalog will reduce the granularity
level of the UC. As a result, this strategy bounds the granularity
level of the UC to the less detailed catalog, which is
unacceptable for most B2B systems
 In strategy (b)
 The addition of a new catalog that is less detailed than the UC
will not influence the latter
 The addition of a more detailed catalog will require updates to
the UC so that it will not be less detailed than the former
Integration at the XML Catalog Level (1/5)
Four types of mapping between the attributes of C1 and
C2 are possible:
 one-to-one mapping (1:1)
 It occurs when the element of C1 has a semantic equivalent in C2,
i.e. element StateOrRegion in IOTP standard is equivalent to
Province in the UC. If the element is encoded by an XML
attribute in C1 and by an XML element in C2 then the rule can
be expressed as follows (from IOTP to UC):
<xsl:for-each select="PostalAddress">
<xsl:value-of select="@StateOrRegion"/>
Integration at the XML Catalog Level (2/5)
 one-to-many mapping (1:n)
 It occurs when an element in C1 has to be translated into
several elements in C2. For example, ADDRLINE in OAGIS
semantically corresponds to the pair of attributes Street and
House in the UC
 XSLT rules must be extended with small XPath expressions
(element parsers) that will split the elements as required
<ADDRLINE>De Boelelaan, 1081a</ADDRLINE>
<STREET>De Boelelaan</STREET>
<xsl:variable name="addrline" select="ADDRLINE"/>
<xsl:value-of select="substring-before($addrline,',')"/>
<xsl:variable name="addrline" select="ADDRLINE"/>
<xsl:value-of select="substring-after($addrline,', ')"/>
</ HOUSE >
Integration at the XML Catalog Level (3/5)
 many-to-one mapping (n:1)
 It occurs when two or more elements from C1 have to be
translated into one element in C2. For example, the Street and
House elements in the UC must be translated into the element
ADDRLINE in OAGIS. This can be done by means of XSLT in
the following way:
<xsl:for-each select="address">
<xsl:value-of select="Street"/>,
<xsl:value-of select="House"/>
<ADDRLINE>De Boelelaan, 1081a</ADDRLINE>
Integration at the XML Catalog Level (4/5)
 Many to-many mapping (n:n)
 It occurs when a piece of a description is spread over several
elements without evident partitioning of information between them.
For example, Street, House, and PObox elements of the UC
correspond to the pair (AddressLine1, AddressLine2) in IOTP without
any indication where street, house, and postbox information should
be stored within these two address lines. Mapping of a structured UC
record into a less structured IOTP record can be done
<xsl:for-each select="address">
<AddressLine1><xsl:value-of select="Street"/>
<xsl:value-of select="House"/></AddressLine1>
<AddressLine2>P.O. Box <xsl:value-of select="PObox"/> </AddressLine2>
Integration at the XML Catalog Level (5/5)
If an element was mapped into the UC with one 1:n
mapping then the reverse mapping will require one n:1
Most of the rules (89%) represent one-to-one
mappings, while the other types only appear in special
cases, once or twice for each catalog standard
Existing Frameworks and Applications
MOMIS Architecture
MOMIS (Mediator envirOnment for Multiple Information Systems) is a mediator-based
system aiming to extract and integrate information from heterogeneous data sources,
such as relational, object, semi-structured sources (XML)
SemanticEdge (1/2)
 SemanticEdge
has developed a state of the art
multilingual natural language (text and voice) dialog
system capable of handling dialogs with humans wanting
to access information, for example, to purchase products
and services
 The technology extends naturally to Customer Relations
Management (CRM) and other e-business functions
 This technology depends on several distinct technology
areas within Artificial Intelligence: natural language
processing, including deep language processing and
statistical analyses; machine learning, including inductive
learning; speech recognition; automated dialog
generation, both user and content specific; and
knowledge representation and ontologies
SemanticEdge (2/2)
 The system mediates between humans and information.
 That is, it mediates between an information space and a
human’s conceptualization of that information space; for
example, between a product space and a customer’s
conceptualization of that product space, and how they
will consequently go about searching and querying that
product space
 Users hold negotiations with the system, which is
mediating access to the product spaces, and it will ask
questions of them.
 This requires the system to have the ability to guide
those dialogs according to a representation of that
product space.
 This ability to a large extent is supported by ontologies
Financial Application demo
[1] Semantic Web Support for Business-to-Business E-Commerce Lifecycle David Trastour, Claudio
Bartolini and Chris Preist. Trusted E-Services Laboratory, HP Laboratories Bristol. April 5th 2002
[2] Towards a Semantics for the Web Christopher Welty. Vassar College Computer Science Dept.
Poughkeepsie, NY 12604-0462, USA
[3] A Semantic Web Approach to Service Description for Matchmaking of Services David Trastour,
Claudio Bartolini and Javier Gonzalez-Castillo. HP Labs, Filton Road, Bristol BS34 8QZ, UK
[4] Reduction of price dispersion through Semantic E-Commerce: A Position Paper Tanya Gupta and
Abir Qasem
[5] An Analysis of Integration Problems of XML-Based Catalogs for B2B Electronic Commerce. B.
Omelayenko, D. Fensel. In: Proceedings of the 9th IFIT 2.6 Working Conference on Database
Semantics (DS-9), April 25-28, Hong-Kong, 2001.
[6] A Data Integration Framework for E-commerce Product Classification. S. Bergamaschi, F. Guerra
and M. Vincini.
CSITE-CNR viale Risorgimento 2, 40136 Bologna, Italy.
[7] A Layered Integration Approach for Product Descriptions in B2B E-commerce. Borys Omelayenko
and Dieter Fensel.
[8] Next-Generation E-Commerce: XML+Mobile Agent+Trust. CG topics 4/2000. Dr. Jian Zhao,
Thomas Blum.
[9] Enterprise-standard ontology environments for intelligent e-business. Alan Flett, Mike Brown
[10] Syntactic-Level Ontology Integration Rules for E-commerce. Borys Omelayenko. In: Proceedings
of the 14th International FLAIRS Conference (FLAIRS-2001), Key West, FL, May 21-23, 2001.
[11] A Two-Layered Integration Approach for Product Information in B2B E-commerce. Borys
Omelayenko and Dieter Fensel. In: Proceedings of the Second International Conference on
Electronic Commerce and Web Technology (EC WEB-2001), Munich, Germany, September 4-6,
[12] http://www.semanticedge.com/
Related Papers
[1] The Contract Net protocol: High-level communication and control in a distributed
problem solver R.G. Smith. In Proceedings Computing Systems, pages 186-192,
Washington, DC, 1979. IEEE Computer Society.
[2] UDDI. Universal Description Discovery Integration Technical White Paper, 2000
[3] Auction theory: a guide to the literature P. Klemperer. Journal of Economic Surveys,
13(3): 227-286, 1999
[4] OilEd: a reason-able ontology editor for the semantic web S. Bechhofer, I.Horrocks,
C.Goble, and R.Stevens. In Working Notes of the 2001 Int. Description Logics
Workshop (DL-2001), pages 1-9, 2001.
[5] Knowledge Modeling at the Millenium – The Design and Evolution of Protégé W.
Grosso, H. Eriksson, R. Fergerson, J. Gennari, S. Tu, and M. Musen. In Proceedings
of the 12th International Workshop on Knowledge Acquisition, Modeling and
Management (KAW ’99), 1999.
[6] Proceedings of the International Workshop on Description Logics (DL'99) I.Horrocks.
FaCT and iFaCT. In P. Lambrix, A. Borgida, M. Lenzerini, R. Möller, and P. PatelSchneider.
[7] Description logics for matchmaking of services J. González-Castillo, D. Trastour, and
C. Bartolini. In Proceedings of the KI-2001 Workshop on Applications of Description
Logics, 2001.

CS 566 Web Semantics Health Clinic Model Daml+OIL