RE: [regrep-cc-review] Kickoff!

[Diego Ballvé <diego.ballve@republica.fi>]

> >- 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