You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Feature Subcode (FSC) is unique to the CDB 1.x metamodel and does not exist as formulated in GGDM, NAS, or any other data model that I'm familiar with.
In practice, subcodes typically map to a context-dependent attribute based on the entity type - common targets include Feature Function (FFN), Physical Product (PPO), and Power Source (POS). However, in others they may require contextually mapping to different feature types depending on the FSC value. In many but not all cases, the target attribute vocabulary terms match up with the CDB feature subcode names due to both coming from a common FACC lineage.
Aligning with GGDM and NAS means that this is unavoidable and the mapping rules from CDB 1.x just need to account for this type of translation. It may require defining new feature types or attributes and eumerant terms particularly for CDB definitions not derived from FACC input.
In my experimental code CDB 1.x loader, I treat FSC as a special built-in attribute type with lists of enumerant terms that are tailored per entity type.
The text was updated successfully, but these errors were encountered:
Feature Subcode (FSC) is unique to the CDB 1.x metamodel and does not exist as formulated in GGDM, NAS, or any other data model that I'm familiar with.
In practice, subcodes typically map to a context-dependent attribute based on the entity type - common targets include Feature Function (FFN), Physical Product (PPO), and Power Source (POS). However, in others they may require contextually mapping to different feature types depending on the FSC value. In many but not all cases, the target attribute vocabulary terms match up with the CDB feature subcode names due to both coming from a common FACC lineage.
Aligning with GGDM and NAS means that this is unavoidable and the mapping rules from CDB 1.x just need to account for this type of translation. It may require defining new feature types or attributes and eumerant terms particularly for CDB definitions not derived from FACC input.
In my experimental code CDB 1.x loader, I treat FSC as a special built-in attribute type with lists of enumerant terms that are tailored per entity type.
The text was updated successfully, but these errors were encountered: