OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-cc-review message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Association Core Components - Represent with Associations


Over the weekend I'll send an updated summary on our proposed handling
of each of the CCTS requirements.

I've been thinking more about Association Core Components - particularly
the example on CCTS p.12. In that example, we have:

- An ACC called "Address. Details", with several BCCs (ex: Address.
Street. Text)

- An ACC called "Person. Details", with several BCCs (ex: Person. Name.

- 2 ASCCs, each of which associate the "Address. Details" ACC with the
"Person. Details" ACC - and each of which provide a different "role" for
the "Address. Details" ACC within the "Person. Details" ACC. These are
reprsented as "Residence" and "Official Address" in the example.

- Also: When each ASCC is created, each BCC within the "Address.
Details" ACC "takes on" the role signified by the ASCC within the
"parent" ACC. For example, the BCC of "Address. Street. Text" becomes
"Person. Residence. Address".

Having said that: It seems to me that there are generally 2 ways to
handle the "transformation" described in the final point above:

(1) Create a new BCC in the Registry for each "pre-transformation" BCC
that has the same metadata as the pre-transformation BCC (except for its
name) - and give it a new name (i.e. "Person. Residence. Address"). 

That is, we would create a BCC called "Person. Residence. Address" that
would essentially be a copy of the "Address. Street. Text" BCC, with a
different name. Seems very redundant and inefficient, and a waste of
Registry storage space.

(2) Do not create a new BCC in the Registry, but use the Association
mechanism of the Registry to "point to" the pre-transformation BCC and
indicate the new name within the Association. This prevents the need to
duplicate BCCs in the Registry and keep them in sync if the metadata for
either of them changes.

I would like to propose that we pursue (2) - and represent the ASCC by
an Association between the 2 ACCs. We can add a slot to the Association
to indicate the new Object Class for the ASCC - i.e. the Object Class of
"Address" for the "Address. Details" ACC would be "qualified" by the new
Object Class Qualifier of "Residence" for the ASCC (the combination of
Object Class Qualifier and Object Class would therefore be
"ResidenceAddress"). When tools join the two ACCs through the ASCC, they
can ensure that they "construct" the name for the ASCC using:

- The Object Class for the "master" ACC (i.e. "Person")
- The Object Class Qualifier for the ASCC (i.e. "Residence")
- The Object Class for the "joined" ACC (i.e. "Address")

...to yield "Person. Residence. Address". So a large part of this would
be up to the tools that ultimately utilize these entities, and we can
place some requirements in our Technical Note that instruct the tools
how to access the entities.

Thoughts, comments?

tel;work:(703) 902-6923
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
title:Senior Consultant
fn:Joseph M. Chiusano

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]