The Wikipedia defines a model as "an abstract (or actual) representation of an object or system from a particular viewpoint".

There are three parts to the definition - an object or system, a representation and a viewpoint.  It is critical to understand the role of each element of a model.  

An "object or system" is essentially an unknown and perhaps unknowable thing; an object as something in the world to be modeled has potentially an unlimited amount of information associated with it.  For instance, a chair as an actual physical object in the world possesses innumerable structural characteristics, such as materials and their strengths, as well as myriad facts about the styles of the chair or its history, for instance who sat upon it ( say, it was your great grandfathers chair and consequently is irreplaceable ).  There might be many thousands of possible facts associated with a single chair.

Of all the many possible characteristics of given object, there often is only a single fact or facet that is of interest to us, a few dozen facts as opposed to many thousands.  Whenever we use a chair, our mental representation of the object discards at least 99.9% of all information about chairs and focuses exclusively on the 0.01 % of the characters that effect us, most commonly whether it will hold me up without breaking or tipping over.

The representation of an object is further simplified by picking a particular viewpoint according to the need of the moment.  For instance, if someone is considering standing on a chair to reach something on a shelf rather than just sitting on it, the fact that the seat is made of woven cane would be the most important aspect of the chair for from that particular viewpoint - it would be more likely to break than a metal chair.  Even if it were a fairly substantial chair, the fact that it was your grandfather's chair might make it unusable as a step ladder - far better to make a trip to the basement and get a ladder rather than risk breaking it.

We perform the mental gymnastics of mapping from object to representation to viewpoint effortlessly and naturally.  Many people are unaware that they are doing it.  However, when one is forced by circumstance ( or inclination ) to try to get a computer to perform commonsense tasks of this sort, it can be a very difficult to accomplish

The cornerstone of idea was a very simple.  There were three components to a physical simulation - function, structure and behavior.  The modeler starts with one of the three components, say a structure, and then derives the function of that structure ( what can be accomplished with it  ) for a given set of behaviors ( actions ).

A typical example might start with the structural description of a hammer and a inventory of possible behaviors ( actions ), such as - 1 ) swing it from the handle, 2 ) throw it, 3 ) lay it on top of something, 4 ) attach it to something, etc.  From these behaviors, one can derive the functions of 1 ) driving a nail, 2 ) driving away pesky critters from the garbage bin, 3) keeping papers form blowing away, 4 ) sinking something that floats, etc.  

There are six possible mappings between the three components.

The conceptual framework is quite simple to use.  For instance, if someone needed to drive a nail but did not have a hammer, one might look for things structurally similar to a hammer ( solid, heavy ) that could be used with the same action as a hammer ( pounding on the nail ) to achieve a given function ( to drive the nail into a board ).  This would be the equivalent of the fifth type of mapping on the list, that is from function ( drive nail ) to structure ( something like a hammer ) for a given behavior ( pounding ).

Note that the order is important.  It is not likely that someone would whack on the nail with a heavy glass vase - the search is for something structurally similar to a hammer.  The question is, what can I use to pound the nail into the board ?  The required 'what' is something like a hammer, so the variable output is structure, not behavior or function, which are both fixed.        

It is a very simple conceptual framework, but has surprising power to describe the workings of physical systems at a high level of abstraction.  The concept was so powerful that that it was picked up by software architects to describe non-physical systems, such as the workings of object-oriented software. 

The Wikpedia defines a design pattern as "a general repeatable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations". 

Since 1994, the number of design patterns has proliferated but Gamma's original text identified three types of design patterns -  structural, behavioral and creational patterns.  The creational patterns are roughly equivalent to the functional component of the function-structure-behavior model.  An example of a structural pattern is a "Composite", which composes individual objects into a collection, often represented as a hierarchical "tree" structure.  An example of a behavior is the "Mediator" pattern, which determines how two objects interact independently of the object themselves, decoupling explicit references to one another, somewhat like a business rule.    

Journalism majors know the drill by heart.  The First Law of Journalistic Excellence, the 5 "Ws" of Reporting ( and an "H" throw in just to make life difficult for journalism students ).  The Law states: every journalistic oeuvre must answer these eternal questions - who, what, when, where, why and how.  That's a fine principle for overworked journalism students, but what about the rest of us, for example they who toil tirelessly in the murky mines of Infotechnology.    

Enter the Zachman Framework.  

A Zachman Framework provides a generic analytic template that can be used to model ( in theory ) any entity that exists or can be thought to exist, more specifically the interactions between the entities.  It is in the form of a table or spreadsheet with the top row containing the six questions and the left column containing the subjects of attention or under discussion.  In practice, the model is usually centered on business process.

Note that in the "Real" Zachman Framework, the subject on the left side are 5 "stakeholders" in the business enterprise - the Planner, Owner, Designer, Builder and Subcontractor.  While these five categories have some relevance to a Semantic Web, at the level of conceptual modeling their usefulness is limited.  In fact, any 'well-formed' collection of interacting subjects will work in a Zachman model.

Below is a simplistic example of a  customer ordering a product, with approval from the credit department of course.     

Usually the empty slots in the framework fill in easily and fairly naturally, giving a basic sense of who the players are and what they are doing.  The order of the questions in the row can be significant.  The model above is focused on 'why' and 'who'.  From the perspective of the order fulfillment process, the questions 'what', 'where' and 'how' might be the most significant.  Each category of question can become a pivot point for a greater level of detail in the model.      

Below are more detailed descriptions of the six categories.  The definitions are fairly flexible, indeed, they need to be.              

Sometimes, there are subtleties in the interaction between the subjects and questions that require a deeper understanding of the subject in order to assign them to a specific slot.

For example, there might be a business policy saying that all orders for a highly profitable product that happen to be out of stock in one location will be shipped out the next nearest location, even at a higher shipping cost for the company.  In others words, locations of shipping point and distances between them are suddenly an important factor - it requires a fairly complex locator function to map from "what gets shipped from where" to "where it gets shipped to".  A deeper understanding of 'where' is required.  

There may be significant features of a situation that demand a stretching of the categories themselves.  For instance, the category of 'where' can include a sense of 'where are we in moving toward our objective", with a clear sense of moving nearer or farther away from it as if it were a definite location.  The category 'when' may refer to a window of opportunity rather than definable instant or duration of time.  In this case, there is a sense is of moving in time toward the window, but once it is past, that time is no longer accessible, it's too late.  In other words, a window of opportunity behaves more like a 'when' than a 'what' or 'where'.

Often the fuzziness is based on the type of task being performed.  For instance, detailed planning tasks have strong elements of 'how' and 'when', mixed with in 'what', in the sense of the plan itself as a concrete structure of tasks.  There is also a sense of 'what' tasks need to be performed, although these tasks are probably more properly modeled as 'hows'.

More confusion can arise by mixing different levels of interaction among the subjects, such as mixing the high level concepts of' why' or 'what to do' with lower level concepts, 'when, 'where' and 'how' to do it.  In the case of a framework for planning, the model would show the interactions between the plan and other plans or objective in the organization.  It would not work to mix interactions between the plan and its constituent parts within the same subject framework.  The framework needs to be 'leveled' the same as any other model -  things of basically the same type need to be shown at roughly the same level of the model.   

Mapping the three model qualitative reasoning concepts, Function, Structure and Behavior ( "FSB" ), against the six categories of the Zachman Framework produces a sort of 'main sequence' of shared characteristics, running from the top left to the bottom right.      

This diagonal mapping implies that subjects will tend to group themselves according to the FSB criteria.  A paragraph above said that "things of basically the same type need to be shown at roughly the same level" of the model - the 'types' correspond to the FSB criteria.

For instance, in the example of a customer ordering a product, the subjects on the right are mostly functional subjects rather than structural or behavioral.  If the subject were production planning, the subjects would be mainly structural descriptions, such as product configuration, raw components and sub-assemblies, inventory locations, highly structured production schedules reflecting aggregated lead-times for processing steps, etc.  At a lower level would be behavioral descriptions of specific processing steps, such as stamping or lathing, mixing chemicals and maintaining a certain pressure and temperature for some duration of time.      

Each E-Z Framework model will show a type of subject and interactions between them.  Each will also have aspects of all six categories of questions within them - even a lower level manufacturing step has a 'why' associated with it.  But a processing step is primarily a behavioral 'how' and 'when' and not a functional 'why', it would be modeled properly on the same level as other behavior entities, rather than mixing up it with functional and structural entities.  

But, sometimes, there's nothing like an object.  It knows things, it knows how to do things and knows other objects that know how to do things ( like the CRC Cards mentioned in a previous section ).    

A most critical facility provided by object technology for the semantic web are so-called 'object ontologies'.  Haley has an excellent definition of ontology.  

[ An ] ontology is a systematic arrangement of all of the important categories of objects or concepts which exist in some field of discourse, showing the relations between them.  

When complete, an ontology is a categorization of all of the concepts in some field of knowledge, including the objects and all of the properties, relations, and functions needed to define the objects and specify their actions.

Another object technology supporting the semantic web is Object Role Modeling. 

The designer of a database builds a formal model of the application area or universe of discourse (UoD). The model requires a good understanding of the UoD and a means of specifying this understanding in a clear, unambiguous way.

Object-Role Modeling (ORM) simplifies the design process by using natural language, as well as intuitive diagrams which can be populated with examples, and by examining the information in terms of simple or elementary facts.

Note the key words are "natural language" and "intuitive diagrams", suitable for non-computer people.  While ORM can used fairly easily in developing computer applications, the whole topic of object technology is too computer technical for this section, and will be discussed in the Inference Engines section.   

The premier methodology is is called "Knowledge Based Systems Analysis and Design Support", hereafter referred to as 'KADS'.   The most generally useful text on the subject is "Knowledge Based Systems Analysis and Design: A Kads Developer's Handbook", by D. S. W. Tansley and C. C. Hayball, currently unavailable on Amazon.com.    

The original objectives of generic tasks were fairly modest, to help build KADS Expertise Models, that is the steps a knowledgeable person would take in solving a problem or analytic challenge of some sort, for example, diagnosis, fault determination, etc.  The specific generic tasks identified by the KADS methodology turned out to be applicable to many area outside of software design.           

Generic task models have been around for years in Europe, but have had surprisingly little impact into advanced information technology in the United States. In fact, interest in KADS has even languished in Europe since the ESPRIT project began to wind down.  To some extent, the ideas of KADS have been absorbed into commercial tools and methodologies that are more focused business processes, such as Carnot.  Most of the benefits of generic tasks models were lost in the process.     

One gleam of light in the gloom is a fascinating site from Australia ( not Europe ).  WebKB  has an interesting comment about itself: "WebKB refers to the knowledge base (KB) servers WebKB-1 and WebKB-2.  KB servers are not Web search engines ...".  It is a cogent observation on one of the ongoing debates about the term 'semantic web', which can be taken to be no more than advanced search engines.

The creator of the site is Dr. Philippe Martin of Griffith University in Queensland, who seems to have a near monopoly on KADS these days.  He has even created an entire ontology for KADS, with a neat little Javascript engine to drive the whole thing.  Generic tasks include collecting, generalizing, specifying, classifying, decomposing, assembling, transforming and a dozen or so more ( slightly extended beyond the original formulation ).       

The concept of generic tasks has great power but can also become very complex as the size of the problem grows.  However, they will be useful as simple stereotypes when modeling relatively complex workflow processes.  The subject of generic tasks will be revisited in the section on Modeling Workflows.