Closed sauterl closed 5 months ago
Ideally, this also involves an integration test to demonstrate that both, vitrivr-engine's and the current storage layer's type system are properly used.
I don't quite understand what is meant by implementing a field. On the one hand, specialized analyzers may be developed for specific metadata sources such as exif. These would then have a corresponding field in the schema with parameters etc. How should I imagine an implementation that seperates this such that the struct descriptor itself is testable? If no one has any thoughts on this, I would make a dummy analyzer that is specific to the integration test and has hard coded metadata values.
Fair enough, I guess there are two approaches to take:
Either an exposed "data container analyser", which is backed by the to-introduce metadata descriptor or specifc analysers which extract industry standard metadata, such as EXIF (#60 ), which are backed by the to-introduce metadata descriptor.
In the second approach, in order for an integration test, indeed there would have to exist a dummy analyser.
Thoughts @ppanopticon @lucaro ?
I'm not sure I fully comprehend the difference between the two options you suggest.
@lucaro upon reflecting the options I have to correct myself.
Part of this issue therefore is the implementation of a configurable, typed map descriptor (in database-y terms: a table with configurable columns), as already described above.
This is the logical foundation for any industry standard metadata feature, capabable of extracting such metadata.
Retrieval, however, is facilitated by the existing means for StructDescriptor
s on the storage layer.
Maybe we can discuss this offline in one of the upcoming meetings.
Done!
Following the highly configurable approach of vitrivr-engine, a metadata
Descriptor
, should incorporate the following:StructDescriptor
StructDescriptor
(boolean) search methodsCulmination of #41