3. An Experimental Study
3.1 A Prototype System
3.1.2 Ontology Editor
The DTD Importer also provides an ability to parse the entity’s metadata.
Through parsing the metadata, we can enrich our document ontology. This program will read the entity information using a batch approach as shown in Figure 7.
Figure 7: The B2B DTD Importer (This Research)
3.1.2 Ontology Editor
We build a process ontology template. The basic classes and properties of the B2B process can use this template to develop the ontology as shown in Figure 8 and Figure 9. Business constraints also can be edited through the ontology.
Figure 8: The Basic Classes of a Process Ontology (This Research)
13
Figure 9: The Basic Properties of a Process Ontology (This Research)
3.2 A RosettaNet Experiment
RosettaNet consortium (RosettaNet Consortium, 2004) is a non-profit consortium of more than 500 organizations working to create, implement and promote open eBusiness standards and services. RosettaNet tries to establish a common language and a standard processes for the electronic sharing of business information. In order to implement the experimental scenario, we install a set of RosettaNet core specifications. We will explain each in the following sections. These
14
core specifications include RNIF, PIP, and Dictionary.
We chose the RosettaNet Partner Interface Process™ (PIP) 3A4, the purchase order request process, to be the experimental public process, which is mostly implemented and installed. Purchase order process is corresponding to Company W’s sales order flow. The PIP3A4 specification provides the details of the purchase order process property and constraint. The structure and content of the business documents to be exchanged in RosettaNet is specified in DTD and XML Schema.
We need to build the process ontology from the PIP specification and to create the document ontology from the DTD and message guidelines.
Step A - to analyze the existing business process
We analyze the current business process of purchase order between Company W and its buyers. In the use case diagram, we see two kinds of participants: Company W and buyers. Company W has the partner role of “Seller” and customers play the role of “Buyer”. In the sequence diagram, we see two business documents that are exchanged. They are the “Customer Order” and “Customer Order Ack”. There are three main activities in the sales order flow such as “Send A Customer Order”,
“Check Inventory” and “Confirm Customer Order”.
Step B - to develop the B2B EC-standard-compliant business process The RosettaNet specifies PIP3A4 exchanging three messages such as
“PurchaseOrderRequest”, “PurchaseOrderConfirmation” and
“ReceiptAcknowledgment”. PIP3A4 further specifies two more activites, that is, ”Request Purchase Order” and “Confirm Purchase Order”. They represent the standards to be complied with.
Step C - to represent the existing firm ontology C.1 to design current business process ontology
Company W and its buyers are B2B_Partner. We add them as the instances of B2B_Partner. The instance’s naming rule should be pre-established. We create the domain ontology of each business process for Company W and its buyers. In Figure 10, we show the B2B_Process “Customer Order”.
Figure 10: Ontology Instance Creation (This Research)
15
C.2 to model current business document ontology
We use the DTD importer in the prototype to convert and store the DTD files into document ontology repository. The converted data result is shown in Figure 11.
Figure 11: Existing Public Process Ontology (This Research)
16
Step D - to represent B2B EC standard ontology D.1 to design RosettaNet process ontology
The PIP3A4’s ontology is built from the standard specification. The PIP restrictions must be considered. For example, the PIP3A4 specification defines when to enable a buyer to issue a purchase order and when to enable a seller to acknowledge the receipt of order, and even down to the line item level. No matter how and if the order is accepted, rejected, or pending. The provider's acknowledgment must include the information about delivery expectation. Further, when a provider acknowledges that a product line item on the purchase order document is “pending”, the provider must later use PIP3A7, "Notify of Purchase Order Acknowledgment" to notify the buyer when the product line item is either finally accepted or rejected. The PIP specification also describes the process start state to be one of the following: Purchase Order Request Exists, TPA Exists, Requesting Partner Approved, Responding Partner Approved, Buyer Authorized, Purchase Order Request Valid, or Purchase Order Request Non-Repudiated as shown in Figure 12. One of the above must be returned as the initial date started.
Figure12: Newly Generated Classes and Properties (This Research)
17
D.2 to model RosettaNet document ontology
The PIP3A4’s DTD files and message guideline give the details of each entity in the standard document. We again use the DTD importer to convert and load the specification. We edit the constraints for each entity. The DTD importer can intelligently determine and set up the business property domain and domain range properly. A RosettaNet PIP definition can be added as the instance’s comment as shown in Figure 13.
Figure 13: Created Instances of PIP3A4
18
Step E - to merge ontology
In the merge of ontologies, the purchase order has a unique number as the identity of the order. In this experiment, the current purchase order number is named
“orno”. However PIP3A4 uses the field “ProprietaryDocumentIdentitfer” as the purchase order number. We resolve the inconsistency via link analysis.
When we generate the current business ontology and the B2B standard ontology, we can merge them in the system. Although Protégé provides the merge, we need to adjust the detail correspondence rules to link the relationship between two ontologies.
The ontology editor provides the test function helps us check the ontology consistency. The purchase order usually has a unique number as the identity of the purchase order. The current order number is named “orno”. However, PIP3A4 names the field as “ProprietaryDocumentIdentitfer”. We use the owl:sameAs to link these two classes as equivalent.
Step F - to represent ontology
We generate a set of HTML files that contain the content of ontology. Users browse the ontology in a user-friendly interface. It minimizes the risk of ontology to be altered. With the hyperlink, we can trace any related classes and properties.
Step G - to test ontology
We validate the ontology with the Protégé test ontology function.
3.3 An ebXML Experiment
The second experiment we have conducted is a realization of ebXML in the case of purchase order. ebXML (ebXML, 2004) was started in 1999 and developed by the Organization for the Advancement of Structured Information Standards (OASIS).
OASIS is a non-profit, international consortium that drives the development,
19
convergence, and adoption of eBusiness standards. The consortium produces more Web services standards than any other organization along with standards for security, eBusiness, and standardization efforts in the public sector and for application-specific markets. Founded in 1993, OASIS has more than 3,500 participants representing over 600 organizations and individual members in 100 countries (OASIS Consortium, 2004). ebXML is a modular suite of specifications that enables enterprises of any size and in any geographical location to conduct business over the Internet. By using ebXML, companies can exchange business messages, conduct trading relationships, communicate data in common terms and define and register business processes. In order to implement the experimental scenario, we install a set of ebXML core specifications. We will explain each in the following sections. These core specifications include the business process, the core component, and the collaboration protocol profile and agreement.
Steps A, B, C from the method are similarly applied in the ebXML experiment.
The main difference is in Step D where we explain the procedure of transition. The difference is when we try to model the ebXML standard specification in ontology.
D.1 to design ebXML process ontology
ebXML uses Business Process Specification Schema (BPSS) to model business processes. In modeling the process ontology, we utilize the sequence diagram and the activity diagram. The BPSS specification specifies a Business Transaction, a Business Document flow for the Business Transaction, a Binary Collaboration, and then a Choreography for the Binary Collaboration. A Business Transaction in ebXML is the basic transaction unit between two partners. It consists of a Requesting Business Activity and a Responding Business Activity. A Binary Collaboration is always executed between two roles. They are called the Authorized Roles because they represent the actors that are authorized to participate in the collaboration. A Binary Collaboration consists of one or more Business Activities.
These Business Activities must be conducted between the two Authorized Roles in the Binary Collaboration. A Choreography is an ordering and sequencing of Business Activities within a Binary Collaboration. The choreography is specified in terms of the Business States and the Transitions between these Business States. In the purchase order process example, we know it has two activities: Purchase Order Request Action and Purchase Order Confirmation Action. Both can be extracted from the BPSS sample file. We further know that if the activity is authorization required or non repudiation required. Below is the converted OWL scripts.
D.2 to design ebXML document ontology
The ebXML document ontology is created in use of the ebXML core component specification. The core component can be used to create the classes and the properties and be converted into ontology. The ebXML document ontology needs to incorporate existing DTD or existing XML Schema in order to support each component conversion. The ebXML core component in the standard ontology corresponds to the basic data entity in the domain ontology. The core component represents the same meaning as the data entity in the domain ontology. The ebXML aggregate information entity, on the other hand, stands for the composite data entity in the domain ontology. Because BPSS is also UML-based, the set of UML diagram such as the use case diagram, the class diagram, the sequence diagram, and the activity diagram our method recommends are adopted. Hence, the correspondence
20
and reconciliation will occur early at the analysis phase and will be carried out in the merge of standard ontology and domain ontology. For ebXML, the actual document definition is achieved using the ebXML core component specifications or by some methodology external to ebXML. They in turn are converted into a DTD or a XML Schema. BPSS specifies the specification name as “PurchaseOrderReques.dtd”.
We only need to get this DTD file and import it. A business document has three types of components. They are the basic data entity, the composite data entity, and the business property. The ebXML consists of: Core Component Type (CCT), Basic Information Entity, and Aggregate Information Entity. CCT are core components that carry the actual value and have no business meaning on their own. A Basic Information Entity is a singular concept that has a unique business semantic definition. A Basic Information Entity adds a semantic meaning to a single datatype or a CCT. When CCTs are reused in a business context, they become Basic Information Entities. An Aggregate Information Entity contains two or more Basic Information Entities or Aggregate Information Entities that together form a single business concept. Each Aggregate Information Entity has its own business semantic definition.
4. Discussion
4.1 Research Implication
The first set of literature investigating the issues of aligning the business processes with the business-to-business electronic commerce standards are described in (Omelayenko, 2001) (Stojanovic, Maedche, Motik, and Stojanovic2002) (Bussler, Fensel, and Maedche, 2002). They represent the earlier efforts working on the programming to approach the interface between the trading processes and new standards. This ad hoc programming approach was primitive and exploratory. Later in the literature survey, (Ding, Fensel, Klein, Omelayenko, and Schulten, 2004), the time when there were more business-to-business middleware systems in the marketplace, the researches gear toward to solve the issue of conversion and hub in the middleware system. Another important stream of literature presented in (Choy and Kim, 2004) (Cao, Zhang, and Seydel, 2005) addresses the integration aspect of the alignment. These studies relate to ours. They perceive the issue as a process and performance issue in the supply chain management. In (Hsieh, Lai, and Shi, 2006) (Iyer, Gupta, Johri, 2005) the process issue is further examined with mathematics to model the business operation.
In 2004 and 2005, we tested new PIPs including PIP3B18, PIP3B2, and PIP4C1 in the live case experiment. Each PIP took one month to three months instead of six months as in the prior years. The IT division assigned four full time system engineers instead of six to deliver the implementations. Figure 14 shows the equivalent classes generated from the PIP3A4 standard. Figure 15 gives the equivalent properties in the test.
Figure 14: Equivalent Classes
21
Figure 15: Equivalent Properties
22
4.2 Managerial and Technical Implications
We summarize the managerial and technical implications into five points.
Ontology is a more powerful technology on semantics and context. A mapping table is simple but lacks the ability to scale. It is a way of “mapping of terms” not an approach to “mapping of sense”. Ontology allows systems to discern the “one to one”, the “one too many”, and the “many to many” correspondences. It allows the systems to undertake the complex conversion such as the situation when there are same terms but with different meanings; different terms but with same meaning;
23
different terms but with different meanings yet close. Ontology can support an automation of the evolution of the terms, the concepts, and the relationships. The relationships between the new terms and the corresponding old terms can update automatically. Ontology is the base of reasoning.
The analysis framework and ontology enables the deployment of a new B2Bi EC standard initiative to be installed and operated in an effective and efficient fashion.
Though RosettaNet PIP message defines many business entities, but there are many repeating entities in different PIPs. RosettaNet PIP3B2 is an example of the shipment notification process which specifies 120 business entities and properties.
PIP3A4 is another example that has 143 business entities. However, there are 59 repeating business entities between these two PIPs. The repeat rate is above 49%. In fact, the more related the processes are, the higher the repeat rate will be. We must take advantage of the repeat rates. The repeat rate of entities between PIP3A4 and PIP3A8 is as high as 92%, almost identical. As new processes are continuously and constantly added to our ontology, the ontology must become more robust. The work of ontology creation becomes more automatic and less labor intensive. At the same time, the new knowledge extracted from the new ontology can be captured. Trading partners regularly collaborate and contribute to the reconciled and merged ontology which in turn forms a semantically rich repository in support of the reasoning, the inference, and the search of organizational learning. By enhancing and enriching the shared ontologies, we can deploy a new B2Bi EC initiative in a more effective and efficient manner.
A special function to transfer data model from DTD and XML Schema to OWL is
useful. A prototype of parser and converter to handle XML documents in the creation of
ontology is needed.
5. Conclusion and Future Work
5.1 Conclusion
In this paper, we have presented an ontology-assisted analysis method and alignment model in the implementation of the business-to-business electronic commerce standard specification over the existing trading partners’ public processes in the syntactic and semantic integration and interoperability. An application of the Unified Modeling Language is made to analyze the public process in the domain and in the standard. Terms, concepts, relations, and links are created from the analysis results and converted into an ontology representation. Web ontology language is introduced to formulate the analyzed knowledge and experience to align the domain and the standard. There are correspondences and conflicts in the process of alignment. They are resolved via the shared and reusable ontology which is a convergence of the domain ontology and the standard ontology. The converged and shared ontology is achieved via a set of rules and heuristics that are created in the research. The key of success in the business-to-business integration electronic commerce lies on the ability to accomplish the process interoperability and the schema comparability. Three main tasks have to be achieved to fulfill the requirements. In this research, we have constructed a prototype to implement the method. The prototype is used to illustrate the feasibility and validity of the method.
A set of starter experiments has been conducted in use of a straight through example of a purchase order process in the alignment with the RosettaNet standard
24
and the ebXML standard. The starter experiment serves as the baseline to demonstrate the method is feasible and valid. The three main things we have accomplished in the research are：
Identifying the main components of knowledge and experience to be reconciled and to be represented in the alignment of the standard ontology and the domain ontology.
Developing the set of rules and heuristics for the ontology correspondence and reconciliation.
Designing an experimental prototype to implement the method and to demonstrate the feasibility and the validity by selecting two main electronic commerce standards as the baseline test. The RosettaNet experiment represents the vertical electronic commerce standard. The ebXML experiment stands for the horizontal electronic commerce standard.
5.2 Future Research Work
The future research work will continue to explore the complex issues of the alignment and automation between domains and standards. Some of the immediate tasks to be undertaken in our study include：
Enhancing the ontology search and inference capability. As the rule base and heuristics base grow, search and inference engine become slow in the ontology management. Tuning and enhanced rules must be developed.
Upgrading the DTD importer to import XML Schema and to enable the conversion between XML Schema and OWL representation. This will solve the version control issue.
Conducting more diverse and complex experiments in terms of scale and scope.
More experiments will be conducted in the public processes of receiving and payment that are closely related with the public process of purchase order.
RosettaNet and ebXML will still be the main standards.
REFERENCES
1. Baclawski, K., Kokar, M.K., Kogut, P.A., Hart, L., Smith, J., Letkowski, J., &
Emery, P. (2002) “Extending the Unified Modeling Language for Ontology Development”, Software and Systems Modeling, Vol 1 No 2, pp. 142-156.
2. Berners-Lee, T., Hendler, J., & Lassila, O. (2001) “The Semantic Web”, Scientific
25
American, Vol 284 No 5, pp. 34-43.
3. Bird, Linda, Andrew G., & Terry H. (2000) “Object Role Modelling and XML-Schema”, ER2000.
4. Bose, R. (2006) “ Understanding Management Data Systems For Enterprise Performance Management ”, Industrial Management and Data Systems, Vol 106 No 1, pp. 43-59.
5. Bussler, C. (2001) “Semantic B2B integration”, ACM SIGMOD Record, Vol 30 No 2, pp. 625.
6. Bussler, C., Fensel, D., & Maedche, A. (2002) “A Conceptual Architecture for Semantic Web Enabled Web Services”, ACM SIGMOD Record, Vol 31 No 4.
7. Cao, M., Zhang, Q.Y., Seydel, J. (2005) “B2C e-commerce web site quality: an empirical examination”, Industrial Management & Data Systems, Vol 105 No 5, pp. 645-661.
8. Choy, L. Y., Kim, H. T. (2004) “A process and tool for supply network analysis”, Industrial Management & Data Systems, Vol 104 No 4, pp. 355-363.
9. Cranefield, S., & Purvis, M. (1999) “UML as an Ontology Modelling Language”, In Proceedings of 16th International Joint Conference on Artificial Intelligence on Workshop on Intelligent Information Integration.
10. Cranefield, S. (2001) “Networked Knowledge Representation and Exchange Using UML and RDF”, Journal of Digital Information, Vol 1 No 8.
11. Cut, Z., Jones, D., & O'Brien, P. (2002) “Semantic B2B Integration: Issues in Ontology-based Approaches”, ACM SIGMOD Record, Vol 31 No 1, pp. 43-48.
12. Decker, Stefan, Sergey M., Frank V. H., Dieter F., Michel K., et al. (2000) “The Semantic Web: The Roles of XML and RDF”, IEEE Internet Computing, Vol 4 No 5, pp.63-64.
13. Ding, Y., Fensel, D., Klein, M., Omelayenko, B., & Schulten, E. (2004) “The
13. Ding, Y., Fensel, D., Klein, M., Omelayenko, B., & Schulten, E. (2004) “The