> >- 0..* and 1..* properties are harder to handle if the
> >possible values are not known beforehand. How to name the
> >slot then??
> >
> I am not sure what you meant here. An example that include how you
> handle it now and how ideally it should be handled would be great.
Sorry, I was really unclear with that point. I was refering to
CoreComponentType and DataType, which have (composite) fields with
cardinality 0..* and 1..*.
To understand this mail, you'll need figure 7.1 from page 75.
Please take some time to understand and criticize it.
For instance, lets take a look at CoreComponentType and its fields:
- PrimaryRepresentationTerm 1..1
- SecondaryRepresentationTerm 0..*
- ContentComponent 1..1
- SupplementaryComponent 1..*
ContentComponent itself has 3 fields:
- Name 1..1
- Definition 1..1
- PrimitiveType 1..1
And SupplementaryComponent has 4 fields:
- Name 1..1
- Definition 1..1
- PrimitiveType 1..1
- PossibleValue 0..*
Having CoreComponentType as a RegistryObject, we could map the
above fields to Slots with the following names:
- PrimaryRepresentationTerm
- SecondaryRepresentationTerm
- ContentComponentName
- ContentComponentDefinition
- ContentComponentPrimitiveType
Easy 'till here.. now what? Indexed?
- SupplementaryComponentName:0
- SupplementaryComponentDefinition:0
- SupplementaryComponentPrimitiveType:0
- SupplementaryComponentPossibleValue:0
- SupplementaryComponentName:1
- SupplementaryComponentDefinition:1
- SupplementaryComponentPrimitiveType:1
- SupplementaryComponentPossibleValue:1
...
Or SupplementaryComponentName as part of the slot name?
This is what I meant by we know the values beforehand.
CCTS has set the permissible names for each CCT type.
- SupplementaryComponent:<name>:Definition
- SupplementaryComponent:<name>:PrimitiveType
- SupplementaryComponent:<name>:PossibleValue
Some other way???
Now, to get it concrete, we can apply these mappings
to Amount CCT defined in Section 8 of CCTS 1.9.
- Slot.name: PrimaryRepresentationTerm 1..1
Slot.value: Amount
- Slot.name: SecondaryRepresentationTerm 0..*
Slot.value: <none>
- Slot.name: ContentComponentName
Slot.value: Amount. Content
- Slot.name: ContentComponentDefinition
Slot.value: A number of monetary units specified....
- Slot.name: ContentComponentPrimitiveType
Slot.value: decimal
Then the supplementaries:
- Slot.name: SupplementaryComponentName:0
Slot.value: Amount Currency. Identifier
- Slot.name: SupplementaryComponentDefinition:0
Slot.value: The currency of the amount.
- Slot.name: SupplementaryComponentPrimitiveType:0
Slot.value: string
- Slot.name: SupplementaryComponentPossibleValue:0
Slot.value: <Reference to codelist in diferent registry object?>
- Slot.name: SupplementaryComponentName:1
Slot.value: Amount Currency. Code List Version. Identifier
- Slot.name: SupplementaryComponentDefinition:1
Slot.value: The version of the UN/ECE Rec. 9 code list
- Slot.name: SupplementaryComponentPrimitiveType:1
Slot.value: string
- Slot.name: SupplementaryComponentPossibleValue:1
Slot.value: <none>
OR
- Slot.name: SupplementaryComponent:Amount Currency. Identifier:Definition
Slot.value: The currency of the amount.
- Slot.name: SupplementaryComponent:Amount Currency. Identifier:PrimitiveType
Slot.value: string
- Slot.name: SupplementaryComponent:Amount Currency. Identifier:PossibleValue
Slot.value: <Reference to codelist in diferent registry object?>
- Slot.name: SupplementaryComponent:Amount Currency. Code List Version. Identifier:Definition
Slot.value: The version of the UN/ECE Rec. 9 code list
- Slot.name: SupplementaryComponent:Amount Currency. Code List Version. Identifier:PrimitiveType
Slot.value: string
- Slot.name: SupplementaryComponent:Amount Currency. Code List Version. Identifier:PossibleValue
Slot.value: <empty
I'm not sure what is the ideal way and what we have done
at Republica in our pilot was to simplify it and not to
add many of these fields, so not appropriate here.
Diego
