Registration According to CCTs (Code. Type)

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

Team,

This is the first of a series of e-mails that I will be sending that
detail the process of registering various entities, with a concentration
on the CCT/Data Type "level", since our handling of CCTs and Data Types
is a deviation from CCTS. My intent is that folks will read each
scenario and point out any inconsistencies or things that they believe
should be changed, and also respond to some embedded questions as well. 

Each e-mail will focus on a different CCTS CCT, as handling may be
different according to CCT. In this scenario, we will focus on CCTS CCT
of "Code. Type". Below I describe:

- The general scenario
- Background
- Registration process

Thanks in advance for your review and feedback.

Joe

SCENARIO:

In this scenario, we will consider a BCC whose Dictionary Entry Name is 
"Document. Processing. Code". 

BACKGROUND:

According to CCTS, the following are the Supplementary Components
associated with a CCT "Code. Type":

• Code List. Identifier
• Code List. Agency. Identifier
• Code List. Agency Name. Text
• Code List. Name. Text
• Code List. Version. Identifier
• Code. Name. Text
• Language. Identifier
• Code List. Uniform Resource. Identifier
• Code List Scheme. Uniform Resource. Identifier

For our example purposes, let's focus only on one of these - "Code List.
Identifier" (i.e. the concepts will project to any of the other
Supplementary Components). We will assume a code list identifier of
"ABCDE".

REGISTRATION PROCESS:

How will registration of this BCC take place? Let's assume that all
"entities" that are necessary to represent this BCC are submitted in
separate requests (although they could be the same requests). We will
also assume that all entities do not yet exist in the registry (i.e.
registering from scratch).

In an earlier e-mail, I asserted that an entity named "Processing. Code"
(i.e. only the Property Term and Representation Term, without the Object
Class) did not have enough "semantic richness" to be able to represent
it "standalone" in the registry - that is, "what" processing code? This
is in contrast to an entity named "Country. Identifier", which I
asserted *does* have enough "semantic richness" to be able to represent
it "standalone" in the registry, with multiple Object Classes/Qualifiers
such as "Address" (Address. Country. Identifier), "IndividualBackground"
(IndividualBackground. Country. Identifier), etc.

Having said that, how will the "Document. Processing. Code" BCC be
registered? I believe the order would be as follows (please note
proposed Data Type handling in (2) below):

(1) Register "Document. Details" ACC

• Object Class "Document" is represented as Slot on ACC RegistryObject

• Property Term/Representation Term "Details" would be implicit (not
represented in submission), and would be evident in serialization (i.e.
XML serialization would insert "Details" in element name)

(2) Register Data Type for processing codes:

• Regarding naming: I propose that we do not separate out the
"components" of the Data Type name as we do the BCC name (i.e. into
Object Class, Property Term, etc.) - for simplicity purposes. Rather, we
will use only the Dictionary Entry Name for this.

• Dictionary Entry Name would be "Document. Processing. Code. Type" -
i.e. the BCC name with an additional Representation Term of ".Type"
appended to it.

• For clarity's sake, Data Type would contain a "CCT" attribute (a
Slot), which in this case would contain the value "Code". This value
would be the same as the first Representation Term in the Dictionary
Entry Name (as shown above).

• Because this Data Type has CCT value "Code", it will contain the
properties (as Slots) that are defined in the CCTS for a CCT of "Code.
Type". For our example, we will assign a value of "ABCDE" to the "Code
List. Identifier" Slot on the Data Type. 

[NOTE: This is different from CCTS in that we will not need to register
a Supplementary Component entity, but instead are representing those
attributes directly on the Data Type]

• If we were not referring to an external code list, we would provide
the valid set of code list values as multiple "Possible Value" Slots on
the Data Type.

(3) Register "Document. Processing. Code" BCC

• Property Term "Processing" is represented as Slot on BCC
RegistryObject

• Association is made from ACC to BCC

• Association is made from BCC to Data Type

• Representation Term "Code" would not be represented as a Slot on the
BCC, but is "known" through the association to the Data Type, as the
Data Type has a "CCT" value "Code".