[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]