Re: [regrep-cc-review] Kickoff!

["Chiusano Joseph" <chiusano_joseph@bah.com>]

Thanks Diego for your excellent points below. For those who may not yet
be familiar with some of the concepts Diego references, below is a short
primer on "Core Component Type" and "Data Type". Please also note
comments following the primer.

<Primer>
Core Component Type (CCT) - p.77, Section 7.1.8:

- A Core Component Type is a Core Component that contains data (i.e. the
actual content) plus one or more "Supplementary Components" that give an
essential "extra definition" to the Content Component.

- Refer to p.94, Table 8.1 "Approved Core Component Types"

- Ex: CCT "Amount. Type" contains the following components:

(1) Amount. Content (contains the actual Amount value)
(2) Amount Currency. Identifier (contains the Currency Code)
(3) Amount Currency. Code List Version. Identifier (contains the code
list that the Amount Currency. Identifier is a part of - for example,
ISO 4217 Currency Codes)

- For our reference, an XML instance example would be:

<ToBePaidTotalAmount currencyID="USD" codeListVersionID="ISO
4217">232.34</ToBePaidAmount>

where: "ToBePaidTotalAmount" is the instantiation of (1) above
       "currencyID" is the instantiation of (2) above
       "codeListVersionID" is the instantiation of (3) above

Data Type - p.79, Section 7.2:

- A Data Type defines the set of valid values that can be used for a
particular Basic Core Component (BCC) Property or Basic Business
Information Entity (BBIE) Property

- It is defined by specifying restrictions on the Core Component Type
(CCT) that forms the basis of the Data Type

- Stored Data Types may include one or more Content Component
Restrictions (e.g. restricting the Content Component value to a range of
values) and one or more Supplementary Component Restrictions (e.g.
restricting the Supplementary Component value to a subset of the
allowable values), to provide additional information on the relationship
between the Data Type and its corresponding Core Component Type (CCT).

- An example would be a CCT of CCT Type "Amount. Type" that has the
following restrictions:

	- Content Component (i.e. amount value) can be no more than 100
	- Supplementary Component #1 (i.e. currency identifier) must be 	"USD"
(i.e. only U.S. Dollars are accepted as currency)
</Primer>

<Quote1>
For instance, lets take a look at CoreComponentType and its fields:
- PrimaryRepresentationTerm 1..1
- SecondaryRepresentationTerm 0..*
</Quote1>

Would order really matter for SecondaryRepresentationTerm?

<Quote2>
- ContentComponent 1..1
- SupplementaryComponent 1..*
</Quote2>

Same for SupplementaryComponent. The UBL and UN/CEFACT ATG work is
instantiating Supplementary Components as XML attributes (see example in
Primer above), in which case order cannot be preserved anyway.

<Quote3>
And SupplementaryComponent has 4 fields:
- Name 1..1
- Definition 1..1
- PrimitiveType 1..1
- PossibleValue 0..*
</Quote3>

Same for PossibleValue - does order really matter here?

<Quote4>
Easy 'till here.. now what? Indexed?
- SupplementaryComponentName:0
- SupplementaryComponentDefinition:0
- SupplementaryComponentPrimitiveType:0
- SupplementaryComponentPossibleValue:0
- SupplementaryComponentName:1
</Quote4>

We may consider representing Supplementary Components as Registered
Objects themselves, since (as per p.75 Figure 7-1, lower right) they
have multiple attributes themselves. If we respresent them as attributes
for CCT's (i.e. as slots), then we have to determine how we can
represent "Slots for Slots" in the registry - which we may/may not want
to do. We could always introduce a "Slot hierarchy", in which a Slot can
refer to its parent slot, but that may be more complex than we'd like.

<Quote5>
Or SupplementaryComponentName as part of the slot name?
</Quote5>

Good thinking - but I don't think we want to go there. This would mean
that we are including data as part of metadata, which is always
dangerous.

Thoughts?

Joe

Diego Ballvé wrote:
> 
> > >- 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
begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard