Capturing the Semantics


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.

start example

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.

click to expand
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.

end example

Let's say that Bill decides he needs a system. We'll use his requirements for the examples we develop in this chapter.

Capturing Concepts

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.

start figure

    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 

end figure

Figure 10.2: Term repository.

Capturing Facts and Relationships

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.

start figure

    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 

end figure

Figure 10.3: Fact repository.

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.

Capturing Rules

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.

start figure

    CommitmentDate Must Precede PlannedTransferDate    Terms: CommittmentDate; PlannedTransferDate    Rule: CommitmentDate must be ?= PlannedTransferDate    Rule: CommitementDate must be ?= timeNow 

end figure

Figure 10.4: Rule example.

[62]Mike Uschold, "The Enterprise Ontology." Available at http://citeseer.nj.nec.com/uschold95enterprise.htm.




Semantics in Business Systems(c) The Savvy Manager's Guide
Semantics in Business Systems: The Savvy Managers Guide (The Savvy Managers Guides)
ISBN: 1558609172
EAN: 2147483647
Year: 2005
Pages: 184
Authors: Dave McComb

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net