249

JOURNAL OF INFORMATION SYSTEMSVol. 22, No. 2Fall 2008pp. 249–277

Automating REA Policy LevelSpecifications with Semantic

Web TechnologiesTod Sedbrook

University of Northern Colorado

Richard I. NewmarkUniversity of Northern Colorado

ABSTRACT: Enterprise modelers require tools and techniques that consistently rep-resent and logically apply domain knowledge. Current modeling approaches rely onentity relationship or unified modeling diagrams to represent semantic descriptions ofbusiness exchanges. However, it remains difficult to transform the implicit metadata,ontologies, and logic embedded in diagrams into a coherent form that can be inter-preted by machines and delivered across the web. This study explores the uniting ofmachine processing capabilities of semantic web technologies with resource eventagent (REA) enterprise ontologies to model complex multienterprise partnerships. WebOntology Language (OWL) and Semantic Web Rule Language (SWRL) were used tomodel REA policies for a distributed e-commerce partnership selling nearly new vehi-cles. We combine a specialized REA application ontology with semantic technologiesto direct multienterprise collaborations. We present a prototype that encodes the on-tology’s concepts within OWL and SWRL and explore these machine-readable repre-sentations within the context of a case study.

I. INTRODUCTION

New approaches are needed to help distributed networks of collaborating partnersunify their shared view of exchanges while, at the same time, allowing each partnerto adapt their individual view to local business conditions. Partners collaborating

within multienterprise systems must continually adapt business policies—such as partnerresponsibilities, product promotions, and supply chain flows—to cope with turbulentenvironments.

It is difficult and costly to maintain coherence and consistency of economic exchanges,as distributed networks of partners make continual adjustments. Current modeling tech-niques rely on manual updates to entity relationship (ER) or unified modeling language(UML) diagrams to capture and communicate changing partner policies. These diagramsrequire careful review by domain experts who understand the implicit metadata, semantics,and logic embedded within diagrams.

We acknowledge the helpful comments from the anonymous reviewers and journal editor as well as participantsat REA-25.

250 Sedbrook and Newmark

Journal of Information Systems, Fall 2008

To augment current approaches, this paper explores the ability of automated semanticweb tools to support logical consistency across trading partner exchanges. The main con-tributions of this paper are adapting the resource event agent (REA) enterprise ontology tosupport semantic web applications and then designing a semantic web architecture thatapplies the specialized application ontology. We illustrate the contributions through a casestudy and follow a design science research approach by constructing and evaluating aprototype that supports a network of partners selling nearly new vehicles.

The REA ontology defines a semantic vocabulary of economic Resources, Events, andAgents to define business exchanges. McCarthy (1982) addressed the semantic weaknessesof traditional accounting systems by employing a database approach to create an eventsaccounting system based on the theory of economic exchange. REA applies economicexchange theory to structure the economic events, exchange relationships, and inflows andoutflows of resources.

Incorporating REA extensions into evolving e-business standards requires evaluatingtools and techniques that apply typification, grouping, and associations to support managers’intentions (Geerts and McCarthy 2006). This should be at a policy level, meaning theprocedures dictate what should or could take place to satisfy partners participating in ec-onomic exchanges.

Developments in semantic web technology such as Web Ontology Language (OWL)and Semantic Web Rule Language (SWRL) provide a new opportunity to apply the REAontology and create specialized REA-based applications (Dunn and Grabski 2000). Seman-tic web technologies define common semantic markup formats for distributing, integrating,and combining business transaction data across networks. Semantic reasoning engines workwith the semantic markup to infer logical consequences from sets of facts.

The recently approved International Organization for Standardization (ISO) Open-Electronic Data Interchange (EDI) standard provides an explicit REA specification of anaccounting and economic ontology to support business transactions among collaboratingpartners. The next step is to explore semantic and machine-readable formalizations of REAontologies and investigate their application within inter-enterprise business scenarios (In-ternational Organization for Standardization 2007).

Using the design science research approach, we identify difficulties encountered withina software development project. We then propose a solution to address problems within thatspecific context (Hevner et al. 2004). The goal is to evaluate semantic web technologiesand provide guidance to support further investigations of machine-readable formalizationsof the REA enterprise ontology.

We explore a solution by (1) defining a specialized REA-based OWL ontology to modelthe application domain, (2) formulating a model architecture for organizing the applicationof the ontology’s constructs, (3) creating SWRL rules to improve policy-level collabora-tions, and (4) presenting a proof-of-concept prototype that operationalizes the constructs,model architecture, and rule-based reasoning.

The next section discusses related research. Since the semantic web applications areobject oriented (OO), we employ UML notation and OO terminology in our discussion ofthe REA ontology. We then address the problem of defining REA extensions required forOWL and SWRL applications. Finally, we present a semantic web architecture and a pro-totype application that applies our specialized REA application ontology along with OWLand SWRL to support partnership collaborations.

Automating REA Policy Level Specifications with Semantic Web Technologies 251

Journal of Information Systems, Fall 2008

II. RELATED RESEARCHThe Resources, Events, and Agents of the REA enterprise ontology (REA-EO) continue

to prove effective in modeling and supporting activities across a wide range of economicexchanges (Hruby 2006; McCarthy 2006). Associations such as stockflow, duality, andparticipation relate REA primitives to express useful cognitive reference points for modelingphysical exchanges of resources and interactions among employees, suppliers, and custom-ers. As REA modeling evolves to support enterprise collaborations across supply chains,researchers recognize the need to extend the REA model to create richer models of eco-nomic transactions and to capture inter-enterprise business policies, including standard def-initions of concepts, budgets, and controls (Geerts and McCarthy 2002).

REA modeling extensions have been proposed to support management planning anddecision making, enterprise level value chains, and workflow structures (Geerts andMcCarthy 1999; Geerts and McCarthy 2002; Verdaasdonk 2003). Geerts and McCarthydescribed an extended REA model to provide a superordinate infrastructure that identifiesadditional ontological categories including typifications, membership groupings, and asso-ciations (Geerts and McCarthy 2006).

REA modeling began over twenty-five years ago by identifying operational-level cat-egories of resources, events, and agents that form a basic ontology. Gruber (1993, 199)defines an ontology as ‘‘an explicit and specification of a conceptualization,’’ where aconceptualization is ‘‘an abstract, simplified view of the world that we wish to representfor some purpose.’’ The REA ontology provides an expressive language to assist managersin capturing and sharing enterprise knowledge.

Typifications and groupings are policy level abstractions that provide extensions to thebasic REA model. These extensions represent organizing forms for expressing policies thatapply types and membership groupings to operational-level classes; and also apply typifi-cations, groupings, and other policy associations between policy level classes. These ex-tensions can be used to define policies through attributes; typifications and associations;and typification and association classes (Geerts and McCarthy 2006).

Typifications provide a hierarchy of types to allow properties associated with generalclassifications to be inherited by types that are more specific. As illustrated in Figure 1,typifications are used to connect operational-level classes (e.g., INVENTORY; individualvehicles) with policy level typification classes (e.g., MODEL; Chevy Nova, Ford Taurus,Volvo XC70). That is, the collection of attributes of MODEL Chevy Nova represent adefinition (or concept) of vehicle #V1. A typification association between individual vehi-cles and model can also be characterized as a-kind-of. Attributes can also be used to definebudgets. For example, the standard acquisition cost attribute of MODEL represents thebudgeted cost of a particular model (what a vehicle of that MODEL type should cost),which can be used for variance analysis with the actual acquisition cost recorded for eachinventory item that is a-kind-of that particular MODEL.

Policies may also be implemented by establishing hierarchical associations betweenpolicy level classes (Geerts and McCarthy 2006). Typification refers to a hierarchical as-sociation from an operational-level class to a policy level class. Typification associationsalso refer to a hierarchical association between a lower-level policy class and a higher-levelpolicy class. For example, in Figure 1 QUALITY (premium, standard, economy) is a typ-ification of MODEL (Dunn and McCarthy 1997; Geerts and McCarthy 2006). Note thetransitivity between INVENTORY, MODEL, and QUALITY. V1 is a kind of Chevy Novaand a Chevy Nova is a kind of standard quality car. Therefore, V1 is a standard quality car(Geerts and McCarthy 2006).

252 Sedbrook and Newmark

Journal of Information Systems, Fall 2008

FIGURE 1Typification

namefuel capacity

standard acquisition cost

inventory IDacquisition date

actual acquisition cost

ChevyNova

FordTaurus

VolvoXC70

V1

V2

V3

V4

Type Defiition

Operational Level

1 .. 1

0 .. a

applies-to

typification

Policy Level

a-kind-of

category nameminimum lengthmaximum length

Premium

Standard

Economy

INVENTORY(Individual Vehicle)

MODEL(Vehicle Category )

QUALITY(Model Type )

1 .. 1

0 .. a

a-kind-of

applies-to

typification

a Adapted from Geerts and McCarthy (2006)

Automating REA Policy Level Specifications with Semantic Web Technologies 253

Journal of Information Systems, Fall 2008

Associations between typification classes can also be used to model policies. The ex-ample in Figure 2 shows a policy association between two policy level classes, quality, andvehicle condition. The policy requires a policy association class because the policy is de-fined by the combination of all quality and vehicle condition instances, a many-to-manyassociation (Geerts and McCarthy 2006).

In Figure 2, management specifies a base markup percentage for all vehicles, a qualitymarkup percentage for each instance of quality (premium, standard, economy), and amarkup percentage for each instance of condition (high, medium, low). The algorithm usedto compute the markup percentage is:

total markup % � base markup � quality markup % � condition markup %.

This method of defining markup percentage allows the price of a vehicle (sales priceto customers) to be derived— /price derived attribute of VEHICLE in Figure 2—based onthe actual vehicle cost (or standard vehicle cost associated with the vehicle MODEL)and the total markup percentage computed from the pricing policy algorithm. Further, man-agement also can change the price of vehicle instances by merely changing the values ofthe pricing policy attributes and/or the pricing policy algorithm (e.g., adding weights to thevariables in the algorithm). Finally, management may change the pricing policy by changingthe attribute values used to define quality (minimum quality score, maximum quality score)and/or condition (minimum condition rating, maximum condition rating).

Common modeling approaches for structuring REA concepts include entity-relationshipdiagrams and unified modeling language (UML) diagrams (Amer 1993; Nakamura andJohnson 1998; Sugumaran and Storey 2006). REA business patterns assist model devel-opment by supporting compact forms for presenting, integrating, and inspecting new policy(Hruby 2006; Sugumaran and Storey 2006). REA models capture requirements and assistin directing applications development (Adamson and Dilts 1995; Reuber 1990; Bergholtzet al. 2003).

Since the business environment is characterized by constant change, supply chain part-ners must realign business processes and negotiate policy changes among partners. Enter-prise information must support managers as they explore the impact of change and managepolicy disagreements among partners. Researchers are considering applications of REA tosupport integration among fragmented supply chain partners (Gailly and Poels 2006a).

Currently, REA extensions have been integrated with e-commerce standards throughbodies such as the United Nations Business Process group, the ISO Open-EDI group, andebXML business process team. These standards apply REA models to specify a businesstransaction ontology for coordinating exchanges (International Organization for Standardi-zation 2007).

Enterprise concepts are modeled through UML class, activity, and sequence diagramsto capture both the static and dynamic abstracts of electronic business transactions. Al-though diagrams support semantic descriptions of business exchanges, they are of limitedvalue in helping computers effectively manipulate the REA ontology (Oshri et al. 2005).

UML originated as a graphical software modeling language to help experts capture adomain’s representations. However, in order to facilitate processing by machines, the im-plicit knowledge embedded in these diagrams had to be translated to procedural code. Thetranslations introduced a semantic gap between the high-level graphical models and thelow-level executable code.

254 Sedbrook and Newmark

Journal of Information Systems, Fall 2008

FIGURE 2Example of Policy Association and Policy Association Class

namefuel capacity

standard acquisition cost

inventory IDacquisition date

actual acquisition costvehicle condition rating

/Price

ChevyNova

FordTaurus

VolvoXC70

V1

V2

V3

V4

Type Defiition

Operational Level

1 .. 1

0 .. a

applies-to

typification

Policy Level

a-kind-of

quality category nameminimum quality scoremaximum quality score

Premium

Standard

Economy

INVENTORY(Individual Vehicle)

MODEL(Vehicle Category )

QUALITY(Model Type)

1 .. 1

0 .. a

a-kind-of

applies-to

typification

0 .. a

vehicle condition categoryminimum condition ratingmaximum condition rating

Excellent

Average

Poor

VEHICLE CONDITION(Category )

1 .. 1

association

0 .. a

Pricing PolicyAssociation

Policy Level

0 .. a

base markup %quality markup %

condition markup %

PRICING POLICY(Policy Association)

a Adapted from Geerts and McCarthy (2006)

Automating REA Policy Level Specifications with Semantic Web Technologies 255

Journal of Information Systems, Fall 2008

In response, UML tools have improved to be more helpful to domain experts whocapture semantics with logical rule structures expressed through the object constraint lan-guage (OCL). By using OCL, designers can augment UML models by logically fillingspecification gaps, checking constraints, and deriving better procedural code. UML andOCL are optimized to represent constraints within individual UML models (Gasevic et al.2006). Semantic web technologies can augment UML and OCL by creating machine-readable knowledge structures that can better link and reason about transactions amonggeographically distributed partners.

As REA modeling is applied to the complex and unpredictable world of multi-enterprisecollaboration, new approaches are needed to better understand, test, and evolve enter-prise ontologies. New tools are needed to share and assess policy changes and then auto-matically apply changes to semantic models of enterprise information systems (Chen et al.1995).

Providing computer-based support for enterprise managers requires explicit and sharedartifacts that support operations and policy decisions. Formal and machine executable on-tologies are needed to support the capturing, storing, retrieving, and sharing of process-based knowledge (Mentzas et al. 2006). Formal ontologies support applications that canaccess and apply machine-readable ontology (Nonaka and Toyama 2003).

Rules can flexibly express relations among ontology concepts and support change proc-esses (Brodie and Ridjanovic 1984). Business rules explicitly capture practical reasons fortaking action and REA modeling efforts are improved with rule-based reasoning. Embed-ding rules within an ontology supports automatic inference within semantic hierarchies(Orriens et al. 2003; Zhang et al. 2005).

Semantic rule systems, such as CREASY (Conceptualizing REA Systems), reason aboutentities that include resources, events, and agents (Geerts and McCarthy 2000). Rules inCREASY are represented as simple predicates that express associations among agents,events, and resources. Predicate structures provide consistent, flexible, and straightforwardrepresentation schemes. Rules organize predicate structures to support inferences, where,for example, a rule may express ‘‘a sale requires a number, date and an amount.’’ Repre-senting knowledge in simple predicate structures provides opportunities for analyzing in-ference chains and detecting inconsistencies.

Semantic Web TechnologiesSemantic web standards promise to integrate ontologies with rule-based inference to

provide a consistent way to capture and apply business policies. Research is ongoing to re-present REA concepts with semantic web technologies such as Web Ontology Language(OWL), which provides an explicit semantic language to define ontologies that interoperateover the web (Gailly and Poels 2006b). REA facilitates advances in ontological engineeringdesigned for improving supply chain collaboration and knowledge sharing for the semanticweb (Hessellund 2006). Inter-operable and machine-readable ontologies provide commonvocabulary to support systemization, sharing, and application of knowledge.

Geerts (2004) adopted XML, XML schema, and XSLT to represent REA enterprisevocabulary, terms, and specific enterprise schema to promote application integration acrossenterprise systems. XML standardizes syntax and data structures promoting consistency ofinformation exchange. However, XML tags do not directly support application integration.Applications that interoperate via XML must agree on the semantic meaning of each string-like XML tag (Lacy 2005). OWL extends the semantic facilities of XML to support de-clarative and self-contained statements more directly compatible with software applications(Baclawski et al. 2002).

256 Sedbrook and Newmark

Journal of Information Systems, Fall 2008

OWL uses XML as a transport and exchange mechanism, but it ‘‘adds more vocabularyfor describing properties and classes: among others, relations between classes (e.g., dis-jointness), cardinality (e.g., ‘exactly one’), equality, rich typing of properties, characteristicsof properties (e.g., symmetry), and enumerated classes’’ (W3C 2003). OWL is specificallydesigned for open sharing among multiple applications and groups. Its fundamental con-struct is a class representing collections of object instances. Generalization structures or-ganize OWL classes to model similarities and differences between classes.

OWL provides declarative metadata and logic to help distributed enterprises exchangeand integrate semantic information to coordinate their tasks more effectively. As new OWLstatements are introduced, they are interpreted by logical inference techniques to maintainan ontology’s consistency and coherence.

An objective of semantic modeling (Sowa 2000) is to combine logic with ontology toformally reason and explicitly derive new knowledge. Rather than hard wiring proceduresto construct associations, rules and reasoning engines could automatically construct andclassify associations. Domain-specific rules help assure and maintain the validity of REAenterprise schema (Geerts 2004). Explicit, testable, and understandable rules allow man-agers to express policies clearly.

Semantic Web Rule Language (SWRL) is a rule description language, officially intro-duced in 2004, to extend OWL semantics to support machine reasoning. Rule inferenceengines called reasoners apply standard SWRL rules to derive logical extensions to OWLclasses (Horrocks et al. 2004). Semantic Web Rule Language formally processes OWL doc-uments to check consistency across ontologies and provide automated support for deducingrelationships and updating ontologies through semantic transformations.

The following provides a brief primer on SWRL rules, illustrating how these rulessupport reasoning. In REA terms, a transaction begins with an outflow event that initiatesa shipping partner’s outflow of resources. However, from the receiving partner’s perspective,the receipt of goods is an inflow of resources with an associated inflow event. The receivingpartner’s change in perspective can be inferred from the following logical rule:

Outflow Type(?y) � (?y hasDecrementEvent ?e) � (?y hasOutflowResource ?r)→Inflow Type(?z) � (?z hasIncrementEvent ?e) � (?z hasInflowResource ?r).

The above rule represents an IF-THEN structure where the symbol ‘‘→’’ is the impli-cation operator that separates the IF (body) part on the top, from the THEN (head) partbelow. The variables in the above predicate pattern are prefixed with the symbol ‘‘?’’ andrepresent unbound placeholders representing instance sets. The symbol � represents a con-junction operator linking individual predicates. An Outflow Type is a stockflow represent-ing an instance of an outflow event (Transfer or Sale) paired with an instance of an outflowresource (Vehicle).

The reasoning engine interprets an OWL document as sets of statements, each forminga triple pattern of subject, predicate, and object. The Outflow Type’s instance (subject) islinked by the named properties ‘‘hasDecrementEvent’’ (predicate) to an event (object).Another statement links the same Outflow Type instance (subject) via the ‘‘hasOutflow-Resource’’ (predicate) to a resource (object).

The reasoner processes SWRL rules by matching each statement’s triple. In the rulebody above the first statement Outflow Type(?y) is a shortcut representation of the triple(?y rdf:type Outflow Type). OWL triples that partially match that statement’s predicate(rdf:type) and object (Outflow Type) supply the binding for ?y representing a matching

Automating REA Policy Level Specifications with Semantic Web Technologies 257

Journal of Information Systems, Fall 2008

statement’s subject. Once bound, ?y acts as the subject for further triples that partiallymatch the predicates ‘‘hasDecrementEvent’’ and ‘‘hasResourceOutflow’’ binding matchingobjects to variable ?e and variable ?r, respectively.

Matching the IF (body) part of the rule triggers the THEN (head) part of the rule andfor each Outflow Type, the reasoning engine asserts a new Inflow Type instance. Variables?e and ?r, previously bound by the matching Outflow Type, are assigned as values to thenewly asserted Inflow’s ‘‘hasIncrementEvent’’ and ‘‘hasResourceInflow’’ properties.

An enterprise ontology, expressed in OWL and SWRL, must reliably express REAoperational-level instances as they relate to concepts within a domain of interest (Geertsand McCarthy 2000). In addition, the ontology must be expandable so that small changes,such as the addition or revision of a concept type, must not require large changes in theontology’s structure. Gruber (1993) suggests that the maintainability of an ontology isimproved by encapsulating details and representing concepts within generalization and spe-cialization hierarchies.

Finally, the evolving ontology must support the goals of individual collaborating part-ners as well as the enterprise as a whole. A domain-specific ontology must help managersmaintain a partner independent view that unifies the understanding and enforces consistencyof resources flows across partner boundaries (International Organization for Standardization2007). The ontology must also support internal partner processes as managers plan andcontrol their internal business policies.

Enterprise Modeling ApproachThe skeletal methodology that identifies four main stages for constructing an application

ontology is used: (1) identify the purpose, (2) formally determine and structure the ontol-ogy’s terms and concepts, (3) build the ontology, and (4) evaluate and revise it (Uschold1996). Building and evaluating the ontology requires defining an architecture, and thenconstructing and evaluating a proof-of-concept prototype. This section considers the firsttwo stages of constructing an ontology by identifying the purpose of the ontology andpresenting a specialized application ontology where we use UML notation for our model.We later build and evaluate a prototype through scenarios identified in a case study ofmultienterprise partnerships.

Purpose of the OntologyThe following presents an application ontology specializing REA-EO for a semantic

web application. This ontology defines application-specific OWL extensions designed tosupport multienterprise collaborations where distributed partners acquire, share, and assim-ilate semantic information according to business policies.

The application ontology is designed to support SWRL association rules that logicallyinfer associations of REA resource, event, and agent types. The goal of the applicationontology is to explore applications that provide a declarative, modular, and flexible approachto express the multienterprise policies guiding economic exchanges.

Specializing REA Enterprise Ontology for Semantic Web TechnologiesThe literature review supports REA as a rich expressive language which explicitly

captures and comprehensively structures economic exchange relationships. The followingcombines specialized OWL artifacts and REA concepts to support multienterprise economicexchange policies. We do not intend to present our specialized ontology as the definitiveontology, but instead present it as a pragmatic attempt in structuring semantic web appli-cations to support policy interactions among distributed partnerships.

258 Sedbrook and Newmark

Journal of Information Systems, Fall 2008

Geerts and Wang (2007) and Geerts (2004) divided the REA domain ontology intothree interrelated layers: ontological specifications, enterprise schema descriptions, and op-erational enterprise schema. The REA Enterprise Ontological specifications (REA-EO) de-fine a common ontology of shared REA terms and definitions to structure enterprise eco-nomic exchanges (Geerts 2004). Enterprise schema descriptions are inherited from theREA-EO in order to define additional classes related to ‘‘the specific phenomena that occurin a company’’ including domain types and associations important to a specific enterprise’seconomic transactions (Geerts and Wang 2007, 162). Operational enterprise schema referto domain-specific instances, properties, and associations of resources, events, and agentsthat populate the classes of enterprise schema descriptions.

Multienterprise OWL-based systems require clear visibility of their overall type struc-ture to help developers understand and maintain applications. Abstraction supports under-standing by organizing high-level concepts within an inheritance lattice of types. The fol-lowing section defines an OWL-based set of REA-EO abstractions to help developersorganize domain-specific schema and instances. Subsequent sections apply the abstractions,partner schema, and operational instances within the context of a case study.

Figure 3 presents a UML class diagram representing packages and classes of abstractREA-EO/OWL specializations. Figure 3 identifies the UML packages labeled REA-EO/OWL Type, REA-EO/OWL Association and REA-EO/OWL Rule. The diagram introducesthe REA-EO/OWL Rule package that contains an Association Rule class whose instancesdirects the creation of Associations. Rule instances are expressed in the SWRL.

Within the REA-EO/OWL Type package, Common represents an abstract class thatspecifies common properties inherited by abstract subclasses of Resource Type, Event Type,and Agent Type. Figure 3 shows, for example, the abstract class labeled Common providesa convenient location for OWL annotation properties including object labels and versionannotations. Common also specifies the ‘‘dc:identifier’’ property intended to be inherited bysubclasses to formally identify instances. The ‘‘dc:identifier’’ property is formally definedin the widely used Dublin Core metadata ontology (Dublin Core Meta-Data Initiative 2008).Resource Type specifies the OWL property ‘‘owl:hasValue’’ to represent the value of aneconomic resource. Event Type specifies the formal Dublin Core property ‘‘dc:date’’ todefine a period of time for an event and Agent Type specifies ‘‘dc:title’’ to formally definean agent’s title.

Concrete subclasses extend their abstract REA type to form specializations related toa particular domain or enterprise schema. For example, Customer Agents and Sales Agentsdefine enterprise schema subclasses that specialize the REA Agent Type.

The ontological association package REA-EO/OWL Association and the specializedAssociation subclasses represent linkages to relate sets of REA Types. The top-level Com-mon Association class represents an abstract class that specifies common properties inher-ited by all Association subclasses. The Common Association class specifies the commonOWL properties defining cardinality and disjointness constraints. The OWL reasoning en-gine enforces these constraints to help maintain semantic consistency throughout the in-heritance hierarchy.

The stockflow classes Resource Inflow Type and Resource Outflow Type, along withDuality Type and Participates Type represent four abstract Common Association subclassesthat further refine association constraints for linking REA-EO/OWL Types. Each of theseassociations specifies common OWL properties that help maintain semantic consistencywith that association class’s hierarchy.

The abstract Common Association subclass Inflow Type is a stockflow association be-tween an inflow Event and a Resource. For example, the association of a purchase event

Automating REA Policy Level Specifications with Semantic Web Technologies 259

Journal of Information Systems, Fall 2008

FIGURE 3A UML Class Diagram for Organizing the REA-EO/OWL Application Ontology

Specializations into Packages of Types, Association Types, and Rules

(increment) and the resulting inflow of purchased resources is an Inflow Type. Inversely, anOutflow Type is an association of a cash disbursement event (decrement) and an outflow ofresources such as cash.

A Duality Type is an association between the two or more events coordinating anexchange of resources. From an individual partner’s perspective, an economic event resultsin either an increment or decrement in the value of an economic resource. For example, aninstance of a Sale Event (decrement event) linked to an instance of a Cash Receipt Event(increment event) is a Duality Type association.

A Participates Type association links an economic Event and the two Agents partici-pating in the economic event. One agent participates as the ‘‘from’’ agent such as a SalesPerson, while the other acts as the ‘‘to’’ agent such as a Customer.

Finally, the REA-EO/OWL Rule package contains the Association Rule class to create,describe, and organize rules that are used to create Associations. An Association Rule is a

260 Sedbrook and Newmark

Journal of Information Systems, Fall 2008

formal specification of a SWRL rule body and head designed to create semantic associationsthat model multienterprise transactions and policies. Association Rules are used by OWLreasoning engines to logically assert new instances of associations. When the premises orbody of an Association Rule are satisfied, the inference engine adds new associations spec-ified by its consequent or head. Declarative association rules are more general, applicationindependent and easier to change compared with procedural representations (Geerts andMcCarthy 2000).

III. APPLYING AN REA/OWL PROTOTYPE IN A CASE STUDY CONTEXTThe next step in ontology development applies the previous section’s REA ontological

types, association types and association rules to support policy-based exchanges within thecontext of a multienterprise partnership.

The collaborating partners’ schema are developed from a case study where we identifyscenarios that characterize distributed partner exchanges. The case study background isdescribed below and followed by examples of partner schema. Then, we define an archi-tecture to enable network-based and semantic interoperability among independent and ge-ographically distributed partners. Finally, we explore a proof-of-concept prototype and in-troduce scenarios that apply SWRL rules to simulate policy-based economic exchangesamong partners.

Case Study BackgroundWe participated in a case study of an enterprise project where we studied design arti-

facts and participated with managers as they adapted enterprise business policies to copewith ongoing and turbulent changes. The name and specific details of the participatingenterprises are fictionalized to assure anonymity.

DEAL is a pseudonym for a cooperating group of enterprise partners whose missionis to provide innovative and web-based customer services to sell nearly new vehicles ob-tained from rental car agencies, corporate fleet managers and manufacturer representatives.These suppliers typically remove vehicles from their fleets when those vehicles are justover six months old or have mileage of over ten thousand miles. The DEAL marketingpartners acquire de-fleeted vehicles, refurbish, and warranty those vehicles and then offerthem for sale. The vehicles are offered for sale through an e-commerce web site that assistscustomers in researching vehicles, selecting vehicles, configuring options, acquiring depos-its, processing trade-ins, obtaining warranties, and securing financing.

The business model requires a multienterprise strategic alliance of geographically dis-tant partners to cooperate across an international supply chain. Financial partners includenumerous banks and credit processors that offer customer financing. Marketing partnersprocess customer vehicle requests and attempt to match those requests to current andplanned inventory. Marketing partners also offer customer referrals, discounts, and pro-motions. Vehicle suppliers provide vehicles for sale as they are removed from their fleets.Rental car agencies coordinate test drives for vehicle types that match customer requests.Refurbishing and warranty partners prepare and certify vehicles. Logistics suppliers trans-port vehicles to and from suppliers and ultimately deliver purchased vehicles to customers.Vehicle data partners support the website’s back office databases by supplying timelydata concerning vehicle model and option descriptions, trade-in valuations, and pricinginformation.

The managing organization located in Belgium has the responsibility of refining thebusiness model and coordinating partner negotiations. Belgium-based client participants

Automating REA Policy Level Specifications with Semantic Web Technologies 261

Journal of Information Systems, Fall 2008

include senior management representatives, business leads and customer service managers,software architects, technical leads and project managers.

In early June, DEAL began software development. However, by July the evolvingbusiness model and changing partnerships forced management and development teams tocontinually re-align priorities. As development continued, the business requirements teamidentified nearly 200 outstanding requirement changes. New banking partnership agree-ments and new business policies for English and German markets forced the requirementsteam to continually reconsider past decisions.

The relationships and strategic enterprise agreements among partners were unstable andmarked by complex negotiations. By the following December, the project was cancelledand project reviews revealed a primary reason for failure was a lack of system flexibilitycombined with multiple partnership changes that eventually led to excessive costs.

The failure of the project led us to consider an alternative architecture based on REA-EO, and OWL and SWRL semantic web technologies. Project reviews helped identify anddevelop partner ontologies and propose an architecture that flexibly coordinates partnercollaborations. In the following section, we highlight the resulting enterprise schema de-scription and develop an architecture and prototype to apply the resulting ontologies tomanage partner exchanges.

Ontologies of Partner Enterprise Schema DescriptionsThe REA-EO/OWL specification of REA types, associations, and SWRL rules pro-

vided a parsimonious framework to help identify and hierarchically structure the DEALpartners’ domain knowledge. We reviewed over 100 use cases that specified system andpartner processes ranging from initial vehicle research, to processes for a customer, to thereturn of unsatisfactory vehicles. By exploring use case tasks, we identified domain re-sources (vehicles, options, warranties, refurbishment services), events (payment arrange-ments, deposits, transfers), and agents (sale agent, test drive agent).

After identifying REA types, economic exchanges were identified through use caseanalysis to reveal inflows and outflows across enterprises. For example, Figure 4 presentsa UML object diagram representing operational level vehicle inflows and correspondingoutflows as part of a cash exchange by a marketing partner that receives vehicles. Thediagrams show properties linking object instances.

Through further use case analysis, we identified business rules necessary to modelexchanges among partners. Association rules were created to explicitly represent specificpolicies that govern typical exchanges among collaborating partners. For example, arranginga customer test drive involves dynamically constructing associations among multiple types,including resources (vehicles), events such as payment arrangements (deposits, refunds),and agents (sale agent, test drive agent).

The ontology was refined by identifying partner-specific concerns and forming separateOWL schema extensions that represent the ontology of each individual trading partner. Forexample, the vehicle supplier’s ontology contains vehicles and options subclasses while themarketing partner’s ontology contains customer, pricing, and promotion subclasses.

Then each partner’s ontology was coded in OWL and applied to simulate multi-ontology interactions across the distributed partnership. The REA-EO/OWL ontology pro-vided the common semantic links across partner ontologies.

The original system architecture relied on customized programs to manage multipledata feeds, partner policies, and customized workflow integration. The following sectionpresents an alternative architecture that uses our specialized REA-EO/OWL applicationontology and related SWRL rules to integrate multiple partner ontologies.

262 Sedbrook and Newmark

Journal of Information Systems, Fall 2008

FIGURE 4Object Diagram of Operational Level Instances for Initiating Purchase of Type Inflow Type,

Responding Payment of Type Outflow Type, and Vehicle Exchange Dualities to Model Part ofa Cash Vehicle Purchase of a Marketing Partner

System ArchitectureFigure 5 shows a partner network of operationally independent and geographically

distant partners involved in a strategic alliance to sell nearly new vehicles. The proposedarchitecture introduces the Partner Services network node to help partners flexibly interactby coordinating exchanges. Trading partner economic exchanges must be consistently andcoherently integrated across partner applications.

Figure 6 presents the component subsystems of the Partner Services. The Partner webservice component provides a common API to support application-to-application interactionover a network. It provides a standard interface for querying and exchanging data betweenapplications. The Partner web service API allows each partner to remotely access OWLmetadata. Semantic data transport facilities are provided by OWL and SWRL to shareontologies among partners. Also, partner applications use the Partner Services common APIfor distributed storage, query, and reasoning about web-based semantic exchanges.

The OWL metadata management component provides services to access and merge setsof OWL documents representing the REA-EO/OWL specialized application ontology, in-dependent and dependent SWRL rules, and trading partner enterprise schema descriptionsand operational enterprise instances. The metadata facilitates common query mechanismsto semantically import, merge, and validate combinations of OWL documents.

The rule engine applies OWL ontologies and infers new associations where SWRLrules direct the addition of new objects to maintain consistency across partner transactions.

Data to support transactions may be retrieved from partners’ data feeds in an unstruc-tured format. The data must first be processed into the highly structured OWL documentsand input into the metadata management facilities. In order to facilitate the transformationof partners’ proprietary data feeds into OWL representations, the architecture provides DataTransformation Adapters. For example, an XSLT (eXtensible Stylesheet Language Trans-formations) retrieves raw feeds and transforms feed data into REA-EO/OWL formats. ThePartner Services API then allows partner applications to dynamically combine distributedsets of partner ontologies regardless of their original form.

Automating REA Policy Level Specifications with Semantic Web Technologies 263

Journal of Information Systems, Fall 2008

FIGURE 5The Proposed Architecture Introduces the Partner Services to Coordinate Partner Exchanges

Partner Network

Partner Services

Trade-In Partners

Marketing and Sales Partners

RefurbishmentPartners

LicensingPartners

Financial Services Partners

Warranty Partners

Delivery Partner

Vehicle Supplier Partners

Internet

Prototype ImplementationOpen source Sesame 2.0 provided the framework for metadata management to store

and provide integrated access to partner ontologies (OpenRDF.org 2008). For example,providing responses to customer sale queries requires the Sesame storage and query lan-guage to support real-time, cross-ontology queries that dynamically merge a supply part-ner’s vehicle ontology with a marketing partner’s customer ontology. Sesame supports theSPARQL Protocol and RDF Query Language (SPARQL) queries (W3C 2008). To simplifyinteroperability access across partner applications, a Java-based set of web services wasutilized to create an API front-end to the Sesame’s SPARQL protocols.

Individual partner enterprise schema ontologies maintained sets of SWRL rules thatreasoned about economic exchanges among partners. The Jena2 inference engine executedSWRL rules and constructed new associations and operational instances (Jena 2008).

Prototype EvaluationBuilding and evaluation are the two main activities of the design science research

approach (David et al. 1999; Hevner et al. 2004). The following provides a descriptiveevaluation of the proof-of-concept prototype within the context of two case study scenarios.We created scenarios by reviewing case study project documentation including use-cases,design documents, partner correspondence, and business planning documents. Discussionswith the DEAL project architect confirmed that these scenarios were not adequately handledby the original system design. Then, the scenarios were simulated through the use of arti-ficial data sets derived from the case study analysis.

264 Sedbrook and Newmark

Journal of Information Systems, Fall 2008

FIGURE 6The Component Subsystems of The Partner Service Node Provide for Metadata Management

of Owl Ontologies, SWRL Rule Inference, and Procedural and XSLTTransformation Adaptors

(Access to Metadata Management is Provided by a Common Partner API Accessed Via aWeb Service)

IV. SCENARIO 1—SEMANTICALLY MERGING SUPPLER AND MARKETINGPARTNER ONTOLOGIES

The first scenario concerns the need to maintain an up-to-date inventory of vehiclesfrom multiple sets of distributed suppliers. To maintain an inventory of vehicles and options,multiple marketing partners must coordinate with multiple suppliers. Because the originalsystem could not easily share current knowledge of resources, events and agents, it proveddifficult to coordinate inventory exchanges.

Figure 7 shows the original system architecture for coordinating inventory data feedsfrom suppliers. Since vehicle suppliers managed their fleet inventories through proprietarydatabase systems, the original design required marketing partners to maintain customizedprograms to translate each data feed to the schema of their sales databases. In addition,definitions of vehicle attributes had different semantic meaning across data feeds. For ex-ample, vehicle price attributes in one supplier’s feed represented the original sale pricewhile in another supplier’s feed it was a minimum acceptable cash price. Data feeds often

Automating REA Policy Level Specifications with Semantic Web Technologies 265

Journal of Information Systems, Fall 2008

FIGURE 7The Original System Architecture for Coordinating DEAL Inventory Data Feeds

from Suppliers(Custom Programs Were Required to Transform Data Feeds to Conform to Individual

Partner Applications)

Marketing Partner A

CustomTransformations

Vehicle Suppliers

SupplierData Feeds

CorporateFleet

Supplier

RentalCompanySupplier

ManufacturerSupplier

Applications

Data

Marketing Partner B

CustomTransformations

Applications

Data

contained inaccurate information because although it may have been identified and cor-rected by the supplier, due to the effort required to coordinate and translate the supplierdata feeds, the corrections were not posted in a timely manner. The system was costly tomaintain, extend, and scale customized partner transformations among data feeds, databases,and applications, especially with multiple partnership changes.

Figure 8 relies on Partner Services to provide a semantic interface to link data feedsand partner applications. Supplier data feeds are transformed via custom adaptors into astructured REA-EO/OWL ontology. Individual marketing partner ontologies are importedinto the OWL Sesame store. The Partner Services node then supports real time queries thatcombine and merge supplier and marketing ontologies to support transactions. Partner ap-plications are therefore decoupled from hardwired interfaces and instead rely on the flexi-bility provided by the common Partner Services API to query, merge, and reason withpartner ontologies.

266 Sedbrook and Newmark

Journal of Information Systems, Fall 2008

FIGURE 8The Prototype Architecture Designed to Improve the Flexibility of Supplier Data Feeds

(A Web Service Provides a Common API to Support and Transform Data Feeds forIndividual Partner Applications)

Marketing Partner A

MarketingPartner AOWL-REAEnterpriseSchema

Descriptions

Vehicle Suppliers

SupplierData Feeds

CorporateFleet

Supplier

RentalCompanySupplier

ManufacturerSupplier

Applications

Data

Marketing Partner B

MarketingPartner BOWL-REAEnterpriseSchema

Descriptions

Applications

Data

Partner Services

OWL-REAVehicleSupplier

OntologiesOWL

Sesamestore

Web Service

DataTransformation

Adaptors

OWL-REAVehicleSupplier

Ontologies

OWL-REAVehicleSupplier

Ontologies

SWRL Rule Engine

Common API

Imports

Applications submit queries that merge market partner and vehicle supplier inventories.Query results support marketing partner applications by providing semantic access to mergea distributed set of vehicle inventories.

Automating REA Policy Level Specifications with Semantic Web Technologies 267

Journal of Information Systems, Fall 2008

FIGURE 9Reclassification of Merged Ontologies to Enforce to Marketing Partner Policies

Saab Turbo X

FiatPunto

VolvoXC70

V1

V2

V3

V4

Type Defiition

Operational Level

1 .. 1

0 .. *

applies-to

typification

Policy Level

a-kind-of

Premium

Vehicle Supplier X Y, and ZINVENTORY

(Individual Vehicle)

Vehicle SupplierMODEL

(Vehicle Category)

In-Process Vehicle(Generalization )

0 .. a

OW

L:E

quiv

alen

tCla

ss

VehicleSupplier

View

MarketingPartnerB

View

Marketing Partner BQUALITY

Marketing Partner BREFURBISHMENT

CopperService

Policy LevelAsserted

Associations

GoldService

SilverService

SWRL AssociationRules:Apply Policies toClassify VehicleGroupings intoRefurbishmentCategories

Economy

Standard

Ford Focus

a Adapted from Geerts and McCarthy (2006)

The ability to semantically merge ontologies facilitates further reclassification of feedsinto different categories that reflect an individual partner’s terminology and help to enforcethat partner’s policies. For example, vehicle supplier feeds reveal only a vehicle’s modeltypes (e.g., Saab, Volvo), while a marketing partner’s polices require newly acquired ve-hicles, regardless of supplier, to be reclassified according to quality categories that driverefurbishment decisions.

Figure 9 shows an example how instances categorized by model type, from the view-point of the supplier, are classified into ‘‘Premium,’’ ‘‘Standard,’’ and ‘‘Economy’’ from themarketing partner’s viewpoint. The following OWL statement is used to infer the newsemantic perspective that Saab vehicles are equivalent to the ‘‘Premium’’ vehicles.

268 Sedbrook and Newmark

Journal of Information Systems, Fall 2008

�owl:Classrdf:about�‘‘http: / /MarketingPartnerB.owl#Premium’’��owl:equivalentClassrdf:resource�‘‘http: / /VehicleSupplier.owl#Saab’’/�� /owl:Class�

Reasoning facilities use statements, such as the one above, to infer quality categoriesfrom instances of a particular model. A marketing partner’s policy rule then matches qualitycategories with SWRL policy rules that infer refurbishment associations.

For example, according to Marketing Partner B’s policy, vehicles with a model typeSaab and Volvo are ‘‘Premium.’’ A rule can then express the ‘‘Premium’’ refurbishmentpolicy as: ‘‘Premium vehicles with accumulated mileage of less than twelve thousand milesrequire Gold level refurbishment service.’’

This policy is formally expressed through the following SWRL rule:

(MktpB:Premium owl:equivalentClass ?v) �(?i rdf:type ?v) �(?i VehicleSupplier:hasUKMileage ?m) �

swrlb:lessThan (?m 12000)→MktpB:Gold(?i)

The rule relies on OWL equivalency to reclassify supplier models into the qualitycategories of the marketing partner. The rule then selects ‘‘Premium’’ instances with mileageof less than twelve thousand and the rule’s consequent associates selected instances withthe Gold refurbishment service. Similar rules consider other accumulated mileage rangesto classify ‘‘Premium’’ instances into the Silver and Copper refurbishment categories. Stillother rules declaratively enforce refurbishment policies for ‘‘Standard’’ and ‘‘Economy’’categories.

In the rule prefixes, VehicleSupplier: and MkptB: denote scoped namespaces associatedwith a Vehicle Supplier and a specific Marketing Partner B’s enterprise schema descriptions,respectively. Namespaces prevent name conflicts supporting unambiguous reference to eachpartner’s schema in the merged ontology.

V. SCENARIO TWO—COORDINATING PARTNER EXCHANGESThe case study analysis found that it was difficult to maintain a shared and consistent

view of partner exchanges. A vehicle sale involved multiple partner exchanges includingvehicles and options, refurbishment service, delivery, warranties, cash payments, and fi-nancing. To implement these exchanges, the DEAL system required customized applicationsto track partner workflows associated with sales and payment activities.

Change efforts to coordinate and manage new partnership initiatives never progressed.A change in one partner’s business methods such as a new pricing scheme or new serviceoffering required a cascade of application and database updates. It proved expensive andtime consuming to update procedural artifacts such as programs, databases, and partners’interfaces to cope with these changes.

Semantic Web Rule Language (SWRL) rules support a declarative way to enforce andmaintain a shared view of partner REA exchanges including events, resources, stockflows,and duality relationships. Rules declaratively process partner events and resource flows toderive responses that enforce policy level agreements among trading partners.

Automating REA Policy Level Specifications with Semantic Web Technologies 269

Journal of Information Systems, Fall 2008

The independent view is concerned with maintaining consistency of cross-partner stock-flows of resources and payments among trading partners (McCarthy 2006). From theindependent view, stockflows undergo a change in perspective as resources crossorganizational boundaries (International Organization for Standardization 2007). For ex-ample, a sale event that results in transfers of goods from a supplier’s perspective is apurchase event and a receipt of goods from the purchaser’s perspective.

We classify SWRL rules that assist in maintaining consistency across independent viewexchanges as independent rules. Independent SWRL rules reason only with top-level REA-EO/OWL types and associations or apply globally to all cross-partner exchanges. We clas-sify SWRL rules that apply partner-specific schema to support an individual partner’sexchange policies as dependent rules. One partner, for example, may define a dependentrule to pay cash in response to an inflow event while another may define a different de-pendent rule to respond to that same event by exchanging a service.

Figure 10 illustrates the inference associations between independent and dependentSWRL rules. First, REA-EO/OWL and partner-specific schema provide a semantic clas-sification hierarchy to generalize instances into top-level REA-EO/OWL categories. Sec-ond, independent rules match resulting REA-EO/OWL typifications to create new associ-ations needed to logically structure independent REA cross-partner economic exchanges.For example, an independent rule assures an Outflow Type is matched by an Inflow Typeto maintain consistency and coherence between cross-partner transactions. Third, the newlycreated assertions then trigger partner-dependent rules to infer new sets partner-specificoperational instances required to complete the exchange. The following illustrates patternsof independent and dependent rule inferences as independent and dependent rules worktogether to facilitate exchanges among vehicle suppliers and marketing partners. We tracethe logical application of SWRL rules that enforce a vehicle for cash exchange.

The first rule is an independent rule applied by an OWL reasoner to translate supplieroutflows to buyer inflows.

Rule One: Outflows (from the seller’s perspective) Create New Buyer Inflows (fromthe buyer’s perspective)

ReaOntologySpec:Outflow Type(?x) �(?x ReaOntologySpec:hasDecrementEvent ?ev out) �(?ev out dc:identifier ?i) �(?x ReaOntologySpec:hasOutflowResource ?v)

→ReaOntologySpec:Inflow Type(?z) � ReaOntology: Event Type(?ev in)

(?z ReaOntologySpec:hasIncrementEvent ?ev in) �(?ev in dc:identifier ?i) �(?z ReaOntologySpec:hasInflowResource ? v)

Rule One responds to a vehicle supplier sale outflow (operational-level instances of asale event and vehicle outflow from the supplier’s perspective). The instance of the saleoutflow then ascends by generalization and matches the Outflow Type required by RuleOne’s premise. Rule One then fires and converts the Outflow Type from the perspectiveof the vehicle supplier into a new Inflow Type from the perspective of the marketing partner.The new instance of the Inflow Type type represents an association between the vehicleresource and a new Event Type instance, representing a purchase event from the marketingpartner’s perspective. The rule assigns the new event instance as the value of the new inflowassociation’s ‘‘hasIncrementEvent’’ property.

270 Sedbrook and Newmark

Journal of Information Systems, Fall 2008

FIGURE 10Independent SWRL Rules Reason with Generalized REA-EO/OWL and Partner Schema

while Dependent Rules Specialize from Generalized Assertions to Trigger Creation of SpecificPartner Operational Level Instances

generalize

specialize

Apply REA-EOIndependent SWRLAssociation Rules

Apply Domain SpecificPartner Schema And

Dependent SWRLAssociation Rules

Vehicle SupplierOperational Instances

Marketing PartnerOperational Instances

Semantic ClassificationHierarchy

2

31

Rule Two is a dependent rule that is trigged by the new inflow to enforce the tradingpartners’ policy for the exchange. In this case, the resulting inflow of vehicle resourcesrequires a corresponding outflow of marketing partner’s cash.

Rule Two: Marketing Partner Dependent Rule to Assert Cash Payment Outflows forVehicle Resource Inflows

ReaOntologySpec:Inflow Type(?x) �(?x ReaOntologySpec:hasIncrementEvent ?e) �

(?e dc:identifier ? i) �(?x ReaOntologySpec:hasInflowResource ?y) �

(?y rdf:type VehicleSupplier:Vehicle)(?y owl:hasValue ?p)

→MktpB:CashDisbursement(?m) �

(?m dc:identifier ? i) �MktpB:Cash(?r) �

(?r owl:hasValue ?p)

Automating REA Policy Level Specifications with Semantic Web Technologies 271

Journal of Information Systems, Fall 2008

MktB:PmtOutflow Type(?z) �(?z ReaOntologySpec:hasDecrementEvent ?m) �(?z ReaOntologySpec:hasOutflowResource ?r)

Rule Two responds to the new vehicle Inflow Type instance, created by Rule One toassert a new marketing partner cash Outflow Type instance. The new outflow instancerepresents a new cash disbursement event and a matching cash resource.

The above two rules respond to vehicle inflows by creating matching cash outflows.Finally, the independent Rule Three creates a new Duality Type instance that associatesthe matching increment and decrement events resulting from the inflow and outflow.

Rule Three: Independent Rule to Assert Duality Relations Among Matching Inflowsand Outflows:

(?x ReaOntologySpec:hasIncrementEvent ?i) �(?i dc:identifier ?j) �(?o ReaOntologySpec:hasDecrementEvent ?d) �(?d dc:identifier ?j)

→ReaOntologySpec:Duality Type(?z) �

(?z ReaOntologySpec:hasDecrementEvent ? d) �(?z ReaOntologySpec:hasIncrementEvent ? i)

Figure 11 illustrates the order of application of the above rules. In step one, the mergedontologies permit semantic classification of VehicleSupplierX’s sales events and vehicleresource outflows. In step two, the independent rule (one) fires to convert Vehicle-SupplierX’s outflows into Marketing Partner inflows. In step three, the dependent rule (two)fires to assert new outflows composed of cash disbursement events and cash resources.Finally, the independent rule (three) matches the newly created outflow events to theircorresponding inflow events to assert a new instance of a Duality Type that links the inflowand outflow events.

Figure 12 shows the result of applying Rule Three to update the Marketing Partner’sOWL ontology. Rule Three creates a new instance of a Duality Type by binding its‘‘hasDecrementEvent’’ property to a newly created instance of a Cash Disbursement Event(created by Rule Two) and binding its ‘‘hasIncrementEvent’’ property to the newly createdinstance of a Purchase event (created by Rule One). The reasoner assigns unique hexadec-imal numbers to represent the identity of the instances.

Rule Two specifies a simple policy which requires the Marketing Partner to pay cashaccording to the supplier’s assigned vehicle value. Additional dependent rules, however,are needed to specify policies that reflect alternative pricing models. For example, in thecase of the DEAL partnership, a pricing discount of 10 percent was available to a marketingpartner at the discretion of a supplier’s authorized discount agents. The following dependentrule automates the price discount policy for an authorized vehicle sale.

Rule Two body predicates statements �

(?p rdf:type ReaOntologySpec:Participates Type) �(?p ReaOntologySpec:hasEvent ?e) �(?p ReaOntologySpec:hasFromAgent ?a) �(?e dc:identifier ?i) �(?a rdf:type VehicleSupplierX:DiscountAgent)

→MktpB:CashDisbursement(?m) �

272 Sedbrook and Newmark

Journal of Information Systems, Fall 2008

FIGURE 11Application of Independent and Dependent SWRL Rules to Assert New Instance to Satisfy a

Vehicle Exchange from the Marketing Partner’s Perspective

REA-EO/OWL

REA-EO/OWL

Marketing PartnerSchema

AssertedInflows

GeneralizedOutflows

AssertedDualities

MarketingPartnerB

Asserted instances:(Inflow#a,vehicle

resources#b, cashdisbursements#cdualities#x,etc. )

VehicleSupplierX

(OutFlows#z,SaleEvent#x,Vehicleresouce#y,etc)

Vehicle SupplierSchemaOutflows

1

Apply IndependentSWRL Rule One toVehicle SupplierSchema to Assert NewInflows

3

GeneralizedMetadataClassificationof Stockflows

Apply Marketing Partnerdependent SWRL RuleTwo to Match NewlyAsserted Inflows toAsset new OperationalInstances

4

GeneralizeAssertedInstances toOutflows andApplyIndependentSWRL RuleThree to assertDualityRelationshipsbetweenInflows andOutflows

2

FIGURE 12An Object Diagram of SWRL Asserted Instances of Event Types (Cash Disbursement and

Purchase) and a New Instance of a Duality Type Associating These Two Events

Automating REA Policy Level Specifications with Semantic Web Technologies 273

Journal of Information Systems, Fall 2008

(?m dc:identifier ? i) �MktpB:Cash(?r) �

swrlb:multiply(?dp, ?p, 0.10) �(?r owl:hasValue ?dp) �

MktpB:PmtOutflow Type(?z) �(?z ReaOntologySpec:hasDecrementEvent ?m) �(?z ReaOntologySpec:hasOutflowResource ?r)

The rule’s body extends Rule Two to now consider the Participates Type association.The rule is triggered when the Participates Type’s ‘‘hasFromAgent’’ property is assignedan agent of type VehicleSupplierX’s Discount Agent. Triggering the rule computes a 10percent cash discount and creates a new Marketing Partner payment Outflow Type thatreflects the discount.

Prototype EvaluationSoftware development teams were disbanded after the DEAL project failed, which

prohibited further evaluation of the prototype within an ongoing development setting. Wenevertheless engaged in follow-up discussions with the project architect on the applicabilityof the prototype. We reviewed project documentation, including use-cases, UML-baseddesign documents, partner correspondence, and business planning documents to criticallyevaluate the prototype’s approach.

We tested heterogeneous partner ontologies and experimented with independent anddependent SWRL rules for structuring and enforcing policies by categorizing instance typesand creating new inflows, outflows, events, and participation types. We identified partnerpolicies that had changed during the DEAL partnership. For changed policies, we reviseddependent rules and again simulated partner exchanges. Independent rules remainedunchanged.

Table 1 evaluates and compares the system development approach in the DEAL casestudy to the REA-EO/OWL proof-of-concept prototype. The comparison dimensions in-clude ease of collaborations, flexibility of changes, and process and transactions alignment(Malhotra et al. 2005). The assessment suggests that the prototype’s combination of REAontologies and semantic web technologies is a new opportunity to help multienterprisepartnerships continually adapt their systems to cope with change.

VI. CONCLUSIONS AND FURTHER RESEARCHThe DEAL project was characterized by constant changes in requirements, partnership

agreements, and business models. DEAL was typical of multienterprise collaborations thatmust continually align supply chains and adapt to chaotic business environments. The casestudy revealed problems in coordinating information systems within distributed partner-ships, including complex workflows, data incompatibility, communication delays, andtightly coupled interfaces and systems. The investigation highlights the need for maintain-able and scalable architectures to support evolving partnership collaborations.

The Resources, Events, and Agents of the REA enterprise ontology (REA-EO), com-bined with Web Ontology Language (OWL) representations, provides a modular, shareable,and platform independent way to organize distributed multienterprise ontologies. Web On-tology Language (OWL) uses standard communication protocols to semantically reconcilechanging resources, events, and agents across geographically dispersed partners. A webservice API supports search integration and reasoning with real-time ontologies to supportinteroperable partner applications.

274 Sedbrook and Newmark

Journal of Information Systems, Fall 2008

TABLE 1Comparison of Facilities of the DEAL Failed Development Approach and the

Proof-Of-Concept Prototype

Ease of MultienterpriseCollaboration Flexibility of Change

Process and TransactionAlignment

DEALDevelopmentApproach

● Lacked a consistentmethod of formallyorganizingmultienterprise businessconcepts.

● Relied on customnegotiations with eachpartner to resolvemisunderstandings.

● Required expensiveand time-consumingupdates to hard-wired proceduralprograms tointegrate changes topartner data andprocesses.

● Required opaque andprocedurally basedworkflow programs tostructure interactions.

● Tracking andcoordination requiredcustomized messagesand interfaces betweenpartners.

REA OWLand SWRLPrototype

● The specialized REA-EO/OWL provides anorganizing ontologythat unifies exchangeconcepts.

● The frameworksupports semanticvisibility andinteroperability ofindividual partnerenterprise schema.

● OWL and SWRLformally represent andshare semantic contentacross distributedpartners to help alignexchanges and policies.

● REA-EO/OWLprovides a semanticfoundation toincorporate newpartners andchanges to existingpartner products andservices.

● A common APIintegrates OWLsemantic data storesand SWRL standardrule engines tosupportinteroperation ofpartner applicationsand data feeds

● REA-EO/OWLenforces consistency inintegration andreasoning acrossontologies.

● SWRL provides aclear, coherent andconsistent declarativelanguage to representpartner exchanges.Standard reasoningengines are availableto apply event-drivenupdates acrossdistributed ontologies.

Semantic Web Rule Language (SWRL) models support event-driven, machine execut-able representations to help a distributed set of partners better assess and coordinate businesspolicy changes. Partners maintain their individual enterprise schema and collaborate byproposing declarative rules to structure interactions. Semantic Web Rule Language (SWRL)provides an explicit machine-executable representation that allows multienterprise designersto formally express their policies, consistently respond to partner events, and adapt tochanging business situations.

We presented an executable ontological representation of a specialized REA-EO/OWLontology that applies semantic web technologies. Web Ontology Language (OWL) wasused to represent type and association semantics. Additionally, independent and dependentSWRL rules were used to automatically direct the construction of associations representingstockflows and dualities, and enforce trading partner exchange policies.

The architectural design attempts to overcome limitations inherent in procedural andcustomized programs by explicitly capturing intentions of managers, automating consis-tency checks and promoting distributed information sharing. The case study analysis andsubsequent prototype evaluations suggest REA-EO specifications and domain-specific en-terprise schema, combined with OWL and SWRL can improve the agility and adaptabilityof partnerships operating in turbulent environments.

Automating REA Policy Level Specifications with Semantic Web Technologies 275

Journal of Information Systems, Fall 2008

The prototype evaluation highlights the key role that REA-EO plays in structuring theapplication of semantic web technologies. Future research is needed to standardize andpromote a machine-executable representation of REA-EO to support OWL and SWRL incoordinating multienterprise partner exchanges.

Limitations of the prototype’s evaluation include a post hoc analysis that evaluated itseffectiveness against case study scenarios. Therefore, the resulting OWL models reflectsubjective interpretations by investigators rather than continuing collaborations among part-ners. Future studies should investigate partner co-development of the REA models thatallow partners to apply OWL and SWRL to define and mitigate changes to multienterprisecollaborations.

Efforts are underway to promote semantic interoperability of service oriented architec-tures (SOA) (Vitvar et al. 2007). SOAs integrate business functions by loosely couplingbusiness web services. Further research is needed explore the role of REA-EO, OWL, andSWRL within developing SOA semantic information standards. Semantic interoperabilityis critical to agile business models that require enterprises to dynamically assemble partnersand respond ‘‘on the fly’’ to highly volatile and turbulent environments.

REFERENCESAdamson, I. L., and D. M. Dilts. 1995. Development of an accounting object model from accounting

transactions. Journal of Information Systems 9 (1): 43.Amer, T. S. 1993. Entity-relationship and relational database modeling representations for the audit

review of accounting applications: an experimental examination of effectiveness. Journal ofInformation Systems 7 (1): 1.

Baclawski, K., M. K. Kokar, P. Kogut, L. Hart, J. Smith, J. Letkowski, and P. Emery. 2002. Extendingthe unified modeling language for ontology development. Software and Systems Modeling 1(2): 142–156.

Bergholtz, M., P. Jayaweera, P. Johannesson, and P. Wohed. 2003. Process models and businessmodels—A unified framework. 22nd International Conference on Conceptual Modeling. Chi-cago, IL, Springer.

Brodie, M., and D. Ridjanovic. 1984. On the design and specification of database transactions. In OnO. C. Modeling. New York, NY: Springer-Verlag.

Chen, J.-L., D. McLeod, and D. O’Leary. 1995. Domain-knowledge-guided schema evolution foraccounting database systems. Expert Systems with Applications 9 (4): 491–501.

David, J. S., C. L. Dunn, W. McCarthy, and R. Poston. 1999. The research pyramid: A frameworkfor accounting information systems research. Journal of Information Systems 13 (1): 7.

Dublin Core Meta-Data Initiative. 2008. DCMI schemas. Available at: http: / /dublincore.org/schemas/ .

Dunn, C. L., and S. V. Grabski. 2000. Perceived semantic expressiveness of accounting systems andtask accuracy effects. International Journal of Accounting Information Systems 1: 79–87.

Gailly, F., and G. Poels. 2006a. Towards an operational REA ontology using web ontology languages.Proceedings of the 2nd International REA Technology Workshop, Santorini Island, Greece, ITUniversity Technical Report Series, IT University of Copenhagen, Denmark.

———, and ———. 2006b. Towards an OWL-formalization of the resource event agent businessdomain ontology. Formalization REA Business Domain Ontology. Ghent University, The Neth-erlands: Ghent University Department of Economics and Business Administration.

Gasevic, D., D. Djuric, and V. Devedzic. 2006. Software engineering approaches to ontology devel-opment. In Model Driven Architecture and Ontology Development, 145–180. Heidelberg, Ger-many: Springer-Verlag.

276 Sedbrook and Newmark

Journal of Information Systems, Fall 2008

Geerts, G. L., and W. E. McCarthy. 1999. An accounting object infrastructure for knowledge-basedenterprise models. IEEE Intelligent Systems and Their Applications 14 (4): 89–94.

———, and ———. 2000. Augmented intensional reasoning in knowledge-based accounting systems.Journal of Information Systems 14 (2): 127.

———, and ———. 2002. An ontological analysis of the economic primitives of the extended-REAenterprise information architecture. International Journal of Accounting Information Systems(3): 1–16.

———. 2004. An XML architecture for operational enterprise ontologies. Journal of Emerging Tech-nologies in Accounting 1: 2004.

———, and W. E. McCarthy. 2006. Policy level specifications in REA enterprise information systems.Journal of Information Systems (Fall).

———, and H. J. Wang. 2007. The timeless way of building REA enterprise systems. Journal ofEmerging Technologies in Accounting 4: 161–182.

Hessellund, A. 2006. Supply chain modeling with REA. IT University of Copenhagen. TR-2006-80.University Technical Report Series: 1–15.

Hevner, A. R., S. T. March, J. Park, and S. Ram. 2004. Design science in information systems research.MIS Quarterly 28 (1): 75–105.

Horrocks, I., P. F. Patel-Schneider, H. Boley, S. Tabet, B. Grosof, and M. Dean. 2004. SWRL: Asemantic web rule language combining OWL and RuleML. World Wide Web Consortium(W3C). Available at: http: / /www.w3.org/Submission/SWRL/.

Hruby, P. 2006. Model-Driven Designs Using Business Patterns. Berlin, Germany: Springer.International Organization for Standardization. 2007. Information Technology—Business Operational

View—Part 4: Business Transaction Scenarios—Accounting and Economic Ontology. ISO/IECFDIS 15944-4. Geneva, Switzerland: International Organization for Standardization.

Jena 2 inference support. 2008. Available at: http: / / jena.sourceforge.net / index.html.Lacy, L. W. 2005. OWL: Representing Information Using the Web Ontology Language. Victoria,

Canada: Trafford Publishing.Malhotra, A., S. Gosain, and O. El Sawy. 2005. Absorptive capacity configurations in supply chains:

Gearing for partner-enabled market knowledge creation. MIS Quarterly 29 (1): 145–187.McCarthy, W. E. 1982. The REA accounting model: A generalized framework for accounting systems

in a shared data environment. The Accounting Review (July): 554–578.———. 2006. The 2nd International REA Technology Workshop. ISO/IEC 15944-2. Santorini Island,

Greece.Mentzas, G., D. Apostolou, K. Kafentzis, and P. Georgolios. 2006. Inter-organizational networks for

knowledge sharing and trading. Information Technology Management 7: 259–276.Nakamura, H., and R. E. Johnson 1998. Adaptive framework for the REA accounting model.

OOPSLA’98 Business Object Workshop, Vancouver, Canada.Nonaka, I., and R. Toyama. 2003. The knowledge-creating theory revisited: Knowledge creation as a

synthesizing process. Knowledge Management Research & Practice (1): 2–10.Documentation for Sesame & Rio. 2008. Available at: http: / /www.openrdf.org/documentation.jsp.Orriens, B., J. Yang, and M. Papazoglou. 2003. A framework for business rule driven web service

composition. Conceptual Modeling for Novel Application Domains, ER 2003 WorkshopsECOMO, IWCMQ, AOIS, and XSDM. Chicago, IL: Springer.

Oshri, I., S. L. Pan, and S. Newell. 2005. Trade-offs between knowledge exploitation and explorationactivities. Knowledge Management Research & Practice (2005) (3): 10–23.

OWL Web Ontology Language Overview (W3C). 2003. Available at: http: / /www.w3.org/TR/2003/CR-owl-features-20030818/ .

Query language for RDF W3C proposed recommendation (W3C). 2008. SPARQL. Available at: http:/ /www.w3.org/TR/rdf-sparql-query/ .

Reuber, A. R. 1990. CO-STAR: A semantic representational schema for cost management. Journalof Information Systems 4 (2): 15.

Automating REA Policy Level Specifications with Semantic Web Technologies 277

Journal of Information Systems, Fall 2008

Sowa, J. F. 2000. Knowledge Representation: Logical, Philosophical, and Computational Foundations:Logical, Philosophical, and Computational Foundations. Boston, MA: Brooks/Cole ThomsonLearning.

Sugumaran, V., and V. C. Storey. 2006. The role of domain ontologies in database design: An ontologymanagement and conceptual modeling environment. ACM Transactions on Database Systems31 (3): 1064–1094.

Uschold, M. 1996. Building ontologies: Towards a unified methodology. The 16th Annual Conferenceof the British Computer Society Specialist Group on Expert Systems, Cambridge, UnitedKingdom.

Verdaasdonk, P. 2003. An object-oriented model for ex ante accounting information. Journal of In-formation Systems 17 (1): 43.

Vitvar, T., M. Zaremba, M. Moran, and D. Fensel. 2007. SESA: Emerging technology for service-centric environments. IEEE Software 24 (6): 57–67.

Zhang, W., L. Lin, J. Qui, R. Tong, and J. Dong. 2005. An ontology-based functional modelingapproach for multi-agent distributed design on the semantic web. Computer Supported Coop-erative Work in Design II, 9th International Conference CSCWD, Coventry, U.K.