What I have in mind, is the duality of concepts in the domain, where:

• some concepts refer to the actual things/objects (like product, property, …), and
• other concepts refer to different things/objects, which are specifications (or descriptions) for the previous ones (like product specification, property description, …).

Both sets of concepts being on the same modeling level, and always have at least one-to-many relationships between each other. The difference of specification from the actual is, that specification can, and in many cases do exist without corresponding actuals. Also specifications have usually own behavior, which is different from behavior of actual.

Participants of this (pattern?) could be represented in models using corresponding stereotypes, or just grouping these together on diagrams.

This pattern has helped me to identify concepts/relationships, and to organize the model.

Maybe this would be possible to model using UML powertypes, but I would avoid mixing different modeling levels (model, meta-model, ...) in the same model, and would prefer to use stereotypes instead of these (to show that certain classes are from given class denoted by stereotype).

If we want to model the business rules for meta-model elements, then we should have a separate meta-model, that shows the specialized elements and respective rules/constraints attached to these.

This distinction in modeling levels is good to be maintained also into the solution, down to the physical models -- that is if we choose to have dynamically configurable system, then from the meta-models we derive the physical models representing the configuration information, and from the models we derive the actual content of configuration information for the system. Failure to make this distinction clearly is the source of problems in maintenance of dynamically configurable systems.

What Fowler describes as specification pattern seems to me too narrowly applied only for selecting objects from object sets, but maybe I am mistaken.