Properties (Was Re: [regrep-cc-review] CCTS Spec RIM Mappings Revisited: [S8] to [S18])

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

Taking a step back here to look at Properties:

When I think of the property of something, I immediately think of
characteristics/attributes - rather than a separate entity. For example,
suppose the properties of a car are its color and model. I think of
"color" and "model" as characteristics/attributes of the entity "car",
not separate entities (i.e. not the car's "property entities").

Having said that: The CCTS spec defines "Stored Core Component
Properties" as having the following attributes (requirement [S10]):

- Property Term
- Cardinality

It then describes "Stored Basic Core Component Properties" as
(requirement [S11]) "a particular category of Core Component Properties.
As such, stored Basic Core Component Properties shall include all
Attributes of stored Core Component Properties."

It then goes on to say that (requirement [S12]:

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

Then, regarding Association Core Component Properties and Basic Core
Component Properties (requirements [S13] and [S15]):

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

AND

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

So my question is: 

Since (a) CC Properties represent the properties of a Core Component,
and (b) Association Core Component Properties and Basic Core Component
Properties are "particular categories" of stored Core Component
properties, couldn't we simply represent CC Properties as attributes
(i.e. with Slots) of Core Components rather than separate entities? This
would mean that in addition to the following Core Component attributes
(requirement [S1]):

- Unique Identifier
- Version
- Dictionary Entry Name
- Definition
- Usage Rule

we would add to the list:

- Property Term
- Cardinality

So all of the above attributes would be present for both BCCs and ASCCs.
The same would apply to ACCs, per requirements [S4] and [S5].

Please find the holes in this logic - because I'm not seeing them.

Thanks,
Joe






Diego Ballvé wrote:
> 
> Comments inline tagged by <Diego>.
> 
> Regards,
> Diego
> 
> > Chiusano Joseph wrote:
> >
> > 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>
> 
> <Diego>
> Hard to decide. Are they the same? IMO no. While BCC defines a concept,
> Property aggregates it to a bigger concept. Associates it to a bigger
> concept... -> Association!!
> 
> Property defines:
> - a name for the Aggregate to identify the aggregated part;
> - a type for the aggregated part (i.e., Name BCC in Person. Details)
> - cardinalities for the aggregated part.
> 
> I still think that Properties should be stored as RIM Associations
> between an Aggregate and its children (Basic/Association).
> </Diego>
> 
> > [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>
> 
> <Diego>
> Sustaining the Associaton approach for Properties, you have no
> ObjectType for them - ObjectType is Association.
> 
> You don't need to difer between Basic and Association Properties.
> You can simply check if the target is a Basic or an Association CC.
> Although Figure 7-1 (p.75) shows BasicProperty related to DataType,
> there is a 1 to 1 relationship from BasicProperty to BCC. IMO,
> DataType can be directly related to BCC. Same for Association
> Propert, ASCC and its ACC. (This was just to show that Property
> types can actually be seen as equal types).
> </Diego>
> 
> > [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>
> 
> <Diego>
> Please check mail in new thread "Cardinality".
> </Diego>
> 
> > 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>
> 
> <Diego>
> Is it said anywhere that a Core Component is, by default, a Basic Core
> Component or is it your/our convention? I'm not aware of it.
> 
> Anyway, +1 on it not being a problem. :)
> </Diego>
> 
> > [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>
> 
> <Diego>
> Yep. Data Types are required. But this req does not say "directly
> linked". So I suppose it's ok to link it indirectly, through BCC.
> </Diego>
> 
> > 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>
> 
> <Diego>
> I still don't get the inheritance need here. I don't think you need
> to associate a ASCC Property to a CC Property in the registry. No
> needo for Association, IMO. CC Property is abstract and doesn't get
> stored. Only Basic or Associated properties. Although, they are both
> CC Properties - inherit from CC Property.
> </Diego>
> 
> >  [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>
> 
> <Diego>
> +1, the Association being the Basic CC Property.
> </Diego>
> 
> > 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>
> 
> <Diego>
> +1, the Association being the Association CC Property.
> </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