sfc-gh-sgrafberger commented on code in PR #585: URL: https://github.com/apache/parquet-format/pull/585#discussion_r3402334755
########## LogicalTypes.md: ########## @@ -635,7 +635,76 @@ The type has two type parameters: The sort order used for `GEOGRAPHY` is undefined. When writing data, no min/max statistics should be saved for this type and if such non-compliant statistics -are found during reading, they must be ignored. +are found during reading, they must be ignored. + +### FILE + +`FILE` annotates a group that represents a reference to an external file, along with +the minimum metadata required to read it. It is intended for use cases such as +storing file inventories, manifests, and unstructured data references (e.g., images +or audio files stored in object storage). + +The annotated group must contain the following fields, identified by name. Field IDs +may also be used for projection: + +| Field | Type | Required | +|----------|--------|----------| +| `path` | STRING | Yes | +| `size` | INT64 | No | +| `offset` | INT64 | No | +| `etag` | STRING | No | + Review Comment: I really think we should include `content_type` as field here. I fully understand that we don't want to have all kinds of optional metadata like `last_modified` as part of the spec, as this optional metadata is only needed for a smaller subset of queries and differs between different engines. However, the `content_type` is required information for a large fraction of common AI/ML workloads, and there is a good reason why existing FILE datatypes in engines like BigQuery or Snowflake have it as part of the datatype. Many existing AI and ML-related functions on FILEs only work for certain modalities. E.g., an `AI_TRANSCRIBE` function only makes sense for audio and video data. Many common ML preprocessing techniques/functions only work for certain modalities, e.g., downscaling the resolution of images, turning image colours into grey scale, cropping and rotating pictures, downsampling the fps of a video etc. Some AI models only support text data, while others also support modalities like images. Routing AI function calls to compatible models critically depends on modalities, conceptually. If this isn't part of the datatype, a large fraction of FILE usecases would have to repeatedly read the first n bytes of a file to try to infer the modality, resulting in a big, unnecessary performance overhead that could be easily avoided. The main reason to add a FILE datatype to the spec is to better support new Gen AI workloads with unstructured data. I think not having a `content_type` field would critically impact the user experience for the intended main usecase of FILE. Can we please reconsider adding `content_type`? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
