Standardizing ADAPT's Id/Code Mappings #165
Description
Use Case
Due to the varied classification systems and terminology in use, it is common to need to cross reference a similar term or identifier in another vocabulary. E.g.s.,
- ISO11783-11 DDI Reconciling ProductUse & DeviceElementUse with Summary objects #12 would map to the ADAPT Standard "AppliedCountPerAreaActual" numeric Data Type Definition.
- We can also map Enumeration Items to other vocabularies in many cases.
- Adding identifiers for paddy-field operations to the ADM #155 raised a need to map more detailed AAO codes to Operations and had intended to do so via Context Items.
- Missing ability to set percentages on Ingredients #161 is replacing our Ingredient vocabulary with an open-ended code and code source that can map better sources of this information.
- Lastly, this may be seen as conceptually the same as the Unique ID mappings in ADAPT.
Current Processes
Ad-hoc Context Items in the ADAPT Framework were often ignored due to non-standard codes and inconsistent usage. It would be preferable to allow any external formal vocabulary source vs. inventing new codes for the sake of Context Items.
Touchpoints
I don't see a downside to adding a Vocabulary Mapping component to Data Type Definition and its child Enumeration Item.
Currently, we only allow Context Items with ADAPT Standard DTD codes and custom codes that are fully defined as Custom Data Type Definitions. One might question the necessity of configuring a custom Data Type Definition if a code is fully defined in some published vocabulary.
Proposed Object Model
As a starting point for discussion:
-
Create a new component called Identifier Code that would have two members. Better yet, simply repurpose "Unique Id" which already has the same conceptual members. (I've proposed removing other members in adapt-data-type-definitions.json: Revisit ID Type and ID Source Type, refactor as Scheme ID, Scheme Agency ID, and use ID Type Code as a business defined name for the ID #156)
a. Code - The identifier defining whatever the component is attached to. Required.
b. Source - A URI to a published vocabulary. Always required? -
Add a optional list of this component with an instance (ConnectCenter ASCCP) called "VocabularyMapping" to Data Type Definition and Enumeration Item.
-
Add an instance of this component to Product Component as "Ingredient." It replaces the two similar fields proposed on Missing ability to set percentages on Ingredients #161
-
Taking it further, replace Context Item "Definition Code" (currently only a string) with this object, perhaps leaving the name "Definition Code" intact. We can remove the requirement that Context Items must map to formal ADAPT or Custom DTDs and specify either to leave the source blank for ADAPT codes or use the ADAPT URI (we use "https:://adaptstandard.org" in ConnectCenter). In this way @Jp-rice could simply attach the appropriate AAO code on an Operation and fully document its type in that vocabulary.
a. With this change, we should evaluate whether we would even need Custom Data Type Definitions.
b. Similarly, and perhaps in any case, we should better clarify what is a Context Item and what is a Unique Id. E.g., my field operation can be classified as AAO code A270 Spraying Biological Insecticide (Context Item), but my farm operation is the logical equivalent of the GLN number issued specifically for it (Unique Id). It may be as simple as a "has" vs. "is" relationship.
I did look at how ConnectSpec defines code (with 12 possible attributes). For ADAPT's purposes, a simple URI (or company URL) both seems adequate to identify the ID source and as much information as we will be likely to get.
@aferreyra @strhea @jim-wilson-kt @dubnemo I know that you each will have much to offer in response to the above.