€¦ · web viewsuch organizations need knowledge management and organizational memory tools...

E-Commerce and Semantic Web Antonis Misargopoulos, Athina Tziaki

UNIVERSITY OF CRETECOMPUTER SCIENCE DEPARTMENT

CS-566WEB SEMANTICS

PHASE 4

E-COMMERCE AND SEMANTIC WEB

ATHINA TZIAKI (MET)ANTONIS MISARGOPOULOS (MET)

JUNE, 2003HERAKLION, CRETE

1


ABSTRACT

The Semantic Web will bring structure to the content of Web pages, being an extension of the current Web, in which information is given a well-defined meaning. Especially within e-commerce applications, Semantic Web technologies in the form of ontologies and metadata are becoming increasingly prevalent and important. In this work, we present a semantic e-commerce lifecycle and describe core issues like data integration and agent use. Finally, there are some existing semantic e-commerce applications and their descriptions.

2


TABLE OF CONTENTS

1. Introduction..............................................................................................42. Semantic Web..........................................................................................43. Ontologies................................................................................................54. Semantic Web Support for the B2B e-Commerce Lifecycle....................7

4.1. Lifecycle Stages.................................................................................74.2. Matchmaking.....................................................................................84.3. Negotiation........................................................................................94.4. Description Language for B2B E-Commerce Lifecycle....................11

4.4.1. Requirements........................................................................114.4.2. Why DAML+OIL is a good solution?......................................124.4.3. Modelling using DAML+OIL...................................................124.4.4. Operations over Descriptions.................................................174.4.5. Implementation......................................................................18

5. Next Generation e-Commerce...............................................................196. Integration..............................................................................................20

6.1. Unified Catalog................................................................................236.2. Mapping Rules.................................................................................24

7. Economic Impact of Evolving Semantic Web.........................................267.1. E-Commerce at Present..................................................................267.2. Semantic E-Commerce....................................................................27

8. Existing Applications and Frameworks..................................................288.1. KAON..............................................................................................28

8.1.1. Requirements........................................................................288.1.2. Conceptual Architecture.........................................................29

8.2. MOMIS............................................................................................318.3. SemanticEdge.................................................................................33

9. Conclusion.............................................................................................3510. Related Papers......................................................................................3611. References.............................................................................................37

3


1. Introduction

The competitiveness of companies active in areas with a high rate of change depends heavily on how effectively they acquire, maintain, exchange and access their knowledge, and whether they can deliver the right information to the right individual customer or business at the right time. Due to globalization and the impact of the Internet, many organizations are increasingly geographically dispersed and organized around virtual teams. Such organizations need knowledge management and organizational memory tools that encourage users to understand each other’s changing contextual knowledge and foster collaboration while capturing, representing and interpreting the knowledge resources of their organizations.

At the same time, competitiveness of companies will also depend on the products and mainly the services they offer. The growth of a wide range of e-commerce services, both to individuals and between businesses, 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-to-Customer (B2C) e-Commerce.

The Web in its’ current form is an impressive success with a growing number of users and information sources. Tim Berners-Lee, the inventor of the WWW, coined the vision of a Semantic Web in which background knowledge on the meaning of Web resources is stored through the use of machine-processable (meta-) data. The SemanticWeb brings structure to the content of Web pages, being an extension of the current Web, in which information is given a well-defined meaning. Thus, the SemanticWeb will be able to support automated, electronic services using semantics-based descriptions. These descriptions are seen as a key factor to finding a way out of the growing problems of traversing an ever expanding Web. In this sense, ontologies and metadata are becoming increasingly prevalent and important in a wide range of e-commerce applications.

The technical foundation of the SemanticWeb is RDF (Resource Description Framework) which provides a generic core data model. Several software components, such as parsers, schema and metadata editors, repositories, have already been developed. However, they generally fail to meet the requirements for sophisticated e-Commerce projects. To support advanced applications much more specialized, comprehensive and integrated tools are required.

2. Semantic Web

The term “Semantic Web” encompasses efforts to build a new WWW architecture that enhances content with formal semantics. This will enable automated agents to reason about Web content, and carry out more intelligent tasks on behalf of the user. ”Expressing meaning” is the main task

4


of the Semantic Web. Tim Berners-Lee has conceived a five-layer architecture for the Semantic Web which is presented as follows:

i. XML - The syntax layer: XML allows to markup arbitrary content by means of nested, attributed elements. The names of these elements don’t say anything about what the structure means, therefore further means are required for the Semantic Web and the role of XML is reduced to a syntax carrier.

ii. RDF - The data layer: RDF allows the encoding, exchange and reuse of structured metadata. Principally, information is represented by very generic means, i.e. directed partially labelled pseudographs. This graph may be serialized using XML. Contrary to XML, RDF allows assigning global identifiers to resources and allows referring and extending statements made in other documents. This feature is the main motivation for its use as a data layer.

iii. The ontology layer: The third basic component of the Semantic Web comprises ontologies. Ontologies describe formal, shared conceptualizations of a particular domain of interest. This description can be used to describe structurally heterogeneous and distributed information sources such as found on the Web. By defining shared and common domain theories and vocabularies, ontologies help both people and machines to communicate concisely, supporting the exchange of semantics and not only syntax. The basic building block for ontologies is concepts, which are typically hierarchically organized in a concept hierarchy. These concepts can have properties which establish named relations to other concepts. Several representation languages have been proposed for the specification of ontologies. Ontologies are presented in section 3 with more details.

iv. The logic layer: The logic layer consists of rules that enable inferences, e.g. to choose courses of action and answer questions.

v. The proof layer: A proof layer has been conceived to allow the explanation of given answers generated by automated agents. Naturally, we might want to check the results deduced by an agent, this will require the translation of its internal reasoning mechanisms into some unifying proof representation language.

3. Ontologies

Ontologies, that provide shared and common domain theories, will be a key for such a Semantic Web. They can be seen as metadata that explicitly represent semantics of data in machine-processable way. Ontology-based reasoning services for providing various services. Ontologies help people and computers to access the information they need, and effectively communicate with each other. Therefore they have a crucial role to play in enabling content-based access, interoperability, and communication across the Web, providing

5


it with a qualitatively new level of service. Semantic Web weaves together a net, linking incredible large part of the human knowledge and complements it with machine processability.

It is clear that if an e-services approach to e-commerce is to become widespread, standarisation of ontologies, message content and message protocols will be necessary. The popularity and press surrounding the release of XML has created great interest in standards within particular communities (organizations) that focus on representing and manipulating content. The dream is that these standards will enable consumers and B2B systems to mere accurately search information on the Web within these communities. The expansiveness and diversity of the Web creates a need for small set standards semantic primitives that have the same meaning and interpretation across communities. Such a standard set of primitives should take into account existing efforts in ontology, and in e-commerce contents standards.

The good news is that most of the existing workshops seem to have taken for granted that ontology is required for having web semantics. However they have mostly focused on the form rather than the content of these ontologies.

Nicola Guarino defines ontology to be an implemented artifact that attempts to constrain the intended meaning of a vocabulary by eliminated unintended models in the interpretation. Differentiating them only in terms of their ontological depth, we present spectrum of ontology kinds as follows:

i. Lexicon (Vocabulary with NL definitions)ii. Simple Taxonomyiii. Thesaurus (Taxonomy plus related terms)iv. Relational model (Unconstrained use of arbitrary relations)v. Taxonomy and relational models (Type restrictions and isA links, some

notion of inheritance)vi. Fully Axiomatized theory

Libraries, for instance, have had three interesting ontologies for a long time (Welty and Jenkins, 1999), though all of these are quite fundamentally affected by digitization and the web:

i. The card-catalog ontology, which has come to define metadata (author, title, publisher).

ii. The bibliographic ontology, which defines records for articles inside periodicals and other documents.

iii. The subject ontology, which carves the world into discrete subject areas.

As a result of the huge surrounding XML and in order to support e-commerce efficiently, other ontology efforts have been ongoing for some time:

i. General contents standards and ontologies (WordNet, CYC, ISO/BSR, CALS/UDEF)

ii. Process standards (NIST/PSL ontology, DARPA/CPR)iii. Product standards (ISO/STEP, UN/SPSC, RosettaNet)iv. Information media standards (Dublin Core, INDECS, CIDOC)

6


v. Conceptual modelling and representation standards (UML meta-model, EPISTLE).

4. Semantic Web Support for the B2B e-Commerce Lifecycle

In this section, we are going to present a lifecycle of a Business-to-Business e-commerce interaction, and show how the Semantic Web can support a service description language that can be used throughout this lifecycle. By using DAML+OIL, a service description language sufficiently expressive and flexible has been developed to be used not only in advertisements, but also in matchmaking queries, negotiation proposals and agreements. We also identify which operations must be carried out on this description language if the B2B lifecycle is to be fully supported. We do not propose specific standard protocols, but instead argue that these operators are able to support a wide variety of interaction protocols, and so will be fundamental irrespective of which protocols are finally adopted.

4.1. Lifecycle Stages

The lifecycle model, we present, helps us understand the interactions which take place between businesses engaged in e-commerce. This model follows the lifecycle of an interaction between two (or more) parties and has the following stages:

i. Matchmaking: A trader locates other traders that it could potentially do business with. This is done by some traders placing advertisements, and others making queries over these advertisements.

ii. 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 through an interchange of negotiation proposals describing constraints on an acceptable deal. The outcome of this is an agreement, specifying the terms that both parties consider acceptable. These terms could include a definition of the good or service being traded, prices, delivery date, etc.

iii. Contract Formation: The agreement is transformed into a legally binding contract.

iv. Contract Fulfilment: The parties carry out the agreed transaction, within the parameters specified in the contract. The transaction may be automatically monitored, and parties would be warned if any behaviour outside the agreed terms of the contract takes place.

In order to make this framework efficient and automated, interactions throughout this lifecycle must be standardised by the industries using it. Standarisation must take place at three levels:

7


i. Standards for business-specific ontologies which describe goods, services and contracts being traded. These ensure that when one trader uses a set of terms to describe a given good, another trader will be able to interpret then accurately.

ii. Standards for specifying the format of advertisements, proposals, contracts and other constructs which are used during B2B interactions. These standards would specify the syntax of these constructs, with the semantics being defined by the ontologies. Hence, these standards need not be business-specific.

iii. Standards that specify the protocols which traders use to interact with each other during different phases of the B2B lifecycle. These determine the messages that are sent back and forth containing the standards constructs described above.

The ARPA knowledge-sharing project was the first to tackle these standardisation issues. Ontolingua provides a tool for defining standard ontologies, KIF a language for representing information and KQML a set of messages for exchanging this information. The FIPA agent standardisation effort has defined a messaging language, and protocols for conducting B2B interchanges such as auctions. While some of the ideas developed in these efforts are clearly important (such as the notion of advertising and facilitators), they do not provide appropriate primitives for defining the constructs used in e-commerce.

In the following sections we focus on the first two stages of the e-commerce lifecycle above: Matchmaking and Negotiation. In addition, we describe different interaction protocols that can be used.

4.2. MatchmakingMatchmaking is the process whereby potential trading partners become aware of each other’s existence. A buyer wishing to purchase access to a service must locate potential service providers able to meet its needs. The buyer’s requirements may initially be not fully specified, and the service providers may be able to offer a range of services. The process of matchmaking should not result in the service becoming fully specified: this is the purpose of the negotiation phase which follows. Instead, the matchmaking phase should result in a buyer (or service provider) having a list of potential trade partners, each with an associated partially specified service description. This description defines the set of possible services the provider can offer which are of interest to the buyer. Using the notion of agents, we present a list of canonical examples using different protocol to accomplish this.

1. A buyer broadcasts its requirements to all agents in the system, irrespective of their abilities. Those agents able to meet the buyer’s need reply with information about what they are able to offer. This protocol is used at the start of Contract Net negotiation protocol [1].

2. Whenever a service provider joins the agent community, or alters its capabilities, it broadcasts a specification of the service it offers to all

8


agents. When an agent wishes to use a service, it contacts just those agents able to meet its needs.

3. An agent community has a centralised facilitator agent, which provides a yellow-pages service. Service providers send advertisements, consisting of descriptions of the service they offer, to the facilitator. Buyers send queries, and receive lists of providers potentially able to satisfy their requirements in response. UDDI [2] provides simple example of such a service. There are several variants on this protocol: buyers may be able to submit persistent queries, allowing them to be informed of new descriptions as they arrive. Buyers may be permitted to advertise alongside or instead of providers, and providers may be permitted to make queries.

4. An agent community may have several facilitator agents, each specialising in information about a given class of service. A buyer can either contact the appropriate facilitator, if they know which, or contact a single “meta-facilitator”, which will direct their query appropriately.

Despite these different agent architectures and communication protocols that can be used to achieve the matchmaking process, 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. These are usually, though not always, service providers. They may be buyers, advertising a service request, or may be marketplaces offering environments where such services can be traded. Similarly, agents adopting the seeker role wish to locate appropriate advertisers. Seekers can query a repository, via the repository host, and may be able to browse the repository.

As it is obvious, different protocols may be appropriate in different situations, depending on the expected message flow. Hence, it is not appropriate to standardise on a unique protocol for all agent systems. Instead, we should allow choice from a variety of such protocols, but standardise aspects of the roles which are common to all of them. Protocol specifications determine where information is stored, and how appropriate messages are passed to access it. Role specifications determine how the information is represented, accessed and used.

4.3. NegotiationThe 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, and as a result, many different protocols have been designed to carry this out. Negotiation protocols determine the interchange of messages which take place during the negotiation, and the roles by which the negotiation must abide.

One-to-one protocols include the shop-front, where a seller simply offers a good at a fixed price, and iterated bargaining, with buyer and seller

9


taking turns to exchange proposed agreements. One-to-many protocols include the English auction [3], the Dutch auction and the Contract Net. Finally, many-to-many protocols include the Continuous Double auction and the Call auction.

In the same way, we analysed the different protocols for matchmaking in the previous section, we can analyse the different negotiation protocols and identify roles and behaviours common at all. Hence, in each case there are at least two negotiation participants trying to make a deal with each other. In addition, there is at least one (possible more) negotiation host, responsible for enforcing the rules of the negotiation and ensuring it goes smoothly. Before negotiation can begin, the parties have already agreed roughly what the negotiation is about (usually as a result of the matchmaking process). 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 schema declares which fields are admissible and how their values are constrained. A proposal is a further refinement of the negotiation space that represents a configuration of parameters that would be acceptable to the submitter. The result of the negotiation process is an agreement.

That is a configuration of parameters that is non-ambiguous and can be used during the execution phase to instantiate the service. Therefore we can define the negotiation process as the process through which participants move from a pre-agreed negotiation template to an agreement, via an exchange of negotiation proposals. A single negotiation may involve many parties, resulting in several agreements between different parties and some parties who do not reach agreement. For example, a stock exchange can be viewed as a negotiation where many buyers and many sellers meet to negotiate the price of a given stock. Many agreements are formed between buyers and sellers, and some buyers and sellers fail to trade.

The three main actions/operations which the negotiation host carries out during the abstract negotiation process as presented earlier are summarized as follows:

1. Validation: When participants submit proposals, they first need to be validated with respect to the negotiation template. The validation step consists in making sure that the proposal is a more constrained form of the agreement template. That is, the constraints over the parameters in the proposal must be tighter that the corresponding ones in the agreement template. The constraints represent acceptable values to the proposing participant.

2. Protocol Checking: The proposal must be submitted according to the rules of the protocol which governs the way the negotiation takes place. These rules specify (among other things) who can make proposals, when they can be made, and what proposals can be submitted in relation to previous submissions. For example, auctions often have a ‘bid improvement’ rule that requires any new proposal to buy to be for higher price than the previous proposals.

10


3. Agreement Formation; If an agreement is to be made, there must be at least two valid proposals which are compatible with each other. Proposals are compatible if there is an identical fully-instantiated form of each.

In the following section, we declare a language to be sufficiently general and flexible to cover the matchmaking phase.

4.4. Description Language for B2B E-Commerce LifecycleIf the constructs and operations, declared above, are to be standardized, we wish to build the constructs from a declarative language for describing services. In addition, we need to show that this language can support the required operations over it. In the following sections, we present the necessary requirements and show how DAML+OIL satisfy most of them.

4.4.1.RequirementsA description language for B2B e-commerce lifecycle should satisfy the following requirements:

i. Description should offer a high degree of flexibility and expressiveness. Parties must have total freedom to create the service description. Different advertisers will want to describe their services with different degrees of complexity and completeness, and our language must be adaptable to these needs. Similarly, a negotiation proposal may be very descriptive in some aspects, but leave others less specified and open for further negotiation. Therefore, the ability to express semi-structured data is required.

ii. Descriptions need to share a common semantics. Moreover descriptions should be able to use vocabularies created by different standard bodies or industry sectors. Therefore support for interoperable ontologies is needed.

iii. Descriptions should easily lend themselves to performing the operations described in the negotiation and matchmaking sections. In particular, matching of advertisements with queries during matchmaking, validation of negotiation proposals against the negotiation template, and compatibility checking of two negotiation proposals to determine if an agreement can be made.

iv. Descriptions should express restrictions and constraints. Whether it is an offer or a request, it is often the case that what is expressed is not a single instance of a service but rather a conceptual definition of the acceptable instances. A natural way of describing this is by expressing constraints over the parameters of the service.

11


4.4.2.Why DAML+OIL is a good solution?DAML is a DARPA program aiming to provide a language and tools for the semantic web. One the most promising technologies it has produced so far is the DAML+OIL ontology language. DAML+OIL will serve as starting point for the design of the future Web Ontology Language from W3C.

DAML+OIL is a good candidate for the language we are looking for, and meets the requirements introduced in section above:

i. It provides a reasonable level of flexibility and extensiveness while keeping a nice balance between expressiveness and decidability. It offers support for types, which greatly enhances the expressiveness and modularity of the descriptions.

ii. DAML+OIL offers support for ontologies. It is almost integrated with tools such as OilEd [4] and Protégé [5] which make the generation of new ontologies for service descriptions much easier. Both tools are being worked on to support the full DAML+OIL specification.

iii. DAML+OIL is a good candidate for expressing descriptions that will be subject to the operations of matching, proposal validation and agreement formation. As we will present in the following sections, all the operations can be expressed in terms of the subsumption operation. DAML+OIL descriptions lend themselves very well to this operation and mature tools exist that can perform this on DAML+OIL descriptions.

iv. DAML+OIL offers some support for expressing constraints, while still maintaining decidability. Description logics constructors allow restrictions on objects, and XML schema allows unary constraints on datatypes. It is worth noting that DAML+OIL does not support n-ary datatype constraints, which may be a problem for real e-commerce applications (i.e. the shipping cost is waved when the sum of the length and width of the product is below a certain threshold).

Furthermore, because DAML+OIL is expressed in RDF and XML schema, it provides the added advantage that many resources and toolsets developed for these technologies can be applied to the B2B interaction lifecycle. In the next section, we explain how DAML+OIL can be used to describe the various descriptions that are used in the e-commerce lifecycle.

4.4.3. Modelling using DAML+OILService descriptions ontologies and domain specific ontologies will have an important role to play in order to achieve the semantic level of agreement between the various parties. For the sole purpose of the following examples, we define a simple service description ontology along with an ontology for the sale and deliver of computers. To keep the descriptions concise, we use the description logics notation which is equivalent to the RDF DAML+OIL syntax.

12


The description ontology: We use the Description class as a common superclass for Advertisement, Query, Template and Proposal. An agreement is an instance of a particular negotiation template.

The service ontology: Two services are defined in this ontology: Sales and Delivery. A Sale describes the sale of one Product through the object property, for a unit price and quantity given by the respective datatype properties.

We use the CompositeService class and the isComposedOf property to leave a choice to model composite services. When using the isComposedOf property to specify component services, the component service can only match if the main service also matches. Alternatively, a composite service can be modelled as a boolean combination of component services. In this case, any single component service can match. For instance, if we consider a service of sale and delivery of a computer, we can model it as a service of sale of computer which contains delivery as a sub-service or as the conjunction of both base services. In the first case, the service is considered as being primarily a service of sale, and would not be matched with delivery services whereas in the second case it would. In addition, we have chosen to model the service of Sale to include the buyer and seller roles as properties. In doing so, we allow the buyer to specify who they are and who they would like to do business with.

The PC ontology: The PC class is a subclass of Product and must have at most one Processor and one amount of memory.

13


The Participant ontology: Public information about prospective advertisers and negotiators is organized in an ontology, following the yellow pages model. The ontology is built from information that individuals and/or companies are requested to provide at registration time. Such information is then used at matchmaking and negotiation time to verify compatibility of advertisements and proposals. For instance a buyer requiring service provision from an ISO9001 certified company will only be matched with advertiser that declare to have ISO9001 certification. For the purpose of the examples, we define some disjoint classes R1, R2, and R3 that will represent participant identities.

Now we are going to give an example for each description type, using the ontologies just defined:

Advertisement

An advertisement is expressed as a DAML+OIL class defined as the boolean combination of a set of restrictions over abstract properties and datatype properties. In Description Logics terms, advertisements are expressed as T-Boxes.

The following example shows an advertisement where R1 would like to buy some PCs. More precisely, R1 is advertising for the Sale and Delivery service. The restrictions over the Sale concept are that:

i. items must be PCs with at least 128 Mb of memory; ii. quantity of PCs being bought will be less than 200; iii. unit price must be less than 700.

Since the advertiser is not interested in getting results of delivery services only, they chose not to describe their advertisement as being a Sale service and a Delivery service (i.e. by subclassing the intersection of Sale and Delivery), but rather as being a Sale service that has a Delivery service.

The restrictions on the Delivery service are the following:

i. goods must be delivered before the 15/12/2001; ii. goods must be delivered in Bristol.

In description logics notation, this advertisement can be written as:

14


As we can see from the ontology of the Sale service, we require both the buyer and the seller roles to be part of the information that is specified in the agreement. When submitting an advertisement, an advertiser who wants to play the role of a seller (resp. a buyer) should restrict the seller (resp. buyer) property to be its identifier. As the ontology shows, it is not forced to do so, but it is in its best interest. If it does not, it would be matched with advertisements of other sellers (resp. buyers). The seller (resp. buyer) can leave the buyer (resp. seller) property unconstrained, or can constrain it to be a certain subset or subcategory if they want to focus business on a certain set, for example, a pre-qualified set of trusted buyers. Advert2 above is made by seller R1 who wishes to avoid doing business with buyer R3.

Query

A Query is similar to an Advertisement. It is also a T-Box. We give an example of a Query where the seeker is looking for all buyers and sellers of PCs with an Athlon processor and who are also requesting or providing delivery.

Negotiation Template

After matchmaking, some parties can choose to enter into negotiation to determine the exact terms of service delivery. The negotiation template represents what is in common between all parties and is the starting point for negotiation. It also serves as a guide to scope the negotiation: negotiation proposals must comply with this template. In DAML+OIL terms, they would have to be subclass of this template.

15


Negotiation Proposal

As stated above, a negotiation proposal must be a subclass of the negotiation template associated with the ongoing negotiation. We now give an example of negotiation proposal which satisfies the template Template1:

Agreement

When a negotiation terminates with an agreement acceptable to both parties, this agreement must specify the service that is going to be exchanged in an exact and non-ambiguous manner. Hence, whereas a negotiation proposal is a T-box, an agreement must be a fully-instantiated instance of the negotiation template. For this reason, we model an agreement as an A-Box.

16


In figure above, we give an example in RDF syntax of an Agreement reached in a negotiation with Template1 as its negotiation template.

4.4.4.Operations over DescriptionsIn this section, we present specifications of the operations we presented in previous sections, together with examples of their operation, and identify the core functionality required by a reasoner to execute them.

Matchmaking: Let be the set of all advertisements in a given advertisement repository. For a given query or advertisement, Q, the matchmaking algorithm of the repository host returns the set of all advertisements which are compatible,

A set of descriptions are compatible if their intersection is satisfiable:

For example, consider the following advertisement:

The intersection of this advertisement with Advert1 above is satisfiable, as AgreementBetweenR1andR2 is an instance of both advertisements. Hence,

Validation: As we have seen previously, the negotiation host, on receiving a proposal , must initially check that it is valid. It is valid if it is a more constrained version of the negotiation template for this negotiation. In description logic, this means that the negotiation host must check that subsumes . Formally, this can be specified as:

17


Agreement Formation: Agreement formation requires the negotiation host to identify all pairs of proposals which are compatible. Protocol specific rules are then used to determine exactly which of these pairs are used to form an agreement, and how exactly to generate the final agreement. Compatibility can be determined using the compatibility operator defined for matchmaking. Hence, the first stage of agreement formation can be specified as follows:

Let be the set of all valid proposals currently registered with the negotiation host.

Note that only two atomic operations are required to define the operations specified above:

satisfiability

subsumption

A standard description logics reasoner is able to carry out both of these. Satisfiability lies at the core of such a reasoner, as all other reasoning or inference techniques are transformed into satisfiability checks. The subsumption operator is already defined by the DAML+OIL subClassOf, because our service descriptions are expressed as DAML+OIL classes (i.e. description logics concepts). A description logics reasoner can check whether two concepts subsume each other. Hence, a description logics reasoner provides a good platform to implement the operations required in the B2B e-commerce interaction lifecycle.

4.4.5. ImplementationAccording to the specification declared above, a prototype matchmaking system has been implemented based on the FaCT [6] reasoner, operating on services descriptions in DAML+OIL. A full description of the prototype can be found in [7].

5. Next Generation e-Commerce

18


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. In addition to the trust problem, the lack of automation is another major problem in present e-commerce. Currently, almost all companies offer, or plan to offer, products for purchase over the Internet using e-commerce. However, none of their e-commerce sites is truly automated: human intervention is required for browsing, selecting, ordering and paying for products. In other words, current e-commerce sites do not include semantic representations of data, services, processes, or business models that are readable by software programs (agents).

Three technologies will bring e-commerce to the next generation by increasing efficiency, compatibility, autonomy, and security:

XML: Create a Semantic Web Mobile Agents: Automate Electronic Transactions Security and Trust: Build a Web of Trust

The combination of a semantic web, trust, and mobile agent technologies will enable efficient and secure next-generation e-commerce in both business-to-consumer and business-to-business transactions.

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 e-commerce application domains. For example, XML-based Electronic Data Interchange (EDI) focuses on business-to-business e-commerce for retail transactions, and the supply-chain from manufacturer to wholesaler to retailer. Internet Open Trading Protocol (IOTP) specifies a consistent, interoperable environment for selling to consumers on the Web. Rules range from how to offer items for sale, to making payment choices, delivering products, generating receipts, and resolving problems.

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, negotiation, payment and delivery of a transaction.In the brokering phase, an agent roams the Web, evaluates available products, and decides what to buy and from whom to buy, based on a purchaser’s requirements and preferences. In the next phase, agents could negotiate deals autonomously according to a set of user constraints and strategic guidelines. In the payment and delivery phase, an agent may automatically fill out a form to place an order, process the order, and track the shipment of the product. So far, the final service and evaluation phase is the

19


area least explored for mobile agent applications. Nevertheless, mobile agents may find a promising future in this phase.

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, such as malicious agents and malicious hosts. A malicious agent is an agent that performs harmful actions, such as unauthorized access and alteration of local resources (data, system calls), or an overuse of a host’s local resources. A malicious host is an agent server that attempts to spy out and manipulate agent code or data and control flow, provide fake system calls, and execute agent code incorrectly, or to reverse engineer and manipulate agent code and trade secrets. Therefore, to provide trustworthiness, it is necessary that both agent and host are well protected.

At CRCG, a trusted mobile agent environment for e-commerce is under development. The current work develops a trust management system (TMS) to provide each entity involved in an e-commerce transaction with a comfortable and trusted environment. TMS is based on a trust-reputation model that is composed of policies and credentials. Credentials are statements issued by an entity about another entity, and a policy is a collection of rules for chaining together statements made in credentials. When combined, credentials and policies can express direct trust in an entity and delegate that trust to a third party. Moreover, trust in an entity in a certain domain can be derived from the reputation of this entity in such a domain. The reputation, in turn, is calculated and provided by trusted third parties (TTP).

6. Integration

Electronic marketplaces for Business-to-Business (B2B) electronic commerce bring together many online suppliers and buyers. In order to function, they require the integration of many product catalogs provided by the marketplace participants. Each individual participant can potentially use his own format to represent the products in his product catalog. 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.

A B2B mediator has to integrate both suppliers’ and buyers’ formats to allow them to do contracting with one another. This makes the problem of standard integration and interoperation a very important one. A number of high-level schema integration approaches exist, proposed by the knowledge

20


engineering and database communities. They either provide valuable but abstract guidelines for model integration, logical view, or database-specific algorithms. Given the dominance of XML, e-commerce integration technology must be based on the XML low-level integration architecture provided by the W3C1 consortium with XSLT and XPath languages.

An address is a simple business concept that occurs very often in e-commerce, and it is an important part of any B2B mediation system. Unlike most of the products, the structure of an address and the meaning of its components are understandable to everybody and this makes the explanation clear. The integration of address descriptions involves several interesting types of problems that also occur in product integration. We present seven address description standards and point to some problems that arise during catalog transformation.

xCBL 3.0 developed by Commerce One2, Inc. It 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. The Document Type Definition (DTD) for an address in the xCBL standard is the following:

<!ELEMENT OrganizationAddress ((AddressType)?, (ExternalAddressID), (POBox)?,(Street)?, (HouseNumber)?, (StreetSupplement1)?, (StreetSupplement2)?, (PostalCode)?, (City), (Country), (Region)?, (District)?, (County)?, (TradingPartnerTimezone)?)><!ELEMENT AddressType ((AddressTypeCoded), (AddressTypeCodedOther)?)>

cXML 1.0 developed by a large consortium of companies including Ariba and Microsoft. cXML is proposed for a similar purpose to xCBL and it targets document integration for B2B mediation. The Document Type Definition (DTD) for an address in the cXML standard is the following:

<!ELEMENT PostalAddress (DeliverTo*, Street+, City, State?, PostalCode?, Country)>

Internet Open Trading Protocol (IOTP) was developed within the Internet Engineering Task Force (IETF3) consortium, and it provides a standard framework for payment operations for Internet commerce. It is independent of any specific payment system. IOTP provides the data structures and communication protocols for payment transactions: purchase, refund, authentication, deposit, and other protocols that occur in electronic commerce. Security, authentication, and digital signatures are its main concerns. The DTD for an address in IOTP standard is the following:

<!ELEMENT PostalAddress EMPTY><!ATTLIST PostalAddress

xml:lang NMTOKEN #IMPLIEDAddressLine1 CDATA #IMPLIEDAddressLine2 CDATA #IMPLIEDCityOrTown CDATA #IMPLIEDStateOrRegion CDATA #IMPLIEDPostalCode CDATA #IMPLIED

21


Country CDATA #IMPLIEDLegalLocation (True | False) "False"

>

Open Applications Group Integration Specification (OAGIS) 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. The DTD for an address in OAGIS standard is the following:

<!ELEMENT ADDRESS (ADDRLINE*, ADDRTYPE?, CITY?, COUNTRY?, COUNTY?, DESCRIPTN?, FAX*, POSTALCODE?, REGION?, STATEPROVN?, TAXJRSDCTN?, TELEPHONE*, URL?, USERAREA?)>

Real Estate Data Interchange Standard (RETS) defines the interchange of real estate information. It defines a standard interface by which a client program may communicate with a property or other real estate data server. The specification 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 machine-interpretable property information. The data structures for the interchange are defined in the Real Estate Transaction Markup Language (RETML), where the DTD for an address is the following:

<!ELEMENT MailingAddress (StreetAddress)><!ELEMENT StreetAddress ((StreetNumber?, BoxNumber?, StreetDirPrefix?, StreetName, StreetAdditionalInfo?, StreetDirSuffix?, StreetSuffix?, UnitNumber?, City?, StateOrProvince?, Country?, PostalCode?, CarrierRoute?) | Unstructured)>

United Nation Standard Products and Services Code System (UNSPSC), is a hierarchical standard classification with five levels. The levels allow users to search products more precisely, because searches will be confined to logical categories and eliminate irrelevant hits, and it allows managers to perform expenditure analysis on categories that are relevant to the company’s situation. Each level contains a two-character numerical value and a textual description as follows:

XX Segment The logical aggregation of families for analytical purposes XX Family A commonly recognized group of inter-related commodity categories XX Class A group of commodities sharing a common use or function XX Commodity A group of substitutable products or services XX Business Function The function performed by an organization in support of the commodity

Ecl@ss is a standard for information exchange and is characterized by a 4-level hierarchical classification system with a key-word register of 12,000 words. Ecl@ss maps market structure for industrial buyers and supports engineers at development, planning and maintenance. Through the access either via the hierarchy or over the key words both the expert as well as the occasional user can navigate in the

22


classification. A unique feature of ecl@ss is the integration of attribute lists for the description of material and service specifications.

The representations of the same concept, the address, differ in each catalog. Product description can be encoded in XML with different ways of using XML tags, i.e. product features can be represented with XML attributes or with XML elements. Conceptually equal product properties can be encoded with XML elements with different names. The elements marked up with the same XML tags can have different semantics. The order of tags is also important in XML. Finally, some product properties can be described with different granularity level as required by the application.

6.1. Unified Catalog

Introduction of a mediating catalog, which is called the 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 instead of nxm.

For selecting the elements for inclusion in the UC, there are two opposing strategies:

The unified catalog stores the minimum core number of attributes for each product. The UC can change if we add a new catalogue. The addition of a more detailed catalog will not change the UC, but 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.

23

Integration with n+m rules

Integration with nxm rules


The unified catalog stores the maximum possible number of attributes. The UC can change if we add a new catalogue. The addition of a new catalog that is less detailed than the UC will not influence the latter. Addition of a more detailed catalog will require updates to the UC so that it will not be less detailed than the former.

The second strategy assumes that the UC is at least as detailed as any other catalog. This strategy establishes the main direction, but it may be reasonable to incorporate a number of exceptions. In the address example, the IOTP standard partitions street information into AddressLine1 and AddressLine2 fields, while other catalogs partition it as a Street name and a House number as presented in the UC, as we will show later. In this case the partitioning of information between AddressLine1 and AddressLine2 is not defined, and AddressLine1 is not required to be equal to Street and AddressLine2 to House. A user of the IOTP standard can freely partition his street and house information between these address lines. Weak defined semantics is the reason to not include redundant elements into the UC. Mapping between different standards has the following features:

The catalogs contain a kernel of well-mapped elements that are present in all catalogs and represent the most important features of the entity described.

The catalogs contain a number of mappings between rarely used elements that represent the features that are important for one agent but not for others and which may be included in the descriptions.

The catalogs contain a jumble of ill-defined and badly shaped concepts, which are grouped and mapped in one concept of the UC.

6.2. Mapping Rules

Mapping rules translate the descriptions between two catalog formats (C1 and C2), one of which is the UC. Four types of mapping between the attributes of C1 and C2 are possible:

One-to-one mapping is the simplest and most common type of mapping between the elements of C1 and C2. It occurs when the element of C1 has a semantic equivalent in C2, i.e. element Region in the xCBL standard is equivalent to StateOrRegion in IOTP, to REGION in OAGIS, to StateOrProvince in RETML, and to Province in the UC. Translation rules in this case are quite simple. If the element is encoded by an XML element in both C1 and C2, then the rule can be expressed as follows (from RETML to UC):

24


<xsl:for-each select="StreetAddress">…<Province><xsl:value-of select="StateOrProvince"/></Province>…</xsl:for-each>

Many-to-one mapping occurs when two or more elements from C1 have to be translated into one element in C2. 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"><ADDRLINE><xsl:value-of select="Street"/>, <xsl:value-of select="House"/></ADDRLINE>…</xsl:for-each>

This will map a pair (Street, House) of UC elements into the following OAGIS record:

<ADDRLINE>De Boelelaan, 1081a</ADDRLINE>

One-to-many mapping occurs when an element in C1 has to be translated into several elements in C2. ADDRLINE in OAGIS semantically corresponds to the pair of attributes Street and House in the UC. XSLT language provides the means to represent mapping on the level of XML elements and attributes, as well as possibilities of analyzing text inside an element in order to split the element into two or more pieces. For example, in the following fragment of an OAGIS address it is assumed that ADDRLINE contains street name separated from the following house number by a comma:

<ADDRLINE>De Boelelaan, 1081a</ADDRLINE>

First ADDRLINE is split into a pair of XML elements:

<ADDRESS><ADDRLINE><STREET>De Boelelaan</STREET><HOUSE>1081a</HOUSE></ADDRLINE>…</ADDRESS>

This can be done using the following XSLT rule:

<STREET><xsl:variable name="addrline" select="ADDRLINE"/><xsl:value-of select="substring-before($addrline,',')"/>

</ STREET ><HOUSE>

<xsl:variable name="addrline" select="ADDRLINE"/>

25


<xsl:value-of select="substring-after($addrline,', ')"/></ HOUSE >

Many-to-many mapping occurs when a piece of a description is spread over several elements without evident partitioning of information between them. Street, House, and PObox elements of the UC which maps into xCBL and RETML, 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 straightforwardly:

<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>…</xsl:for-each>

The ratio of the reverse mappings from the UC into the individual catalog reflects the partitioning of the straight mappings presented in the following table:

xCBL to UC IOTP to UC OAGIS to UC RETML to UC Ratio1:1 11 7 12 9 89%1:n 0 0 1 0 2%N:1 1 0 1 1 7%N:n 0 1 0 0 2%

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.

7. Economic Impact of Evolving Semantic Web

7.1. E-Commerce at PresentInformation asymmetries create situations where a better informed buyer gets the best value. As a specific example in the context of e-commerce, we take the case of an actual price search for a specific model of a camcorder: Panasonic PV-DV102 Digital Camcorder.

There are several websites that sell the exactly same product at different prices. A consumer, new to online purchasing may go to Amazon and buy the product for $599.99. A consumer who is more educated about internet searches is able to do a quick but detailed search through websites such as www.dealtime.com or www.pricegrabber.com. In this manner, they identify the same product being sold at http://www.tristatecamera.com for a cost of $509.99 and total with shipping for $533.22. The total savings is $66.77. There is a significant gain due to the information asymmetry, this is price dispersion. Price dispersion implies that households and firms must spend time and energy in looking for the best value. Search is considered an important and costly economic activity. As it is costly it will stop before the

26

http://www.amazon.com/


consumer has all the information she needs and may result in poor bargains. As the opportunity cost of a search increases with each additional unit

of time, the amount of search will be at the exact point where the marginal benefit equals the marginal cost. With an increase in the phenomenon of price dispersion (i.e. same good, different prices), the search amount increases.

Thus we see that a problem created by information asymmetry and price dispersion is that the costly economic activity of search takes place; which can be seen as a loss in precious resources as well as inefficiency in the market. Another problem is that consumers do not get the best value for their money if they place a high value on their time. When this happens, firms that offer good quality for the consumer dollars may lose out. They are also adversely impacted because it takes time for the market to absorb price reduction information. The current search engines are contributing somewhat to reduction in information asymmetry; but because they still require the consumers to be fairly adept in searches, the information asymmetry still results in price dispersion. A sampling of the search engines at http://directory.google.com/Top/Home/Consumer_Information/Price_Comparisons/?tc=1 indicated measurable price dispersion.

7.2. Semantic E-Commerce Millions of searches (over 300 million) are conducted everyday on the Internet by people trying to find what they need. This represents a huge cost in terms of people hours and an enormous drain of resources. The semantic web will transform millions of dumb (read “un-searchable”) web pages into intelligent, semantically annotated web pages where search for a particular product or service will be comprehensive and precise. In near term a fatal blow will be dealt to competition among search engines as all search engines will give relatively similar results, in long term agents will replace the search functions completely. Price differentials will also be driven down as a result. The additional advantage possessed by consumers with search engine skills will disappear while the premium that customer had been hitherto willing to pay for convenience will decrease.

Under this scenario, anyone looking for a Panasonic PVDV102 Digital Camcorder will know that the lowest price available for this product is $533.22. Consumers who then choose Amazon over Tristate Camera will be consciously paying the additional $66.67 for conveniences such as customer service, support, reliability etc. – advantages that Amazon has due to brand recognition. In this way, through the Semantic web, price dispersion is likely to decrease significantly. It may not reduce to zero as there will still be a difference in the perceived quality and reliability of the providers as well as the value placed on the search time and convenience. The significant decrease in price dispersion caused by the Semantic Web will increase the efficiency of the e-market and provide increased utility to consumers and e-firms.

27

http://directory.google.com/Top/Home/Consumer_Information/Price_Comparisons/?tc=1%20

http://directory.google.com/Top/Home/Consumer_Information/Price_Comparisons/?tc=1%20


8. Existing Applications and FrameworksIn this section, we are going to present a number of existing application and frameworks that have been developed to add semantics to e-commerce systems.

8.1. KAONThis section we present KAON - the Karlsruhe Ontology and Semantic Web Tool Suite. KAON is developed jointly within several EU-funded projects and specifically designed to provide the ontology and metadata infrastructure needed for building, using and accessing semantics-driven applications on the Web and on our desktop.

The Karlsruhe Ontology and SemanticWeb Tool Suite (KAON) builds on available resources and provides tools for the engineering, discovery, management, and presentation of ontologies and metadata. It establishes a platform needed to apply Semantic Web technologies to e-commerce and B2B scenarios. Because of that, important design goals were robustness and scalability, since these are key quality factors for any enterprise application.

8.1.1.RequirementsWhile building semantics-based applications within E-Commerce, Knowledge Management, Web Portals, etc. we have gained insight into application features that warrant a success. Based on that experience and in order to enabling reuse across projects, we have decided to build a framework addressing these issues. An extensive requirement gathering process was undertaken to come up with a set of requirements that such framework must fulfil. The following key requirements were identified:

Accessibility: A framework should enable loose coupling, allowing access through standard web protocols, as well as close coupling by embedding it into other applications. This should be done by offering sophisticated standard APIs.

Consistency: Consistency of information is a critical requirement of any enterprise system. Each update of a consistent ontology must result in a ontology that is also consistent. In order to achieve that goal, precise rules must be defined for ontology evolution and an evolution service implementing these rules has to be provided. Also, all updates to the ontology must be within transactions assuring the usual properties of atomicity, consistency, isolation and durability (ACID).

Concurrency: It must be possible to access and modify information concurrently. This may be achieved using transactional processing, where objects can be modified at most by one transaction at the time.

28


Durability: An almost trivial requirement easily accomplished by reusing existing database technology. A sophisticated storage system must offer facilities for replication: for often used ontologies redundant copies must be maintained to address scalability and availability problems.

Security: Guaranteeing information security means protecting information against unauthorized disclosure, transfer, modification, or destruction, whether accidental or intentional. To realize it, any operation should only be accessible to properly authorized agents. Proper identity of the agent must be reliably established, by employing known authentication techniques. Sensitive data must be encrypted for network communication and persistent storage. Finally, means for auditing (logging) of sensitive operations should be present.

Reasoning: Reasoning engines are central components of semantics-based applications. Our tools should have access to those engines which provide the reasoning services required to fulfil a certain task.

Mapping: Often multiple ontologies have to be supported by an ontology system. This support is only complete if means for mapping and mediating between heterogeneous ontologies are provided.

Discovery: We assume that data in the Semantic Web will be distributed. Therefore means for ontology-focused and intelligent discovery of metadata are required. Based on a semantic description of the search target, the system should be able to discover relevant information on the Web.

Internationalization: The framework should allow users to create ontologies and their instances in different languages and should support non-Latin character sets.

Formal ontology The formal semantics specified by ontology must be unambiguous and clear.

KAON tries to satisfy these requirements by introducing a Formal Model for Ontologies which out of the scope of this report. More information stand on paper [8].

8.1.2.Conceptual ArchitectureIn this section we introduce the general architecture that is the basis of KAON. We mainly distinguish three layers within our conceptual architecture, namely the data and remote service layer, the middleware layer and the applications and services layer. Figure below shows this layered architecture:

29


KAON Architecture

i. Applications and Service Layer: Application and service clients can be either (i) the components of the Java-Application-based OntoMat application framework or (ii) applications extending the web-based KAON-PORTAL and web site management framework. All application clients connect with the middleware layer via KAON API, an application programming interface accessing ontology elements. The API realizes the application model by providing a set of object-oriented abstractions of ontology elements. Application clients provide views and controllers for model realized by KAON API.

ii. Middleware Layer: The primary role of the middleware layer is to provide an abstraction for ontology access. Its second role is the dynamic instantiation and delegation of requests to the underlying external services layer. The first role is implemented by the KAON API, which isolates clients from different API implementations and provides a unified interface. For example, a transient ontology model is provided by implementing the KAON API on top of RDF files. This implementation may then be used for inmemory processing of ontologies stored in files and stand-alone deployment of tools. KAON RDF Server is a data source specialized in storing RDF data. It allows concurrent modification, supports transactions and persistence. Non-RDF data sources may be accessed using other implementations of the KAON API, thus creating an ontology compatible view of data not in a format according to Semantic Web standards. The dynamic instantiation and delegation of requests to services is out of scope for this paper. The implementation relies on the framework provided by the Java Management Extensions (JMX).

iii. Data and Remote Service Layer: This layer has several roles. First it offers access to physical data stores such as databases or file systems.

30


Second it groups external services such as reasoning engines, the aforementioned mapping engine etc. and announces availability to the middleware layer.

For more details about how the conceptual architecture has been implemented, stand on the paper [8].

8.2. MOMISA marketplace is the place in which the demand and supply of buyers and vendors participating in a business process may meet. Therefore, marketplaces are virtual communities in which buyers may meet proposals of several suppliers and make the best choice. So, marketplaces seem to be an interesting solution for e-commerce actors, because they show products, distributed by different vendors, but that may be compared since they have similar classification and they represent comparable products. In the e-commerce world, the comparison between different products is blocked due to the lack of standards describing and classifying them. Numerous proposals of classification standards have resulted in each supplier describing his own product in his own way.

The marketplace has to provide an environment using which to mediate among different standards used by the different participant to the transaction. In this way, each actor of the business process may exchange information using his own format. Therefore, the need, for B2B and B2C marketplaces, is to reclassify products and goods according to different standardization models.

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). Starting from source descriptions, the system generates an integrated global virtual schema of all data sources that is expressed in XML. MOMIS creates a global virtual schema by using different techniques, and by creating a common thesaurus of intra- and inter-schema relationships, which defines ontology of the terms used to represent the information provided by the different sources. The common thesaurus contains intra-schema relationships extracted by using inference techniques, inter-schema relationships obtained using the lexical WordNet system (which identifies the affinities between inter-schema concepts on the basis of their lexicon meaning) and inter-schema relationships explicitly given by the integration designer. MOMIS also enriches the thesaurus using the Artemis system, which evaluates structural affinities among inter-schema concepts and ODB-Tools Engine, a tool based on Description Logics, which performs checking consistency and subsumption computation.

MOMIS follows a “semantic approach” to information integration based on the conceptual schema, or metadata, of the information sources, and on the mediator architecture. In the MOMIS system, each data source provides a schema and a global virtual schema of all the sources is obtained in a semi-

31


automatical way. The global schema has a set of mapping descriptions that specify the semantic mapping between the global schema and the sources schema.

MOMIS Architecture

The system architecture is composed of functional elements that communicate using the CORBA standard. A data model, ODM, and a language, ODL are used to describe source schemas. ODL and ODM have been defined as subset of the corresponding ones in ODMG, augmented by primitives to perform integration. ODL is a source-independent language and it is used to describe heterogeneous schemas of data sources. In particular, ODL includes the following terminological relationships:

SYN (synonym of) is a relationship defined between two terms t i and tj

where titj that are synonyms in every involved source. BT (broader terms) is a relationship defined between two terms t i and tj

where ti has a broader more general meaning then tj. The opposite of BT is NT (narrower terms)

RT (related term) is a relationship defined between two terms t i and tj

that are generally used together in the same context in the considered sources.

To interact with a specific local source, MOMIS uses a Wrapper, which has to be placed over each source. The wrapper translates metadata descriptions of a source into the common ODL representation. The core of the MOMIS system is the Mediator. The Global Virtual Schema (GSB) module processes and integrates descriptions received from wrappers to derive the global shared schema by interacting with different service modules, namely ODB-Tools, an integrate environment for reasoning on object oriented database based on Description Logics, WordNet lexical database that supports the

32


mediator in building lexicon-derived relationships, and ARTEMIS tool that performs the clustering operation.

8.3. SemanticEdgeSemanticEdge 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.

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. Not only does the technology model products objectively, as might be done with a sophisticated database system, but we also model subjective quality judgments that consumers tend to use when conceptualizing the product space before them. These subjective, ad hoc, categories give the system the ability to communicate to the consumer in a human friendly way, in a way that is, in terms of the ontological commitments made by the system, similar to those of the typical customer or user. These human-oriented aspects are further enhanced by other technologies within the system, such as user models of consumer reaction to the dialog process as it happens.

SemanticEdge has also developed the sePDC to enable the acquisition of product instances. This extensional information has to conform to the imported ontology, and a number of ontology formats, including F-logic, can be accommodated. Here we are capturing some new instances of the Country concept from the CIA World Fact-book as shown below:

33


sePDC: Instances Example

SemanticEdge is among a growing number of companies that offer specialized technology for carrying out this information extraction task. A number of trainable and self-learning Artificial Intelligence (AI) technologies are encapsulated inside a single Information Extraction Engine. These AI technologies can be configured to map any number of different product catalogue formats onto a single intermediate, predefined product schema. From this schema, information can be exported into one or more formalized representations (including ontology languages). Export involves two basic steps:

Normalization: This can simply involve mapping one of a number of synonyms for a given piece of product information onto a single predefined symbol. It can also involve more complex normalization

34


rules such as converting numeric attribute values that can be given in one of a number of units onto a single standard unit.

Generation of Export Syntax: Through the attachment of formatting rules to the intermediate product schema, high flexibility in the export format can be achieved, and as noted, the information can be output to ontology languages, such as, for example, F-logic.

9. Conclusion

In the area of heterogeneous information integration, which is the core issue related to semantic e-commerce, many theoretic projects based on mediator architecture have been developed. In addition, the description languages differentiate according to the requirements and the implementation way. As we presented above, the first step have been made using XML as the basis language for B2B e-commerce services descriptions. Some of XML limitations have been overcome by RDF and DAML+OIL use.

However, most of the techniques presented above are still in research stage, without implemented tools or frameworks. Standardization and integration using agents is a real challenge for further work with great interest for B2B and B2C e-commerce lifecycle description improvement.

35


10. Related Papers

[1] R.G. Smith. The Contract Net protocol: High-level communication and control in a distributed problem solver. In Proceedings Computing Systems, pages 186-192, Washington, DC, 1979. IEEE Computer Society.

[2] UDDI. Universal Description Discovery Integration. Technical White Paper, 2000

[3] P. Klemperer. Auction theory: a guide to the literature. Journal of Economic Surveys, 13(3): 227-286, 1999

[4] S. Bechhofer, I.Horrocks, C.Goble, and R.Stevens, OilEd: a reason-able ontology editor for the semantic web. In Working Notes of the 2001 Int. Description Logics Workshop (DL-2001), pages 1-9, 2001.

[5] W. Grosso, H. Eriksson, R. Fergerson, J. Gennari, S. Tu, and M. Musen. Knowledge Modeling at the Millenium – The Design and Evolution of Protégé. In Proceedings of the 12th International Workshop on Knowledge Acquisition, Modeling and Management (KAW ’99), 1999.

[6] I.Horrocks. FaCT and iFaCT.In P. Lambrix, A. Borgida, M. Lenzerini, R. Möller, and P. Patel-Schneider, editors, Proceedings of the International Workshop on Description Logics (DL'99), pages 133-135, 1999.

[7] J. González-Castillo, D. Trastour, and C. Bartolini. Description logics for matchmaking of services.In Proceedings of the KI-2001 Workshop on Applications of Description Logics, 2001.

[8] Erol Bozsak, Marc Ehrig, Siegfried Handschuh, Andreas Hotho, Alexander Maedche, Boris Motik, Daniel Oberle, Christoph Schmitz, Steffen Staab, Ljiljana Stojanovic, Nenad Stojanovic, Rudi Studer, Gerd Stumme, York Sure, Julien Tane, Raphael Volz, Valentin Zacharias. KAON-Towards a large scale Semantic WebForschungszentrum Informatik FZI, 76131 Karlsruhe, http://www.fzi.de/wimInstitute AIFB, University of Karlsruhe, 76128 Karlsruhe, http://www.aifb.uni-karlsruhe.de/WBS

36

http://www.aifb.uni-karlsruhe.de/WBS


11. References

[9] 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

[10] Towards a Semantics for the Web Christopher Welty. Vassar College Computer Science Dept. Poughkeepsie, NY 12604-0462, USA

[11] 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

[12] Reduction of price dispersion through Semantic E-Commerce: A Position Paper Tanya Gupta and Abir Qasem

[13] 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.

[14] A Data Integration Framework for E-commerce Product Classification. S. Bergamaschi, F. Guerra and M. Vincini.CSITE-CNR viale Risorgimento 2, 40136 Bologna, Italy.

[15] A Layered Integration Approach for Product Descriptions in B2B E-commerce. Borys Omelayenko and Dieter Fensel.

[16] Next-Generation E-Commerce: XML+Mobile Agent+Trust. CG topics 4/2000. Dr. Jian Zhao, Thomas Blum.

[17] Enterprise-standard ontology environments for intelligent e-business. Alan Flett, Mike Brown

[18] 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.

[19] 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, 2001.

[20] http://www.semanticedge.com/

37

http://www.semanticedge.com/

http://informatik.uibk.ac.at/users/c70385/ftp/paper/EC-Web01.pdf

http://informatik.uibk.ac.at/users/c70385/ftp/paper/EC-Web01.pdf

http://www.cs.vu.nl/~borys/papers/Flairs01.pdf

http://www.csd.abdn.ac.uk/ebiweb/papers/flett.pdf

http://www.csd.abdn.ac.uk/ebiweb/papers/omelayenko.pdf

http://www.csd.abdn.ac.uk/ebiweb/papers/omelayenko.pdf

http://sparc20.dsi.unimo.it/prototipo/paper/iswc2002.pdf

http://informatik.uibk.ac.at/users/c70385/ftp/paper/omelayenko1.pdf

http://informatik.uibk.ac.at/users/c70385/ftp/paper/omelayenko1.pdf

http://semanticweb2002.aifb.uni-karlsruhe.de/proceedings/Position/gupta.pdf

http://semanticweb2002.aifb.uni-karlsruhe.de/proceedings/Position/gupta.pdf

http://www.semanticweb.org/SWWS/program/full/paper52.pdf

http://www.semanticweb.org/SWWS/program/full/paper52.pdf

http://www.cs.vassar.edu/faculty/welty/papers/dagstuhl-2000.pdf

http://delivery.acm.org/10.1145/520000/511458/p89-trastour.pdf?key1=511458&key2=5494184501&coll=GUIDE&dl=GUIDE&CFID=10726349&CFTOKEN=95757742

http://delivery.acm.org/10.1145/520000/511458/p89-trastour.pdf?key1=511458&key2=5494184501&coll=GUIDE&dl=GUIDE&CFID=10726349&CFTOKEN=95757742

€¦ · web viewsuch organizations need knowledge management and organizational memory tools...

Documents