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: "Top-down" vs. "Bottom-up" Registration


CC Review Team,

Happy New Year to all.

In going through some use cases involving the registration of Core
Components, I've realized that there needs to be 2 possible approaches
for registering Core Components:

- Top-down
- Bottom-up

The CCTS spec does not address this aspect (probably for a very valid
reason).

Consider registration of an Aggregate Core Component (ACC) and a Basic
Core Component (BCC) that is contained within the ACC. The "top-down"
approach involves registering the ACC then the BCC, while the
"bottom-up" approach involves (you guessed it) registering the BCC then
the ACC. Which approach is taken (or even required) depends on whether
or not a BCC can be registered without an Object Class in its Dictionary
Entry Name (i.e. without an ACC), or whether an Object Class is required
for the BCC to "stand on its own". That is, whether or not an Object
Class is "required" for a BCC to be registered.

More details to follow - please let me know what you think of the
concepts below.

For example, we will register the following entities:

- Document. Details (ACC)
- Document. Processing. Code (BCC)

By an Object Class being "requiring", we mean: given the Data Type that
the BCC is based on, does a Dictionary Entry Name that contains only a
Property Term and Representation Term provide enough semantic clarity to
sufficiently describe the BCC?

For example: A BCC whose Dictionary Entry Name is "Country. Identifier"
has a Dictionary Entry Name (I believe) that provides enough semantic
clarity to sufficiently describe the BCC, in the absence of an Object
Class. That is, the BCC "Country. Identifier" can be associated with a
Data Type named "International country codes" that lists all ISO country
codes from ISO 3166-1. Therefore, both the "top-down" and "bottom-up"
registration approaches can be used here - that is, the BCC can be
registered first (along with the Data Type), and then the ACC can be
registered.

But consider a BCC whose Dictionary Entry Name is "Processing. Code" -
the question remains, "what type of processing code? Document processing
code? Chemical processing code? Patient processing code?" So we can say
that the BCC Dictionary Entry Name is "Processing. Code" does NOT have a
Dictionary Entry Name that provides enough semantic clarity to
sufficiently describe the BCC, in the absence of an Object Class.

Furthermore, what Data Type would this BCC be associated with? Could
there be a Data Type that represents "processing codes"? This would
probably be too "generic" a subject for a Data Type.

However, a BCC whose Dictionary Entry Name is "Document. Processing.
Code" (i.e. contains an Object Class)  has a Dictionary Entry Name that
*does* provide enough semantic clarity to sufficiently describe the BCC.
That is, there may exist a set of "Master document processing codes"
that an organization uses that are represented as a Data Type named
(perhaps) "master document processing codes" that lists all the
organization-specific master document processing codes (Note: this Data
Type will be further restricted when a BBIE called
"PurchaseOrder_Document. Processing. Code" is created based on this
BCC).

Therefore, only the "top-down" registration approache can be used here,
because the Object Class (which is a property of the ACC) needs to be
"known" when the BCC is registered, so that the full Dictionary Entry
Name for the BCC ("Document. Processing. Code") can be constructed. That
is, the ACC must be registered first, and then the BCC can be registered
(along with the Data Type).

In other news:

(1) CCTs AND THEIR METADATA ATTRIBUTES:

We will be moving the metadata attributes listed in the CCTS for Core
Component Types (CCTs) - i.e. code list ID, agency ID, etc. - to Data
Types. The primary reason for this is that from a modeling perspective,
I believe that the CCTS representation is not accurate. That is, it
lists a very "generic" Dictionary Entry Name of (for example) "Code.
Type" for a CCT, but very "specific" properties (such as code list ID,
etc.) that can only apply to an entity whose name is more specific then
"Code. Type". 

That is, trying to express the code list ID for something named "Code.
Type" is equivalent to going to a car dealership and telling them that
what you specifically want is a "car" (with no other description). The
CCTS team suggested that we work around this CCTS spec defect by
creating a set of  "empty entities" in the registry to represent each
CCT (Code. Type, Identifier. Type, etc.) with "empty properties" - but I
believe that we would be very remiss to create such a kludge in our
architecture. No disrespect whatsoever is meant to the CCTS team or any
of their members - just fulfilling my duty to express things in black
and white terms for the benefit of our initiative.

(2) NAMING DATA TYPES:

I'm starting to see that Data Types should have freeform names, as in
the examples above (e.g. "Master document processing codes") - it just
makes things a lot easier, and I don't see that it is necessary to
provide structured names for Data Types as we do for Core Components,
BIEs, etc. 

Does anyone see a strong need for us to use structured names for Data
Types? What specific purpose would they serve?

Thanks,
Joe


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