Generalized schema.org Extractor
Notes from an Akademy 2020 discussion between Dan, Kai and Volker.
Remove the restriction of the extractor engine and data models to travel documents from kitinerary, as we have two users already wanting to do more with this:
- PBI: extracting schema.org annotations from websites (business information, locations, etc)
- KMail: Order and invoice data extracted from business email
Split what is now kitinerary into 3+ parts:
- a generic core library containing basic types, JSON-LD de/serialization and the extractor engine
- a domain-specific library with the travel data types, and travel-specific extensions for the extractor (pkpass, vdv, uic918.3, iata, etc)
- a domain-specific library for the order/invoice data model
- additional domain-specific libraries can be added for whatever else PBI needs and isn't covered yet
The idea is to do this in-place in the current repo for now, as we lack a proper name for the generalized library yet. Possibly aim for the core part to become a low/medium tier framework.
We will need to add extension points for the domain-specific extensions in the following places:
- the JSON-LD import filter, probably some kind of @type to function registration, and a @type to @type mapping
- the JSON-LD deserializer, a simple type registering mechanism should cover this
- the extractor engine. Idea: remove the hardcoded types in there and make this generic on mimetypes, and allow to register additional extractor functions by mimetype. While at it, consider making the interface async.
- the JS API for the custom extractors: this can probably somewhat follow the API used in QJSEngine to export this
- the post-processor: probably some kind of QMetaObject to function registration mechanism, for filters and for validators
Related to this are attempts to get some of the basic knowledge db features to a low-tier framework.