Re: ebXML Registry: Deviations from CCTS

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

Fred,

Thanks so much for your responses to this. I've marked my responses
below with <JMC>.

Kind Regards,
Joe

"Fred Blommestein, van" wrote:
> 
> Hi Joe,
> 
> I got the planned deviations from CCTS by the RegRep team through Alan Stitzer and took the liberty to comment on it from my personal point of view. Some of my views hopefully will later be confirmed by material to be prepared by TGBG17, but I felt it would be good to send you some reaction as soon as possible.
> 
> (1) ASCCs and ASBIEs will not be represented as entities as described in the CCTS; rather, they will be represented as Registry associations;
> 
> <Fred>OK with me, as long as you can store the Property Term and its Qualifier Term(s) with the association.</Fred>

<JMC>
We originally considered this approach, then realized that it would be
flawed - here's why:

Considering the CCTS p.12 example (with Official Address and Residence
Address), let's suppose that there is an additional BCC that "applies
to" (i.e. is included in) one (or both) of these 2 ASCC's. For example,
the "Official Address" ASCC (more specifically, "Person. Official.
Address") must include a "mail stop" BCC, because this ASCC represents
(for our purpose here) an office address.  

Let's say that we use the proposed approach (storing the Property Term
and its Qualifier Term(s) with the association). What the p.12 example
does not take into account is the fact that the Official Address or
Residence Address may include a set of BCCs that are different than
those in the "Address. Details" ACC - that is, it may include (perhaps)
an additional BCC, or a "swapped" BCC (that is, a new BCC is "swapped"
for one of the existing ones - e.g. Post Code becomes Zip Code). If this
is the case (and it often will be), there is no efficient way (in the
p.12 example representation) to indicate which "new" ACC (ex:
OfficialAddress. Details, which includes a mail stop BCC) the Property
Term and its Qualifier Term(s) are related to. 

That is, how can an assembly/serialization process efficiently know that
when it assembles (and subsequently serializes into XML, for example) an
ACC called "OfficialAddress. Details", that it needs to include a mail
stop BCC in the assembly/serialization? Given the p.12 example, this
would require somehow associating the mail stop BCC with the
"OfficialAddress" Property Term/Qualifier Term on the association -
which is quite inefficient (i.e. there are much better was to do this).

Instead, we've decided that the cleanest approach would be to create a
new ACC (or we might call it an ABIE - does not matter for purpose of
the example) based on the "Address. Details" ACC, add the mail stop BCC,
and name it "OfficialAddress. Details". We would then associate the
"OfficialAddress. Details" ACC with the "Person. Details" ACC. This
allows an assembly/serialization process to cleanly handle the proper
set of BCCs because they are "encapsulated" within the proper ("new")
ACC, and furthermore to handle the name properly because it is
represented in Slots on the new ACC for Object Class and Object Class
Qualifier. The Object Class and Object Class Qualifier on the new ACC
become - when serialized - a Property Term and Property Term
(respectively) on the ASCC.

So when it comes time to assemble/serialize an ASCC called "Person.
Official. Address" (I realize we will not be serializing ASCCs, but the
same concept applies to ASBIEs), the assembly/serialization process
would be "smart enough" to know that it must:

- Use the Object Class from the "upper" ACC - ex: Person
- Use the Object Class Qualifier and Object Class from the "lower" ACC -
ex: OfficialAddress
- Use the Property Term from the "lower" ACC - ex: Details

in constructing its name. I call this concept "smart storage" combined
with "smart serialization". :)

Please let me know if you feel that there is any more efficient way of
handling this within the ebXML Registry architecture, specifically
version 2.5.
</JMC>
 
> (2) BCCs will not be required to have Object Classes (but some will need them); this allows us to register a BCC named "Country. Identifier" and reuse it within multiple ACCs. However, a BCC named "Processing. Code" does not provide enough semantic clarity to stand on its own; so it will require an Object Class (such as "Document. Processing. Code"). This determination will need to be made by the registering user.
> 
> <Fred>If you stay consistent with (1) you would represent BCC's and BBIE's as associations as well. 

<JMC>
Thanks so much for this suggestion - in the ebXML Registry architecture,
it makes much more sense for us to represent all Core Component entities
(BCCs, BBIEs, ACCs, etc.) as RegistryObjects rather than Associations.
If we were to represent these as Associations, what would the Source and
Target objects be?
</JMC>

To make a distinction between "Reusable" and "Non-reusable" property
terms seems awkward and is not supported by CCTS. 

<JMC>
A data modeling methodology in 2004 that does not take into account
reuse?
</JMC>

You could however draw (some or all) property terms from a controlled
list. You could then add definitions, synonyms and examples to each
property term. As that would be an "extra" feature of the registry you
would not violate CCTS. 

<JMC>
Absolutely - that would be the job of a registry user interface, which
is out of scope of our work (we leave the user interface to
implementers). Our architecture will, however, absolutely allow this
feature to be implemented.
</JMC>

You should IMHO not make a distinction between property terms in (1) and
in (2).</Fred>
> 
> (3) Addition of Object Class Qualifiers will not always cause an ACC to become an ABIE. That is, addition of an Object Class Qualifier of "Residence" for an ACC called "Address. Details" does not result in an ABIE; rather, "Residence_Address. Details" will still be considered an ACC because "Residence" does not fall under any of the 8 context categories.
> 
> <Fred>
> First: the use of qualifiers with ACC's violates the CCTS. Either qualify it and call it an ABIE or use an adjective instead of a qualifier to form a multi word term.

<JMC>
I believe that the CCTS is inconsistent on this concept (I believe UBL
had the same question). Can you please cite a place in the CCTS that
clarifies this?
</JMC>

> Second: The relation between qualifiers and context needs not to be a one-to-one relationship. One qualifier may be valid in multiple contexts and within one context multiple qualifiers may be valid. 

<JMC>
Absolutely. The registry architecture would use the context-sensitive
classification feature for this.
</JMC>

Therefore applicable contexts should be defined at BIE level rather than
on qualifier level.

<JMC>
My understanding is that for BIEs, the context drives the qualifier(s)
that are used. So I really don't see two different "levels" here.
</JMC>

> </Fred>
> 
> (4) Core Component Types will not be represented in the registry as they are in the CCTS. That is, CCTS lists properties for CCTs (such as codeListID for CCT Code. Type) that do not belong at that level - that is, they belong at a "higher" level (such as Data Type). The reason for this treatment is that one cannot determine the code list ID, agency ID, etc. for a CCT that is simply named "Code. Type" - i.e. there has to be more specific information in the Dictionary Entry Name, such as "Country_Code. Type". So, we will "transfer" the CCT properties to Data Types and not represent CCTs as RegistryObjects.
> 
> <Fred>OK. I foresee that for each CCT an unqualified DT will be defined anyway.</Fred>

<JMC>
I should mention that this changes Figure 7-1 in that (bottom right) the
"Content Component" and "Supplementary Component" entities would be
transferred to the "Data Type" entity. That is how we will generally
treat this.
</JMC>
 
> (5) There will be more than the 8 context categories required to create BBIEs/ABIEs. The additional context categories required can be left to the user.
> 
> <Fred>To be honest I think that the number of context drivers will be smaller rather than larger than 8. The complexity will otherwise be too huge to handle. But I have no problem leaving this open in the registry.</Fred>
> 
> (6) Properties will not be represented in the registry as defined in the CCTS - this approach is much too heavyweight. For example, an ACC in the registry will be represented as a RegistryObject, and will be associated with its comprising BCCs (which will also be RegistryObjects) using Registry Associations. We will not create Properties that "sit" between ACCs and BCCs, because it is not necessary.
> 
> <Fred>See (1) and (2). Properties are not Registry Classes according to CCTS. Properties may IMO be represented as attributes to associations.</Fred>

<JMC>
Sorry, I did not understand your comment about how properties could be
represented as attributes to associations (and also why). Can you please
clarify?
</JMC>
 
> (7) We will not implement section 7.5 on, because this information is meant to redefine/enhance core registry concepts, which is considered out of scope of the Core Components effort.
> 
> <Fred>Surely you implement a subset of 7.5. Each registry will contain administrative info, I assume (like date of entry, registrar, etc.). It would be good to indicate which elements *are* implemented.</Fred>

<JMC>
Since this section is indeed out of our subcommittee scopel, I would
encourage you to provide to the Registry TC itself any enhancements to
the core registry concepts that are included in 7.5 on. I would
personally recommend that someone does a mapping between the current
registry architecture as described in v2.5 and that described in 7.5 on,
and provide any deltas to the Registry TC itself along with a
justification as to why the enhancements should be made.
</JMC>

Thanks,
Joe
 
> (8) We will not represent Content Components, because it is not necessary to store an additional entity in the registry that represents the contents of a BCC. This will be taken care of by the assembly process (which is out of scope of our effort here), in which the data is placed within the XML tags.
> 
> <Fred>OK</Fred>
> 
> (9) We will not represent Supplementary Components, Supplementary Component Restrictions, and Content Component Restrictions as individual entities. This approach is much too heavyweight. Rather, we will represent the properties of these entities on other entities - for example, we will represent the Supplementary Component Restriction and Content Component Restriction properties directly on a Data Type.
> 
> <Fred>I (with you) think restrictions or facets should be defined on data type level (see CCTS fig. 7-1).</Fred>
> 
> (10) We will not represent Content Component Primitive Types at all, because we will instruct registry implementers to use the pertinent primitive types according to the CCT that is used. The same will apply for the CCT properties (codeListID, etc.) - will not have a Slot on a Data Type for the value of a property, and the primitive type of the property (too heaveyweight). Registry implementations should enforce the primitive types according to the properties, as detailed in Table 8-2.
> 
> <Fred>OK</Fred>
> 
> Fred van Blommestein
> 
> -------------
> Dit e-mailbericht en enige bijlage is vertrouwelijk en
> uitsluitend bestemd voor de geadresseerde(n). Indien u niet
> de geadresseerde bent, mag u deze e-mail of enige bijlage niet
> kopieren of aan derden ter inzage geven of verspreiden.
> Indien u deze e-mail per vergissing heeft ontvangen
> verzoeken wij u de afzender ervan onmiddellijk op de hoogte te
> stellen per e-mail en de betreffende e-mail te vernietigen.
> 
> This e-mail and any attachment is confidential and may
> contain legally privileged information. If you are not the
> intended recipient, please note that this e-mail or any
> attachment may not be copied or disclosed or distributed to
> others. If you have received this e-mail by error, please notify
> the sender immediately by return e-mail, and delete this message.
> --------------