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

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

I just had a thought regarding cardinality on RegistryObjects vs. Slots.
The quote below addresses cardinality on RegistryObjects:

<Quote>
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.
</Quote>

However, in many cases in CCTS we have cardinality on slots. This was an
issue that Diego brought up early on:

<DiegoQuote>
- 0..* and 1..* properties are harder to handle if the
possible values are not known beforehand. How to name the
slot then??
</DiegoQuote>

Let's revisit this earlier debate on how to represent cardinality with
slots. Any thoughts?

Thanks,
Joe

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>
> 
> [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>
> 
>   ------------------------------------------------------------------------
> You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/regrep-cc-review/members/leave_workgroup.php
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