API: Redesign of Extraction Pipeline Configuration

[net-cscience-raphael]

Problem Statement

The current configuration is quite complex.
In particular, the configuration of the pipeline is very extensive and repetitive.

1. the context contains a list that contains the local setting for each operator.
   • The scheme of the settings is not intuitively clear and relies on proper and up-to-date documentation in the wiki.

"..."
      "decoder": {
        "timeWindowMs": "1000",
        "audio": "true"
      },
      "selector":{
        "contentSources": "decoder"        
      },
"..."

2. the operators themselves, a list of operator descriptions that contain the type and, depending on the type, a field name, factory, exporterName. There are also some operators that contain properties in this list, e.g. enumerator with “mediaTypes”: [“VIDEO”]

"..."
    "decoder": {
      "type": "DECODER", "factory": "ShotBoundaryFFmpegVideoDecoder"    
    },
    "selector": {
      "type": "TRANSFORMER",
      "factory": "MiddleContentAggregator"
    },
"..."

3. the operations represent a graph in which each node has several inputs. The concatenated operators must be defined in operators set, whereby the same operator can occur several times in the graph.

"..."
    "time": {"operator": "time", "inputs": ["source"]},
    "selector": {"operator": "selector", "inputs": ["time"]},
    "thumbnail": {"operator": "thumbnail", "inputs": ["selector"]},
    "clip": {"operator": "clip", "inputs": ["thumbnail"]},
"..."

This results in various sub optimal properties:

• Bad Overview: When editing a specific operator in a pipeline config, you have to scroll up and down to get the necessary information.
• Redundancy: Since field name operator name and node name are often used concurrently, such as ocr or whisperasr, this name appears redundantly 7 times in the configurations.

Future Improvement Goal

(Feel free to suggest further goals or adjustments.)
The aim of the simplification must be to enable the advanced user to get started quickly with vitrivr-engine.

• A simple linear ingestion pipeline should be configurable in the $< 10"$ range.
• The configuration should be possible without code-insigths.
• For the development, the documentation of the operator configuration should be a guided / enforced process.

Discussion

This issue is intended to be a platform for discussing how the stated goals can be achieved in concrete terms.
Please feel encouraged to add your suggestions as comments. Selected solution approaches will then be added as sub-issues.

[ppanopticon]

Discussion on the ingest API are open. Please add your suggestion, design-goals, issues etc.