Capturing the semantics is primarily a matter of expressing the terms, facts, and relationships in a standard syntax. To make this more tangible, we'll use a single concrete example throughout the rest of this chapter.
Bill Swets is something of an institution in the Fort Collins area. His business is real, but I have made up these systems, because he has what may be the most semantically straightforward business imaginable. Bill has been welding sculptures from surplus car and tractor parts for more than 20 years (Figure 10.1). He occasionally sells one of his creations, and he has set up a park where families can enjoy the sculptures and have a picnic. The "zoo," as he calls it, is supported by anonymous cash donations.
Figure 10.1: Sculpture from Swetsville Zoo. (Photograph by Marek Uliasz.)
For the purpose of our narrative, let us assume that the zoo donations cover the cost of the welding supplies and that all the parts are donated scrap.
Let's say that Bill decides he needs a system. We'll use his requirements for the examples we develop in this chapter.
The main thing is to capture and organize the concepts of a domain. To refer to concept we use labels that we call terms. Take terms to be the same as entities, or vocabulary entries.
For each term, we should have a distinctionary entry for it. This will include the following:
Term—A word or set of words that describes the concept in business terms.
Synonyms—Other phrases or keywords that are either used interchangeably with this term or would be used by someone looking for this term.
Scope—Most terms are not "universals." That is, most of the terms you will uncover will be specific to a line of business, an industry, or a department. Capturing this is essential, because it avoids confusion of false synonyms.
Primitives—Record the primitive of which this term is composed.
Definition—A concise definition that users would agree to.
Specialization/generalization—If it is a subtype of another type, specify what type that is and how it is distinct from other subtypes of the same parent.
These can be difficult to construct. A good example of high-level business concepts expressed similar to this can be found in "The Enterprise Ontology."[62]
Distinctionary | A type of glossary. It is different from other glossaries in that it assigns each item to a broader category and then sets up the characteristics that distinguish it from its peers. |
Figure 10.2 shows a few of the key cataloged items from the Swetsville Zoo. Some of the terms aren't defined here (such as Physical Persistent Object and Made Item) because the task of defining them back to their ontologic roots is beyond the scope of this chapter. You can assume that their meaning is close to what you might expect from the name. Note that "isa" is the traditional specialization/generalization relationship.
Sculpture Synonyms: creature. Scope: Swetsville, the term sculpture elsewhere typically means something that was carved from a large homogenous mass. Primitives: Discrete Made Object Definition: a figure made from welded together surplus parts. Specialization/Generalization: Location Scope: Swetsville, Primitives: Geospatial (a place on the earth) Definition: The sculptures are relatively large, and most are bolted in place. For most of them, their location is given by a numbered position on the path that winds through the Swetsville zoo. The entrance to the zoo itself is represented by latitude and longitude positioning. Spec/Gen: isa Place Price Scope: Swetsville Primitives: Currency, Offer Definition: The amount each sculpture is offered up for sale. Price is at Swetsville zoo, there are no delivery arrangements. Spec/Gen: isa Amount CommittmentDate Synonyms: SoldOnDate Scope: Swetsville Primitives: Historical Event Definition: The date on which the transfer was committed to Specialization/Generalization: isa Date PlannedTransferDate Synonyms: ShipDate Scope: Swetsville
Facts, in the business rules jargon, are assertions about possible relationships between terms.
For example, we can say "Customer places order." This is the same as declaring a relationship in a semantic model or an entity model. We need to record slightly different information for relationships than for terms:
What type of relationship is it?
Part/whole (meronomy)
Type of relationship (hyponymy)
Reference (the relationship is a one-way pointer to some reference material or standard)
Member/collection
Subarea/superarea
Composition/assembly
Dependency
Agent/result
Valence (number of end points to the relationship and how they interrelate)
What are the cardinality constraints? For each end of each relationship, we need to know whether it is
Mandatory (i.e., there must be at least one)
Multiple (i.e., there can be more than one of the items at the end of the relationship)
A plain English description of the relationship
Attributes that might be associated with this fact (date, effectivity, etc.)
Any other constraints on the fact or relationship (a person cannot be one's own parent, grandparent, etc.)
Figure 10.3 shows some example relationships (or facts in business rule jargon). As you do this analysis you may be unsure whether something is a term or a relationship. For example, is an "order" a term or a relationship? We have been discussing "order" as if it were an object. We have "reified" what was a relationship. This is normal. For years we have reified relationships in database design, because there is no good way to deal with high valence relationships or attributes on relationships. Until we have systems that can directly implement a semantic model, we will be confined to treating relationships as entities, so that any misclassifications in this area won't be too serious.
OfferForSale Valance:2 Referents (Domain/Range):Offeror; MadeItem; Cardinality: offeror (1); madeItem (0+) Attributes: price, effectiveFromDate, effectiveToDate. Description: indicates an offer to sell a particular product or group of like products at a given price. Offer is potentially date limited Scope: Swetsville Basic RelationshipType: Constraints: Offeror must have ownership rights in madeItem, price must be > 0 Sale Valance:3 Referents (Domain/Range):Owner; MadeItem; Customer Cardinality: owner (1); madeItem (0+); customer (1) Attributes: price, committedDate, plannedTransferDate Description: This is the recording of a sale (not a special price offering) Scope: Retail, physicalgoods Basic RelationshipType: Constraints: prior to sale, owner must have ownership rights in madeItem, after sale customer must have ownership rights MadeFrom Valance:2 Referents (Domain/Range): MadeItem; Material Cardinality: MadeItem(1); Material(0+) Attributes: quantity Description: billOfMaterial relationship at the as built level Scope: Swetsville Basic RelationshipType: Constraints: Must be acyclic
Reify | To regard or treat an abstraction as if it had concrete or material existence. Note that we do this at many different levels. We treat corporations as if they were people for legal reasons. We treat agreements as if they were things, and we treat relationships as if they were things. |
At this point we are not attempting to build fully expressed rule-based systems from our semantic discovery, but if you studied the business rule methodologies you could see how they would lead to the ability to fill them in here. However, we should capture what we have found; not to do so would be wasting valuable discovery.
Figure 10.4 shows some examples of the information you might capture on rules for storage in your repository. Rules that will come up that can be dealt with at this time include the following:
Validation—In the discussion, validation issues will come up regarding terms.
Temporal status—There will be rules that describe how an item moves through various defined states (pending, open, in process, complete, closed out, etc.).
Calculations—People will volunteer scoring systems. For example, you may know the entities that make up an algorithm, but not the algorithm itself. This is OK; at this point knowing what goes into it is most important.
Description—An English-language description of the rule so that it can be verified by the user.
CommitmentDate Must Precede PlannedTransferDate Terms: CommittmentDate; PlannedTransferDate Rule: CommitmentDate must be ?= PlannedTransferDate Rule: CommitementDate must be ?= timeNow
[62]Mike Uschold, "The Enterprise Ontology." Available at http://citeseer.nj.nec.com/uschold95enterprise.htm.