SEMANTICS OF COMMERCIAL TRANSACTIONS
Levent V. Orman
Cornell University, Ithaca NY 14853
www.johnson.cornell.edu/faculty/profiles/orman
Abstract:
Commercial transactions have rich semantics that is largely ignored by the commercial data base systems. Capturing the semantics in a machine-searchable form would create an infrastructure that can support a variety of novel applications, ranging from recommendation systems and consumer communities, to experimental and virtual organizations. Recommendation systems can be reduced to mere queries against rich semantic transaction databases. Consumer tasks and consumer goals can be expressed unambiguously as collections of transactions, and semantic descriptions of these large aggregates allow consumers to subscribe to the aggregates, instead of executing individual transactions, significantly reducing transaction costs. Incentives can be designed to encourage consumers, businesses, and third party experts to contribute to the creation of such databases, by creating an environment that generates economic opportunities from small contributions. Finally, organizations can be described unambiguously as collections of transactions they executed in the past, and as collections of transactions they plan and anticipate for the future. Such descriptions can be used by the various stakeholders to exert strict controls over the organization at various levels of detail.
Keywords: commercial transactions, transaction semantics, semantic data model, semantic queries, recommendations, virtual organization
1. Commercial Transactions
A commercial transaction is an exchange of resources. In modern economies, transactions typically take place in physical or electronic marketplaces, and they involve an exchange of cash or credit for various goods and services. Credit is often provided by third parties such as banks and credit card companies through various payment systems. More complex transactions involving multiple parties, and delayed or repeated exchanges of various resources, are also common. A commercial transaction may involve individuals, firms, nonprofit or government organizations, or even take place entirely within an organization. A transaction can be a spot transaction with the exchange taking place completely at a certain point in time, as in cash purchases of consumer items. It can be a delayed transaction where the two sides of the exchange are not synchronized, as in credit sales or deliveries where the payment or the delivery of goods comes at a later date than the sale. It can also be a protracted transaction with multiple exchanges taking place over a period of time, as in employment transactions, where the value is generated over time, and the payments are made periodically [5].
Commercial transactions are recorded carefully in the databases of the participating firms for reporting and auditing purposes. Even individuals tend to track their transactions, and sometimes keep records, for the purposes of tax computation and reporting, settling disputes, or budgeting and planning. But the information captured about transactions is minimal, and the rich semantics of transactions often remains buried in the minds of the participants. A typical commercial transaction may record what was exchanged and who the participants were. But, the rest of its semantics is not likely to be recorded anywhere, such as the purpose of the exchange (i.e. did you buy that book as a gift, or for yourself), the context of the exchange (i.e. was it a birthday gift for your ten-year old nephew), the expectations from the exchange and the extent to which those expectations were satisfied (i.e. did you expect it to be a children’s book, and was it), the relationship to other transactions, past, present, and future (i.e. did you have the book shipped, did you have the cover engraved, did you also buy the second volume later when your nephew liked the first), and other transactions that were considered in lieu of this one, but rejected, and the reasons for it (did you consider buying a CD instead, but rejected it, and why). Such semantic content can be very useful, if captured and recorded in a searchable format, in a variety of applications ranging from recommendations, advice, and planning, to reducing transaction costs, automating some predictable transactions, and building flexible and experimental organizations. That is the objective in this article through semantic modeling of commercial transactions [23].
2. Semantics
Semantics has received a great deal of attention in the context of the Semantic Web [2]. Description of web documents has been critical to the development of WWW, and more effective description through semantic models is an ongoing concern to facilitate more effective search and utilization of the web resources [11, 12]. Extended Manipulation Language XML was a critical development. It created a tagging system for document components, attaching keywords to document components, which in turn allowed querying for document components on the basis of those tags [11]. The tags can be viewed as attribute names attached to values where the values are document components, leading to a collection of attribute-value pairs. For example the text “Ford Focus” can be tagged with the keyword “car model”, leading to an attribute-value pair of “car model-Ford Focus”. Such attribute-value pairs have been the basis of many semantic models ranging from semantic networks to semantic data models [22, 23, 24].
Attribute-value pairs of XML can be arranged hierarchically to represent the hierarchical arrangement of document components [11]. For example, a car document and its Ford subcomponent are in a hierarchical relationship. These document components are stored as XML databases and queried using XML query languages such as XQuery and XPath that retrieve document components when related components in an XML hierarchy satisfy some given attribute-value conditions. For example, the fuel economy mpg of Ford Focus hatchback can be retrieved from an XML document about cars with the tag sequence of
car. ford. focus. hatchback.mpg=?
by using a stylized language similar to XPath where every node on the path is a node on a type hierarchy or an attribute name. A number of languages such as XPath are available to query XML databases, and similar attribute-value based query languages have been very successful with relational and object-oriented databases also [4, 22]. XML databases are supported by Data Type Descriptions (DTD’s) which act as schemata to ensure consistent use of tags. DTD’s can also be extended to universal ontologies that define terms, place them in type hierarchies, and attach constraints to limit the acceptable values [10,17].
XML provides an infrastructure on top of which more elaborate semantic structures can be built. XML’s simple attribute-value pairs proved inadequate for universal identification and description of web resources, and reasoning and inference with such widely distributed objects. Resource Description Framework (RDF) was built on top of XML, and extended XML with Universal Resource Identifiers (URI) for unique identification of all resources, and with entity-attribute-value triplets where entities are uniquely identified by URI’s and the values can be other entities [12]. Such a recursive definition increases the semantic power of the model, and the complexity of the resources it can describe. Finally, the resource descriptions have to be placed in central repositories to facilitate search, selection and retrieval. This capability requires searchable resource description databases, and many of these were developed such as the Universal Description Discovery and Integration (UDDI) framework [12, 25]. They all rely on XML for their database structure, and XML languages for search, selection, and retrieval.
This article follows in the tradition of semantic resource description, but focuses on a specific resource: commercial transactions. It sketches out a semantic model to describe commercial transactions using an RDF type model; it develops the arguments for developing such a model, including its advantages both for business and consumer applications; and finally it lists technical and organizational difficulties in developing such an extensive semantic system, and proposes solutions. As a first attempt in designing such a large scale semantic system, it focuses on motivation, advantages, and general design principles, rather than specific implementation, scale, and efficiency issues.
3. Transaction Semantics
Consider the purchase of an automobile. The transaction is recorded by the seller, and the record includes a description of the automobile, the sale price, the payment method, and the buyer’s identity. The buyer may also record the transaction in his personal records for tax and record keeping purposes including the price, the payment method, and the seller’s identity. The third parties such as insurance companies and government agencies may also record the same data for insurance and registration purposes. Such transaction databases of large businesses and government agencies grow quickly to terabyte sizes, and become difficult to use. But, despite their formidable size, they fail to capture some important components of the transaction semantics, which contributes to their usability problems. For example, they fail to capture and record why the automobile was purchased, how it was intended to be used, and for what purpose, i.e. its goal semantics. They fail to capture and record how it was used after the purchase, and which objectives were satisfied and to what extent, i.e. its outcome semantics. They fail to record and capture secondary transactions such as insurance, repairs, maintenance, accessories, and the eventual replacement, and the relationships between the secondary transactions and the original transaction, i.e. its bundle semantics. They fail to capture and record what other automobiles were considered, but rejected by this consumer, in lieu of this transaction, and why they were rejected, i.e. its alternatives semantics. Finally, they fail to capture and record the conditions and the events that triggered this automobile purchase, i.e. its time semantics.
Capturing and recording such information in a searchable format can have significant benefits. Such semantic information can be queried by consumers in their search for detailed product descriptions and recommendations. A typical query would involve finding the most appropriate automobile for a given set of requirements and consumer characteristics, by utilizing the goal and outcome semantics. The semantic information can also be aggregated to predict future needs of consumers and the future demand for the products and services of businesses under various economic conditions and triggers. Typical aggregate information could determine the demand for a particular model of cars, in a particular community, at times of increasing oil prices, or increased sensitivity to environmental degradation, by utilizing the time and alternatives semantics. The semantic information can be organized to identify and bundle groups of related transactions, for specific consumers, to reduce transaction costs. A typical bundle would cluster an automobile purchase with insurance and maintenance contracts, or even the eventual replacement of the automobile, into a single transaction by utilizing the bundle semantics. The semantic information can be analyzed to aid in the design of new products, services, and new organizational forms. Some design opportunities for an automobile dealer could be new leasing arrangements, new pricing schemes, or new car sharing or customized transportation systems, by utilizing the goal and alternatives semantics. The semantic information can be used to identify select consumers and third party experts who provide useful relevant information to others, and reward them with leadership opportunities. Typical leadership opportunities could be in the form of role models, consumer community leaders, and expert advice generators, by utilizing the outcome and alternatives semantics.
A typical commercial transaction records what resources are exchanged, and who the participants are. These can be called “what” and “who” semantics. A complete semantic description would have to elaborate on what and who semantics by describing the resources and the participants in detail, and would have to add many more components, such as the goal of the transaction, called the “goal” or “why” semantics; the use of the resources involved and the resulting satisfaction level, called the “outcome” or “use” semantics; the location of the transaction, called the “location” or “where” semantics; the payment mechanism, called the “payment” semantics; secondary transactions supporting the original transaction, called the “bundle” or “what else” semantics; and the alternative transactions that have been considered and rejected, called the “alternatives” semantics. All of these components can be implemented as the attributes of an RDF resource, where the resource is a commercial transaction. The values attached to these attributes can be quite complex, and require the full recursive power of RDF, where the attribute values can themselves be entities with their own attributes, and with complex constraints and relationships imposed on them. Such complexity is rare in corporate data stores, or even in web documents, and it motivates the complex model proposed in this article. The complexity is exacerbated by the difficulty of collecting, structuring, searching, and utilizing such complex and detailed information about transactions.
transaction 655876
who what why outcome when where payment what else alternatives
entertainment feeling oct1208 theater
buyer seller action object type amount action object action object why not
JohnSmith Cinemapolis watch movie romance romantic Cinemapolis cash $8 buy popcorn watch football
who who when
Casablanca Bills Cowboys oct1208 too expensive too violent
Figure 3.1: The model of a simple transaction of John Smith going to the movies where the labeled edges are attributes and the unlabelled edges are subtypes.
The basic model of Figure 3.1 is a simple set of entity-attribute-value triplets such as transaction-why-entertainment that can be implemented as a relational database with commercial software that stores and maintains the data and facilitates retrieval with its query language [21]. But there are a number of complications. The first complication is the need to disambiguate the terms used, for universal consistency in a large scale distributed system. The solution for entities is to use Universal Resource Identifiers (URI’s) as suggested by Resource Description Framework (RDF) [7]. Figure 3.1 contains URI’s at all unnamed nodes and also at the transaction node. The solution for attribute-value pairs is to use ontologies, such as Web Ontology Language (OWL) attached to RDF [8]. Ontologies place each attribute value into a type hierarchy, and attach to it a dictionary definition and constraints [16]. The movie Casablanca for example points to a specific movie in the movie ontology. The movie is identified uniquely by a URI; it is characterized by the type hierarchy of the ontology as to its genre and type; and it is described by a set of attributes of the movie entity to identify its actors, directors, producers, awards it won, and the reviews it received. These features can be implemented with a relational database for the attribute-value pairs, OWL ontologies for defining attribute values unambiguously in dictionaries and type hierarchies, and special pointers inserted into the database linking database values to the ontology entries, as shown in Figure 3.2.