Overall Dimensions vs. Dimensions of Parts about linkedart

[SamiNorling]

Potential issue: tables for blanket records often include dimensions for parts, and those dimensions may or may not also be documented in the table on the corresponding parts records. Examples of these Dimension Types include:

• "Costume: Bust .1" and "Costume: Bust .2"
• "Costume: Center Back A" and "Costume: Center Back B"
• "Dimensions 10" and "Dimensions "11"
• "Dimensions A" and "Dimensions B"
• "Image Dimensions A" and "Image Dimensions B"

Need to determine how these should be handled by the transformation. The Type value may be the same, regardless of whether the entry is on the parts or blanket record(s). So the same transformation or ignore rules wouldn't apply the same to each (e.g., SKIP "Dimensions A" on a record with AssIsParent = Yes; DO NOT SKIP "Dimensions A" on a record with AssIsParent = No).

Will likely start with most simple and obvious Dimension Types being accepted for transformation, and handle more complicated instances later (if ever).

[SamiNorling]

Added documentation of Dimensions Types. This list indicates which values represent objects as a whole, or partition-able parts of objects.

Access to the document here.

[SamiNorling]

Initial modeling plan:

• Will ignore all entries in the dimensions table that serve a note purpose.
• Will partition dimensions that facilitate partitioning (e.g., Backing Dimensions; Frame Dimensions; etc.). Will follow parts model and assign an AAT Type if possible. These parts will have super minimal information, pretty much just the dimensions.
• Will follow basic dimensions pattern for everything else. Even if dimensions are inconsistently documented on blanket vs. parts records, going to model them at whatever level they are catalogued. Ideally, parts dimensions are included on the blanket record, and then specific part dimensions are also documented on the part record, so the data would be represented on both.

[SamiNorling]

Closed with last commit