Appendix: Metadata Consistency - Intergraph Smart 3D - Reference Data

Intergraph Smart 3D Reference Data

PPMProductFamily
3D Design and Visualization
PPMProduct
Intergraph Smart 3D
PPMCategory
Reference Data
Version_S3D
12.1(2019)

Metadata consistency is important when copying objects between models with different catalogs. This topic discusses how to ensure that the metadata in both the source Catalog Schema and the target Catalog Schema is consistent.

The two catalogs must be consistent in their schema and in their data. However, exceptions exist. For example, only the object name for a part must be the same. The rest of the data for a part does not need to be consistent.

While reading the following information about data consistency, it is helpful to know the difference between user classes and system classes in reference data.

System classes are modeled during design time using the Rose model. User classes are those classes that the user creates by bulkloading part sheets. Furthermore, there are two types of user classes that are created during the processing of the part class sheets during bulkloading. The first type is a definition class, and the other type is an occurrence class. The definition class name appears in the Catalog task and in the Catalog browser. You can specify the definition class name in the UserClassName field on the part class sheets. The occurrence class name appears in the business object hierarchy on the Object Type tab on the Filter Properties dialog boxes. You can specify the occurrence class name in the OccClassName field on the part class sheets.

In the delivered reference data, the definition class name and occurrence class name for a part class are often the same name. For example, on the 3WayBallValve part class sheet in Piping Catalog.xls, the definition class name and occurrence class name are both specified as 3-Way Ball Valve.

Catalog Schema Consistency

  • The user classes must have the same CLSID. A CLSID is an identifier that is assigned when you specify the schema.

  • Any of the system classes (non-virtual) that implement virtual interfaces (during the bulkload process) in the source catalog should have the same set of implemented interfaces in the target schema.

  • The user interfaces that are intended to exist in both catalogs must have the same IID. An IID is an identifier that is assigned when you specify the schema.

  • The user properties that are intended to exist in both catalogs must have the same DispID. A DispID is an identifier that is assigned when you specify the schema.

  • Each user attribute definition in the original schema should match with the definition in the target catalog’s schema. User attribute definition includes its Type, UnitsType, and PrimaryUnits attributes. For metadata consistency, we are concerned about the following attributes: Name, Type, UnitsType, PrimaryUnits, and Codelist.

  • User attributes that are codelisted should have the codelist table exist in the target catalog schema. In addition, the target schema should have all the values of the codelist table in the source schema. The valueIDs should match in both schemas. The short and long strings can be different.

  • Properties that are mapped to symbol parameters must exist in both catalogs.

  • Properties associated to an interface that exists only in the source model will not be exposed in the target model, even though the value of the property from the source object will probably be copied.

  • Properties associated to an interface that does not exist in the source model will be exposed in the target model, but the values will be NULL.

Catalog Consistency

  • Catalog objects that are related to model objects being copied must exist in the target catalog and must have used the same internal name as in the source catalog.

Inconsistencies between catalogs can arise in the following areas:

  • User class definitions

  • Custom class definitions

  • User interface definitions

  • User attribute definitions

  • Symbols

When the source and target catalog schemas are different, the case may be that a definition exists in the source, but not in the target. Alternatively, a definition exists in the target but not in the source. A third scenario is that the definitions exist in both the source and target, but the definitions are different. The procedures to remedy these situations depend on the exact details of the situation.

If you copy a part with different values in the target catalog and the source catalog, the target or source set of values is used for the part when it is placed in the target model.

For assistance with metadata, contact Intergraph Process, Power & Marine Support.

See Also

Adding and Modifying Custom Interfaces
Describing the Common Sheets in the Workbooks