Distributed Object-Oriented Schema to Share XML-based Catalogs among Business

Kimio Kuramitsu
Department of Information Science, Graduate School of Science,
The University of Tokyo
Ken Sakamura
Digital Museum Laboratory, The University Museum,
The University of Tokyo

About this Document

The paper was originally presented at WISE2000. We transformed and revised the original for Web readers.

The paper has been published by IEEE Press. I wish you to refer the original below.

K. Kuramitsu and K. Sakamura. Distributed Object-Oriented Schema for XML-based Electronic Catalog Sharing Semantics among Businesses. In Proceedings of the first International Conference on Web Information Systems Engineering, pages 81-90, June 2000.


The Internet commerce increases the demands of service integrations by sharing XML-based catalogs. We propose the PCO data model supporting semantic inheritance to ensure the synonymy of heterogeneous semantics among distributed schemas that different authors define independently. Also, the PCO model makes semantic relationships independent of an initial class hierarchy, and enables rapid schema evolution across the Internet business. This preserves semantic interoperability without changing predefined classes. We have also encoded the PCO model into two XML-base languages: PCO Specification Language (PSL) and Portable Composite Language (PCL). This paper demonstrates that intermediaries defining service semantics in PSL can automatically integrate multi-suppliers' PCL catalogs for their agent-mediated services.

1. Introduction

The HTML catalogs have been exploring electronic commerce, which make an appeal to web consumers by introducing beautified product information. [2] However, the lack of semantics in HTML makes it difficult for businesses to integrate Internet services across websites. More recently, XML, or semantic web, have become intensively anticipated, as a new modeling language for application integrations. [10,11,12,13,20]

The XML can define semantic specifications newly by using DTD (Document Type Definition), or the emerging XML Schema standard. However, an interoperability issue still remains with XML semantics.[3] For example, when different merchants define original DTDs/schemas for their catalogs independently, third parties cannot understand semantic relationships among them. For Internet mediators, schema interoperability, or automatically semantic sharing, is required to establish the integrated application of XML catalogs across websites. The purpose of this paper is to propose a new schema design model on XML, which enables distributed schemas to share semantics across the Internet.

We have designed a new commerce modeling language, called PCO (Portable Compound Object). [9] The contribution of the PCO model is that it enables semantic interoperability among distributed schemas (without ontology) by semantic inheritance based on the object-oriented model. The PCO model has unique modeling facilities such as controlled overriding and partial inheritance, in order to ensure the synonymy of sharing semantics in class hierarchy. Moreover, the PCO model is designed to support rapid schema evolution, keeping with the schema interoperability across Internet services.

We have also encoded the PCO model into two XML-base languages: PCO Specification Language (PSL), a schema language in the PCO model, and Portable Composite Language (PCL), an exchange format of semantic representations in the PCO model. This paper addresses that the polymorphic views of PSL classes enable agent-mediated services to automatically interrupt the semantic equivalence of PCL-based multi-vendor catalogs that different schemas specify.

The remainder of the paper is organized as follows. Section 2 describes the scope of this paper from viewpoints of semantic interoperability in Internet commerce. Section 3 defines the design of the PCO data model. Section 4 describes implementations including PSL, PCL, and its Java-based data processor. Section 5 demonstrates Internet service integrations using PCL and PSL. Section 6 compares our efforts with related works. Section 7 concludes the paper.

2. Semantic Interoperability on the Internet

Many companies have stored their business data in traditional RDMS systems for internal use. However, electronic commerce today is trying to integrate those heterogeneous data semantically to share with trading partners or consumers on the Internet. This section defines the scope of this paper from viewpoints of the semantic interoperability across Internet businesses.

2.1 Background

In Internet commerce, a centric and monolithic schema design is unacceptable because of the exhaustive diversity of goods and services. Distributed schemas and its integrations are therefore essential.

Semantic schema integration is an old database problem that has been intensively investigated in the context of heterogeneous multi-database systems. Nevertheless, no researches could reach any kinds of definitive breakthroughs. [5] This paper doesn't aim at solving such essentially semantic mismatches as homonyms, synonyms and different dimensions among various XML documents.

We focus on the difference in the lifecycles of data structure; the trading XML data is temporary, whereas the data stored in database systems is relatively permanent. Temporality of XML data is one of the key factors in proposing a new schema design model on XML, which enables distributed schema to share semantics across the Internet, rather than to adhere the integration of existing schemas. As a result, merchant can generate various formats of XML catalogs dynamically from heterogeneous data resource.

2.2 Goal

Let us consider a typical example to concrete semantic interoperability issues in Internet commerce. Suppose that two web merchants (a PC shop and a camera store) independently define DTDs/schemas for their XML catalogs, both of which use <price> tag for representing the price of products. In this case, should a third-party's shopping agent interpret two <price> as the same meaning?

The advantage of Internet lies in establishing new business collaborations without offline partnerships. Indeed, many kinds of agent systems have been integrated Internet services across websites. However, it is difficult for shopping agents to understand underlying meanings of real world autonomously, even if they can retrieves schema definitions from web sites. For example, some shops may define <price> including value-added tax, and others may exclude any tax.

The ultimate goal of this study is to extend a schema design model on XML, which enables third parties to automatically distinguish whether each tag in distributed schemas is the same meaning or not. In other words, using the proposed model, the PC shop and the Camera store can independently define <price> tags with the same meaning explicitly, for others.

2.3 Interoperability in the OO model

Our basic approach to the interoperability is to utilize class hierarchy in the Object-Oriented (OO) model. For example, if both of PC and DigitalCamera class are designed as the inherited classes of the common Commodity superclass, the meaning of each <price> is shared among PC, DigitalCamera and Commodity (see Figure1). Accordingly, a shopping agent can equally interpret the price of PC and Camera catalogs on the ground of class hierarchy.

Figure1: Semantic Inheritance. Name, Desc and Price are sharing common meanings among Commodity, PC and DigitalCamera, while the synonymy of two Memorys (in PC and DigitalCamera) is still ambiguous.

The schema interoperability based on class hierarchy is a simple mechanism, because it can only check homonymic mismatches. However, we consider that such simplicity is suitable enough to setup cross-site applications of Internet business rapidly.

2.4 Problem: Schema Evolution across the Internet

The OO-based semantic interoperability strongly depends on the design of an initial class hierarchy, although the OO model has essential difficulties in designing class hierarchy well embodied in underlying relations. Unfortunately, the relationships of goods and services vary dynamically. For example, suppose the appearance of new I/O interface connecting with PCs and digital cameras. In this case, both PC shop and Camera store will want to add new properties into their schemas as soon as possible, for the sake of representing the compatibility with each other.

The OO-based interoperability confronts the schema evolution problems, traditionally involving with hierarchy redesigns, change notifications and version controls. However, in widely distributed environments such as the Internet, the modification of super-class leads to the serious confusions for predefined sub-classes.

We must propose a design model that enables schema evolution both with keeping schema interoperability and without changing predefined classes.

3. PCO Data Model

XML (eXtensible Markup Language) is a portable format for semi-structured data on the Web. [18,19] The extensibility of XML allows each application to extend various data models (such as documents, tables and languages) on its syntax. We have designed PCO (Portable Compound Object) data model as a semantic modeling language for Internet service integrations. In this section, comparing with the generic XML standard model, we describe the three major extensions in the PCO model: discreteness of semantics and datatypes, object-oriented semantic definition and service-centric class sharing.

3.1 Semantics and datatypes

Generally, semantic representation is based on an attributed-value pair. For example, let us consider a numerical string '9.85'; it is meaningless for us, because we cannot understand what the value means exactly. However, if an author adds a semantic qualifier such as <price> to the number, we can regard it as price (at least without misunderstanding other dimension such as length and weight). In XML, accordingly, the semantic representation of price value is marked up as follows:

<price>9.85 </price>

In addition, XML/DTD define the structure of internal elements in <price>. Accordingly, we can understand the type of currency by referring to the DTD definition. However, if the type of <price> is statically defined as U.S. dollar, can an author describe the price with other currency such as Japanese yen at the same time?

We consider that the semantics should be independent of datatypes. We therefore designed that the PCO model can dynamically identify the type of value in each semantic representation. This means that the author can select datatypes freely at authoring time (see also type overloading). For example, the typed semantics of the price are described as follows.

<price type="number/currency-usd">9.85 </price>
<price type="number/currency-yen">1000 </price>

Note that the PCO (Portable Compound Object) model, as the name implies, is designed to represent composite semantic structures by "class" type.

In the PCO model, we call the fundamental structure of semantic representation as chunk, comprised of the three fields: name, type and value.

3.2 Schema and object-oriented classes

A PCO schema is a collection of predefined chunks (name and types) that specifies the semantics of a PCO instance. Shortly, only <price> declared in a schema is able to have a specific meaning that according to schema designer's intensions.

In the PCO model, we can define the schema as a union of object-oriented classes, or a subclass derived from classes. The class is the smallest unit of semantic specification that allows the designer to define a set of name-type pairs in the object-oriented manners.

The PCO model supports multiple inheritance, which permits a subclass to inherit properties from multiple parent classes. However, such a multiple inheritance causes name conflict that leads conflicted names to ambiguous meanings.

The originality of PCO is a semantical management of name conflicts; the PCO model fails class inheritance whenever a name conflict occurs except that all conflicted names are derived from the same parent class. This management ensures the semantic equivalences of the same names among superclass and subclasses. Also, the PCO model defines the behaviors of semantic inheritance as follows.

3.2.1 Partial Inheritance

Another uniqueness of the PCO model is to support partial inheritance for the reusability of names. The partial inheritance is a variation of class inheritance, which allows the designer to inherit some properties and to suppress others [14]. However, in the PCO model, a partially subclass is not defined as a child version of parent classes, in order to avoid a mess of a class hierarchy.

3.3 Service-centric class sharing

To exchange the semantics of PCO instances through networks, class sharing between a sender and receivers is required, because only chunks under class constraints can specify their meanings exactly; we can regard class as semantic context.

The generic XML standard, however, defines no rules to share DTDs/schemas across the Internet, except for the universal identification of DTDs by URI. Therefore, the question is ambiguous that who can design DTDs/schemas for whom? The service mediators, on the other hand, must know semantic definitions in advance, in order to program processing logics for suppliers' contents. The PCO model therefore defines the rule of class sharing between the following two parties in the context of electronic commerce.

The PCO model adopts a service-centric approach [1] to class sharing, where service mediators can define classes solely, and content suppliers create contents conformable to the pre-distributed classes (see Figure2). This approach allows mediators to interrupt properties only that they define or understand in advance and to ignore others. The elimination of class distribution from suppliers makes it possible for mediators to interrupt distributed contents automatically.

Figure2. The basic concept of service-centric class sharing (left) and the n-tuple extension in the PCO model (right).

The basic service-centric model has some limitations to content flexibility against individual suppliers. The originality of the PCO model is to extend class-content relationship from single-pair to multiple dynamic n-tuple; suppliers accordingly can coordinate content schemas by selecting and combining classes that multiple mediators define for their own services. This means that each PCO instance contains a schema definition as a union of predefined classes.

4. Implementation of PCO Language

We have encoded the PCO data model as two XML-based languages: PSL (PCO Specification Language) and PCL (Portable Composite Language). This section describes the design of PSL and PCL, including Java-based implementation of its data processor.

4.1 Architecture

The PCO language is comprised of two kinds of language. The PSL defines classes or datatypes to specify PCO instances, while the PCL represents the structure of PCO instances as an XML[2]-based format. However, according to traditional semi-structured data models [16], PSL classes do not strongly constrain the full structure of PCL instances; instead, each of PSL classes are worked as a view (i.e., external schema) of a polymorphic PCO schema. Through these views, PCO data processor can access PCO instances semantically. Figure 3 shows the three-layer architecture of the PCO language.

Figure3. The three-layer architecture of the PCO Language.

4.2 PCO Specification Language

The PSL is a specification language that allows the designer to define classes and datatypes. This subsection mainly describes class definition in PSL.

4.2.1 Basic Class definition

In PSL, the designer can define a class by using <ClassDef> module, which includes semantic definitions such as super classes, a set of predefined chunks, and other documentation information (e.g., designer's names, class descriptions, and dates). The following source is an example of PSL-based class definitions.

<ClassDef name="PersonalProfile">
 <ChunkDef name="Name"/>
 <ChunkDef name="Affiliation"/>
 <ChunkDef name="PostalCode"/>
 <ChunkDef name="Address"/>
 <ChunkDef name="Phone" type="string/phone"/>
<ClassDef name="NameCard">
 <super class="PersonalProfile"/>
 <ChunkDef name="Photo" type="image/jpeg"/>

4.2.2 Explicit declaration of chunk synonymy

Name conflicts in multiple inheritance result in ambiguous meanings; the PCO model aborts class inheritance at conflict case, because conflicted names are interrupted as homonym. However, such a strict interruption decreases the flexibility of class combinations. For reasons of improving the flexibility, we introduce an <equiv> scope to explicitly declare the synonymy of the same named chunks in other classes.

In the following example, chunks (PostalCode, Address and Phone) within the <equiv> scope in Contact are defined as the same meaning with those in PersonalProfile respectively. In other words, Contact is not child of PersonalProfile, but some chunk semantics in Contact are partially inherited from PersonalProfile.

<ClassDef name="Contact">
 <equiv type="PersonalProfie">
  <ChunkDef name="PostalCode"/>
  <ChunkDef name="Address"/>
  <ChunkDef name="Phone"/>
 <ChunkDef name="Email" type="string/email"/>

4.3 Portable Composite Language

Portable Composite Language (PCL) defines an XML-based serialization format of a PCO instance.

4.3.1 Semantics and Structure

Since XML is based on SGML/DTD document model, XML tags are used to represent not only semantics but also data structures or processing logics (e.g., <table> and <font> in XHTML). We have designed a PCL instance as the combination of the three different-purpose tag sets (i.e., namespaces). The following source is the example of a complete PCL instance.

<?xml version="1.0" ?>
<d:PCO xmlns:d="urn:x-pco-structure" 

  <d:class name="PersonalProfile"
  <d:class name="NameCard" href="http://www/classes/NameCard.psl"/> 
  <d:class name="Contact" href="http://www/classes/Contact.psl" /> 

 <m:Language> en </m:Language>
 <s:Name lang="en"> Kimio Kuramitsu </s:Name>
 <s:Affiliation lang="en"> University of Tokyo </s:Affiliation>
 <s:Photo type="image/jpeg">
  <d:file encoding="base64 ">
 <s:PostalCode> 113-0033</s:PostalCode>
  7-3-1 Hongo Bunkyo-ku Tokyo, Japan 
 <s:Phone type="string/phone"> 
 <s:Email type="string/email"> 
  1. PCO structure (d): a static tag sets for representing predefined data structures (for example the above <d:file> element encodes a file object on the XML syntax). In PCL, any PCO structured data (including a PCL object itself) can be qualified with chunk semantics.
  2. Meta semantics (m): a static tag sets for representing the common information to control each PCL object.
  3. Chunk semantics (s): a dynamic and extensible tag sets for representing semantics of a string value or PCO structure. Although each chunk belongs to multiple semantic contexts (PSL classes), the aggregation of them maps a single non-polymorphic XML namespace as a virtual PCO schema. (The PCO schema is also designed to be compatible with XML schema by automatic generation from PSL classes.)

Note: this paper usually use "d:", "m:" and "s:" prefixes for representing PCO structure, Meta semantics and chunk semantics relatively.

4.3.2 Schema Coordination

In PCL, an author can define a schema that specifies the full semantics and structure of instance itself, although his definition are limited as a combination of predefined classes. The PCL prepares <m:Schema> module to coordinate PCO schema virtually. Of course, this coordination is applied to semantic inheritance scheme with the controlled overriding and multi-typed overloading in name conflicts.

4.4 PCO Data Processor

We have implemented the prototype system of PCO data processor, by using Java2 (JDK1.2) programming language. The processor reads a PCL file, parsing XML syntax and PCL-extended structure, and then canonicalizes chunks as a tree-based structure. The uniqueness of the processor is that it allows software modules to access chunks only through the view of class constraints.

The following example is an excerption of sample source, in which Java-based applications access to chunks' value semantically.

try {
  PCO pco = PCLParser.load("file.pcl");
  if(pco.openClass("NameCard") {
    String name = pco.getString("Name"); 
     // name --< "Kimio Kuramitsu"
    Image photo = pco.getImage("Photo");
    String email = pco.getString("Email");
     //  --< throw OutOfClassException
  }catch(OutOfClassException e) { 
  }catch(IOException e) {}

We have already developed a GUI-based PCL editor embedded in the processor (Figure 4).

Figure4: PCL Editor. a GUI-based editor to author PCL templates from multiple class views.

5. Sample Session

We have already described various kinds of product catalogs (e.g., books, personal computers, tickets, stationary and clothes) by using PSL and PCL. The section evaluates the design of the PCO model and its implementations (PSL and PCL) by using the sample description in the experimental project sponsored by JIPDEC[3].

5.1 Scenario

In the original JIPDEC's experimental environment, there were two content suppliers such as a ticket vendor and a hotelkeeper on the Internet. The ticket vendor defines ConcertTicket class as a subclass of ProductCatalog. Similarly, the hotelkeeper extends HotelVoucher class from ProductCatalog. (Figure 5 shows an example of PCL-based catalog with mixed HTML catalog.) Moreover, we have developed a shopping agent service, in which a customer can place orders for any PCL instances of ProductCatalog across merchant sites.

Figure5(a): a web browser view of HTML/PCL catalog without any disarranges of HTML layout.

<title> Hotel Reservation </title>
<d:PCO xmlns:s="urn:x-pco-semantics" xmlns:m="urn:x-pco-metadata" 
<h2><s:Name type="string">Teikoku Hotel </s:Name></h2>
<h4>Winter Free Plan</h4>
<blockquote><font color="#b2002c">Let's enjoy at Teikoku hotel 
  about beautiful Japanese winter. </font></blockquote>
<table width="100%">
<tr><td> Location </td><td><s:Area type="string">
  Ginza, Tokyo </s:Area></td></tr>
<tr> <td> Regular rate </td><td> 
  <s:Price type="number/currency-yen">30000</s:Price> yen 
<dl> <dt>Contact</dt>  
<dd><b>Address: </b> <s:Address type="string/address">
  1-1-1 Uchisaiwai-cho, Chiyoda-ku, Tokyo, Japan </s:Address></dd>
<dd><b>Telephone: </b> <s:Phone type="string/phone">
 <d:class name="ProductCatalog"
<d:class name="HotelVoucher"
<hr>LastUpdate: 1999.

Figure5(b): a HTML source mixed with PCL semantics.

In addition to the environment, let us here consider the following scenario in that we need schema evolutions with keeping the interoperability among businesses. (Figure 6 illustrates the overview of the scenario)

Figure6: The Scenario for Sample Description (based on the JIPDEC experimentation)

Suppose that a World-Cup promoter opens an intermediary service on the Internet, in which he wants to mediate tie-in products and services with special privileges for World-Cup participants. Shortly, he wants to add common properties for the ticket and hotel catalogs.

Ultimately, the promoter must define description constraints (i.e., a class) for unspecific kinds of product as well as ticket and hotel. Of course, he cannot redesign ProductCatalog directly, because additional properties for World-Cup are temporal and specialized.

5.2 Creation of WorldCup2002 class

The promoter is interpreted as a service mediator in the PCO model. Thus, he can create a new class that defines chunk semantics specifying requirements (such as properties of privileges) for his service, as follows:

<ClassDef name="WorldCup2002">
 <equiv type="ProductCatalog">
  <ChunkDef name="Name"/>
  <ChunkDef name="Description"/>
 <ChunkDef name="AppliedTo"/>

5.3 Catalogs for WorldCup2002

The hotelkeeper prepares a special dinner during the World-Cup season, and wants to give publicity to Internet customers at the promoter's site. He can create a new hotel catalog as follows:

<?xml version="1.0" ?>
<d:PCO id=".. ">
  <d:class name="ProductCatalog"
  <d:class name="HotelVoucher"
  <d:class name="WorldCup2002"

 <s:Name lang="en">
  Tokyo Hotel (for WorldCup 2002)
 <s:Description lang="en">
  We prepare a special dinner for c
 <s:Photo type="image/jpeg">
  <d:file href="http://c"/>

  <!-- (other chunks in HotelCatalog) -->

 <s:Price type="number/currency-yen">
 <s:AppliedTo lang="en">Travelers

5.4 Service Interoperability

The promoter can automatically interrupt all the PCL instances of WorldCup2002 class without understanding other chunk's meaning (such as Price and Photo). On the other hand, the existing service mediator can deal with PCL instances even if the instances contain WorldCup2002 constraints or not. For example, the shopping agent can still interrupt any PCL instances of ProductCatalog.

Note that we would like to refer the readers to our paper [8] about our prototyped system of multi-purpose shopping agent.

5.5 Summary

The scenario demonstrates the following results about the PCO model, PSL and PCL.

6. Related Works

We here discuss related works from the following three viewpoints: domain-specific commerce language, ontology-based interoperability and object-oriented schema for XML.

6.1 Domain-specific commerce language

Today, there are many emerging XML-based commerce languages, such as XML/EDI, ICE, OBI, and RosettaNet. [10,11,12,13,20] These languages are well employed in specific business domains, because central organizations define semantic specifications for their business domains. For example, XML/EDI is an XML-version of ANSI X12 EDI business data messages; RosettaNet, on the other hand, defines how to exchange PC product catalogs among manufactures, distributors, and resellers.

The PCO is unique in that it requires no centric coordinators to share schemas across Internet businesses. This decentralized sharing expands the applications of PCO language more widely.

6.2 Ontology-based Interoperability

Ontology, or a semantic dictionary, is a super description that defines relationships between independent schemas or data types. Also, not a few languages have been proposed to apply ontology into heterogeneous schema integrations. [7] For example, MMF is a typical commerce language (although its syntax is not XML-based) that supports an ontology layer to ensure the interoperability among distributed schemas. [17] More recently, Common Business Library (CBL) is proposed as a pragmatic ontology to be automatically mapped with the domain-specific languages, such as XML/EDI, OBI, and RosettaNet [12].

Theoretically, ontology can integrate any mismatches of heterogeneous semantics/structures across various domains. However it is difficult to maintain ontology effectively in widely distributed environments, because the increase of distributed schemas makes their relationships more complicated.

We consider that the incompatibility in schema sometimes needs to represent deliberate unpartnerships between competitive businesses. It is therefore concluded that the PCO model supports enough interoperability, because it allows partner companies at least to share common semantic constraints that they desire.

6.3 Object-Oriented Schema for XML

The object-oriented (OO) model and its class reusability have been widely popularized in programming languages and database systems. In XML, many object-oriented schema languages are proposed as alternatives to XML/DTD: RDF schema, SOX, and XML Schema. [1, 4, 6] These schemas, as well as PSL classes, makes it easier to extend a new schema by reusing predefined schemas.

The originality is that PCO schema and PSL class are designed to support not only reusability but also several encouragements for semantic inheritance, including negative overriding and partial inheritance. To our knowledge, the attempt to semantic inheritance across the Internet has not been reported before in the XML technical efforts.

7. Conclusion

The Internet commerce increases the demand of cross-site service integrations sharing XML-based catalogs. In addition, the diversity of products and services also essentially requires the semantic integrations of distributed schemas.

The main contribution of the PCO model is to propose an approach to semantic interoperability without ontology. The PCO originally supports various object-oriented features such as controlled overriding, multi-typed overloading, and partial inheritance to ensure the synonymy of inherited semantics among schemas/classes that different authors define independently. Moreover, schema coordination in the instance layer makes semantic relationships independent of an initial class hierarchy, and also enables rapid schema evolution across the Internet with keeping semantic interoperability but without changing predefined classes.

We have also encoded the PCO model into two XML-base languages: PCO Specification Language (PSL) and Portable Composite Language (PCL). This paper demonstrates that agent-mediators that define service semantics in PSL can automatically integrate multi-suppliers' PCL catalogs for their cross-site services.

This paper mainly focuses on the PCO model and its semantic integrations. The PCO language also supports other commerce modeling facilities, including content supply-chain of compounded PCL objects and authorized modifications of PCO schema and instances. We would like to continue discussions for establishing PCO-based electronic marketplace on the Internet.


The authors would like to thank Mr. Tadashi Murakami, Mr. Hajime Matsuda and Mr. Vikram Kant Upadhyay (the University of Tokyo) for useful comments and suggestions that helped in improving an earlier draft of this paper.


  1. Andrew Davidson, Matthew Fuchs, Mette Hedin, Mudita Jain, Jari Koistinen, Chris Lloyd, Murray Maloney, and Kelly Schwarzhof. Schema for Object-Oriented XML 2.0. W3C Note, July 1999.
  2. Arie Segev, Dadong Wan, and Caroline Beam. Electronic catalogs: a technology overview and survey results. In Proceedings of CIKM'95, 1995.
  3. Aris M. Ouksel and Amit Sheth. Semantic interoperability in global information systems: a brief introduction to the research area and the special section. ACM SIGMOD Record, Vol. 28, Num.1, March 1999.
  4. Dan Brickley, R. V. Cuha, and Andrew Layman. Resource description framework (RDF) schema specification. W3C Proposed Recommendation, March 1999.
  5. Evaggelia Pitoura, Omran Bukhres, and Ahmed Elmagrmid, Object Orientation in Multidatabase Systems. ACM Computing Surveys, Vol. 27, No.2, June 1995.
  6. Henry S. Thompson, David Beech, Murray Maloney, and Noah Mendelsohn. XML schema part 1: structures. W3C Working Draft, September 1999.
  7. Howard Smith and Levin Poulter. Share the ontology in XML-based trading architectures. Communication of ACM, Vol. 42, No.3, March 1999.
  8. Kimio Kuramitsu and Ken Sakamura. Digiket: Decentralized Architecture for Worldwide Electronic Market. In Proceeding of IEEE COMPSAC99.
  9. Kimio Kuramitsu and Ken Sakamura, d: EC content description language supporting distributed schema across the Internet. Transactions of Information Processing Society of Japan, Vol. 41 No.1, January 2000. (in Japanese)
  10. Neil Webber, Conleth O' Connell, Bruce Hunt, Rick Levine, Laird Popkin, and Gord Larose. The Information and Content Exchange (ICE) protocol. W3C Note, October 1998. Available at http://www.w3.org/TR/NOTE-ice.
  11. RosettaNet. Available at http://www.rosettanet.org/
  12. Robert J. Glushko, Jay M. Tenenbaum, and Bart Meltzer. An XML framework for agent-based e-commerce. Communication of ACM, Vol. 42, No.3, March 1999.
  13. The OBI Consortium. Open buying on the Internet (OBI): Technical specifications release V2.0. Available at http://www.openbuy.org/.
  14. Oscar Nierstrasz. A survey of Object-Oriented Concepts. Object-Oriented Concepts Databases, and Applications, Frontier Series, ACM Press, 1989.
  15. PCO/EC Forum, available at http://tron.um.u-tokyo.ac.jp/EC/.
  16. Peter Buneman. Semistructued data. In Tutorial of ACM PODS'97, at http://www.cis.upenn.edu/~db/.
  17. Sakata, Tada, and Ohtake. Metadata mediation: Representation and protocol. In Proceedings of 6th International World Wide Web conference, Apr. 1997.
  18. Tim Bray and Jean Paoli. Extensible Markup Language (XML) Specification 1.0. W3C Recommendation, February 1998. Available at http://www.w3.org/TR/REC-xml.
  19. Tim Bray, Dave Hollander, and Andrew Layman. Namespaces in XML. W3C Recommendation, January 1999. Available at http://www.w3.org/TR/REC-xml-names.
  20. XML/EDI. Available at http://www.xmledi.com/.