The Representations Package contains classes used to describe, order, manage, and compare the classifications/categories used for enumerated value domains. Representations may be a simple code list (the association of a code with a category) or complex managed statistical classification.

Namespace URI:
Color of objects in the uml graph: 
Include in build?: 


DataPoint now inherits from ProcessingInstruction. This means that it takes a binding and has an input and an output. If a DataPoint hosts datum from an InstanceVariable for a particular Unit, then the binding of the DataPoint enables it to get data from other ProcessingInstructions. A DataPoint may be both self-binding and bind other ProcessingInstructions besides and/or in addition to itself.

Not sure why the Value Domains point to the Variables and not the other way around. Even if we maintain the direction of the association, I don't think Value Domains "measure" Variables, they rather "provideValuesFor" or "define" or some similar name.

Shouldn't data type be associated to value domain? Right now the only link between a data type and a value domain is indirectly via an instance or represented variable. However, a data type is always defined for a value domain.

Code has been aligned with the new Signification Pattern. It needs to be reviewed again.

Would like to create an abstract enumeratedValueDomain so that CodeList, StatisticalClassification, and Geographic classifications could use this as an extension base, thereby letting all of them serve as value representations. All would be using a realization of Sign which provides the core content used by a value representation

Package Graph