Complete provenance model and modelling example
The provenance model is built using common PROV patterns and the Distributed Provenance Model detailed in the "Workflow Provenance" Wiki section. The idea is to use the provenance model as the backbone of the entire datamodel. Although this model represents all steps of the workflow and all entities with PROV classes and properties unspecific to literary works, we do not need a completely separate model to represent, for instance, author, title, publication date for literary works. We can use a Multiple Generalization pattern to add domain-specific additional superclasses such as frbr:Work to each subclass of prov:Entity in the model, and then add the respective frbr (or LRMoo) properties. For an example from the PROV docs see here and here; and for background see this video. Since provenance is represented on three levels, we have to find suitable domain-specific classes to describe works on different levels of granularity (Datasets, WorkRecord and EnrichmentRecord).
We previously discussed modeling data provenance with a property specialization pattern using rdfs:subPropertyOf (see "Provenance model" Wiki section). This pattern is not shown in the model. Instead, a standard n-ary relation pattern is used to represent data provenance by qualifying sources for enriched data. In PROV, n-ary relations are modelled using the Qualification Pattern, which is detailed here and consists of a prov:PrimarySource class and relations qualifiedPrimarySource and hadPrimarySource. To make querying straightforward and ensure that provenance is returned by default without requiring a specific provenance query from the user, we could consider combining this pattern with the subproperty specialization pattern and see if we can infer a suitable subproperty (f.e. to distinguish assumed, self-identified gender, as well as geographic location based on language of the text and location based on birth place of author) from the n-ary relation. Alternatively we could solve this issue when we implement the web app by modifying incoming queries and injecting the provenance query into the user query.
The Stubs Metapattern Krisnadhi/Hitzler 2017 is used to indicate that some classes are not modelled in detail at this point, but will be modelled properly later on (the grey boxes around classes).
Example:
Note that instead of modeling both GND and GeoNames as primary sources for GeoRecord, we could also differentiate between the source of the geodata and the strategy used to obtain geocodes by adding a new entity of type prov:Plan to represent the strategy used to assign geolabels to literary works.
