Just a quick ORM Source Model tool tip today....

The Business Rules window (Database | View | Business Rules) has an interesting feature that I never gave much thought about until today. By default, the left pane ("All Folders") of the window has a tree control with a root node named after file name of the model and a child folder node named "Entire Contents". If you right click on the root node, you can create a new child folder underneath the root node. Similarly, you can create child folders beneath any child folder (except the Entire Contents folder).

From there, you can click on a given folder and use the Fact Types tab to create a new fact type "within" the folder.

What this does is sort your fact and object types based on folder, because when a particular folder is selected, the Fact Types tab will only display fact types created within that folder.

The "Entire Contents" folder then is the aggregation of all folders: it displays every fact type. Further, you can create a fact type within the Entire Contents folder which will not show up in any child folder fact types listing.

Finally, note that if you want to use the Object Types tab to create a new (not yet used by a fact type) object type, you have to have the Entire Contents folder selected. The Object Types tab of any child folder will only display object types used by fact types created within that folder; you cannot create new ones via the Object Types tab.

This is a useful feature if you have a very large model, you are not using more than one Visio page to display your model (i.e. you like those big "wallpaper" models printed out on one sheet of plotter paper), and/or you do not have all facts displayed on a page as folders will allow you to more quickly locate a fact without scrolling through the long list.

For example, on a large model, selecting a fact type in the Fact Types tab, right clicking, and selecting "Find Fact in Drawing" is a quick way to locate that fact type in the drawing. However, the Fact Types listing is alphabetized by the default reading of the fact. If you were searching for the fact "Car is driven by Person" you might not find it easily because it is listed as "Person drives Car". If you used folders, you could lump fact types together based on, say, subject area (e.g. a folder named "Silly Example Facts used in ORM Articles") and not scroll through potentially thousands of fact types to find the one you are looking for.

As a post-script to this entry, jMM and I were playing with this concept and thus I (we) have some more info. John came up with the good idea of using folders to indicate workflow such as New, In Progress, Validated, and so on. You could also create folders based on the fact type’s current position in the Conceptual Schema Design Procedure (CSDP) as laid out in Terry’s writings.

Other usages would be to use them to separate base fact types from derived fact types or core "important" fact types from the not-so-interesting ones.

Also note that you can create references to fact types in child folders by merely dragging the fact type between folders.

One thing to keep in mind: when you move a fact type from one folder to another as the fact type goes through your workflow, you’ll probably want to delete the reference (either from the right click menu or via the delete key) from the old folder after you drag it to the new folder. Essentially, folders just contain a pointer to the instance stored in the Entire Contents folder (despite my writing above, which implies the fact type is contained within the child folder).