CCTS Spec RIM Mappings Revisited: [S8] to [S18]

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

Team,

We had put requirements [S8] to [S18] on hold pending clarifications on
Properties and Data Types. Now that we have a better understanding of
these entities, I'd like to revisit these requirements - please see
below. 

The biggest question I have is whether we need to store both an entity
(such as a BCC) and its Properties, or if its "Properties" are simply
another way of viewing the entity.

Thanks in advance for your feedback.

Joe

p.76:

7.1.3 Stored Core Component Properties

[S8]
Stored Core Component Properties shall be stored as part of the stored
Aggregate Core Component to which they belong, i.e. they shall never
exist independently of their owning Aggregate Core Component.

<JMC>
We can represent the relationship between ACCs and Core Component
Properties through Associations.

QUESTION: Do we need to represent BCC Properties and BCCs as separate
entities in the registry? According to Figure 7-1 (p.75), they are
separate entities. Or, are these just 2 different ways of looking at a
BCC?
</JMC>

[S9]
Stored Core Component Properties shall be defined as one of the two
recognized types: Basic Core Component Property or Association Core
Component Property.

<JMC>
We can represent this through the "ObjectType" classification of
RegistryObjects.
</JMC>

[S10]
Stored Core Component Properties shall include the following Attributes:
- Property Term
- Cardinality

<JMC>
Property Term - represent using a Slot
Cardinality - represent using a Slot that indicates the maximum number
of occurrences of the Core Component Property (like W3C Schema's
"maxOccurs" facet).

QUESTION: How should we represent "mandatory/optional" for attributes,
as specified in the CCTS? We could have "minOccurs" and "maxOccurs"
Slots for all entities, in which:

(0,1) indicates optional (i.e. minOccurs="0", maxOccurs="1");
(1,1) indicates mandatory;
(0,r) indicates optional, repetitive
(1,r) indicates mandatory, repetitive

This approach would allow us to represent both the optional/mandatory
characteristic and cardinality characteristic for a given entity using
the same set of attributes.
</JMC>

p.76:

7.1.4 Stored Basic Core Component Properties

[S11]
Basic Core Component Properties are a particular category of Core
Component Properties. As such, stored Basic Core Component Properties
shall include all Attributes of stored Core Component Properties.

<JMC>
This is handled by the fact that a Core Component is, by default, a
Basic Core Component - otherwise it is an Aggregate Core Component.
Therefore, a Core Component Property is, by default, a Basic Core
Component Property - otherwise it is an Aggregate Core Component
Property (i.e. this is simply a matter of semantics). No RIM update
required.
</JMC>

[S12]
Stored Basic Core Component Properties shall be linked to the Data Type
that describes the possible values of the Basic Core Component Property.

<JMC>
It appears that Data Types should be represented as RegistryObjects (see
[S27], p.79). Having said this, we can "link" a BCC Property to its Data
Type using an Association.
</JMC>

7.1.5 Stored Association Core Component Properties

[S13]
Association Core Component Properties are a particular category of Core
Component Properties. As such, stored Association Core Component
Properties shall include all Attributes of stored Core Component
Properties.

<JMC>
We can represent this in the registry through a "derivation" mechanism
that indicates that ASCC Properties are derived from CC Properties (i.e.
they contain all of the attributes of CC Properties). We can use a
"Derived From" association.
</JMC>

 [S14]
Stored Association Core Component Properties shall be linked to the
Aggregate Core Component that describes the structure of the Association
Core Component Property.

<JMC>
In context of the example on p.12 of CCTS, this would roughly read:
"ASCC 'Residence' has properties Address. Street. Text, Address. Post
Code. Text, etc.; these properties shall be linked to ACC
'AddressDetails'".

We can represent this as an Association between the ASCC (Residence) and
the ACC (Address. Details).
</JMC>

7.1.6 Stored Basic Core Components

[S15]
Basic Core Components are a particular category of Core Components. As
such, stored Basic Core Components shall include all Attributes of
stored Core Components.

<JMC>
Same as [S11]: This is handled by the fact that a Core Component is, by
default, a Basic Core Component - otherwise it is an Aggregate Core
Component (i.e. this is simply a matter of semantics). No RIM update
required.
</JMC>

[S16]
Stored Basic Core Components shall represent a Basic Core Component
Property of a particular Aggregate Core Component.

<JMC>
Similar to [S8]: We can represent the relationship between ACCs and BCCs
through Associations.
</JMC>

7.1.7 Stored Association Core Components

[S17]
Association Core Components are a particular category of Core
Components. As such, stored Association Core Components shall include
all Attributes of stored Core Components.

<JMC>
Similar to [S13] which addresses ACC Properties: We can represent this
in the registry through a "derivation" mechanism that indicates that
ASCCs are derived from CCs (i.e. they contain all of the attributes of
CCs). We can use a "Derived From" association.
</JMC>

[S18]
Stored Association Core Components shall represent an Association Core
Component Property of a particular Aggregate Core Component.

<JMC>
Similar to [S8] and [S16]: We can represent the relationship between
ACCs and ASCCs through Associations.
</JMC>
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