This paper discusses the role contexts play in the meaning of the semantics of an ontology. It is based on observations from three different but related fields:
The paper starts with some background thoughts that help to set the context for what follows. It then tries to identify what constitutes "the truth", distinguish it from "the whole truth" and then identify what "nothing but the truth" means. Finally I appeal for God's help as to how to resolve the problems that face us in enabling the interchange of business data on a global basis in a way that does not have a particular linguistic or cultural bias.
F. H. Bradley stated in 1914 that the aim of thought is to develop a comprehensive and coherent system of concepts. This is basically what is needed for global commerce. We need a set of concepts that trading partners in different countries can accept as a common basis for exchanging information.
There are two principal types of data that businesses need to exchange: commercial data and technical data. The electronic exchange of commercial data has for many years been harmonized through the UN's work on Electronic Data Interchange For Administration, Commerce and Transport (EDIFACT) and related efforts by various industry bodies. The electronic exchange of technical data has been the remit of the International Organization for Standardization's technical committee responsible for product data exchange (ISO TC184). This paper is based on observations of trends in both of these arenas.
Ontology is defined in the Concise Oxford English Dictionary as the "department of metaphysics concerned with the essence of things or being in the abstract". Webster define "ontological" as "pertaining to the science of being in general, and its essential attributes and relations". This ties in nicely with the modern concepts of data modeling, as practiced using languages such as the Unified Modeling Language and ISO TC184's EXPRESS language, which formally describe the attributes of "objects" and relationships between them.
What is the truth? This is one of the great questions of metaphysics and philosophy in general. I don't intend to try to answer such a thorny question in this short paper, but I do want to explain the role that context plays in the understanding of truth.
Truth is a basic concept in the "realist" field of metaphysics, but what it constitutes is a matter for heated debate. In his Presidential Address to the 77th Annual Western Division Meeting of the America Philosophical Society in 1979, William P. Alston asked that those in the "non-realist" school of metaphysics to "abandon the concept of truth and talk instead of justification, confirmation and verification". As early as 1920 John Dewey had called for the replacement of the term "true" with "warrantably assertable". But I would contend that neither of these approaches, in themselves, is sufficient. Let me try to illustrate why not. Consider the following "tale" of the role of three identical red flags:
Our three identical red flags, from same production batch, are owned by Englishman Mike Brown, Russian Mikhail Teplov and Chinaman Chang Sheng.
When there is a carnival in his home town Mike Brown hangs his red flag out of the window as one of the street decorations. Once a month he uses the red flag whilst working as the guard on a preserved steam railway. Here he waves the red flag when he wants to stop a reversing train.
Mikhail Teplov works for the Russian State Railway, where he too needs to wave his red flag to stop reversing trains. In his spare time he is a member of the local communist party, with whom he regularly goes on parades waving his red flag as a symbol of his support for the party.
Chang Sheng is currently training in a Chinese Railway School, where he has to wave his red flag in class. This does not actually stop any trains, but does help educate him in what is required to stop trains. When there is a carnival in his home town the local communist party normally parade past Chang's house. On such days he, like Mike, hangs the red flag out of the window. But for what reason? Is it for the same reason as Mike does, or for the same reason that Mikhail does, or for both reasons.
Note that during the changes in the context in which these flags are used there is no change in the physical attributes of the flag, or in the relationships between them. What changes is the contexts in which the flags were being used, and the justifications that apply to the use of such a flag in such a context. There is no more "truth" in the assertion that "a red flag is a symbol of the communist party" than there is in the assertion that "a red flag is used by a guard to stop a reversing train" or "red flag's are used as decorations for carnivals". All three are true statements in a particular context, and may be false statements in another context. For example, in England would it not generally be true to link the statement "red flag's are used as decorations for carnival" with the statement "a red flag is the symbol of the communist party", but in China it might be relevant to link these two statements.
Truth is also a thing which is critically dependent on time. Consider the role of a red flag hung out in a Chinese street in the T'ang dynasty. Does that have the same role as a similar one hung out in 1960? Whilst some time dependencies of truth have clear time boundaries, others do not. Consider the following questions:
The trunk of a tree that fell in a rain forest more than a million years ago can now be seen as a fossilized trunk in the middle of the Arizona desert. At what point in time (or place) did the wood (in the forest) change into stone (in the desert)?
A white snowflake that fell in Antarctica 5000 years ago now forms part of a 'black' iceberg that has recently 'calved' off the ice cap. At what stage did the snowflake change its colour or other measurable properties?
There are no clear answers to these questions. For any gradual process it is not possible to categorically state when something occurs, only when the process started and when it was observed to have been completed.
In one of her Adrian Mole books Sue Townsend gives Adrian's address in the form:
302 High Street
Longville
Rutland
England
Great Britain
Europe
The Earth
The Solar System
The Universe
This form of address clearly defines the context in which Adrian is supposed to have existed. Note its comprehensiveness. The Universe is presumably that area delimited by what scientist know as the "echo of the big bang". The Solar System seems at first sight to be more ambiguous, but what other interpretation could be given to it? (Unlike many science fiction writers I cannot for the life of me envisage any other civilized life form inventing a language that used the same shaped characters and same grammatical structures as English, so I presume that "The Solar System" is a unique set of symbols that only has meaning when interpreted in one language within Adrian's universe.) Similarly The Earth is the term used in English to denote the third planet from the solar component of the enclosing system, and England is clearly identifiable as part of the largest island in the northeast part of the narrower of the two oceans that stretch from the north to the south pole, which is part of the political unit referred to as Great Britain within the continental area known as Europe.
The point of this example is to show that by explaining all possible contexts it is possible to identify a clearly unique object (even if a fictional one in this example!). In general, however, we do not need to be so explicit. Some things can be taken for granted. For example, if we wanted to address a letter to Adrian we would stop at England: anything further would be a waste of time as, so far, there are no inter-planetary mail services that pick up from our planet. (We should, however, remember to translate England into the name used to describe England in the language that is used where the letter is posted, otherwise there is a chance the letter may not get to first base!)
To determine the whole truth of a subject we, therefore, need to be able to distinguish the contexts that are needed to uniquely identify it from similarly-named related or unrelated subjects. This is especially important within business communications. An order may contain a number of addresses, and a number of dates. As well as the address of the person or company submitting the order there may need to be a separate delivery address, invoice address and even an address of a carrier. In some cases the order may even require to specify an address that is to be placed on one or more items that have been ordered. Simply referring to the information as an address is not sufficient. The context in which the address is to be applied must also be clearly specified. Similarly the order may have a date of creation and a delivery date. It may also refer to other documents, such as a price list, using a date. Therefore each occurrence of a date within the order has to be qualified by a context to distinguish it from other information objects of the same type.
Yet there need be no intrinsic difference between the type or structure of the different addresses or dates in the order. In most cases a single "information object type" will suffice for all uses. What is necessary is that either the information object has some property that distinguishes its role from that of other information objects of the same type, or that its context within the message unambiguously defines its role.
In the past the context in which the address or date appears has normally made it possible for an intelligent human being to correctly interpret its role. But now that we are relying more and more on "dumb" computers, we need to take more care to ensure that the context in which we are using an information object is clearly distinguishable from all occurrences of similar information objects.
How can we distinguish the truth from the information available to us? Can we expect a computer to be able to make the same distinctions? Or perhaps what I should really ask is "How can we ensure that we record the full context in which an information object is used in a manner that can be unambiguously interpreted by a computer?"
One way that we can help the computer to understand the contexts in which we use information is by clearly relating that information to an information model. What form should that model take? Should it be a network, of the type typically created by formal modeling languages and knowledge management systems, or should it be a hierarchy of the type typically used in information management systems developed for the production of printed documentation?
One of the problems with many network-based modeling systems is that they allow an information object to occur in multiple contexts without clearly identifying each context. Hierarchical structures are much better in this respect in that for every information object there is a set of "ancestral" information objects that show the relationship between the object and the root of the information set. Providing the permitted paths are uniquely identifiable it should be possible to distinguish between the roles of different uses of a particular information object.
Hierarchies, however, often make it harder to record the relationships between objects that are a key factor in any modeling system. Related objects can start a different points in different hierarchies. This can be because the starting point in one hierarchy is at a higher level than in another, or because one hierarchy has left out some steps that the other hierarchy had to use to differentiate the use of information objects. To determine relationship it is often necessary do partial rather than exact matches within the ancestor lists of related information objects, or to rely on some form of key to relate one information object to another (as is typically used to relate different types of information object within relational databases).
The recording of relationships between information objects has been a key factor in the development of the so-called "Information Age". The main factor in the success of the Internet to date has been the ease with which it allows people to move from one information source to another, related, one. To date this has mainly been done using "keys" - pre-determined pointers from one named information object to another. The recent development of a hierarchically structured Extensible Markup Language (XML) for describing information sets to be exchanged over the World Wide Web will, however, radically change this. In future we will not need to rely on predefined relationships but will be able to build relationships "on the fly" by searching for the use of particular information objects in specific contexts.
In environments based on structured information sets the key to the automation of relationships will be the consistency of the semantics used to describe the contexts in which information objects are being used, and the power of tools in identifying context matches where different structuring levels apply to different information sets.
It is unlikely that all user communities will adopt a single set of semantics, so tools used to automatically identify relationships will need to be able to build or reference "maps" that bring together related concepts. To make this easier the concepts will need to be broken down into easily mappable components. It is one thing to map Address to Addresse and Anschrift, but altogether a different one to map Delivery.FinalLocation.RelatedLocation.Code to DeliveryLocation.Warehouse.CustomerAssigned.Identifier, which are two of the object names currently proposed for the mapping of EDIFACT information objects by ISO's TC154 data semantics group. If, however, these names are broken down into their component information object contexts (e.g. Delivery/Location[Final]/Location[Related]/Code and Delivery/Location/Location[Warehouse]/Identifier[CustomerAssigned]) the relationships between them can become much easier to spot and we can start to consider using computers to identify relationships.
If we want "nothing but the truth" it is important that we develop mechanisms for associating information objects based on the characteristics of their "basic semantic units" rather than on compound names developed specifically to differentiate one concept from another closely related one. It has to be realized that similarities are more important than differences in information management. Only when we can create maps between similar basic semantic units will it become possible to automate the identification of relationships, which must be the long-term goal of any business information management project. The first stage in this process is to allow the context in which each basic semantic unit is being used to be fully recorded.
So what can we start doing today to make this long-term goal a reality? The first thing we must do is to start structuring our information in such a way that the role of each piece of information is clear from its position within the structure. Consider the following two examples, one of which uses HTML to describe an order in terms of its presentation characteristics, and the other that uses XML to describe the same information in terms of its logical structure. The HTML file looks like:
<H1>Purchase Order</H1> <P>Order Number: 12346633</P> <P>Order Date: 2000/1/21 <P>From: XYZ Trading</P> <Address>29 High Street<br> Lowertown<br> Durham</Address> <P>To: ABC Supplies</P> <Address>200 Millbank<br> Uppertown<br> Durham</Address> <p>Deliver To: The Post Office <Address>High Street<br> Lower Loxley<br> Durham</Address> <table> <tr><th>Item No:</th><th>Item Name</th><th>Quantity</th></tr> <tr><td>11245132</td><td>Dolly Mixture</td><td>2 gross</td></tr> <tr><td>15743576</td><td>Wine Gums</td><td>10 kg</td></tr> </table>
Note that with the exception of the Address element, the "markup" within the angle brackets that is used to describe the layout of the document tells us nothing about the role of the data within the message.
The same order can be described in a structured language such as XML as:
<Order>
<DocumentNumber>12346633</DocumentNumber>
<Date Of="Order">2000/1/21</Date>
<Buyer>
<Company>XYZ Trading</Company>
<Address>
<Street>29 High Street</Street>
<Place>Lowertown</Place>
<Area>Durham</Area>
<Address>
</Buyer>
<Seller>
<Company>ABC Supplies</Company>
<Address>
<Street>200 Millbank</Street>
<Place>Uppertown<Place>
<Area>Durham</Area>
</Address>
</Seller>
<DeliverTo>
<Company>The Post Office</Company>
<Address>
<Street>High Street</Street>
<Place>Lower Loxley</Place>
<Area>Durham</Area>
</Address>
</DeliverTo>
<Item ProductNo="11245132">
<ProductName>Dolly Mixture</ProductName>
<Quantity>2 gross</Quantity>
</Item>
<Item ProductNo"15743576">
<ProductName>Wine Gums</ProductName>
<Quantity>10 kg</Quantity>
</Item>
</Order>
Whilst this format is more verbose, it is also much more explicit. The role of each data field is clearly defined by its name, as are the limits of where the name starts to apply and when it stops applying. Similarly the parents of each element clearly define its role. The three Address elements are clearly defined as identifying the Buyer, Seller and DeliverTo locations for the order by being contained within elements of this name. Similarly the role of the components that make up an Item of the Order have clearly defined roles.
Each data element in the well structured XML document can be uniquely identified by combining its name with the names of all its parents. The following is a list of all such names in the above example:
Order/DocumentNumber Order/Date[Of="Document"] Order/Buyer/Company Order/Buyer/Address/Street Order/Buyer/Address/Place Order/Buyer/Address/Area Order/Seller/Company> Order/Seller/Address/Street Order/Seller/Address/Place Order/Seller/Address/Area Order/DeliverTo/Company Order/DeliverTo/Address/Steet> Order/DeliverTo/Address/Place Order/DeliverTo/Address/Area Order/Item[ProductNo="11245132"]/ProductName Order/Item[ProductNo="11245132"]/Quantity Order/Item[ProductNo="15743576"]/ProductName Order/Item[ProductNo="115743576"]/Quantity
Note that while each of these names is unique (when appropriately qualified) the subcomponents of each can be interchanged without having to rename them in any way. So if we wanted to send another order, but this time in the other direction, we could reuse the first two Address elements, with all their subelements, without having to rename them. Only the name of the immediate parent needs to be changed to change the role of the unit of information.
Also note that we can choose to further breakdown our information units
without losing the relationships between them. For example, we might need to
separate streets from building names and numbers, creating objects such as
.*/Address/Street/BuildingId and
*/Address/Street/Name. By using structured names we can do this in
such a way that a query asking for */Address/Street/* will identify
both components.
If we adopt a process of using properly structured naming to identify structured information components then we can start to manage message fragments rather than complete messages. For example, all the addresses in the above example can be stored in a single address database: there is no need to have one database for buyer addresses, another for seller addresses and a third for delivery addresses just because they are separately named objects.
Similarly we can start to create reusable subprocesses. Instead of having separate subprocesses to deal with each type of address we can reuse the same subprocess for each one, using the differences in parentage at those points where differentiation in handling is required.
We can then start to think about subsets and supersets. By searching for all
orders with Item[ProductNo="11245132"] as part of their structure
we can quickly identify orders with this as a potential relationship. (This was
one reason why I chose to use ProductNo as an attribute rather than a subelement
in the XML example. If the product number had been stored as a subelement a two
stage process would be needed to identify all the quantities of an item type
that have been ordered. Using attributes allows for faster searching of the
information in certain cases.)
We must also start to think about relationships across language barriers.
Instead of having to define complex names in translations to allow for the ways
in which certain languages create compounds (e.g. the long compound names used
for German and the complex reordering of components needed for French) we can
translate the term used at each level in a hierarchical structure individually,
without direct reference to its precedents and antecedents. This means that we
can end up with terms such as Livraison/Addresse/Rue instead of
having to use a name such as Rue d'Address de Livraison, which is
difficult to express formally. (I know that for international trade there should
be a single set of semantics, but in many cases there will also need to be a
national expression of that set that can be mapped to the agreed international
expression so that internal trade can be handled more expediently.)
It is not only language differences that lead to the need to map relationships between terms. For example, for many service industries the terms Buyer and Seller used in the purchasing example above will not be relevant. For example, someone in the legal profession might prefer to use terms like Client and LegalRepresentative in place of these terms. Similarly not all Orders relate to purchasing. An order could equally validly be sent from an Agent to a Manufacturer. The structure of the rest of the order may not change, but the names assigned to specific wrappers within the message may need to change to identify local circumstances. But at the same time we need to be able to retain as many relationships and subprocesses as possible. For hierarchically structured information sets this is much easier to do than for networks or relational sets where different tables are used to identify different roles.
There is still a long way to go to develop a coherent ontology for describing the "truth" about business processes, but now that we better understand the necessity for clearly defining the context in which that truth occurs the task should prove easier. With God's help we may be able to end up with a unified model for defining the relationships between information sets. What I hope that I have proved in this brief paper is that there are advantages to be gained by adopting structured naming to identify semantic components within ontologies, irrespective of whether or not you are using structured data modeling techniques. Structured names are easier to manage, make data reuse easier and ensure the maximum portability of data.