From dd2567e38dc89b41a2aa813e55c0184897a1b532 Mon Sep 17 00:00:00 2001 From: Eric Hanson Date: Fri, 16 Feb 2024 10:42:38 -0500 Subject: [PATCH] Add 4th option based on PR comments --- ...02-field-for-data-type-form-information.md | 22 +++++++++++++++++++ 1 file changed, 22 insertions(+) diff --git a/docs/adrs/0002-field-for-data-type-form-information.md b/docs/adrs/0002-field-for-data-type-form-information.md index 4f3fbf0..d1094b5 100644 --- a/docs/adrs/0002-field-for-data-type-form-information.md +++ b/docs/adrs/0002-field-for-data-type-form-information.md @@ -124,6 +124,28 @@ Cons: * would require reworking the transformations + re-indexing any sources that use `literary_form` * nested field type, a bit harder to query for aggregations +#### Option 4 - Use `file_formats` for current `format` values and `format` for Data Type values + +In this approach, the current `MITAardvark.format` values would shift to the previously unused `MITAardvark.file_formats` property and the Data Type values would be stored in `MITAardvark.format` + +Example: +```json + +{ + "content_type": "Geospatial data", + "format": ["Polygon", "Point", "Raster", "Image"], + "file_formats": ["Shapefile", "TIFF", "GeoTIFF", "JPEG"] +} +``` + +Pros: + * does not require TIMDEX data model changes + +Cons: + * `file_formats` has previously only stored MIME type values, such as `application/pdf` + * may require explanation of the facet mapping in the UI documentation + * may require updates of other transform classes for consistency + ## Decision It is proposed to move forward with **Option 3: Create new, multivalued objects field `form`; collapse `literary_form` into this**.