WG2-MEL-019

(CAC/SC32 C0120R2)

Title: Canadian position on definition of Permissible Value and related items

Supersedes: -

Source: Canada

Status: National Body Position

Action: For discussion by WG2 and Ballot Resolution meetings

Date: 27 October 2003 (12:46 GMT +10)

1.  Referenced Documents

[1]  ISO/IEC 11179-3:2003 Information technology -- Metadata registries (MDR) - Part 3, Registry metamodel and basic attributes

[2]  ISO/IEC JTC1 SC32 N0992 FCD 11179-1:200x Information Technology -- Metadata Registries (MDR) -- Part 1: Framework

[3]  ISO/IEC JTC1 SC32 N1002 DCOR 11179-3:200x(E) Information technology —Metadata registries (MDR) - Part 3, Registry metamodel and basic attributes

[4]  WG2-MEL-006 Issue 11179-3 Cycle 3 Mann # 1: Value object class deletion

2.  Canadian ballot comments on definition of Permissible Value

In our ballot comments on FCD 11179-1 (SC32 N0992) (comment CAN-P01-012) and on DCOR 11179-3 (SC32 N1002) (comment CAN-P03-010), Canada proposed replacing the definition of "Permissible Value" in ISO/IEC 11179-3:2003 with the new definition from FCD 11179-1. On further reflection, we wish to change that position.

3.  Revised Canadian position on definition of Permissible Value

3.1  Current Definitions

3.1.1  From ISO/IEC 11179-3:2003:

3.3.72

Enumerated Value Domain

a Value Domain that is specified by a list of all its Permissible Values

3.3.99

Permissible Value

an expression of a Value Meaning allowed in a specific Value Domain

3.3.140

Value Domain

VD

a set of Permissible Values

NOTE1 Metamodel construct is: Class.

NOTE2 The Value Domain provides representation, but has no implication as to what Data Element Concept the Values may be associated with nor what the Values mean

NOTE3 The Permissible Values may either be enumerated or expressed via a description.

3.1.2  From FCD 11179-1 (N0992):

3.3.27

permissible value

An ordered pair consisting of a value and its corresponding value meaning

3.2  Notes

1.  Figure 1 on page 4 in this document is taken from Figure 9 of ISO/IEC 11179-3:2003.

2.  We are unable to locate the ballot comment that led to the change to the definition in FCD 11179-1.

3.  WG2-MEL-006 proposes collapsing the Value object class into the Permissible Value object class (see Figure 1 on page 4).

4.  WD 18022 is currently using the definition of Permissible Value from ISO/IEC 11179-3:2003.

3.3  Problems with definitions

3.3.1  Problem description

1)  The definitions of Value Domain and Enumerated Value Domain use the term "Permissible Value" inconsistently. The former uses it to include non-enumerated domains, which is also inconsistent with the model.

a)  According to the model, Permissible Values are defined as enumerated values only.

b)  Note 2 states that a Value Domain “has no implication as to … what the values mean”. This directly contradicts the definition of Permissible value.

c)  Note 3 states that Permissible Values may either be enumerated or expressed via a description. However, the term “Permissible Values” explicitly refers to enumerated values. We need two distinct terms, one which includes values that are “expressed via a description”, and one that does not.

2)  A Permissible Value as defined in the model, specifies:

a)  a value within a Value Domain

b)  the associated Value meaning

c)  a period of validity (start date and end date)

3)  Permissible Value is defined as “an expression of a Value Meaning…”, however, a Value Domain is defined (note 2) as providing “representation”. A better definition of a permissible value would therefore be “a representation of …”.

3.3.2  Proposed Resolution

  1. Use the term "Permissible Value" to include both enumerated and non-enumerated values.
  2. Use the term "Enumerated Permissible Value" to refer explicitly to values which are enumerated.
  3. Rename the object class "Permissible Value" in the model (e.g. in Figure 9) to "Enumerated Permissible Value".
  4. Modify the definition of Permissible Value from ISO/IEC 11179-3:2003 to reflect the new usage, and add notes as shown below.
  5. Define the term Enumerated Permissible Value based on modifications to the definition of Permissible Value from FCD 11179-1.
  6. Change the definition of Enumerated Value Domain to be use Enumerated Permissible Value.
  7. Change Figure 9 in ISO/IEC 11179-3:2003 accordingly.
  8. Check the rest of ISO/IEC 11179-3:2003 to ensure the appropriate terms are being used everywhere. (To be completed if the proposal accepted in principle.)
  9. Include these changes in a Technical Corrigendum to 11179-3:2003.

3.3.x

Enumerated Permissible Value

A permissible value explicitly listed within an Enumerated Value Domain.

NOTE 1: Metamodel construct is Class

NOTE 2: Each Enumerated Permissible Value is associated with a corresponding Value Meaning in a Conceptual Domain. The Value provides a representation of the Value Meaning

NOTE 3: An Enumerated Permissible Value has an associated permissible_value_begin_date and optionally a permissible_value_end_date.

3.3.72

Enumerated Value Domain

a Value Domain that is specified by a list of all its Enumerated Permissible Values

3.3.99

permissible value

a Value allowed in a specific Value Domain

3.3.140

Value Domain

VD

a set of Permissible Values that provides representation for a Conceptual Domain

NOTE1 Metamodel construct is: Class.

NOTE2 The Permissible Values in the Value Domain may be expressed either as an enumerated list (in which case the Value Domain is said to be Enumerated), or via a description, in which case the Value Domain is said to be "Non-enumerated".

3.4  Other Possible problems with Figure 9 in ISO/IEC 11179-3

There appear to be some problems with the relationships between Permissible Value and Enumerated Value Domain.

The cardinality of the relationship shows that an Enumerated Value Domain contains 2 or more Permissible Values, and that a Permissible Value may be contained in zero or more Enumerated Value Domain.

The following problems exist:

  1. It is conceivable that an Enumerated Value Domain may have only a single value, perhaps in anticipation of future growth. (For example, the domain "product code" may have only one value when a company launches its first product.) Therefore, the minimum cardinality at the Permissible Value should be reduced from 2 to 1.
  2. It is probably not very useful to define a Permissible Value independently of a Value Domain, therefore the minimum cardinality at the Enumerate Value Domain should be increased from 0 to 1.
  3. It is probably not very useful to define a Permissible Value as shared across multiple value domains . If this is agreed, then Permissible Values should be defined as belonging to exactly one Value Domain. (However, probably we do want to allow permissible values to be shared across multiple version of the same value domain. How can we make this explicit?)

Figure 1: Conceptual and Value Domain metamodel region

1